At some point, while networking with other teams and companies, you may develop an impression that certain words are used in all contexts just as a hint that you know what the current hype is about. One such example is “the microservice architecture”: sometimes the zest of using it looks like purely a wish to be up-to-date and follow the examples of such tech giants as Netflix, eBay, Amazon, Twitter, or PayPal.
Let’s be honest: with the term so buzz, it leaves too much room to imagination and using it whenever we are inclined to. Though the term “microservice architecture” emerged a few years ago to describe a particular way of designing software applications as suites of independently deployable services, it still lacks a precise definition. There are only certain common characteristics in organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data — a list of desirable and much talked about features.
So how we can avoid sounding overhyped with a new trendy word?
First of all, let’s compare microservices to the monolithic architecture — a monolithic application built as a single unit. Enterprise Applications are often built in three main parts: a client-side user interface, a database, and a server-side application that handles HTTP requests, executes domain logic, retrieves and updates data from the database, and selects and populates HTML views to be sent to the browser. This server-side application is a monolith — a single logical executable. Each change to the system leads to building and deploying a new version of the server-side application.
A monolithic server is a natural way to build such a system. All your logic for handling a request runs in a single process, while you use the basic features of the chosen language to divide up the application into classes, functions, and namespaces. With some care, the application can be run and tested on a developer’s laptop, and a deployment pipeline will ensure that changes are properly tested and deployed into production. Besides, you can horizontally scale the monolith by running many instances behind a load-balancer.
On the contrary, the microservice architecture is as modular as possible. In the simplest form, microservices build an application as a suite of small services, each running in its own process communicating with lightweight mechanisms, often an HTTP resource API and are independently deployable by fully automated deployment machinery.. These services may be written in different languages and may use different data storage techniques.
You can already see the pros of using such an approach:
· Teams may independently develop and deploy services
· Being a module, a microservice can be developed by a fairly small team
· When change is required in a certain part of the application, only the related service can be modified and redeployed — no need to modify and redeploy the entire application
· Code for different services can be written in different languages
· Easy to understand and modify for developers
· Easy to scale and integrate with third-party services
· No long-term commitment to technology stack, therefore freedom to use the latest technologies
· Easy integration and automatic deployment (using open-source continuous integration tools such as Jenkins, Hudson, etc.)
· The code is organized around business capabilities and priorities: in the monolithic approach, teams are separated to focus on UIs, databases, technology layers, or server-side logic, and even a minor change can lead to a cross-team project taking time and budgetary approval. In the microservice architecture, teams are small and cross-functional. They own the product for its lifetime and can quickly find a solution for their specific service
· Better fault isolation: if one microservice fails, the other will continue to work (although one problematic area of a monolith application can jeopardize the entire system)
· Decentralization: since microservices involve a variety of technologies and platforms, decentralized governance gives developers the freedom to produce useful tools that can then be used by others to solve the same problems. Moreover, microservice architecture also favors decentralized data management where each service usually manages its unique database.
It may sound like a perfect solution. Besides, you have probably heard the words “decentralization” or “cross-functionality” repeated as incarnations by all marketing teams and all speakers at each conference you attend.
Yet, we should understand that it is not a perfect architecture with no drawbacks:
· Additional complexity to the system when the developers have to mitigate fault tolerance, network latency, and deal with a variety of message formats as well as load balancing
· Increasing number of services may lead to information barriers and complicate integration and managing of the product
· Distributed deployment may result in complicated and tedious testing
· The architecture requires adding a mechanism of communication between the services
· Handling use cases that span more than one service requires communication and cooperation between different teams
· The architecture usually results in increased memory consumption
· Partitioning the application into microservices is an intricate process: moving away from single data storage usually means that you are giving away state consistency that it gives. Which means that you have to manage transaction in your highly distributed application by yourself. This is a hard thing to do right. Giving away ACID leads to really hard challenges that you have to meet while designing your architecture.
So, DO NOT go into microservices just to be in line with the industry if:
1. You have a monolithic legacy application, when its migration to a microservices architecture will require too much time and effort;
2. If you want to avoid complexity in management: even though breaking monolithic applications into multiple discrete parts can simplify programming, it can also make the application more difficult to manage;
3. If you do not have or do not wish to have a large technology stack: managing the complexity of microservices applications often requires you to deploy additional tools, such as orchestrators, that you would not need with traditional monoliths;
4. If you wish to avoid much networking: microservices applications typically rely on the network to enable communication between microservices, which means that managing and securing the network becomes crucial for the team;
5. If you need a quick solution:, developing a microservices application requires more planning and coding. This is one of the reasons why these types of applications tend to perform and scale better; they force developers to work more carefully. However, when you need quickly come up with a solution or test several options, investing the time required for a microservice architecture may not be worth it.
To recapitulate, choosing microservices, or monoliths, or SOA, or Microliths or whatever trendy term is in the air is not the point. Businesses will be always looking for ways to deliver customer value and technology can be a differentiator. So think first about your business objectives, the time and the force available and choose smart. If you have doubts, contact our consulting department at info@sciforce.solutions, and our specialists will review your existing system and business needs and advise on the approach you should opt for taking into account your current situation and future prospects.
