I'm not a developer therefore cannot espouse the technical benefits of microservices. Having founded GuideSmiths, a software development consultancy with many successful microservice implementations, I’m in a reasonable position to explain the business benefits.

Microservices are by no means a panacea to helping major enterprise break free of legacy technology and slow release cycles. They are an integral part of the approach and ensure that when you do commence the digital transformation journey, you do not create a new legacy.

Microservices is an approach to application architecture and development. Code is broken down into small and practical components which typically support a single function.

It isn’t purely about breaking down the code into the smallest possible components, you need experienced developers leading the way who know how to make the services inter-connect and ensure they're correctly sized. It's important to construct your microservices architecture thoughtfully to avoid a complicated new legacy. If you get the balance right, the benefits are clear. I pondered how to explain the ‘before and after’ of a microservices implementation and it made me think of a reference book written by multiple contributors.

Imagine the reference book:

• Is approximately 100 pages in length
• Covers 50 different topics
• There are no chapters
• There is no table of contents or index
• You don’t know who the contributors are
• The book is published as one long uninterrupted page

This leads to the following impacts:

• It’s not easy to read
• It’s difficult to know how far you’ve read
• It’s not easy to locate something you read previously
• You’ll most likely give up on the book
• Adding to the existing book makes the problem grow

Now imagine this book as monolithic code…. it’s one big splat of code down a page and you’re one of the developers looking for where an app is breaking. Unless you’re the person who created the app, it might take you hours/days to find where the code is breaking and your business is subjected to a potentially long and drawn out process to find, test and release a fix. It doesn’t need to be this way, modern development approaches (and technology) allow you to move beyond this.

Now imagine a typically constructed reference book. It has:

• 100 numbered pages
• The contributions decoupled as 50 chapters
• A table of contents or index
• The contributors are all credited

Now, you can:

• Add to or alter the book
• Add new contributors
• Re-construct the book, if desired

Think of microservices in the same way. You’ve created the services to do one job well with the least amount of code required to do so. You can potentially re-apply the service in multiple business contexts. One of the benefits is teams don’t interfere with each other. Their work is decoupled, and so developing and deploying microservices separately provides greater value, since you remove the dependencies and therefore, the risks. Developers new to your stack shouldn’t find it difficult to understand how to pick up and check out small amounts of code when there are bugs or issues and check it back in with minimal fuss.

If you’re struggling with tech and release cycles, I’d encourage you to consider a microservices architecture in conjunction with a continuous integration/deployment platform. If you do choose this path, you should seek the input of someone who has tread the microservices path in an enterprise context and avoid the coaches or theorists. Agile is a mindset, not a product, and microservices can and should be an integral part of the transformation toolset.