This week, I would like to welcome Chris Richardson from microservices.io to discuss how to champion microservices implementation when building a microservice architecture. Chris is an independent consultant helping enterprises with their microservices implementation strategies.
Magda Kuczkowska (MK): Can you please tell us what microservices are? How can enterprises benefit from them?
Chris Richardson (CR): The microservice architecture is an architectural style that structures the application as a set of loosely coupled services that are organized around business capabilities. In other words, rather than develop a large, complex monolithic application, functionally decompose it to smaller services that are easier to develop, test and deploy.
Today, IT needs to deliver better software faster. To do that they must adopt DevOps, which is a methodology for rapidly, yet reliable, delivering software. The microservice architecture is the application architecture that supports DevOps. It gives the application that deployability and testability that DevOps needs. It also enables application developers to be done by small, autonomous teams. Each team owns one or more services, which they can develop, test and deploy independently. As a result, code committed by developers is typically in production in under an hour and teams deploy into production many times a day.
MK: It seems microservices definitely have a positive impact on enterprises, especially around speed to service. In your consulting engagements, how do you assess the customer readiness for microservices implementation?
CR: The microservice architecture is not a silver bullet. Like every technology, there are downsides, most notably complexity. Consequently, it is important to determine whether an application is a good candidate for the microservice architecture. If it is a small application developed by a small team then it’s probably not appropriate to use the microservice architecture team. However, if it’s a large application developed by a large team then it will likely benefit from the microservice architecture.
It is also important to determine how willing an organization is to embrace DevOps. That’s because, without DevOps, the benefits of microservices are minimal. For example, microservices architecture enables you to deliver software rapidly and safely in small increments. This capability won’t be very useful if your corporate policy is to only deploy into production once a month.
Read also Virtualization, Containerization and DevOps
MK: Sounds very interesting. If I understand you correctly, not every customer might be ready for microservices. For those kinds of customers, what do you typically recommend as a starting point to move towards a microservice architecture?
CR: The key problem you need to solve when using the microservice architecture is how to decompose an application into services. For example, if you have an existing application, you need to develop a plan for incrementally migrating it to the microservice architecture. Many popular technical concerns, such as whether to use containers or some other implementation technology, are secondary. Similarly, there are people and organization issues around adopting DevOps. In other words, you need to solve architecture and people problems. You can’t buy a microservice architecture!
MK: Great! Last question. Based on your experience working with various enterprises on microservices, what are the key indicators which could contribute towards maturity of success microservices implementation?
CR: It’s critical that the business supports the effort to migrate to a microservice architecture. After all, it consumes resources that would otherwise be spent doing feature development. There are a couple of strategies that can be useful:
- Adopt the microservice architecture to solve a critical business problem that cannot be solved using your existing monolithic architecture.
- Demonstrate the value of the microservice architecture early and often. For example, implement a new feature as one or more services rather than making the monolith large. It should be clear that the development velocity of the team working on enhancing those services much higher than if they were working on the monolith.
MK: Thank you so much Chris for spending time with us. I am sure our readers will find this interview beneficial and would love to engage with you for further discussions. We are looking forward to work with you and help organizations with microservices journey.