Anyone with a background in IT has at some point reflected on the massive monolith that powers their business. They’ve seen it morph into a clear dichotomy of success and failure all in one. In one breath it is referred to as too important to fail, to touch and fix, yet in the next breath it is the bane to growth, it constricts innovation, and is a hindrance to true business agility. So how do we break this pattern and stop every new feature from having a negative impact on cost, complexity and reliability? If you’re going to improve business agility, open the door to innovation and become Ready by Design, you need to address the monolith.

Microservices should solve all our problems, right? I wish that were true, but a more measured response is that if done right they can bring reliability and resilience to your environment. If done poorly they can greatly increase development and support costs and the complexity of your systems. Here we will discuss three key cultural aspects of microservices that must be considered when architecting complex business solutions.

1. Embrace a product mindset - A microservice is not an API. It is not a SOAP, COM or REST call with parameters that returns some expected value. It may contain those components (well hopefully not the legacy ones) but should be molded in the vision of a true software product. It is built to service a business domain, powered by a dedicated product team and has a well thought out business value case and contract with consumers. The contracts define expectations of interactions, adhere to SLAs, RPOs, RTOs and all the key elements of site reliability engineering. They ensure that we can change anything under the covers, if those contracts remain valid (though as with most products they can evolve under agreed timelines), without impacting consumers of the service.
2. Empower product teams – One of the reasons monoliths come about is the lack of product team empowerment. In the old days you might have shared service teams managing databases, servers, networks, testing, deployment, etc... which meant the product team was opening tickets every time they needed something done and then waiting. This would lead to unrelated line of business apps being cobbled together to reduce the overhead of each new product. When we talk of agility achieved from Azure, we are referring to empowered teams. They’re guided best practices, by a core center of excellence enabled with end-to-end DevOps practices, mature CI/CD pipelines, and they have access to the services they need.
3. Adopt a domain driven design approach - There is a great adage, Conway’s Law, which states that software will mirror an organization’s communication structure. We want to avoid this when developing microservices and instead design systems around business domains. To achieve this, you don’t want to start the conversation around requirements with your stakeholder because you end up with a “beautiful” spreadsheet of all high and very high priority items that will mirror their organizational structure yet provide no true product vision. Instead we recommend the approach of event storming, a methodology we are in love with, as it does not ask what you want in the software but instead what your business and users expect. Done correctly it can lead to innovative approaches to breaking down monoliths, and innovation in creating new dynamic solutions.

I have not even touched on the technology decisions that come with building microservices, but in comparison to cultural change that is a much easier topic to tackle. The future state target is a living system created by empowered product teams, who can confidently make changes in a reliable and agile fashion, where contracts and dependencies are well understood and maintained.

There is a path to breaking down monoliths and we can help you on that journey with our cloud and application services.