In this fast-moving, immature space, expect to spend cycles assessing where the greatest value lies for each team and the business as a whole.
The term “microservices” is popping up everywhere in software development circles. Indeed, microservices are frequently touted as The Next Big Thing in terms of how to write applications to avoid the problems of complex, monolithic architectures.
From a Devops perspective, the microservices discussion is usually related to Docker or other containers. Both share an emphasis on lightweight individual units that can be managed independently, so containers are often regarded as a natural implementation choice for a microservice architecture. But what are microservices actually?
Microservices constitute a software architectural style that approaches a single application as a suite of small services, each running its own process and communicating with lightweight mechanisms, such as an HTTP-based API. The services are small, highly decoupled and focus on providing a single “useful” business capability. Typically, microservices involve very little centralized management, may be written in different programming languages, and use different data storage technologies.
A good way to understand the microservice style is to compare it to the monolithic style, in which an application is built as a single unit. A classic example of this approach is the “standard” three-tier enterprise application, consisting of a client-side user interface, a database, and a server-side application. Changes made to monolithic applications can be both painful and costly as any change made to a small part of the application requires the entire monolith to be rebuilt and deployed.
Microservices clearly offer many advantages — notably the ability to make small changes to code quickly and efficiently, and with minimum risk. The services are organized around business capabilities, and they lend themselves to Continuous Delivery.
Some of these advantages include the following:
Small, Easy-to-understand Code
As a microservice app is responsible for only one thing it requires little code, is easy to understand, and involves minimal risks when changes are made.
Easy-to-scale, Easy-to-deploy and Easy-to-discard
Size is important. Microservices technology make it easy for developers to scale, deploy and discard apps and features. In contrast, a single change to a monolithic app requires changing the whole application.
Smaller Teams
It’s much easier and faster to work with a small team than a large one. Each small team can own a microservice and access other services via a high-level API.
Facilitates System Resilience
If a monolith application stops working a lot of functionality will stop working. In contrast, if a microservices app stops working only a small, specific functionality will be lost.
However they are not without their serious challenges, especially relevant from a DevOps perspective — such as coordinating interdependent deployments, fusing developer skills with technologies, and confronting disagreements between developers.
As developers break down monolithic applications and move complexity from within to between applications, obvious challenges come to the fore. Some of these include the following:
Coordinating Interdependent Deployments
Individual microservices are supposed to be independently deployable, but in order to provide any kind of useful functionality from the perspective of the user you typically need to get a whole set of microservices running.
Deploying microservices requires a new generation of tools that can manage a multitude of simple deployments, while tracking and managing their dependencies. These tools need to be able to bring everything together on time to deliver an app without being too rigid, for instance by supporting version ranges for services rather than fixing on individual versions. These tools should help developers to deploy different bundles of services easily, without having to ask an administrator to reconfigure the deployment tool.
Planning and configuration should be done through a single interface with a real-time view of app deployment. Essentially, developers should seek to attain the same balance of speed and efficiency that Continuous Delivery offers.
Microservices Need Skilled Developers and Operators
While there are many potential productivity boosts to separating services, tracking all of the relationships between them is vital. The team needs to know the entire development landscape and be able to test live components together.
Testing isolated services is a simple enough proposition, but testing the entire user-facing business service can be problematical.
Developer Disagreements
There will be a lot of time-consuming debate and friction when developers butt heads about the pros and cons of keeping a monolithic stack versus embracing microservices: which applications to refactor, which to rewrite, which to leave alone, etc.
The worst-case scenario: developers lose sight of the overarching system goals, focus on the service they are working on, refuse to be flexible, and resist being part of an overall team.
Finding the right set of technologies for a microservices implementation will not be a quick or simple task. As this is a fast-moving, immature space, expect to spend a lot of time assessing where the greatest value lies for each team and the business as a whole. Delivering the greatest benefits may mean adopting a hybrid system that draws on and integrates different technologies.
About the Author/Andrew Phillips
Andrew Phillips heads up product management at XebiaLabs. Andrew is an evangelist and thought leader in the DevOps, Cloud and Continuous Delivery space. He sits on the management team and drives product direction, positioning and planning.
