In this blog of DevOps consulting series, we look at what microservices architecture is and how the structural style allows for:
We’ll also look at potential mistakes that can be made with a microservices approach and when it may not be the right choice for an application.
Agile & DevOps teams and consultants
Supercharge your next cloud development project!
The term ‘microservices’ refers to a service-oriented structural style to software architecture that splits an application into a collection of loosely-coupled services. Derek Comartin describes microservices as:
“Loosely coupled service-oriented architecture with bounded contexts.”
And Bounded Context, a term from Domain-Driven Design, is defined as:
“If you have to know too much about surrounding services you don’t have a bounded context.”
Microservices involve logically separating pieces of code in a way that they can run independently with as few dependencies on each other as possible. But individual microservices are still able to “talk” to each other and work together to form a complex application from the sum of its microservices.
Separating out chunks of code into self-sufficient microservices means minimising dependencies and the need to coordinate changes being made in one service with others. It also means one service failing will have less of an impact on the functioning of the application as a whole.
Before the rise of microservices, developers tasked with the implementation of support for third-party services via API and various clients tended to use monolithic architecture patterns. It was the most obvious way to implement such applications and helped utilize hardware resources more efficiently.
Fast forward to 2022, and microservices, which support the CI/CD priority of a DevOps approach to web development, are now the preferred approach.
Microservices are often discussed within the context of Containers, Docker, Kubernetes and Serverless architecture. However, it should be clarified that these are all tools and technologies used by backend architects used to physically deploy microservices. Microservices refer to the logical separation of chunks of code into autonomous services. Containers, Docker, Kubernetes and Serverless architecture are tools and approaches to the physical deployment of Microservices.
If you’re planning a new software application of relative size and complexity there is a high chance its backend architecture will be built on microservices.
Relatively recent developments in software and hardware technologies have allowed for an application to be broken down into multiple simultaneous processes and services instead of consisting of a single monolithic architecture. As the architectural approach of designing software as suites of loosely coupled but independently deployable services was developed and gained in popularity, it started to be referred to as microservices architecture.
Note, however, that following а microservices pattern is not a one-size-fits-all approach that should be implemented for any software system. In many of our projects at K&C, we combine microservices with CQRS, event sourcing and DDD patterns when designing the architecture of a new enterprise web application.
While a microservices architecture brings many benefits and cost advantages, one of the most important decisions to make is to decide how far you should go with the componentization of your application. You’ll have many arguments to consider, for instance:
While a microservices architecture offers many advantages, it is far from the case that it is always the right choice for every kind of app. And microservices also leave plenty of room for error when executed poorly. We had a case where a client came to us for help with an app that had been split into dozens of components. When things were going smoothly that granular approach led to strong performance indicators. But the development team maintaining the app were often faced with problems and bugs caused by improper interaction between the microservices.
In this particular case, the app had been overly-zealously broken down into more microservices than it should have been. Breaking down functionalities into too many microservices led to additional time and costs for maintenance, support, and updates instead of the inverse. And a lack of resources to handle those difficulties ultimately impacted on the app’s performance.
1. Once the business logic of the future product has been defined, we prefer to start by breaking the app down into larger components that can later be again split out into more Microservices if advantageous.
2. Smaller parts of the original components that turn out to be critical in terms of performance can be split out as an autonomous service.
3. Proof-of-concept of the architecture proposed for implementation (or at least the most important parts of it) should be prepared and corner cases analysed.
4. We use well-known libraries and frameworks to minimize the costs of updating snapshot versions and dealing with bugs.
5. We stringently test services code and implement integration tests for API checks.
6. We build and use a well-organized continuous integration pipeline with “one-button” deploy and release.
7. We consider using Docker and Kubernetes to orchestrate services.
While such an approach may sound pretty straightforward, our experience shows this is the most cost- and time-efficient development strategy for most enterprise products.
Most of our enterprise clients with large, complex applications where high availability is non-negotiable have a preference for a microservices architecture for the following reasons:
Since failure in one service does not affect other services you can be sure the whole app won’t go down just because of a small bug in the code of one component.
Services providing critical functionality can be easily scaled to more servers (which can even be done on the fly), while monolith apps oblige you to invest time and resources into scaling the entire system at once.
Development can be done in parallel by different developers or teams which allows for adding new people quickly if the development process needs to be accelerated.
While Microservices architecture requires DevOps expertise in a development team, it makes deployment easier and more reliable, especially when using technologies like Docker.
If you’d like to discuss a new software development project you think may benefit from a microservices architecture approach or are considering migrating a legacy monolith application to microservices, please do get in touch. We’d love to hear about it and offer you our assessment of the suitability of microservices in your particular context!
You might also be interested to read why and how we helped the world’s largest events company migrate their core enterprise multi-tenanted CMS from a monolith to microservices architecture.
K&C - Creating Beautiful Technology Solutions For 20+ Years . Can We Be Your Competitive Edge?
Drop us a line to discuss your needs or next project