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 the Market 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.
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.
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:
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.
(image: Divante)
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.
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.
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:
That should give you enough homework to start with, but let us know if you have questions.
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 implement Azure Cosmos DB. There are also plenty of tools on the market that provide microservices for data integration.
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.
Service Instance per Container
Running each service as its own container image, which may consist of a complete Linux root filesystem. Using containers can also provide the gateway to running microservices without the cloud. Building such a heterogenous system without the advantages of cloud management or DevOps can lead to other headaches.
Serverless Deployment
Packaging the microservice as a ZIP file and uploading it to AWS Lambda, which runs it as a service without servers, virtual machines, or containers.
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 called Cloud Run, which allows users to run and scale stateless Docker containers in a serverless execution environment powered by Knative (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 helpful learning module for how to deploy microservices using containers on AWS.
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.
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:
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.
– Stuart Mann, Standard Bank Group
There are several things a microservice should not be confused with:
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.
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.
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.
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.
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.
Microservices and monoliths each have their respective flaws. So as not to overcomplicate this, here is a summary:
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!