Innovation is everywhere. State-of-the-art, disruptive technology is thrust upon us continually. Artificial intelligence, machine learning, cryptocurrencies, NFTs, the metaverse, and other cutting-edge technology puts pressure on us to keep up with new trends in the ever-evolving software development ecosystem. New architectures and design principles are frequently on the horizon, and to remain competitive, we must experiment and innovate new solutions.  

Microservices vs Monoliths 

Microservices are an architectural approach where an application is constructed for a collection of small and well-defined services. The primary concept entails each service having one single, distinct purpose, working independently of one another; this differs significantly from the traditional monolith approach, in which a single application or service is responsible for everything. Monoliths are a conventional approach to application architecture where one database consolidates all user and order information on a single server.

Picture a 10-story building where a lift services every floor. However, none of its floors can be accessed if the lift were to break.  

In this metaphor, a microservices approach would propose introducing separate elevators for each floor, individual "elevators" to tend to each task. Elevator one would take us only to the first floor, while elevator two, exclusively to the second floor, and so on. That way, if you lived on the second floor, you could still reach it if the elevator serving the first floor were to malfunction. 

How do we manage high-traffic scenarios?  

Imagine a restaurant on the top floor of this same building with one apartment per floor on the lower floors. The number of people wishing to access the restaurant will be much higher than the number of residents trying to enter their apartments. Since the elevator for an individual floor does not permit access to the restaurant, residents would not have to queue to use an elevator when applying the microservices approach. 

Additionally, we could have multiple elevators going to the top floor, which is more affordable than having multiple elevators going through the entire building. Now, in a multi-purpose elevator solution, even if we were to increase the number of elevators, we would still have restaurant patrons using all of them, thus, still resulting in longer wait times for residents. 

Examining eCommerce microservices 

Ecommerce websites illustrate practical applications for microservices. In this scenario, we can quickly identify multiple services, such as:  

• Product listings 

• User login 

• Shopping cart 

• Payment system 

With a more traditional approach, when facing heightened user traffic, for instance, on Black Friday and the Holiday season, the eCommerce site would be required to increase the capacity or number of servers handling all requests. A distributed services solution can revolutionise performance by enabling the distribution of server capacity to where it's most needed. For example, a widely visited catalogue that does not convert into purchases. Here, you could boost the capacity for the service related to the product listing. On the other hand, if a discount advertising campaign yielded a considerable increase in checkout users, you could reinforce services connected with the "basket" and "payments."  

By strategically manoeuvring critical service resources, we can achieve long-term cost savings, and the system can react faster to surges in traffic.  

Defining over-engineering 

Over engineering is the process of designing a product or providing a solution with unnecessary functions and capabilities, often accounting for improbable tertiary conditions. These offer no more efficiency or effectiveness than a more straightforward design.   

Often, the issue with over-engineered design solutions lies in the urge to tackle every possible problem imaginable, even ones that don’t need solving. There are multiple reasons, such as a lack of a clear strategy, excitement over new technology, or the fear of seeing a simple solution rejected. 

Returning to the elevator example, do we need an elevator exclusive to each floor? In theory, the elevator dedicated to the top floor will have an elevator shaft the same size as the one used in the traditional approach. Therefore, a solution using the microservice system requires nine independent elevator shafts. 

By this illustration, when we consider the spatial demands of this approach, we can easily understand that microservices as a solution come with extra infrastructure costs and, most likely, more implementation time.  

The art of the monolith  

Microservices architecture can be more challenging to implement and come at an additional infrastructure cost, but it is vital to some businesses. One of the earliest and most noteworthy examples of the microservices approach came from Netflix. 

The company launched their first online streaming service in 2007, using monolith architecture and an in-house data centre; this was the standard approach for most online services, and streaming sites being a relatively new phenomenon, few examples could set a precedent. As more people used their platform, Netflix faced issues running a stable and efficient application, resulting in their databases going offline for three consecutive days. Netflix underwent a complete transformation, migrating all of its services to the cloud and deploying microservices architecture, enabling them to reinforce areas with heavy user traffic segmentally. 

The success of this approach is evident. Today, we understand it was the proper course of action. That being said, not every application or problem will have the exact requirements as Netflix. Therefore, it is often more appropriate to build a beautiful, well-designed monolith rather than an overly complex architecture full of small and unmanageable services. 

Deciding the best possible approach 

Many companies are moving toward this type of solution for tackling high traffic and data demands, which is very well supported by cloud providers such as AWS or Azure. Without this architecture, it would not be possible for Netflix or similar services to provide their vast selection of videos to their extensive client base. Simultaneously, this strategy may not be well-suited for all projects. The additional infrastructure cost, more significant setup effort and the extended time before going live might not always be worthwhile. 

Microservices is a new strategy developed out of necessity and has an intrinsic value. It is a service with abundant support from cloud providers such as AWS and Azure. Many businesses are switching to this approach as it helps them meet significant traffic and high data demands. 

The optimal strategy considers all project needs, including features, timeline, team size, and available resources; based on those requirements, companies should make well-informed decisions about technology or architecture rather than following "hunches." 

Keep it simple  

When planning a project's execution, the design principal KISS, an acronym for "Keep It Simple Stupid", is frequently referenced for gauging requirements, a reminder that the optimum solution does not need to be the most complex.  

Microservices' compartmentalised approach can risk over-engineering a system, especially if a site's user demand is not localised to individual services, resulting in redundancies of infrastructure, design, processing power, and perhaps most importantly, cost and implementation time. In such instances, an elegantly designed monolith is the preferable solution.