Choosing the Right Architecture: Monolithic vs. Microservices — Analyzing Requirements for Success

In the world of software development, architectural choices play a crucial role in determining the success of a project. One of the most prominent debates in recent years has been the comparison between monolithic and microservices architectures. While monolithic architecture has been the traditional approach, microservices have gained popularity due to their flexibility and scalability.

When I started my career back in 2016, The first thing I learned was about Microservices. It was considered the future of software development, promising greater scalability, flexibility, and resilience. It seemed like everyone was embracing it, even startups, despite the challenges involved.

A strong monolith structure will allow you to replace any segment of the application with microservice when needed. Most of the successful startups we read about (Netflix, Uber, Airbnb, etc.), all started with a monolith architecture.

Before diving into microservices, it’s important to consider the specific outcomes you hope to achieve. Ask yourself questions such as:

Why do you need microservices?

• Is there anything within the system that is scaling at a different rate than the rest of the system?
• Is there a part of the system that requires more frequent deployments than the rest of the system?
• Is there a part of the system that a single person, or a small team, that operates independently from the rest of the group?

Once you have clear answers to these questions, you can analyze the costs and benefits to decide if using microservices is really necessary for you.

Everything comes with a price, sometimes people forget the cost you need to pay when pursuing new trends in technology. Some typical costs include:

• Increased development complexity
• Exponential infrastructure costs
• Added organizational overhead
• Debugging challenges

If you are not sure about requirements, always start with Monolith first

1. When starting a new application, how confident are you that it will be valuable to your users? The most effective way to determine the usefulness of a software idea is by building a basic version and assessing its performance. In this initial phase, it is important to prioritize speed (and therefore quick feedback cycles), which means avoiding the complexities of microservices.
2. For Microservices to function effectively, it is crucial to establish clear and stable boundaries between the services. However, even experienced architects face challenges in determining these boundaries accurately from the start, particularly in familiar domains. By initially building a monolith, you can identify the appropriate boundaries before transitioning to a microservices architecture that may complicate the process.

In conclusion, no architecture is often the best architecture in the early days of a system.

Advantages of Microservice Architectures

• Agile and flexible
• Fewer and more isolated code issues
• Smaller in size and scope
• Independently stacked and deployed
• Deployment is rapid and continuous
• Functional with cloud-based containers
• Best in class solutions and performance for every use case
• Low cohesion, (the advantage is that any change you make has a drastically reduced risk compared to monoliths, which are very cohesive but cannot be edited without high-risk)
• Smaller domains
• Lack of transactional requirements in regards to cross-services

Disadvantages of Microservice Architectures

• Can be challenging to maintain separate frameworks
• Lower/no cohesion between platforms (it is important to keep platforms separate without strong connections. Starting with a monolithic approach helps identify and resolve any issues with platform connections before moving to a microservices setup )
• Data stored in technology and operational silos
• Can lead to a disjointed experience for your customers
• Can be more expensive, depending on the configuration
• More complicated

3 Microservice Case Study — Amazon, Netflix, and Uber

we’ll explore the microservices journeys of these wildly successful enterprises. But first, let’s look at the general circumstances that inspire enterprises to use microservices in the first place

• Microservices are a way of constructing applications by dividing them into several independent, small services.
• In Java, microservices are a software architecture pattern where applications are created as a collection of these small, autonomous services.
• Prominent companies like Amazon, Netflix, and Uber have embraced microservices to gain advantages in scalability, flexibility, and profitability.
• The benefits of microservices include agility, adaptability to evolving business needs, scalability, and the ability to easily integrate new components.

Examples of Microservices in Action

1. Netflix

Netflix is a company that has found success through the use of microservices connected with APIs.

Netflix began its microservice journey in 2008 before the term “microservices” became popular. Netflix started its movie-streaming service in 2007.

By 2008 it was suffering from service outages and scaling challenges, for three days, it was unable to ship DVDs to members.

At this point, the company was still dealing with physical DVDs, which put a damper on how well it could serve its customers. Streaming was still a dream, and online business, while thriving, was difficult. The monolith design was still not very functional beyond a certain point. Microservices architecture was a much better option, but it didn’t truly exist yet.

According to a Netflix vice president:

Our journey to the cloud at Netflix began in August of 2008, when we experienced a major database corruption and for three days could not ship DVDs to our members. That is when we realized that we had to move away from vertically scaled single points of failure, like relational databases in our data center, towards highly reliable, horizontally scalable, distributed systems in the cloud. We chose Amazon Web Services (AWS) as our cloud provider because it provided us with the greatest scale and the broadest set of services and features.

Starting in 2009, Netflix initiated a step-by-step transformation of its monolithic architecture into microservices. They began by migrating their non-customer-facing movie-coding platform to operate independently as a microservice on Amazon AWS cloud servers. Over the course of the next two years, Netflix proceeded to convert their customer-facing systems into microservices, completing the transition in 2012.

The first step was to migrate its non-customer-facing, movie-coding platform to run on Amazon AWS cloud servers as an independent microservice. Netflix spent the following two years converting its customer-facing systems to microservices, finalizing the process in 2012.

ROI

Refactoring to microservices allowed Netflix to overcome its scaling challenges and service outages. By 2013, Netflix’s API gateway was handling two billion daily API edge requests, managed by over 500 cloud-hosted microservices.

By 2017, its architecture consisted of over 700 loosely coupled microservices. Today, Netflix makes around $8 billion a year and streams approximately six billion hours of content weekly to more than 220 million subscribers in 190 countries, and it continues to grow

Here’s a visual depiction of Netflix’s growth from 2007 to 2015:

Netflix

2. Amazon

Amazon is an Internet retail giant, but it didn’t start that way. In the early 2000s, Amazon’s retail website behaved like a single monolithic application.

The tight connections between — and within — the multi-tiered services that comprised Amazon’s monolith meant that developers had to carefully untangle dependencies every time they wanted to upgrade or scale Amazon’s systems. It was a painstaking process that cost plenty of money and required time to adjust.

Previously, Amazon found that the monolith structure worked very well. However, the code base quickly expanded as more developers joined the team. There were too many updates and projects coming in, which had a negative impact on the software development and function. With such obvious drops in productivity, it was necessary to look at a better way of doing things.

In 2001, development delays, coding challenges, and service interdependencies forbid Amazon’s ability to meet the scaling requirements of its rapidly growing customer base. The company and its site were exploding, but there was no way to keep up with the growth.

Here’s how Amazon did it:

Developers analyzed the source code and pulled out units of code that served a single, functional purpose. As expected, this was a time-consuming process since all the code was mixed up together, and the various functions of the site were intertwined. However, the developers worked hard to sort it out and determine which sections could be turned into microservices.

Once they had the separate sections of code, the developers wrapped these units in a web service interface. For example, they developed a single service for the Buy button on a product page, a single service for the tax calculator function, and so on. Each function had its own section.

ROI

Amazon’s “service-oriented architecture” was largely the beginning of what we now call microservices. It led to Amazon developing a number of solutions to support microservices architectures — such as Amazon AWS and Apollo — which it currently sells to enterprises throughout the world. Without its transition to microservices, Amazon could not have grown to become the most valuable company in the world — valued by market cap at $1.27 trillion as of June 2, 2023.

3. UBER

Uber, the world’s largest taxi company, owns no vehicles. isn’t it interesting, But how UBER achieve this lets understand

Despite being introduced to the world more recently than either of our previous examples, Uber also began with a monolith design.

This microservice example came not long after the launch of Uber, when the ride-sharing service encountered growth hurdles related to its monolithic application structure.

The platform struggled to develop and launch new features efficiently, fix bugs, and integrate its rapidly growing global operations. Moreover, the complexity of Uber’s monolithic application architecture requires developers to have extensive experience working with the existing system just to make minor updates and changes to the system

Here’s how Uber’s monolithic structure worked at the time:

• Passengers and drivers connected to Uber’s monolith through a REST API.
• There were three adapters — with embedded API for functions like billing, payment, and text messages.
• There was a MySQL database.
• All features were contained in the monolith.

The above diagram provided illustrates the former architecture employed by UBER.

To overcome the challenges of its existing application structure, Uber decided to break the monolith into cloud-based microservices. Subsequently, developers built individual microservices for functions like passenger management, trip management, and more. Similar to the Netflix example above, Uber connected its microservices via an API gateway.

The changes were faster in this case, since it was done earlier in the business. There were fewer functions mixed into the monolith design, and this made it simpler to change things around when it was time to switch.

Refer to the diagram below to look at UBER’s microservice architecture.

• The major change that we observe here is the introduction of API Gateway through which all the drivers and passengers are connected. From the API Gateway, all the internal points are connected such as passenger management, driver management, trip management, and others.
• The units are individual separate deployable units performing separate functionalities.

Conclusion

• Monoliths are easier to develop, test, and deploy but are difficult to maintain, enhance, and scale.
• Monoliths may suffer from a single point of failure.
• Microservices require specialized skills and more resources to develop, but they are easier to debug, maintain, enhance, and scale.
• Microservices do not suffer from a single point of failure

Please show your appreciation for the article by giving it a round of applause 👏, and don’t forget to follow for more insightful stories in the future.

Follow Me: LinkedIn