03 - 04 November 2016
M Shed, Bristol, UK

How to break apart a monolithic system safely without destroying your team

Matthew Skelton Skelton Thatcher Consulting

Session type: Experience Report
Session duration: 60 minutes

Slides from session

The slides used for this session are available to download from here.

About this Experience Report

Many people have observed that microservices will not fix a broken software architecture, and 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).

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, like Sam Newman in the book 'Building Microservices', we must consider aspects other than pure code if we are to make the new system responsive to business demands. In particular, it is useful to look for 'fracture lines' in the monolith that correspond to a set of natural pressures:

  • product boundaries (probably the bounded context)
  • regulatory (eg PCI-DSS, ISO 27001)
  • change cadences (daily, weekly etc)
  • any need for subsytem isolation (reporting, performance etc)
  • different kinds of users/personas for different subsystems
  • the number of people working on an area - limit to 7-9 people in a team

Taking a team-first approach, we especially need to be mindful that an effective software team has, at most, around 7-9 people, thereby limiting fundamentally the size of software that team can collectively comprehend and own. Choose a too-large size, and the 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.

Furthermore, with Conway's Law ready to shape our software based on 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 contexts that do not naturally communicate (much). Contexts that communicate are likely to merge together if the same team develops them.

Finally, we need to address some very real dangers of moving away from a monolith, like:

  • reduced domain consistency (UX, architecture, data)
  • data duplication
  • additional operational complexity due to distributed system
  • degraded UX across the product

Fortunately, modern logging and metrics tooling can help us to 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.

The insights are informed by our work on the DevOps Team Topologies and shaped by work with a variety of organisations including a global publishing organisation, software vendors with blue-chip clients, a global technology company specialising in telecoms, several organisations in the financial services sector in the UK, an international commodities trading organisation and a major UK broadcaster.

Participants will learn some team-first heuristics to use when decomposing large or monolithic software into smaller pieces. These rules of thumb have been tested in the real world with teams and organisations around the world and with different kinds of software systems.

About the Speaker

Matthew Skelton has been building, deploying and operating commercial software systems since 1998. Co-founder and principal consultant at Skelton Thatcher Consulting, he specialises in helping organisations to adopt and sustain good practices for building and operating software systems: continuous delivery, DevOps, aspects of ITIL (information technology infrastructure library) and software operability.

Matthew curates the well-known DevOps team topologies patterns at devopstopologies.com and is co-author of the books 'Database Lifecycle Management' (Redgate) and 'Continuous Delivery with Windows and .NET' (O’Reilly).


To buy tickets to see this fantastic talk, and many others like it head over to our ticket page.