For many software developers, microservices-based architecture has 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 potentially benefiting from microservices to make an informed decision about their use in an organization. Let’s talk about microservices; the pros and cons, and more.

Microservices – what are they really?

According to a popular definition by Gartner, a 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 the whole implementation of its functionality as part of its code.
• Loosely coupled – it’s, for the most part, independent and does not need other microservices to work.
• Independently deployable – it can be deployed separately in a distributed system (e.g. using cloud computing), without having to compromise other microservices. Each can be written in a different programming language, but they all constitute an entire application.
• 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.

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 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.

How do microservices work (as opposed to monolithic systems)?

Let’s delve even deeper into how microservices work. As you know, in a standard monolithic system, 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.

As opposed to monolithic architectures, in a microservice-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 can be observed in the graphic below. This is a big advantage for the efficiency of software systems based on microservices, which alone can make up for many potential disadvantages of microservices, which we will also mention later.

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. 

Back to the monolithic vs microservices question. How else does the microservices-based architecture differ from the monolith?

Benefits of using microservices

Opting for the microservices-based architecture for your software has tons of potential benefits for your organization.

1. 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.
2. 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.
3. 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.
4. Easy to deploy – since you don’t disrupt the entire app, you can often modify and deploy new and existing microservices. There are also tools that make it far easier, such as Kubernetes.
5. 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 a smaller codebase is easier to understand. Quality Assurance also gets a break in the process.
6. 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 software.
7. 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.
8. 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 – cons of microservices. Let’s consider a couple of 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 and the independent services it offers. 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 of 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 increases, 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 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 dependent 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 is DevOps capabilities as well as careful monitoring of the services’ performance – logging, tracing, and metrics configuration. Thanks to all that, our services are stable. And when problems do occur, we are able to find the cause quickly.

Are microservices for you? Conclusions

Just to sum it up:

• Microservices have great potential, but it shouldn’t suggest that there aren’t any cons of microservices. The microservices architecture forces you to think about many variables related to deployment that do not occur in monolithic applications.
• The process of developing a microservice architecture-based application is far more complex than a monolithic one. The software development process always needs to be adjusted to the actual needs of the project. There is not one architecture that is inherently better than others. The monolithic application still has its place in modern software development and it was not made obsolete by the increasingly popular microservices architecture.
• You should only use microservice architecture in a project if it’s complex enough to outweigh the costs of maintaining and moving to a microservices-based architecture. You should consult your developers to come up with the best strategy for moving to service-oriented architecture.
• Moving from a monolith to microservices should be done with many considerations in mind
• A lot of best practices such as these by The Software House development team can make it easier, cheaper and faster to create and maintain multiple services.

Microservices happen to be one of our top technologies. See for yourself that we have already worked with microservices before from our success stories: making microservices more efficient & scalable with Backend For Frontend and joining 500K  businesses under an employee management platform. So make sure to check out even more microservices content from us and find the best process for your next web project.