Monolith vs Microservices Architecture: To Split or Not to Split?

What Is a Microservice Architecture and Why It Is Often Chosen

Currently, the software paradigm is represented by two types of solutions: microservices and monolithic architecture. In general, microservices architecture represents an application as a collection of small, loosely coupled services. In this kind of solution, the complexity is moved to the level of coordination of services. Each service represents one business capability that makes it easier to locate the code.

Whereas monolithic architecture assumes several discrete functions composed into a single unit that is tested, deployed, and scaled as a whole. All components are interdependent and often cannot run separately. That also means a bug in a module can slow down or break the entire application.

Microservices Architecture: Pros & Cons

Like every solution, microservices architecture has its advantages and disadvantages.

When to Choose Microservices

Martin Fowler (2015) gives advice on how to build useful software: “Almost all the successful microservice stories have started with a monolith that got too big and was broken up” Amazon pioneered the microservice architecture. In 2001, the company found itself unable to keep up with the scaling demands of its rapidly growing customer base. Due to countless requests from a wide variety of applications, the company faced coding issues, development delays, and service interdependencies. To figure out the refactoring of its system from scratch, Amazon broke its monolithic applications into small, independent service-specific applications. One service accepted orders, another one generated a list of recommended items to buy, and one more was a simple authentication service.

It is the wrong approach to choose microservices just following modern trends. However, heavy system load or the necessity to interact with different payment systems requires software architecture, and code to be designed in a way that supports it.

Moving to microservices is the right choice for business in some cases:

• The need to overcome growth and scaling challenges. If your monolithic application has become too inflexible to upgrade. There are system outages and the need for scaling.
• Accelerated time to market. To succeed in a competitive business environment, you need to quickly develop and release applications, updates, and new application features.
• Business intelligence, artificial intelligence. You need to implement advanced business intelligence solutions to get deeper and more competitive business data, reports, and analytics.
• IoT Networks: You need to build an IoT network, and your current infrastructure cannot provide the required horizontal scalability and cannot handle the huge data processing load.

Amazon Microservices Infrastructure, known as the Death Star. 2008 

Challenges When Moving to Microservice

There are some challenges that companies may face during the migration from a monolithic architecture to microservice architecture. The adoption of microservices poses technical and organizational issues, and it is really important to understand them. So, now we discuss the risks:

• It is extremely difficult and time-consuming. You need to understand that the migration of the monolith can take a lot of time and effort. This is why the refactoring toward microservices should be done in small parts. The company has to pay developers, but in fact, the project will be not developed. You should carefully organize a development team if you want to develop new features despite the migration process.
• It is very expensive. Expensive not only from the point of development and code writing, but it is also expensive from the point of support, operation, and making changes. It requires significant investments in building infrastructure, developing documentation, and refactoring applications.
• Microservices is a distributed system. That means the development team needs to choose and implement an inter-process communication mechanism based on either messaging or RPC.
• Moving of the codebase. The extraction of microservices from existing monolithic is dangerous for the data and code bases. It is extremely important to be careful during refactoring because there is a possibility of introducing new bugs. That is why good test coverage is needed.
• Organizational challenges. The organization must split big teams into smaller ones that can work autonomously. This way, the structure of the organization is in the line with the structure of architecture.
• Teams take responsibility for their service. Teams own their codebase, and they are in charge of the service functionality. And they cannot blame someone else for failure. If there is a problem in the product, the team has to fix it.
• Manage the migration process without stopping the system. Users should have access to the application.

These issues demonstrate that a microservice architecture may not always be beneficial for startups and midsize companies as it needs resources.

Migration. Where to Start: Audit and Analysis

Moving from a Monolith architecture to a Microservices might take years. How do you know if it is right for your organization? Sam Newman, the author of a book on microservice migration patterns, offers developers to consider three questions before adopting a microservice architecture:

• What are you hoping to achieve?
• Have you considered alternatives to using microservices?
• How will you know if the transition is working?

Before deciding to move a monolith to microservices or change the architecture, it is very important to assess how necessary it is for the product. As we mentioned, it is very expensive and time-consuming, and there are big risks. Based on Sam Newman’s recommendations and due to our experience, we propose an analysis approach:

Set Up the Goals

• Why you might want migration and when you cannot avoid it.
• Form a set of outcomes that the business is trying to achieve and described the benefits for the end-users of the system. Clarify what you want to gain moving to microservices. It might be rapid development, or you need to reduce interdependence of services, increased uptime, or scalability.
• Measure the expected load on the system and the number of users.

Think About Alternatives

• The decision about migration may be connected with a heavy load, then you need to opt:
• Move part of the functionality. It depends on the project. The functionality of sending an email, push notification, or phone call is not tied and can be divided. But if we have a system of the dashboard where analytics is collected from the linked database, it will be almost impossible.
• Analyze the current functionality and optimize it. Reconsider what creates downloads on the main project: suboptimal database queries or a large amount of unnecessary information. Maybe it is necessary to update the hardware. Develop new features and bring them to microservices.
• Try to apply vertical or horizontal scaling.

Evaluate Your DevOps Team Maturity Level

Your teams need to understand core DevOps practices. Is there a general culture of automation? Does your operations team support scripted deployments? What about Infrastructure as code? Do you have standards for how to do a code review? If you have mature development and operations practices, then a microservices architecture might be good for you.

Take Inventory of Business Functions and Capabilities

You architects should find associated code objects and match them to business functions in the system. Many functions cannot be moved because their domain has not been clearly defined. The technical team must understand how problematic it is to divide all the functionality into microservices. For example, there might be a situation where each entity is tied to several other entities. In this case, it is impossible to split it into a normal microservice. The logic of the business process may be very confused.

Make Sure You Can Get Rid of the Dependency Loop

Dependency cycles are sometimes impossible to avoid, but they create a connection between services, then blur their boundaries and offer to combine them into a single module.

Clarify if You Can Create Cross-Functional Teams

They should include developers, QA, operators, and business owners. Microservices need a different command structure. Create teams that can design, build, deploy, and maintain service without the need for any approval process. "We try to create teams that are no larger than can be fed by two pizzas." Jeffrey Bezos called it "the two-pizza team rule."

Choose the Scaling Platforms.

You need soft that can scale resources for microservices or to support autoscaling. As a solution option, you can use a serverless infrastructure hosted by cloud providers (such as Google Cloud, Microsoft Azure, and Amazon Web Services).

Then you should consider how to build a process not to damage the user experience. Engineers, together with customers, conduct business requirement analysis and construct a detailed data flow of business logic. It should not be changed while a migration.

You Decided to Split. Step by Step Instructions

The migration of monolith systems to the microservices architecture is a complex problem that software development teams have to solve. Now we summarize some experiences and instructions on how to adopt microservices.

Define Boundaries

Correct microservice boundaries are the base of healthy microservice architecture. In the case of false boundary measures, a change in functionality in a new microservice leads to a change in functionality in other microservices. As a result, the interfaces of all dependent microservices will "float" with subsequent integration tests. And if these microservices belong to different teams, they are faced with inter-team meetings and approvals.

A vivid example of what may cause domain separation is the software company Istio. They have confirmed that they are moving back from a microservices architecture to a monolith to make it easier to develop their products and meet some business requirements with less effort.

After migrating to microservices, the Istio team started getting feedback from their users; they soon realized that microservices weren't as useful as they initially thought. The main reason was that all control plane services were deployed and used together and shared the same administrative and security domains. Thus, moving the Istio control plane to a monolithic architecture was a good decision, as it greatly reduced the operational complexity of Istio. So, make sure that the monolith can be broken according to technical criteria. Recognize business domain boundaries within architectures and enforce them using public APIs as interfaces.

Highlight the Functionality in a Monolith, Which Can be Moved

It is important to determine which functional groups provide the most value as microservices. The rest of the functionality can be left in a monolithic system for now. A team of engineers and domain experts will walk you through existing implementations, dependencies, and internal events. Non-technical experts will point out things that are missing from your services or features that may be critical in the future.

Separate Data Store for Microservices

Each microservice should have one data repository. Note that separating data can make it more difficult to manage. Individual storage systems can easily get out of sync or become inconsistent. Therefore, you need a tool that performs master data management (MDM). Let's say it can check each database of subscriber IDs to make sure that the same IDs exist in all of them. Ensure the safety of user data, even if the service stops working. Initially, it is better to store data both on the microservice and in the monolith table.

Keep Code of a Microservice

Instead of adding or rewriting a piece of code in a well-performing deployed microservice, it's better to create a new microservice for the new or changed code. This way, you can deploy and test new code without the risk of failure in the existing microservice.

Separate Build for Microservice

Do a separate build for each microservice. Thus, it will be possible to obtain component files from the repository at the appropriate revision levels.

Deploy Microservices in Containers

To deploy a microservice, it's better to use a container, so you only need one tool. Note that Docker is advised as the standard for containers.

Avoid “Snowflake” Systems

Treat microservers as interchangeable members of the group. The one that stops working is automatically replaced by another. Avoid "snowflake" systems, and do not rely on separate servers for specialized functions.

Some Cases to Know

Netflix

Main Reason. To overcome the scaling challenges and service outages. Back in 2008, a single error caused massive data corruption and led to days of downtime. The company needed an architecture that allowed Netflix to operate 24/7, scale to the next order of magnitude, and optimize speed. The microservices architecture allowed Netflix to split the system into independent services: one service stores all the shows watched, another is responsible for monthly credit card payments, and the third analyzes the viewing history and offers similar shows and movies. Main Challenges. It takes a full seven years to complete the migration. There were a lot of latency issues with the web pages when Netflix first moved the customer-facing website to the cloud. There was an outage in AWS US-East that brought down several popular websites hosted on AWS. Best Practice. Netflix decided to move away from vertically scalable single points of failure, such as relational databases in our data center, in favor of highly reliable, scale-out distributed systems in the cloud. They chose Amazon Web Services (AWS) as a cloud provider because it gave the most scale and the widest range of services and features. Netflix denormalized the data model using NoSQL databases.

Netflix Microservices Infrastructure

Wix.com

Main Reason. To reverse a massive technical debt that had created serious stability issues. Since applications were interconnected, bugs in one part of the system had the potential to bring down our whole system. Main Challenges. Issues of handling communications among microservices, addressing failures, and debugging problems Best Practice. To invent new integration and end-to-end testing patterns and foster a new internal culture around these guidelines. To implement its own JSON/RPC protocol and built a microservices framework on top of SpringMVC.

Cloud Elements

Main Reason. To deal with the needs of a "hyper-growth company." For a company experiencing exponential growth, a microservices design helps to continually iterate to match new demands.

Main Challenges. Organizational changes. There were many opinions and conflicts due to differences in communication in the organization structure and in-building communications around microservices.

Best Practice. Usage of such tools, such as Minikube and Docker, helps run services locally and runs them remotely. All microservices are in Node.js; therefore, they leverage npm-based packages such as Ava for unit testing, NYC for Istanbul’s code coverage module, and XO for linting.

Best Buy

Main Reason. Interdependent architecture became an issue for deployments. the downtime was too long to sustain for conducting business online Main Challenges. Building trust. There was cultural resistance to how software is built and deployed. Teams used to pack features upon features into infrequent releases, and then they had to deal with changes in how they do their jobs.

Best Practice. CI implementation and deployment tools such as Chef and Jenkins. However, the biggest change was moving to Riak, a distributed NoSQL key-value data store.

Conclusions

So, should we keep up with new architectural decisions or stay with monolith? Actually, there is no final answer. Microservices architecture is neither good nor bad; it is just a different way of building software. The decision depends on the business needs of the application.

The customer and development team must find a common solution. Let's say that the project does not plan high loads and interaction with external services, in this case, it is better to choose a monolith. On the other hand, if the system must work under any load and with a large number of services, then a microservice architecture is the best option.

A lot depends on the organizational structure of your business. Do you have several IT teams working on the same product? Microservices may be suitable. But if you have one team of several developers, they will build and maintain the monolith well.

It is up to you to decide, just be sure your solution is reasonable. In certain situations, it may be easier to start with a monolith. Let your services grow inside a monolithic application, and only then start moving them to independent services. The choice is yours.