Microservices: why isn’t it a panacea?

In recent years, only the lazy hasn’t heard of microservices. “Down with monolithic architecture, microservices are the future of web development!” – literally all companies that have Kubernetes in their technology stack and have started implementing DevOps practices are trumpeting this.

But should you change something in the software, if everything works like that? Let’s figure it out.

Microservice architecture: what is it?

Microservice architecture is an approach to web development in which an application is broken down into many parts, each of which performs a single function. Each microservice is “tied” to a separate domain (using a stand-alone storage with data and tools independent of external modules to connect to this storage) and can be deployed independently.

Today microservices act as the main antagonist of a monolithic architecture, where all business logic is interconnected.

Linking microservices to each other: fewer dependencies, more versatility

From the point of view of the end user, the difference between monolithic and microservice architectures will be noticeable only when they encounter system malfunctioning, because in the case of monolithic applications, there can be much more bugs. And all – because of the large number of dependencies.

Therefore, to reduce the number of unnecessary links, microservices interact with each other through universal APIs. As necessary, in the future, you will be able to connect new and disconnect already unnecessary blocks, without losing the viability of the updated software.

What technologies are used to create a microservice architecture?

The most common tools used to build microservices are Docker (for containerization) and Kubernetes (for container orchestration), ideal for enterprise deployments.

Of course, you can always opt for virtual machines, but in the latter case, you will have to pay even for the minutes of downtime of your software.

Advantages and Disadvantages of Microservices

Let’s find out the pros and cons of microservices.

Pros:

  • no binding to specific languages ​​and technologies;
  • easy integration with third-party solutions and the ability to reuse;
  • almost infinite scalability;
  • ease of maintenance (managing the server side in monolithic software has always been the responsibility of the software owner, and in the case of microservices, everything lies in the competence of the cloud provider);
  • fault tolerance;
  • Simplified symmetric application architecture instead of hierarchical (which is typical for monolithic products) with peer dependencies between components;
  • making edits without the risk of “collapsing” the entire system.

Minuses:

  • the testing process for the assembled software is complex, because microservices are based on separate domains;
  • Migrating a monolithic architecture to a microservice architecture can be very expensive;
  • managing software versions becomes more difficult;
  • Responsiveness issues may arise as the amount of code executed on the non-backend side increases;
  • you need experienced people to deploy microservices.

Down with the monolith. Long live microservices

Compared to monolithic software architecture, microservices almost always win. Indeed, in the case of a candy bar, all connections, data and functions work as a whole. That is, if you decide to upgrade your software, this will entail additional changes in many other components of the application. And this is your time and money.

In addition, in the case of a monolith, if any of your code blocks “breaks”, the entire system will collapse. Therefore, you should definitely not count on the stable operation of such an application.

On the other hand, not all, initially monolithic software can be split into microservices without radical refactoring of the code (which is also your time and money). The fact is that in any case, you will find components that, from a logical point of view, can function autonomously from each other, but in practice they are codependent.

Do you need microservices if “everything works fine anyway”?

In 2019, an independent survey showed that about 92% of respondents are actively increasing the number of microservices in their business solutions, and about a third of respondents are able to appreciate the benefits of innovations already in the first months of their implementation. True, at the same time, about 50% of companies are completely unaware of what advantages these technical innovations can bring them.

So is the game worth the candle? Or is microservices just another technological know-how that will soon become obsolete?

With all of the above benefits, a microservice architecture should seem like a true panacea for any business. Indeed, given the rather complex structure of most modern applications, without dividing them into separate modules, there is confusion, irrational consumption of human resources and the appearance of a heap of bugs.

However, there are cases where such blind IT trend following results in performance problems. After all, as we know, each of the microservices / web services is “tied” to a separate data source (DBMS). This means that with the simultaneous use of many functions of the application, such a structure will imply the synchronous execution of more than a dozen user requests. And the more microservices-components of the application, the greater the risk that the server will be overloaded.

Therefore, developers have to leave larger modules, in which connections would be built without the participation of network protocols. They carry less load on the server and reduce the risk of DDoS attacks.

Another problem with microservices is the lack of standardization. Initially, developers rarely bother with format harmonization. When microservices interact with each other, this omission can lead to errors, it is great to complicate the debugging procedure and increase the total number of hard-to-fix bugs.

Finally, the transition to microservices can be too expensive. Surely you might have encountered the problem that some components, which, in theory, could be divided among themselves into separate microservices, within the existing functionality work inseparably from each other. Completely rewriting them is not always a rational undertaking.

In such situations, it makes sense to use web services – a private version of a service-oriented architecture that describes the mechanisms for interacting an API with the main codebase using the universal data formats XML, JSON, etc., as well as the standard HTTP protocol. At the same time, like microservices, web services are not tied to a development language or software platform.

With this trade-off, you can maintain the performance of your application as well as reduce the cost of migrating to a new architecture.

Conclusion

As you can see, microservices are not a cure for all diseases, but just one approach to providing a scalable and easy-to-manage software architecture. They are typically implemented by global corporations such as Google, Netflix and Amazon, which offer thousands of individual services to end users. On the other hand, the initially chosen microservice software architecture will be a good foundation for building a flexible and fault-tolerant system.

Therefore, carefully weigh all the pros and cons, assess the risks and only then look for developers.


Advertising

Many of our clients have already appreciated the benefits epic servers!
it inexpensive virtual servers with AMD EPYC processors, CPU core frequency up to 3.4 GHz. The maximum configuration will allow you to come off to the full – 128 CPU cores, 512 GB RAM, 4000 GB NVMe. Hurry up to order!

Similar Posts

Leave a Reply