Moving towards microservices means moving towards distributed systems where you have to deal with latency, authorization and authentication, and messages that do not arrive, argues Sander Hoogendoorn, an independent software craftsman. With microservices you can break down large systems into smaller components to regain control over the architecture. You can implement small changes and add individual features with microservices by extending a single or set of components and deploying them.
Hoogendoorn will give the closing keynote at SwanseaCon 2016, the second agile development and software craftsmanship conference in South Wales, to be held September 12-13, and will talk about microservices at the Agile and Software Architecture Symposium 2016 on September 28. InfoQ interviewed him about problems with monolithic software products, using microservices to build minimum viable products, testing microservices, how microservices fit into continuous delivery, advantages and disadvantages of microservices, and advice he would give to organizations who want to implement microservices.
Several more people wrote about how to use microservices and test them, how microservices come with the additional complexity of creating a distributed system, and provided ideas for implementing microservices in organizations.
InfoQ: What are the biggest problems that organizations have with monolithic software products?
Sander Hoogendoorn: Monolithical systems, written in any language, running on any platform, tend to grow over time. This means that many different people have worked on them, 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?
Hoogendoorn: The basic idea of a microservices architecture is to break down large systems into much smaller components, and thus organizations 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.
In the InfoQ article on microservices anti-patterns, Vijay Alagarasan explains how microservices and service oriented architecture (SOA) are related:
If you do not have the right people, culture, and investment, SOA will not deliver the business value. Microservices architecture is not fundamentally different from SOA; the goals and objectives are the same but the approach is slightly refined and in fact, I would simply say that Microservices is mere SOA made scalable.
InfoQ: How can you use microservices to build Minimum Viable Products?
Hoogendoorn: 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?
Hoogendoorn: 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.
In an interview about developing and testing microservices, Jose Lima from Redgate software suggests that with microservices you don’t need to automate all tests and that checking can be done by people other than testers:
Some people will say that test automation is also a required skill although I don’t agree. First of all I don’t believe in test automation; second of all, check automation can also be performed by other members of the team, not exclusively testers. There’s no such thing as test automation, but there certainly is check automation – to me testing is a lot more than just checking, and the checking process can be automated, but only after you have studied and learned what something is doing and what is meant to be doing you can put a check in place (automated or not) to check that something is performing as it should.
InfoQ: How do microservices fit into continuous delivery?
Hoogendoorn: 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.
If you want to start with microservices, continuous deployment and automated testing are a a necessity, argues Alagarasan:
Continuous deployment, if you have not done so, is a must investment and a cultural change that every enterprise should aim for. At least, if you don’t have a way to automatically test and deploy – do not do micro-services. Microservices are aiming to drive agility, with the speed we need to change; quality assurance involves each service having automated unit, functional, security and performance testing.
InfoQ: What are the advantages and disadvantages of microservices?
Hoogendoorn: 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.
In the InfoQ article Microservices: Decomposing applications for deployability and scalability, Chris Richardson confirms that implementing microservices implies creating a distributed system:
Developers must deal with the additional complexity of creating a distributed system. Developers must implement an inter-process communication mechanism. Implementing use cases that span multiple services without using distributed transactions is difficult. IDEs and other development tools are focused on building monolithic applications and don’t provide explicit support for developing distributed applications. Writing automated tests that involve multiple services is challenging. These are all issues that you don’t have to deal with in a monolithic architecture.
InfoQ: What advice can you give to organizations who want to implement microservices?
Hoogendoorn: Organizations who 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.
Alagarasan suggest to partner with executives and senior leaders to enable the culture change that’s needed to implement microservices:
The goal of microservices is to solve the three most common problems i.e. improve customer experience, highly agile to the new requirements and drive down cost by delivering the business functions as fine grained services. This is not a silver bullet and requires a disciplined platform, where delivering the services in an agile fashion with high quality is possible. (...) This is the first baby step before we can even talk about containerization, cloud adoption etc. (...) Most of the items will drive cultural changes within the organization and cannot be done just by yourself, ensure partnership with your executive and senior leaders.
