In September 2016 I will do the closing keynote for SwanseaCon in Swansea, Wales. Although my talk will evaluate agile after twenty years, InfoQ interviewed me preceeding the conference on one of my other favorite topis, microservices. Here’s the answers to InfoQ’s questions.
InfoQ: What are the biggest problems that organizations have with monolithic software products?
Monolithical systems, written in any language, running on any platform, tend to grow over time. This means that many different people have worked on it, each have written code in their own style. Features have been added, modified and removed along the years of existence of the system, quite often resulting in a less stable architecture. Moreover, systems don’t run in isolation, but are often integrated into a much wider systems landscape, resulting in an abundance of external interfaces.
Therefore, many organizations are facing long time-to-markets for new features, due to the inability to incorporate new features. Innovation slows down, and often it becomes hard or even impossible to embrace new technology.
InfoQ: How do microservices provide a solution to these problems?
The basic idea of a microservices architecture is to break down large systems into much smaller components, and thus organization try to regain control over the architecture of their systems landscape. These components then communicate through easy-to-use protocols, such as REST and JSON over HTTP. Although the preposition “micro” seems to imply that the size of these components is measured in lines of code or number of service end-points, I prefer to break systems down using the bounded context pattern from the domain driven design paradigm, where components each handle a isolated part of the systems domain.
InfoQ: How can you use microservices to build Minimum Viable Products?
Thinking in minimal viable products means continuously focusing on adding value to the product by implementing the most minimalistic version that offers that value. Microservices allow organizations to add individual features by continuously extending a single or a set of components, and deploying these (individually) into the systems landscape. Once continuous delivery is set up accordingly, deploying a new version of altered components can be done for instance on a daily basis, of course with automatic testing in place. This allows organizations to implement small changes continuously.
InfoQ: Which approach can be used to test microservices?
When you split up your systems landscape into small components, testing is required at a lot of different levels. First of all, inside your components unit tests will likely cover the component’s internals. Next, the service interface needs to be tested whether it produces the right output or document, such as JSON objects or PDF’s. Next applications or other components consuming services offered by components need to test whether these components still offer the right output. As the services in a microservices architecture are loosely coupled, usually via REST and JSON over HTTP, a change to a service interface is not always picked up immediately by the teams. Having automated tests run at every change of a component, the pipeline signals breaking changes as fast as possible. As the number of tests expands quickly with the number of components and services growing, in a microservices architecture, I recommend to test everything automatically.
InfoQ: How do microservices fit into continuous delivery?
With continuous delivery every change is a potential candidate for release. In a microservices architecture this means that continuously new versions of a single or a couple of components might be released into the landscape. As these components are released into a distributed system or collaborating services, having well-designed deployment pipelines with automatic testing integrated, is even more important than with continuous delivery on a monolith. You might say that in theory continuous delivery and microservices go very well together. In my experience, organizations are facing a multitude of configurations, rather than only a few, not always making things easier.
InfoQ: What are the advantages and disadvantages of microservices?
Moving towards a microservices architecture can help organizations to break down large systems into smaller components, and thus regain control over the architecture of their systems landscape. These individual components are then easier to manage, replace, deploy, extend and test. Embracing new technology, such as new languages, frameworks or databases, becomes easier too, as it can be used first in a few components, instead of having to force it onto the hole systems landscape at once. However, moving towards microservices also comes with consequences. There is a big increase in communication between these small components. In fact, organizations have to realize that moving towards microservices means moving towards distributed systems, with all the benefits, but also with all the drawbacks of distributed systems as well, including having to deal with latency, authorization and authentication and messages that do not arrive.
InfoQ: Which advice do you have when organizations want to implement microservices?
Organizations that consider moving to microservices should do this for the right reasons, and not just because it is the biggest hype of the moment. Arguments could for instance include that the current systems are un-maintainable, new technology or platforms need to be incorporated in the systems landscape, or the time-to-market of new features needs to be shortened dramatically. But when you move towards a microservices architecture, please be aware that there is a lot of aspects to take into account. It requires changes to the way you design, build and test software, to the way you set up your deployment pipelines, authorization and authentication, the way teams operate and collaborate – do they build features, or do they own components? – and it even changes the way you interact with your internal and external stakeholders. But most of all, you have to realize that you are moving towards building distributed systems, and that doesn’t make it easier. Sometimes, an alternative is to break down the monoliths using the same design techniques as you would use in microservices, but use them to restructure and modularize you code within the monolith.
The full interview can be read at: https://www.infoq.com/news/2016/09/microservices-distributed-system.