Microservices are individual pieces of business functionality that are independently developed, deployed and managed by a small team of people from different disciplines. See picture.
Inner versus Outer Complexity
Fundamentally, microservices shift complexity outward. “Inner” is what’s in a single microservice and how it’s packaged. It includes the runtime, the business logic, coding to the database, circuit breakers, management of application state, and so on – basically, anything for which an individual developer is responsible. “Outer” is everything outside of the individual microservice, including how instances of the application are deployed, how individual instances are discovered/routed to, load balancers, messaging, networking – basically anything for which an ops person outside of an individual microservice team is responsible.
Monolithic applications have always been difficult to build, especially as they increase in size. But monoliths are relatively easy to deploy and manage. With microservices, each microservice is exceedingly easy to build because the application is small and limited in scope. Large monolithic applications can have millions of lines of code whereas a microservice may only have a few thousand lines. Some of the more extreme microservices practitioners say that a microservice should be so small that it can be completely rewritten over a weekend. However, although each microservice is easier to build, deploy and manage, the outer complexity becomes more difficult.
Each microservice stays small and simple, with each team having full control over it. Monolithic applications, on the other hand, grow in complexity with each passing year as they get larger. Over time, this dramatically slows down development due to the complexity of the monolithic applications.
As monolithic applications grow in size, the time requirement to implement a new feature increase, to the points where release occur every quarter or three months. The large monolithic applications that run many banks, airlines, and retailers are sometimes deployed once a year or once every two years. Over time, the inability to deploy new features puts organizations at a severe competitive disadvantage relative to more nimble organizations that are able to release weekly, daily or even hourly as shown in the picture
Defining Microservices
Now that we’ve reviewed some of the high-level characteristics of microservices, let’s take a look at what the defining characteristics actually are:
Single purpose
Do one thing and do it well.
Encapsulation
Each microservice owns its own data. Interaction with the world is through well-defined APIs (often, but not always, HTTP Rest)
Ownership
A single team of 2 to 15 people develop, deploy and manage a single microservice through its lifecycle.
Autonomy
Each team is able to build and deploy its own microservice at any time for any reason, without having to coordinate with anyone else. Each team has a lot of freedom in making its own implementation decisions.
Multiple versions
Multiple versions of each microservice can exists in the same environment at the same time.
Choreography
Actions across multiple microservices are managed in a distributed fashion, with each endpoint being intelligent enough to know it inputs and outputs. There is not a top-down workflow that manages a transaction across multiple microservice boundaries.
Eventual consistency
Any given bit of data is eventually consistent. One of the biggest issues that enterprises have with microservices is the fact that not all data is strongly consistent. A product can exist in 20 different microservices, each having a copy of the product from a different point in time. Enterprises are used to having one single database for all the data, which is strongly consistent – one copy of the product that is always up to date. This is not the microservices model because it introduces coupling, which harms development velocity.
Advantages of Microservices
Faster Time to Market
Faster time to market of new features is the most important benefit of microservices. Microservices are so fast because they eliminate dependencies. With microservices, you don’t have to deal with the following:
- Horizontal dependencies – for example, no waiting on DBAs to change the shared database, no waiting on ops to provision compute
- Release approval from management
- Architectural approval from centralized architecture review team.
Better and Less Complex code
Microservices tends to produce much better code because a single microservice performs exactly one business function. Code is also better because a small team owns it and is responsible for it.
Security
Microservices are also better from a security point of view because each microservice is independently deployed, often to its own private network within a public cloud. If an attacker manages to access one microservice, he can’t easily get to other microservices. This is called bulkheading. If a monolithic application is breached, the attacker will have access to the entire datastore and all application code. Much more damage can be done.
Easier Outsourcing
It’s difficult to outsource roles such as development, operations, and QA with traditional monolithic applications because everything is so tightly coupled. For example, it might take only a few days for a third-party system integrator to build a new payment module, but it will take weeks to set up development environments, learn the process to make changes to the shared database, learn the process for deploying code and so on.
Microservices makes it very easy to outsource. Instead of payment module, a system integrator could be tasked with creating a payment microservice, which exposes a clean API. That system integrator could then build the payment microservice and host it themselves as a service or hand it over for hosting alongside the other microservices. By outsourcing in this manner, dozens or even hundreds of microservices could be developed in parallel by different vendors, without much interaction between the different teams.
Accountability
Each small team owns a single microservice from its inception to retirement. That team has great freedom to make architecture, implementation and technology decisions.
Enhanced Domain Expertise
With monolithic applications, business analyst tends to be in a large pool and are periodically assigned to different functional areas. With microservices, it is easy to develop very deep business expertise in one area. For example, a team building the inventory microservice are able to develop extensive expertise with distributed locking.
