Download the authoritative guide: Cloud Computing 2018: Using the Cloud to Transform Your Business
In recent years, many enterprises have embraced microservices, also called microservices architecture. This development approach creates applications that are comprised of a group of small independent services. Each of these independent microservices can be tested and deployed individually; they may even be written in different programming languages or use different development frameworks.
Microservices applications are very different from the monolithic applications that organizations have produced in the past. Decades ago, development teams commonly created applications as a unified whole. That worked fine for applications with a small code base, but as the code base grew larger, monolithic applications became unwieldy.
In some cases, this monolithic architecture results in throughput bottlenecks as the application scales, resulting in poor performance. In addition, if you need to make a relatively small change, you’ll need to update the entire application — and test it all again — before redeploying the application.
Microservices architecture addresses many of these problems — although it is not without challenges of its own. It is particularly appropriate for very large applications that are maintained by large groups of developers. Microservices goes hand-in-hand with many of today’s most popular technologies, like DevOps, automation and cloud computing. In addition, microservices and containers are particularly interoperable and are often used together.
Several vendors offer products that they label as a “microservices platform” or a “microservices framework,” but you do not really need any particular software or tooling to deploy microservices. It is more of a design approach and a style of architecture than a specific technology.
That said, some development tools are better than others at supporting microservices. In general, tools that support DevOps and cloud computing well are also good choices for microservices.
The following diagram shows the relationship among the various aspects of microservices architecture:
Microservices architecture breaks down monolithic software applications into more manageable service components. Image: courtesy Microsoft.
In this type of architecture, each of the microservices is completely separate from the others. They may each have their own separate databases, and they may also connect to remote services (usually via an API). Communication between the client and the various microservices is handled via an API gateway. The application may also have management and/or service discovery capabilities as well.
Some individuals and organizations have attempted to identify different types of microservices. For example, some people divide microservices into two types: stateless and stateful. Others say there are three types of microservices: stateless, data centric and aggregator.
The difference in opinion stems in part from the fact that there is no standards body or other organization that has created a widely accepted definition of microservices. Several groups have put out competing definitions of microservices, some of which include diagrams and descriptions of different types of microservices. As a result, confusion persists about the exact nature of microservices.
Even experienced developers and industry experts sometimes confuse microservices with related terms and technologies, such as service-oriented architecture (SOA), APIs and Web services.
Microservices vs. SOA
You can think of microservices as a successor to or a subset of SOA, but the two are not exactly the same.
Service-oriented architecture, also called service-based architecture, is a software development approach that views the independent components of an application as services — which is similar to microservices architecture. However, SOA applications traditionally try to reuse and share as much architecture as possible. For example, SOA services often share storage, are built on a common platform, and use the enterprise service bus (ESB) for communication.
By contrast, microservices are meant to be as independent and decoupled as possible. As the name suggests, microservices are also much smaller than the services in SOA, and they usually communicate via lightweight protocols rather than via the ESB.
Microservices vs. APIs
An application programming interface (API) is a defined way for the components of an application to communicate with each other. For example, applications regularly use an API to make calls to a software library, such as a Java API.
Within a microservices application, the individual microservices use APIs to communicate with each (and possibly with external services). A microservices applications requires APIs to function, but the APIs and microservices are two different things.
Microservices vs. Web services
Another set of terms that people sometimes conflate are microservices and Web services.
A Web service is a service that provides functionality to other applications via the Web. For example, Google makes Google Maps available as a Web service so that other developers can add the mapping feature to their websites or apps. So when you look up a restaurant’s website and you see an embedded Google Maps link that provides directions to the restaurant, the website is accessing the Google Maps Web service.
A microservices application can make use of Web services. And to make things even more confusing, a Web service could be based on microservices architecture. However, the two are not necessarily related in any way.
Enterprises and software vendors choose to use microservices architecture because it offers a number of benefits, including the following:
- Faster development — Breaking an application down into many small pieces means that you can assign independent teams to work on each piece, with only minimal coordination among the teams. That speeds the entire development process, both in the initial development phase and during updates.
- Easier testing — With microservices architecture, each of the microservices can be tested independently. If a particular microservice needs to be updated, only that microservice needs to be tested again before re-deployment, which, again, makes the process faster.
- Simplified deployment — Because microservices can be deployed independently, you can push out the separate components independently. If something goes wrong with one microservice, you can easily roll back just the changes to that microservice without affecting the entire application.
- Fault isolation — If something goes wrong with a microservices application in production, it should only affect one microservice. In theory, the rest of the application should continue functioning normally if just one small part contains an error.
- Greater scalability — Microservices can also scale independently. That is, you can assign more resources to just those microservices that need them without assigning more resources to the rest of your application, especially if your microservices application is cloud-based. This helps to prevent some of the bottlenecks that can occur with monolithic applications.
- More technology choice — The team developing each microservice can choose programming languages and frameworks based on their preferences and the needs of their applications. They don’t need to build a piece of an application in Java just because the rest of the application is written in Java.
While microservices offers many advantages, it also introduces some challenges, including the following:
- Complexity — Individual microservices are very simple, but an application comprised of many independent parts with many different languages, frameworks and dependences is very complicated. Governance and management of microservices applications can be very difficult.
- Network latency — Because all the microservices within an application are communicating with each other via APIs, they necessarily place a heavy load on the network. That can slow performance unless the network is designed to handle the increased load.
- Testing — While microservices can be tested independently, you will also have to test the entire application as a whole. It can be difficult to troubleshoot problems across separate teams.
- Microservices versioning — In a traditional application, teams give new numbers to each update that they roll out to users. That becomes more difficult when components are developed separately. One microservice might be on version 1.2, while another is on 3.7. This also complicates testing as a microservice might work fine with version 1.3 of a separate component, but break completely when version 1.4 is released.
- Lack of skills — Microservices architecture is a new approach, so not all developers have experience with this form of architecture. Some might also be resistant to changes in the development approaches.
If you are familiar with the DevOps approach, you will recognize that many of the advantages of microservices also overlap with the advantages of DevOps. The two technologies are a natural fit with one another.
For example, both DevOps and microservices promise faster development and deployment. When you use DevOps alongside microservices architecture, you may be able to compound the advantages of each.
In addition, many technologies and approaches used by DevOps teams are also very helpful when creating microservices applications. For example, automation, cloud computing (especially PaaS offerings and serverless computing) and containers are often associated with both DevOps and microservices. And DevOps goals like continuous deployment and continuous testing are much easier to accomplish with microservices applications than with monolithic software structures.
The list of companies that are using microservices architecture reads like a who’s who of the technology industry. Some of the most well-known examples including the following:
- Netflix was one of the earliest adopters of microservices. The streaming service began changing its architecture in 2009, and it was unusually open about documenting its transition, which included a few hiccups along the way. Today, the Netflix Web application is managed by an API gateway that handles billions of requests each day for hundreds of microservices. The new architecture has allowed the service to scale to the size it is today and has also helped to prevent outages.
- Airbnb was another early adopter of microservices. The online room booking service began its migration to microservices by first adopting DevOps. Over time, the continuous deployment demanded by DevOps became too cumbersome to handle with monolithic architecture. By moving to microservices, the company was able to scale up its continuous delivery so that it now supports more than 75,000 production deployments every year.
- Uber transitioned from monolithic to microservices architecture beginning in 2015. In its blog, the company outlined some of its tooling choices, and noted that it ran into some obstacles. It advised other organizations that are adopting microservices to budget a lot of time for the process, to start with a small service, and to devote a lot of resources to testing.