Lessons learned: Why you should use Microservices Architecture for your applications
Bas de Wit
Read more by Bas de Wit
Defining Microservices Architecture
First, we should define what a Microservices Architecture is, and what it means for the wider perspective. Breaking this down into different parts makes it possible to extract the following definition(s):
Micro – micro refers to small components, but mostly to small components that are isolated from other components.
Service – each component should represent a business service, focus only on that, do nothing else, and do it well!
Architecture – combination and orchestration of a number of components (Microservices) to create a larger, combined fully-functional application.
In other words, a Microservices Architecture is:
A suite of small, contained business services that are orchestrated to provide a business application.
Why choose Microservices Architecture?
Now that we have established a definition, it’s time to ask the obvious questions: “Why should you consider using a Microservice Architecture?” and “What are the benefits when compared to more traditional application Architectures?” In order to answer these questions for you, I will give you five reasons why we at INFO prefer a Microservice Architecture.
1. Simpler, smaller services
A simple – and frankly, quite obvious – answer lies within the definition itself. A small service with a single focus is easier to understand and therefore maintain. The business’ complexity should be kept within a single domain (or even smaller). The exact boundaries are not set in stone but should be set and kept nevertheless so that there is no dilution of the business reason for a single Microservice.
2. Many small services
When we have a number of small components in an architecture that has to work together to expose a complete business application, we have to keep a sharp eye on the interactions between these parts. This is where the complexity of a single big application manifests itself, even if we can’t see it. This complexity has to be designed and maintained with the same rigor and passion as the individual services. Another benefit of these small services is that we can easily scale them individually, making it possible for the backing servers to be used more effectively.
3. Many hands make light work
Less obvious maybe, are the benefits gained by making sure we have small individual services. A benefit of a small service is that it, when created correctly, can be horizontally scaled; where we run multiple instances of the same services that share the load. When we make full use of orchestration platforms, we can even have services scale up and down automatically when the demand for the service changes.
4. Single team with one focus
“The organizational structure reflects the type of applications you create” is a mantra repeated throughout the industry and one we at INFO take to heart. We make sure we have multi-disciplinary teams that can fully focus on delivering the business logic to the Microservices that deliver the application.
5. Reduced time to market
Furthermore, as the business demand changes, the changes to a single service can be rolled out without affecting the application as a whole; the well-known concept of continuous deployment. This vastly improves the time to market on new features.
INFO’s experiences with Microservices Architecture
At INFO, we use a Microservices Architecture as it has proven itself to be the best way for us to deliver the requested features in a consistent and progressive manner.
Even though it has many benefits, Microservices Architecture has its challenges as well, and those have taught us some important lessons.
Defining the correct boundaries of the business services, and guarding against scope creep, is a continuous cycle of validations that a team has to go through. The forces pulling on a team to deliver features fast can cause friction with the definition of the scope of a Microservice. In addition, when the choice is made to expand a Microservice, it can occur that the micro becomes a monolith and the short-term gains turn into long-run costs real quick.
And a single team focusing on the development of Microservice applications and the environment they operate in – as opposed to a more siloed, traditional approach where development and operational tasks are the responsibilities of two different teams – requires a much broader knowledge of the team. The best way is to embed an operations member in the team: the DevOps engineer. By using this knowledge on how the team operates, we ensure that the Microservice will integrate smoothly within the application suite.
Theory vs practice
As a norm, we use Docker to contain each Microservice, as this is the de facto standard within the industry and there are numerous Docker images that can be used as a basis for a service to operate on.
We make use of Docker orchestration platforms: Kubernetes, Mesos/Marathon, and AWS, as those, provide the benefit of rolling deploys, scaling of individual services, and a monitoring and logging connectivity that is required for operational purposes. If the situation calls for it, we can also use the Serverless Architecture of the cloud.
Our multi-disciplinary development and operation teams have extensive experience with Microservices Architectures and are happy to talk to you about it in more detail.
What we at INFO have learned over the years of building Microservice Architectures, is that their benefits can be substantial when compared to more traditional architectures. To get the most out of Microservices, we make sure we focus on the areas where we can make the biggest difference; setting up a multi-disciplinary client team to maintain the Microservices, making the services small and manageable, ensuring team focus when it comes to time to market, setting up the orchestration, and ensuring scalability.
There are many blogs, books, and tweets about Microservices Architecture, but these are some that we like:
The best stories about innovation?
Sign up for our newsletter!
Please leave your name and email below