Patrick Debois had a quick tweet last week that cut to the core of a huge shift we've been undergoing for the past few years:
Serverless are like Libraries : dependencies - Can’t wait to see the Maven equivalent of that :D
— patrickdebois (@patrickdebois) October 20, 2017
While Serverless is at an extreme end of the spectrum I think we are seeing similar things cropping up in the microservices space with Docker seeing things like Helm charts and Compose configurations. The best practice is not changing. Carve up your code into libraries that call one another. Try to make the APIs stable to make reuse not a nightmare and limit how much of the inner workings of each piece a given developer must know.
All that is changing is that our use of libraries is shifting from compile-time relationships to run-time relationships.
In this runtime dependency world, still need to be managed because they need to be tested together. Few developers will take a new version of a library into their build and deploy to production without testing. We don't trust version to version compatibility in libraries that much. However, we are in a time where the "12 Factor App" crowd demand high enough version to version fidelity that you can update a single library (microservice), test it in isolation and then move it to production. It will be fascinating to watch this play out as we may finally do "libraries" well enough that we trust them completely. I think for most teams this won't be the reality and we will continue to need "the Maven equivalent." The expression of either a dependency graph or a simple bag of co-dependent stuff that needs to be tested together to be released.
Will runtime dependencies care about cyclic dependencies? I have no idea. Keeping a non-cyclic dependencies graph is key to clean builds. With the need to link gone and the legitimacy of multiple versions of a service running concurrently, are cyclic dependencies something we have bought with the move to runtime?