Microservices as an Architectural
Style
Although microservices have been around for more than a
decade, they gained real popularity only recently
Microservices as an Architectural Style
Although microservices have been around for more than a decade, they gained real popularity only recently
Although microservices have been around for more than a decade, they gained real popularity only
recently, But, does microservices architecture deserve your attention? What kind of projects is it a
good fit for? How may it change the outcomes of product development?
Let’s try to answer these questions – and few others which will undoubtedly come up along the way.
What Is Microservices as an Architectural Style?
Unlike the traditional approach which implies building a product from beginning to the end as a
single entity, microservices
architecture is about putting together a puzzle of different standalone services in the most
efficient way.
Traditional development techniques didn’t come to be traditional without offering many benefits.
Just as well, microservices-based architecture didn’t appear for no reason whatsoever.
Namely, traditional product development comes with few significant pitfalls. One of these is the
inherent difficulty of making changes to a particular part of an application after it’s complete;
obviously, any change to almost any part of an application built in a traditional manner would
involve rebuilding and redeploying the whole application. Just as importantly, traditional
development comes with severe scalability issues; they also stem from the monolith nature of the
traditional approach: one cannot just scale one part of the application and expect to leave the rest
of the application intact.
And this is where microservices architecture came in handy. Furthermore, we owe its emergence to the
massive influx of new services during the past few years. Once they were here, people realized that
they could use a lot less energy and financial expenses to integrate them than building a whole new
application from scratch.
[caption id="attachment_3829" align="aligncenter" width="800"]
Source: Microsoft
Azure documentation[/caption]
Source:
Microsoft Azure documentation

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.
Main Features of Microservices Architecture
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.
Features (Advantageous and Neutral)
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.