3 September, 2019
Microservices – there are few trends in software that have captured the attention of IT decision makers to this extent. They are supposedly capable of making your apps more efficient and scalable. But what exactly does it mean? When is it a good idea to invest in them over other types of architecture? The Software House translates the technicalities into actionable information for you to use in your business.
For many software developers, microservices-based architecture have become an important part of their everyday work, as more and more apps are made that way. But with so much hype, it’s easy to play microservices down as a buzzword. This article attempts to make it easier for everyone that can potentially benefit from microservices to make an informed decision about their use in an organization. Let’s talk about microservices; pros and cons of their use and more.
Microservices – what are they really?
According to a popular definition by Gartner, microservice is a “tightly scoped, strongly encapsulated, loosely coupled, independently deployable and independently scalable” component of an app. Let’s break it down.
- Tightly scoped – it has a clearly defined, usually very narrow use.
- Strongly encapsulated – it contains, as part of its code, the whole implementation of its functionality.
- Loosely coupled – it’s, for the most part, independent and does not need other microservices to work.
- Independently deployable – it can be deployed separately, without having to compromise other microservices.
- Independently scalable – even if one microservice handles the majority of traffic, we don’t need to scale the entire system, but focus only on scaling the affected microservice instead.
Still confused? A good example of a microservices-based application could be an eCommerce store, in which every business domain (e.g. handling orders, products catalog, internal search, billing, payments, delivery form, PCI DSS certification) is a separate microservice. Microservices are often organized to correspond with particular business use cases, but functionalities such as authentication or notifications can also work as separate microservices.
This unique ability of being able to divide all these functionalities into completely independent blocks makes microservices an ideal choice for dispersed/distributed teams. As a result, large companies with distributed teams such as Netflix or Twitter can work efficiently by assigning different microservices to different teams. But this is not the only reason why many innovative tech companies go for microservices. As you read on, those advantages should become clearer.
Do you have experience with microservice architecture? 🤔 Take part in the State of Microservices 2020 survey!
How do microservices work?
Let’s delve even deeper into how microservices work. As you know, in a standard monolithic application, the codebase can be roughly divided into two parts: the frontend and the backend. Each of these has a separate repository of code. Typically, different teams would handle these and each layer can have its own dominant technology (e.g. React for frontend and Node.js for backend). This is illustrated below.
In a microserviced-based architecture, the frontend layer remains the same, but the backend is split into multiple parts dedicated to specific functionalities. Each one of them can have its own repository. And since they are strongly encapsulated, each microservice can be potentially written in a different language, as it can be observed on the graphic below.
For many projects – in which there is no need (or ability) to involve so many different technologies, and the presence of so many repositories creates confusion (complex project structure, difference in code organization between repositories etc.) that outweighs the benefits of this separation – a simplified version can be used. By using monorepos, one can create repositories that include code for all microservices that use the same technology stack.
How else does the microservices-based architecture differ from the monolith?
|Development||Each service is an independent app. It might (but not necessarily need to) have a separate code repository, so conflicts are much less common.
In order to share some code, you need to have a separate library.
You can scale teams much easier, because each team might be assigned to a specific service.
Adding new features is either extending one of existing services or adding a new one.
|Everything is in a single place, so it’s much easier to share code. At the same time, it might lead to an unmaintainable state where everything is coupled.
Working in the same area might lead to conflicts in code, which will lead to longer development time.
Adding new features is about adding new code to an existing app.
It’s harder to scale teams.
|Testing||Each service is a separate app that not only requires unit tests, but also component/contract tests.
What’s more, we should add an additional layer that will allow us to test integration between multiple services at once.
|Easy to test. Everything is in a single place.
Most of the time, it can be covered with unit and E2E tests.
|Deployment||Each service requires separate CI and deployment process. You need to orchestrate the whole infrastructure and configuration for the whole system.
However, if something goes wrong only a single service won’t be able to start up.
|You set it up once. Does not require a lot of orchestration. However, if something goes wrong, you cannot deploy your app at all.|
|Maintenance||Requires DevOps knowledge about Docker, Kubernetes and more.||Easy to maintain|
|Reliability||Breaking one service does not break others, so only a set of functionalities might be affected.||Breaking a single place in an app, breaks everything.|
|Scalability||Each service is scaled independently. We use only as much resources as we need.||In order to scale a single part of a system, you have to scale the whole system which might lead to resources not being used fully.|
|Releasing||You release a single service, so only tests related to this specific service are necessary.||You release the whole system at once, so the whole regression is necessary every time.|
Benefits of using microservices
Opting for the microservices-based architecture for your software has tons of potential benefits for your organization.
- Codebase aligned with business domains – your microservices are usually organized around actual business functionalities/goals of your organization, which means that it’s easier for both developers and business people to understand how technology and business are connected.
- Perfect for distributed teams – different developers/teams can work on different microservices without being in each other’s way. For distributed teams, it’s a far more convenient situation than a monolith.
- Easier to build and maintain – splitting your codebase into smaller independent fragments based on functionalities means that they are easier to understand and thus maintain. Lots of tools such as Docker streamline the creation of new microservices.
- Easy to deploy – since you don’t disrupt the entire app, you can modify and deploy new and existing microservices very often. There are also tools that make it far easier, such as Kubernetes.
- Improved productivity – developers who work on particular microservices don’t need to wait for other devs to finish their job. Taking over one’s work is also easier, since smaller codebase is easier to understand. Quality Assurance also gets a break in the process.
- Freedom in choosing technologies – each microservice can be developed in a different technology, which allows one to choose the most efficient solution for every problem. This also largely eliminates technology and vendor lock-in – your app doesn’t wholly depend on any third-party piece of software.
- High-performance, efficiency and scalability – you can scale each microservice separately. It means that a single service can be deployed in multiple servers to serve increased traffic, while the rest only consume the standard amount of resources at the same time. You can maintain high-performance in a cost-efficient way.
- Reliability – fault-isolation means that the failure of a single service is unlikely to impact the performance of other services. In a monolith app, a similar error can potentially cause the entire system to collapse.
Microservices: pros and cons in different scenarios
You should probably have a pretty good idea by now about the kind of projects microservices will work well with. Just to sum it up:
- Since microservices deliver outstanding scalability and encourage Agile-based workflows, they are perfect for applications that have high requirements in these areas.
- Since the codebase can be divided into completely independently developed units based on functionalities, it’s an obvious choice for distributed teams, especially for developers who represent various technology stacks.
- The more complex, traffic-intensive and long-term oriented the project is, the more suitable it is for a microservices-based architecture.
Now, let’s try to figure out when microservices might not be the best choice. Let’s consider a couple scenarios.
What is good for Netflix may not be good for us
Large companies, such as Netflix, which employ various development teams all over the place, can benefit greatly from the modular nature of microservices. The cost of implementing a microservices-based architecture tends to be higher than building a monolithic app (you need to account for a log monitoring system, request tracing and the ability to deploy the entire system as well as any individual microservice). It may not be worth it for systems that don’t expect large traffic, scalability issues and mixing various technologies.
Too much agile can make you rigid
Thanks to microservices, you can iterate more easily by being able to deploy each microservice separately. Testing and deploying becomes a big part of your everyday workflow rather than a rare occurrence. But with that comes big responsibility. As the number of dynamically changing microservices increase, it takes significant DevOps capabilities and lots of experience to be able to command them.
I’m only just testing the waters!
Are you creating a new (greenfield) project? Do you have an idea in mind and want to create an MVP? Your best bet will probably be a monolith. Not only are you probably still not sure what kind microservices you need, but you also don’t need microservices’ complexity from the start. After all, you can always move from a monolith to a microservices-based architecture in the future, should it be necessary.
How to get started with microservices?
There are a couple of things you should remember about. First, let’s consider consider points that hold true regardless of the circumstances
Starting from scratch
- Don’t jump on the bandwagon – make sure the project justifies microservices. Make sure that your project is suitable for microservices, based on all the considerations we made above.
- Don’t be Agile just in theory. You won’t be able to benefit from microservices without a strong Agile culture.
- Invest in your DevOps culture/capabilities. The same goes for DevOps – the bigger your architecture is and the more microservices you need to manage, the more evident it will be.
Now, onto the more specific (and highly likely!) scenario of moving from a monolithic architecture to microservices.
Moving from monolith to microservices
- Don’t start from scratch! Since you already have an app, you should start with it as your base. Even if you’re not planning to go “microservices all the way” immediately, you can simply develop new functionalities in microservices, while keeping your base as a monolith for the time being.
- Avoid a distributed monolith. Don’t go from a traditional monolith straight into microservices. Otherwise, you might end up with a distributed monolith – a superficially modular app, in which all the modules are actually highly dependant on each other.
- Go for a modular monolith. The best approach is to split your monolith into smaller, independent pieces, and then incrementally proceed to turn them into services.
Microservices the TSH way
Would you like to know how The Software House works with microservices? We will leave the details of our best practices for another time, but here are some of the most important points from TSH’s head of Node.js, Adam Polak.
“An important practice at TSH is not wasting time on creating a so-called boilerplate (everything you need to create a structure of a new service). With a set of tools created in the early phase of the project, we can rapidly create new services and focus on what matters most – the business logic.”
Careful monitoring of microservices by DevOps is vital for efficiency, stability and quick recovery.
Another important matter are DevOps capabilities as well as careful monitoring of the services’ performance – logging, tracing, metrics configuration. Thanks to all that, our services are stable. And when problems do occur, we are able to find the cause quickly.
At this point, you should know if microservices are for you. Just to sum it up:
- Microservices have a great potential
- But you should only use them in a project if it’s complex enough to outweigh the costs of maintaining and moving to a microservices-based architecture
- Moving from a monolith to microservices should be done with many considerations in mind
- A lot of best practices such as these by TSH can make it easier, cheaper and faster to create and maintain microservices
If you want to talk with us about microservices-based projects, contact us (initial consultations are free of charge).