Christensen believes the reason for these mistakes occuring so often is ease; we know how to use shared libraries and we too often optimize for the short-term since it feels more productive. He notes though that delaying the cost of decoupling is very high and that we already know the solution, it takes a bit of extra thought and effort to put the tools in place from the beginning but when they are in place they are straightforward to use. He therefore recommends looking beyond the short-term ease, avoiding binary coupling and instead leveraging contracts and protocols to get the benefits of the microservices architecture.
During the Q&A after his talk he emphasized that he thinks it’s OK to use even a large framework as long as it’s used inside a self-contained service, but not if the architecture of the whole system adopts this large framework because that leads to long-term coupling.
Spotify may emphasise the autonomy of their teams, but they have a shared operations team to facilitate more efficient code production, a matrix organisation to manage cross-team collaboration and an architecture team to look after a longer-term technology roadmap.
Bookmarks on this page are managed by an admin user. 