Transition from Monolith to Microservices: Advantages, Disadvantages & Use Cases
Principal and Co-Founder, Prime TSR
I’m going to start with a simple, but loaded, question: Are microservices the future of application development?
Well, if you look at the growth of companies using microservices, the answer is absolutely yes. The microservices architecture market is growing at a steady pace. Data from theMarket Research Future shows that the microservices industry is expected to increase by 17% between 2017 and 2023 and will soon reach $33 billion. Given this trend, let's take a closer look at the advantages (and disadvantages) of adopting microservices.
The growth is fueled by companies who are frustrated by their IT departments moving slowly and are looking to move to modern application development practices focused on speed and agility. Basically, the cloud has made it easier to split a monolith application into manageable microservices. Much of this growth has also been stimulated by cloud-based solutions that make it easier to create microservices.
But, as you can imagine, a microservices architecture can bring you a lot of pain if it isn’t done right. More on that later. Let’s start with the basics.
What does microservices architecture really mean?
A microservices architecture is an approach to developing an architecture that emphasizes modularity and independence of each application. Instead of building a single monolithic application, microservices split an application into discrete sets of smaller, interconnected services that each have their own business logic, database, and other adapters connected by APIs to other services.
One of the advantages of microservices is that when one component breaks, the entire system doesn’t fail. This approach has been trending since 2014 and has become especially popular in connection with the adoption of more Agile and DevOps frameworks for enterprise software development.
In plain English, a microservices architecture allows you to develop and publish an application without breaking another, which is a significant problem in monolith applications.
When did microservices start, and when did it make sense to use?
The term "microservices" was first used in 2011 at an event for software architects, where it described a style of architecture many attendees were experimenting with at the time. Netflix and Amazon were among the early pioneers of microservices.
As with anything, microservices are great for certain use cases and bad for others. A microservices architecture should be implemented when:
You want to design and ship code fast.
Your application will have a high volume of transactions.
You expect modularity and decentralization to be a critical part of your project.
You and your team are committed to cutting edge tools and technologies and will do anything to get away from a monolith architecture.
What companies currently use microservices?
Some of the world’s biggest companies and most notable brands have shifted from a monolithic architecture to cloud-based microservices in recent years, including Netflix, eBay, Amazon, Twitter, PayPal, and many other large-scale websites and applications.
Netflix, for example, which pioneered microservices at scale, estimates it uses close to 700 microservices to control the many parts that comprise its service. These range from your viewing history to deducting the monthly fee from your credit card to algorithmically guessing which movies you’ll like. “How do you always find the best movies?” asks the Curiosity Kid in the recent AWS commercial:
AWS is how. Netflix migrated to the cloud over a period of seven years, and today uses AWS to power its 700+ microservices. These services encompass everything from computing and storage, databases, analytics, recommendation engines, video transcoding, and involve over 100,000 server instances on AWS.
Where do you start with microservices?
Here’s the deal. There are a lot of great things to say about microservices. As I just mentioned, some of the best, growing technology companies use microservices-based architectures. But, there’s also something to be said about the complexity.
So, before you begin your journey with microservices, please know that implementing microservices can become complex very quickly. It’s best to start with simple, customer-facing mobile or web apps. There are many resources on the web to help you get started.
I would begin with these three resources:
This introduction to thebasics of microservices can help familiarize you with basic concepts without oversimplifying them.
Following this,DZone’s introductory series provides a solid introduction to a newbie and covers everything from the rationale for the architecture, how to implement it, to advantages and challenges you might encounter along the way.
Another resource is Spring Boot, an open-source Java-based framework used to create microservices.This tutorial offers a “gentle introduction” to spring boot-microservices.
That should give you enough homework to start with, but let us know if you have questions.
Where do you store data with microservices?
Within a microservices architecture, each service manages its own data to avoid conflicts and dependencies in case one system fails. For example, an application that manages a collection of car parts will require a number of services—including what happens when a new delivery is scheduled, pickup and drop-off locations, and size and weight of the package.
All of these services require different read and write profiles. Since each service has its own data storage requirements, the type of storage will differ. For example, Azure Microservices offers a full set of offerings; in one segment,Azure Cache for Redis might be used, while Azure Data Lake Store will be best for another, while yet another might implementAzure Cosmos DB. There are alsoplenty of tools on the market that provide microservices for data integration.
Where are microservices deployed, and where do they run?
There are a number of different microservices patterns used for deployment. Here are four of the most popular ways to do it:
Multiple Service Instances per Host: Provisioning one or more physical or virtual hosts to run multiple service instances on each one.
Service Instance per Host: Packaging each service as a virtual machine (VM) image (such as an Amazon EC2 AMI) that is launched using that VM image.
Serverless Deployment: Packaging the microservice as a ZIP file and uploading it toAWS Lambda, which runs it as a service without servers, virtual machines, or containers.
Where are microservices hosted?
Where you host your microservices depends on which type of deployment model is used in your organization (VMs, containers, serverless). For example, Google offers a service calledCloud Run, which allows users to run and scale stateless Docker containers in a serverless execution environment powered byKnative (Google’s own Kubernetes-based platform).
In AWS, you can store your microservices using a serverless hosting option.
This tutorial offers a helpful framework for creating a simple microservice using AWS Lambda with an Amazon API Gateway. If you prefer using containers, AWS microservices offers a helpfullearning module for how to deploy microservices using containers on AWS.
Can microservices talk to each other?
Yes, they can, but not without some tradeoffs. The original vision of microservices was to create a decentralized system in which each service had its own discrete code base, an independent release schedule, and no overlapping dependencies. But the reality is otherwise. In an online store, for example, billing and authentication services both need user profile data.
Not sharing data can lead to other issues, such as duplication of data—which then creates data consistency issues. So, there’s no easy answer about whether microservices can share a database. Data sharing in microservices is one of the field’s big debates, but the best advice out there is to keep data sharing to a minimum.
Which features make microservices so popular?
As I alluded to in the introduction of this article, microservices are growing in popularity in a big way. Whenever you get big names using them at scale, such as Netflix and Amazon, it’s a great case for enterprises that have scaling issues.
There are several major features that make microservices for the enterprise so popular:
Autonomous, Cross-Functional Team: Microservices grant the developers more independence to work autonomously and make technical decisions quickly in smaller groups.
Organized Around Business Capability: This means the same service can be reused in more than one business process or over different business channels depending on the need. Each team member is responsible for a particular service, which results in building a smart, cross-functional team.
Decentralized: The key principle of microservices is the simplicity of creation, deployment, and management since each service can be implemented using different programming languages, databases, and software environments.
Build It, Run It: This means each team is responsible for building a service and operating and maintaining its code in production. This DevOps approach leads to faster speed and productivity than in a monolithic application.
Technology Flexibility and Scalability: The lack of technology interdependence means each service can use the best technology for the problem being solved. This leads to better scalability and improved efficiencies.
Black Box: This implies that the details of each microservice are hidden from other components. Since each service communicates to the other using a set of well-defined APIs or messaging channels, this prevents the proliferation of dependencies between microservices.
Business agility is the ability to change direction as fast and efficiently as possible. Microservices are one of the enablers of business agility – removing the traditional technical constraints that slow down the delivery of new and improved products and services
There are several things a microservice should not be confused with:
It is NOT a simple API to a more complex service implemented as part of a monolithic application, nor a service exposed via API by another party.
It is NOT a service implemented with a small amount of code.
It is NOT a component, module, service, or capability that’s labeled as a “microservice” by a vendor that you don’t have control over.
It is NOT built and tested without automated testing and deployment and operations, nor does it have dependencies preventing it from being changed and updated independently.
It is NOT a large, coarse-grained service or monolithic set of services packaged in a Docker container.
Most importantly, a microservices architecture is not an easy, out-of-the-box solution for many problems, but if you do it right, or partner with the right team to do it, you will see a significant improvement in your ability to get code out faster.
Why choose a microservices architecture?
A microservices architecture offers a number of benefits, including helping enterprises release software faster, update software more frequently, and onboard new features more quickly. Microservices adoption enables agile teams to focus on smaller sections of the application, leading to quicker deployment and faster updates. This improves a team’s ability to innovate while unblocking their creativity.
For well-established enterprises, developers can use microservices to create new apps or as a pattern to break apart and refactor legacy monolithic apps for the cloud era.This approach to application development applies across many business verticals and industries. Microservices for data science and microservices for machine learning, for example, could be deployed in the healthcare field to optimize patient data and provide better quality of care and customer service, as well as flag safety issues. In the process, the microservices to the cloud model could function as the gateway to a company’s digital transformation.
Can microservices be optimized for a single function?
Yes, in fact, one of the hallmarks of a microservice is scalability. Since each service is a separate system, you can scale up a single function or service without having to scale the entire application. Business-critical services can be deployed on multiple servers for increased availability and performance without impacting the performance of other services.
What are microservices vs. serverless environments?
A serverless application shares some characteristics with a microservice, and even looks very similar but is also very different in a number of ways. Here are several key differentiators.
Microservices typically run in-house and are managed by IT, whereas serverless computing relies on a cloud vendor that performs all server management, capacity planning, and support tasks for the underlying infrastructure.
Serverless applications use functions, which are named procedures that perform a distinct service and return a value to the application. Typically, a microservice is larger than a serverless function and can perform more than one function.
Serverless computing products, such as AWS Lambda, work on a pay-as-you-go model. Microservices on containers, while relatively cheap to provision, require payment for the instance to run 24/7, even if there is no load.
Microservice patterns can solve a lot of the problems that come with monoliths. However, they won’t work for all organizations. Microservices are not just a technology architecture. They demand a deep understanding of the solution domain in addition to supporting organization structures, communication patterns, culture. If those are aligned, you may find significant benefit.
Microservices is the way to go, but, make sure you use it for the right reasons
We’re big fans of microservices, as you can tell, but we tread carefully. We never use microservices as a big bang approach from Monolith applications to microservices. We start by identifying specific use cases and do them one at a time.
What are the advantages and disadvantages of monoliths?
Microservices and monoliths each have their respective flaws. So as not to overcomplicate this, here is a summary:
Advantages of Microservices
Better organization: each service is standalone and does not depend on other systems.
Reusability: the code is easier to reconfigure and recompose in other systems.
Autonomous systems: one collapse doesn’t break the entire application.
Faster and more seamless on-boarding of developers: Since each service is modular, a developer doesn’t need to understand each separate service but can focus on building and deploying just one.
Reduced risk: each feature can be developed and deployed independently so that a single point of failure doesn’t cripple the entire system.
Data can be stored in multiple locations: which promotes faster scalability than a monolithic application.
Microservices increase fault isolation and tolerance: Because they’re loosely coupled, one point of failure won’t affect the entire application.
Disadvantages of Microservices
More complex development: loading of libraries, connections initialization, classes ecosystem, and monitoring all must be done manually (no out-of-the-box solutions).
Longer time to market: development is complex.
Requires a cultural shift: there should already be an Agile and DevOps environment in place to put microservices into practice.
More expensive: each service uses its own technology stack, CPU, programming language, etc.
Potential security threat: since you’re working with multiple containers that may share the same source code.
Advantages of Monoliths
Easier to develop: a large variety of tools that can be integrated into a single directory that’s deployable all at once.
Faster to develop: less complexity means faster time to market.
Disadvantages of Monoliths
Increased dependencies: more reliance on external libraries as more features are introduced.
Code is not reusable: everything is integrated so that one failure can impact the entire system.
It took Netflix seven years to move a majority of their applications to a microservices environment, so don’t feel too bad about not making the switch fast enough. I hope this article was useful for you as much fun as it was for me to write it!