Back in 2004, the wisdom was to build monolithic Java applications. However, skilled teams are increasingly finding that small, loosely-coupled services provide a good degree of isolation between system contexts in the face of rapid change, and this flexibility to mutate the system by regular isolated deployments seems to match a very human cognitive timeframe (hours or days between changes rather than weeks or months).
But how do we set about safely decomposing a monolithic (or just large) component into smaller, decoupled bits? There are several technical practices to help at a lower level, especially those articulated by Michael Feathers in his classic book Working Effectively with Legacy Code. However, as Sam Newman argues in Building Microservices, we must consider aspects other than pure code if we are to make the new system responsive to business demands, including the nature and composition of the software team itself.
An effective software team has at most around nine people, thereby fundamentally limiting the size of software that team can collectively comprehend and “own.” A larger team struggles to work with the domain; split the work across more than one team and “rot” can quickly set in as teams lose a sense of ownership over the code. Since according to Conway’s law, our software takes the shape of underlying team communication patterns, we need to ensure that teams have “just the right amount” of communication between them, reflecting the natural communication needed between components or contexts. This means that a product team can take on more than one bounded context but only such contexts that do not naturally communicate (much). Contexts that communicate are likely to merge together if the same team develops them.
Drawing on insights informed by his work on the DevOps Team Topologies and with a variety of organizations including a global publishing organization, software vendors with blue-chip clients, a global technology company specializing in telecoms, several organizations in the financial services sector in the UK, an international commodities trading organization, and a major UK broadcaster, Matthew Skelton explains how to infer some useful heuristics for evolving from a monolithic architecture to a set of more loosely coupled services by starting with the needs of the team. Matthew addresses some very real dangers of moving away from a monolith, including reduced domain consistency (UX, architecture, and data), data duplication, additional operational complexity due to distributed system, and degraded UX across the product and explains how modern logging and metrics tooling can help instrument the monolith before (or during) the decomposition into smaller services, helping us to understand how it really works and providing a valuable source of validation for the new services.
Matthew Skelton is a cofounder and principal consultant at Skelton Thatcher Consulting, where he specializes in helping organizations adopt and sustain good practices for building and operating software systems, such as continuous delivery, DevOps, aspects of ITIL, and software operability. Matthew has been building, deploying, and operating commercial software systems since 1998. He curates the well-known DevOps Team Topologies Patterns and is coauthor of Database Lifecycle Management (Redgate) and Continuous Delivery with Windows and .NET (O’Reilly).
Comments on this page are now closed.
©2016, O’Reilly UK Ltd • (800) 889-8969 or (707) 827-7019 • Monday-Friday 7:30am-5pm PT • All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners. • firstname.lastname@example.org