Straightforwardly, software architecture is usually thought of in terms of either server-side or client-side logic. However, each of these can be further broken down into a range of slighter functional parts, which, in turn, can be substituted by microservices. Such well-known Internet giants as Amazon, Netflix, and Guardian have switched to this decentralized approach to product development,
using clouds as a connecting base.
As already implied above, microservices architecture does wonders when one has to work on large-size long-term projects.
In cases such as these, one is often faced with the necessity of altering
only certain parts of an application. However,
monolithic applications don’t really allow this, which essentially means that modifying even a small part of the application is no different from rebuilding the whole application itself,
In addition, massive projects often necessitate the use of different frameworks and programming languages, which isn’t really how traditional development works. But when you use a single platform/framework/programming language to
build an application, you end up with another problem: a failure of any part means the failure of the entire application.
Microservices as an architectural style offers solutions to all of these problems – and a bunch of others as well. However – just as the traditional approach – it comes with few caveats of its own as well.
So, let’s list all of its gains and drawbacks.
Microservices architecture can be defined along these lines:
- each part of the architecture (“microservice”) is independent, which allows opting for flexibility over standardization;
- decentralized data storage;
- possibility to use different programming languages;
- communication between services happens by means of API calls;
- a small development team can handle each functional part of such application;
- cross-functional teams can simultaneously handle different microservices;
- cloud-based application architecture;
- development with regard to a failure;
- the code is easy to understand, which is especially beneficial for dynamically changing teams.
Disadvantages
Although microservices architecture looks both promising and here to stay, it does come with its own variety of pitfalls which, in some cases, may discourage developers from using it.
Ironically enough, most of these disadvantages are actually the downsides of their benefits. For instance, decentralized approach to storing data (which makes each part of an application independent) results in difficulties of keeping overall data consistency. Also, different frameworks and languages within one application make project maintenance a pretty complicated affair.
I’ve tried summing up the main disadvantages of microservice architecture into four main drawbacks:
- the difficulty of maintaining overall data consistency;
- particular attention is needed so as to avoid versions incompatibility;
- things get complicated for developers and managers when it comes to a wide variety of languages and frameworks;
- complicated management of cross-functional teams.
When to Consider Using Microservices
Even so, microservices architecture seems like the way to go when it comes to multi-part large-scale projects, which are intended to be modified in a while.
That being said, it’s fairly obvious that each large-scale project has its own peculiarities, which stem from the available budget, the character of the final product and the type of company which is tasked with the project.
As a rule of thumb, consider using microservices architecture in the following three cases:
- large projects with a limited budget;
- outsourced projects which are done by way of managed coordination of scattered teams (both technologically and geographically);
- when the objective is two similar products, which allows teams to use the same functional parts.
SOA or Microservices?
There seems to be a common misconception when it comes to microservices architecture, with many people considering it just another name for service-oriented architecture (SOA).
This is obviously not true. Now, whether these two should be regarded as two kinds of the same thing, or whether one should consider microservices architecture as the next evolutionary step of SOA is a wholly different question. And one which, truthfully speaking, has no certain answer.
What is, however, certain is that, as they are currently defined, SOA and microservices architecture have their own fair share of differences.
We don’t need to go over them all here, but it’s nice if we point out the primary distinction between microservices and SOA. Namely, while SOA implies building an application as a combination of different modules which can be reused later, microservices architecture means creating an application as if a puzzle consisting of different independent services.
Obviously, whether you want SOA or microservices for your project depends on many different factors and is usually a subjective decision.
Conclusion
Although microservices architecture seems to be
an excellent fit for large monolithic projects – since its decentralized approach to product development solves many problems traditional development can’t – it turns out that it also requires a substantial management effort and generates quite a few maintenance glitches.
In other words, you may be better off using microservices for large frequently altered projects – but consider its drawbacks as well, before being lured away by its definite advantages.
Do you need some help?
