From Monolithic to Microservices: Evolution of Software Design

Alex Tarasenko
Alex Tarasenko

It is not a secret that the global IT industry evolves rapidly in size, shape, and form. So do the software development practices applied to support it. Like any evolutionary process, these ones strive to maintain efficiency while increasing capabilities. To keep the progress going, some of the essential ways of doing things are often dropped or replaced. 

For IT development, this means there is a point along the journey of software enhancement where we cannot continue to add structures upon structures of ever-increasing complexity, without sacrificing performance. 

Historically, this point fell on the edge of 2011-2012, when software experts from a prominent workshop in Venice came up with the term Microservices to define a new architectural style they have been exploring at the time. Dubbed “fine-grained SOA”, it wasn’t an entirely new approach to product design, but rather a refined and structured way of building service-oriented applications – where services are provided by application components over a network (Wiki). 

Strictly speaking, microservices divide the bulk of a product’s functionality into smaller, independent chunks of software, in order to disintegrate the essential components of a product from one another while preserving the cohesiveness of the system. 

Here’s a general idea of the architectural difference when it comes to comparing microservices vs monolithic software:

Monolithic vs Microservices software architecture.

Which Architecture Is Better? 

With just above half of the enterprises out there adopting the loosely-coupled services approach, it’s a tough one to crack. 

The short answer is – well, it depends. 

Microservices are much like government decentralization, which gives power and responsibility to the regions while maintaining essential relations to keep the state solid. The opposite of that is centralized governance – where the decision-making is nucleus-concentrated.      

Now, as they often say at international student exchange programs – neither is better or worse, they’re just different. 

The choice of a suitable model is mostly dictated by your needs and setup. 

A simple project will hardly see the advantages of using microservices, just like a small state does not need decentralization. A bigger and more complex project, on the other hand, may very well benefit from abandoning the conservative method in favor of the more advanced approach. 

MintyMint has built a number of microservice-based products and we consider it a convenient and productive software model. One of the bright examples is 4friends – a crowdfunding platform for generating recurring donations.

That said, it is not all that simple when you dig deeper. There are many factors to consider when doing a microservices vs monolithic comparison to meet your goals perfectly.

Microservices vs Monolithic: In-detail Comparison

Comparing Microservices vs Monolithic software architecture is not an easy task. We have to remain scientifically objective, after all.

For that reason, a point system seems just right. 

Are you ready to kick-off the contest? Great! Follow me.

Performance

When it comes to the inherent performance of application architecture, there are two main indicators – network latency and data throughput. 

Latency represents the amount of time data takes to travel between two destinations. 

Representation of latency in a MIcroservices system.

Here’s how it works: 

To pass information, bytes are converted into an electromagnetic signal. It then travels via wires or air and is reassembled back into bytes by the receiving party. Now, we can cut down the decoding time. But since the signal takes time to travel, data transfer will always have a slight delay. It is a natural consequence of the basic laws of physics.

In this regard, having a localized, single-core system is superior to a network of interconnected clients operating with each other, often at long physical distances. While the latency of a microservice call is minuscule (around 25ms), the more calls – the higher the delay. 

There are, of course, solutions that can minimize this gap, like running all calls in parallel or using a so-called fan-out pattern. In this case, the difference tends to zero as more calls are executed. And still, Monolithics turn out slightly quicker every time. 

The same is true for absolute data throughput (the amount of data processed over time), which is directly related to latency. It’s simple – the slower the data transfer, the less of it can be transmitted in a period of time. 

A close call in the first standing, but still a point goes to the Monolithic architecture.  

Moving on.

Resource usage & Scalability

Now that we’ve touched on the matter of performance, let’s examine the situation with the usage of resources.

This is a tricky one. 

At first glance, microservices calls use more resources than the monolith ones, when doing the same amount of work with the same algorithms.

However, since microservices can allocate resources as needed, they enable using it in a lot smarter way, decreasing the memory and CPU power need per task. More so, the more instances are being performed – the greater the difference in resource usage, in favor of loosely-coupled services. 

Monolithic software can come ahead in some of the edge cases (when a call transfers large amounts of data), but most of the time they fall behind. 

The same principle works when you need to upgrade the computing capabilities as the requirements increase. By managing resources more efficiently, decentralized software allows one to scale easily and precisely, adding or removing cloud computing servers as needed. 

Clearly, a win for Microservices. 

Development complexity

Speaking about the complexity of the development process. 

While the good old monolithic apps call for greater skillsets from individual developers, microservices allow dividing large projects into smaller ones, so the tasks may be spread between highly specialized devs. Each – responsible for his part of the software and particular technology. 

Here’s an illustration to help you understand why:

A comparison between the structures of microservices and monolithic software.

At that, the overall amount of work to be done is in general considerably greater with Microservices.

Unlike single-core projects, assembling a number of modules may involve several source codes, multiple frameworks, and different coding languages for that matter.

Data synchronization also adds up to the complexity of running dispersed software as opposed to its locally-contained rival. Once again, there are tools that tackle the issues. Nevertheless, a monolithic architecture is innately more clear and transparent.   

Another point in favor of Monolithics. 

Are you still there? Great!

Deployment & Reliability

One of the main reasons why companies prefer microservices is the stunning deployment opportunities it provides. 

As compared to the bulky and highly-bound structure of monolithic software, its counterpart is simple and flexible enough to have updates as frequently as desired. In fact, you don’t have to roll out the entire system after changing some of the functionality. All you need to do is redeploy that particular service. 

More so, modifying a microservice does not affect the dependent services. Therefore, it won’t threaten the entire system’s work should there be a program malfunction. Whereas even a minor code error can stall the entirety of software built with a monolithic approach. 

This boosts the software’s reliability, eliminating a whole bunch of critical operational issues.

Something like having more engines on a plane…

In addition, microservices are a lot easier to test. A limited number of features dedicated to each of the services substantially decreases the number of dependencies involved. This makes it much more simple to write and run tests. Therefore, you can release the product a lot earlier. 

In this one, Microservices come out ahead. 

So far the score is 2 – 2.  

Technological Flexibility

This is where things get interesting. 

There are countless development technologies on the market. Some of them are quick, some – are easier to build. A part of them is better for billing, others are a good suit for data processing, or have better security… You name it. 

Microservices empower you to add all of it to the arsenal, taking the best from each technology. 

Technology Distribution In Microservices.

It’s like having all of the superpowers at one’s disposal. 

Like that, a piece of software can be quick, rigid, capable, and secure all at the same time. It’s no wonder why the method is so popular among architects of complex IT projects like Netflix, Medium, and Uber.

This will, of course, require hiring a whole bunch of specialists to implement, as mentioned earlier. But hey, that development complexity point is already granted to Monolithics, so we can’t complain. 

Another win for microservices.

Team Communication

Finally, team communication plays a key part in the process of IT product development, and it can be affected by software architecture choice.  

Here’s the thing: by dividing the software into smaller chunks, Microservices not only distribute the tasks but also the teams, decreasing the number of individual communication channels between devs. 

This goes in-line with Amazon’s well-known “pizza rule”, which states that a team is too big and inefficient if it can’t be fed with two pizzas. 

You decide what’s right.

I sure wouldn’t be arguing with Amazon’s expertise in project management. 

So, the final round goes to the Microservices architecture, too. 

Monolithics, it was a fair battle…

Conclusion

Finally, who comes out victorious in a microservices vs monolithic competition? To summarise what we have learned – there really is no leader in the software architecture race. 

Microservices are clearly more progressive and seem to be staying around for the foreseeable future, furtherly conquering the market. This will definitely be the case with complex, versatile products where having the risk of a system failure is simply not an option. 

That said, there are currently no reasons for smaller teams and projects (which are prevalent in number) to give up the well-established and proven tradition of monolithic software architecture. 

So, is it an even, you may ask? 

I guess it is safe to say it’s just different.