This blog post captures some of the lessons learned from my experience at ThoughtWorks helping clients move from monolithic applications to microservices. That said, I won’t be focusing on the technical details of writing microservices, but mostly on how to break down the monolith in order to build independent and high performing teams. Moreover, I will also cover some pitfalls you may run into while transitioning towards microservices.
One of the promises of building microservices is to increase code ownership and quality by breaking the monolith into small and cohesive units of code. This is mostly the result of identifying the bounded contexts under which each team will operate. To give you an idea of what a bounded context is, I will recall this definition: “a specific responsibility enforced by explicit boundaries.” For instance, in Retail, it could be Product Catalog, Loyalty Program, Checkout, …
In order to identify the bounded contexts within your application, it’s recommended to apply Domain Driven Design principles. Thankfully, Eric J. Evans has done a fantastic job describing them in his book “Domain Driven Design” and showing how to use them to achieve higher isolation in complex systems. To get started with domain modeling, I recommend reading Martin Fowler blog entry, which can be found here.
Now that you have a glimpse of how to break the monolith from a technical standpoint, let’s focus on some of the traps you may fall into while transitioning towards microservices architecture.
While microservice architecture promises faster delivery, higher ownership, and cohesive components, it also comes with a higher operational workload and organizational change. That being said, people adopting this architecture style should be conscious of some of the faux pas that fall under the following groups:
In the first part of this article, I will focus on team structure and introduce some techniques to guide you through your journey.
One of the challenges that come with microservices is restructuring IT teams to achieve a continuous flow of added value, which requires frequent deployments to production (ideally multiple times a day). In fact, in layered organizations where dev teams hand over the artifact to be deployed to QA and Release management teams, the cycle time to production is often bigger compared to cross-functional teams.
During my years of experience, I have witnessed cross-functional teams achieving greater results by owning the whole process from writing code to deploying to production. Moreover, they showed higher ownership especially when agile techniques like pair-programming and automated testing are embraced by the team.
It comes as no surprise that structural changes are often hard to implement. For this reason, it’s wise to run a pilot to determine the challenges you may face before applying the transformation across the whole organization.
Moreover, I strongly recommend defining your assumptions and your KPIs (Key Performance Indicators) before undertaking such effort. In fact, collecting quantitative data before and after each experiment is crucial to make informed decisions. It also helps you establish a data-driven culture within your company.
Back to our example, your first hypothesis could be: “By forming cross-functional teams, we will be able to roll-out new features faster.” To be able to validate this assumption, we need to measure how long it takes to build and deploy an artifact to production. To achieve this goal, we will use Value Stream Mapping. In fact, Value Stream Mapping is a lean technique to analyze processes and help improve them.
As depicted in the flowchart above, most of the cycle time is spent waiting for the QA and Release teams to perform their tasks. But, a deep analysis of the situation shows that the big effort is spent on the following activities:
Debrief & Context switching
Internal processes (Filing change requests, QA Reports, …)
Let’s imagine now that the team has all the capabilities to own the process end-to-end. After running an experiment with its respective Value Stream Mapping flowchart, we should be able to make an informed decision to confirm or reject our initial assumptions (At ThoughtWorks, We have already validated this hypothesis at multiple clients, but I would love to hear about your personal experience). To conclude, the method I showed here is based on the 4 following steps:
Finally, in this first part, I tried to demonstrate that implementing microservices inherently requires organizational changes to build high performing teams. I also explained a data-driven approach to help teams make informed decisions. In the next part, I will talk about some pitfalls you may run into while transitioning towards microservices.
