Microservices as an Architectural Style

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.

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.

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:

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:

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:

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.

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.