Microservice architecture is becoming more and more popular. Hearing so much about it, have you wondered is this the only right direction? Let’s take a look at microservices’ characteristics, their advantages and disadvantages, and consider in which scenarios they’ll work better than a monolithic architecture.
Table of contents
Microservice architecture – definition and major idea behind it
“Microservices” is the term used to describe an application’s architecture, the way it’s built. Unlike monolithic architecture – in which application elements function within a single system – microservices divide them into smaller, independent components. Microservices are, therefore, separate parts of the same application, allowing developers to work on specific areas without interfering with the whole system.
The main characteristic of microservices
They are atomic, which means every service is well-defined, autonomous, and doesn’t depend on others’ contexts or states. Each microservice can be created, deployed and maintained separately without affecting the rest of the system. These isolated elements communicate with each other via APIs.
Dedicated to one business logic. It’s a good practice to have one microservice per one problem. A single logic shouldn’t be spread over several services.
Assigned to separate teams. Since one microservice holds one business logic, it’s good if each of them is maintained and developed by a specific DevOps team. With a microservice architecture, you replace the ownership product model with a project model. A team is not responsible for delivery on a single stage but for a whole service lifecycle, even if on production.
Having separate repositories. Each microservice should have a separate repository, as they shouldn’t share source code.
Decentralised. As a system with a microservice architecture may consist of different technologies (programming languages, frameworks, operating systems), it’s not advisable to have a centralised governance structure. Unlike monolithic apps with a single database, in a microservice architecture, every service has its own database. So they should be in a distributed architecture as well.
Failure resistant. Microservice architecture is designed to cope with failures. When one service fails, others continue to operate uninterrupted.
Be up to date with cloud updates and connect with other GCP users
Microservices in light of DevOps and agile development
The emergence of microservice architecture is linked to the spread of DevOps ideology.
DevOps is not only a cluster of the Development and Operations words; it’s a set of best practices, principles and processes to make an organisation more agile, speed up application development, and increase stability and scalability. Google, having the philosophy firmly embedded in its structures, outlined five objectives of DevOps:
- Silos reduction. Google believes businesses can increase and foster collaboration by breaking down team barriers.
- Acceptance failure as normal. They say computers are inherently unreliable, so leaders can’t expect perfect execution.
- Gradual changes. Small incremental changes are easier to review. And if a gradual change does release a bug in production, it allows teams to reduce their time to recover, making it simple to roll back.
- Leverage of tooling and automation. Identifying manual work that can be automated is key to working efficiently and focusing on the tasks that matter.
- Constant monitoring and measurement. Measurement is a critical gauge for success. There’s no way to tell whether your actions are successful if you have no way to measure them.
How do microservices relate to these DevOps principles? The premise of both is to increase the speed of development while maintaining application stability.
The main idea behind microservices is that each service is an isolated component with a separate team. This translates into the fact that if you want to make a change, you don’t have to update the entire application – just the microservice. That leads to increased agility when it comes to application development. The microservice architecture also allows a quick rollback in case of error identification.
Increased agility is also the result of closer collaboration between software engineers and infrastructure administrators (Dev + Ops). Reduced silos and improved communication enable the implementation of changes in an application faster, increasing the frequency from a few per month to even hundreds per day.
The rapid adoption of agile methods has also contributed to the development of another concept that is supported by a microservice-based development cycle – CI/CD (Continuous Integration, Continuous Delivery). CI/CD endorses the process of implementing changes more efficiently, i.a., thanks to automation. Thereby it increases the speed of product development.
Microservice vs monolithic architecture
Microservice architecture is decentralised, while a monolith is one large unit. In a monolith application, a change in one area requires the deployment of the whole system; troubleshooting is also tricky, as the error can be located anywhere. This slows down development and also increases the likelihood of failure. Scaling may also be problematic, as one functionality needs increased capacity, you must scale up the whole application.
A microservice architecture offers faster development and greater agility compared to a monolith. Deployments can be done more frequently as the system is made up of small components that reduce the need to update the entire application. The process can be further streamlined with CI/CD pipeline. Breaking the system into independent units with their own databases increases fault tolerance because if one service fails, the rest function flawlessly. Tracking and fixing the fault, testing and implementing the improved version are done without affecting the functioning of the rest of the system. Scaling is also more efficient, as individual services can be scaled independently.
So, are microservices undeniably better than monolithic architecture? A microservice architecture may bring many benefits but is much more complicated to maintain. Managing isolated components, APIs, and monitoring them require a lot of work. Implementing microservices also comes with necessary changes to the structure of teams, following the principle that every service should have a dedicated DevOps team.
A architektura monolitu wcale nie jest przestarzała. Każdy przypadek jest inny i w wielu z nich monolit sprawdzi się lepiej niż mikroserwisy. Nie warto pchać się w mikroserwisy tylko dlatego, że to fajna i nowa technologia, że o kontenerach jest głośno i że fajnie byłoby się pobawić Kubernetesem. Mikroserwisy nie są proste i w niektóych przypadkach przyniosą więcej trudności niż rzeczywistych korzyści.
And the monolithic architecture is not obsolete at all. Every case is different; in many, the monolith will perform better than microservices. It’s not worth pushing microservice architecture because there’s a buzz about containers, and it’ll be fun to play with Kubernetes. Microservices are not a piece of cake; in some cases, they would even bring more difficulties than actual benefits.
Advantages and challenges of microservices
Pros of microservices
Agility. As independent units, microservices favour the creation of separate teams. Each team works on a particular section of the system, which can be tested and implemented without affecting the other services. This independence contributes to faster development and the ability to implement changes more efficiently, and test new ideas, as the rollback can be quickly done.
Scalability. Microservices can scale independently. If a function needs to consume more resources, it can be scaled individually instead of scaling the entire system. Every team can estimate the infrastructure requirements of its service, which translates into better planning and budget management. This also dovetails nicely with the flexibility of the cloud.
Durability. Applications in a microservice architecture are more fault-tolerant than monolithic ones. In a monolith, a failure of one component can cause the entire system shutdown. In the case of microservices, when one fails, the others function uninterruptedly.
No restriction to one technology. Thanks to the distributed architecture, each service can be built using a different language, framework or library. Since each business logic may require other solutions, teams can choose the appropriate tools. Admittedly, some practitioners advise against mixing technologies within a single application because it can lead to chaos. But it is undoubtedly true that a company doesn’t have to commit to one technology stack and can introduce newer and newer technologies over time.
Cons of microservice architecture
Complexity. Specialists have more work associated with maintenance, as they have to take care of load balancing, minimise latency or ensure the resilience of various components. They must also ensure secure communication between hundreds or thousands of services. Over time, as the application grows, managing it becomes even more complex.
Interfaces control. While making changes to services is relatively straightforward, managing the APIs requires more effort. If a change is made to the API, microservices communicating with each other will struggle if a change is not backwards compatible. And APIs in a system built on a microservice architecture can be a multitude.
Costly implementation. It’s not advisable to plan an application architecture with microservices in mind. But if you’d like to go from a monolith to microservices, separating chunks of code, creating APIs, or refactoring will require a lot of work.
Microservices: where to start?
As mentioned, you probably shouldn’t build an application in a microservice architecture from scratch; instead, you’d rather start with a good old monolith.
When developing a monolithic application, divide it into modules and ensure that they meet the tenets of microservices – i.a., that each service is atomic, responsible for one business logic, and with a dedicated team. You’ll have dummy microservices but within a monolithic architecture.
And if everything works, there’s no need to change a single thing. But if, after a while, you find that a module is failing – e.g., its performance has dropped – you can take it out of the monolith and transform it into an independent microservice that will communicate with the rest of the system by an external API. If the scenario repeats for another module, you can separate it as well. Bear in mind that if not needed, there’s no point in creating too many microservices as their maintenance is much more complex than a monolith.
Google Cloud Platform services for microservice architecture
Microservices architecture works well in a cloud, as it provides flexibility, the convenience of scaling, and supports agile application development, also with CI/CD leverage.
Google Cloud Platform offers the following services to manage microservices in the cloud better:
- Google Kubernetes Engine – a secured and managed Kubernetes service with four-way autoscaling and multi-cluster support,
- Cloud Run – a serverless platform for deploying and scaling containerised applications quickly and securely,
- Cloud Build – a continuous integration, delivery and deployment platform for running fast, consistent and reliable automated builds,
- Cloud SQL – a fully managed relational database service for MySQL, PostgreSQL, and SQL Server,
- Anthos – a service dedicated to application modernisation and building cloud-native apps anywhere to promote agility and cost savings.
Would you like to take advantage of the microservice architecture in the cloud? Use the knowledge and experience of a certified Google Cloud partner.
Download a free ebook and learn how to secure your cloud infrastructure from the ground up
