If you are familiar with microservices and are trying to determine if this architecture is the right choice, start with our article on why companies should choose microservices.
A microservices architecture involves the building of modules that address a specific task or business objective. As a result, these modules tend to exhibit low coupling and high cohesion. A microservice architecture is often achieved by decoupling a monolithic application into independent modules that each contain the components necessary to execute a single business function. These services typically communicate with each other using language agnostic API’s such as REST.
Microservices were created in order to overcome the issues and constraints of monolithic applications. Monolithic applications have a tendency over time to grow in size. As applications become larger and larger, the tight coupling between components results in slower and more challenging deployments. Because of the tight coupling, the potential for a failure of the entire application due to a recently deployed feature is high. In some cases, deployments can take several months to a year, greatly reducing the number of features that can be rolled out to users. This tight coupling also makes it difficult to reuse and replace components because of the effect they may have on other components throughout the application.
Microservices address these issues by being small in scope and modular in design. Modular design results in components being loosely coupled, which offers enormous benefits from the standpoint of being fault tolerant and independently deployable. The result is functionality that can be frequently deployed and continuously delivered.
While there is no consensus of the characteristics of a microservice architecture, there are some characteristics a microservice should have in order to achieve the benefits possible.
When microservices first became a concept, people couldn’t help but find it difficult to distinguish the difference between microservices and service oriented architecture. While microservices and SOA architecture patterns do share a lot of similarities, there are some fundamental differences that set them apart.
One of the biggest differentiators between monolithic, service oriented, and microservices architectures are their levels of granularity. Granularity plays an important role in software architecture. The reason for this is related to the degree of coupling and cohesion that course grained and fine grained architectures present. Coupling is the degree of interdependence between software modules. As an application’s coupling becomes tighter, the modules within an application becomes less fault resistant and more difficult to reuse. Cohesion is the degree to which the elements inside a module belong together. As a general rule, software systems should be built to be loosely-coupled and highly-cohesive. Modules that exhibit high cohesion tend to be more robust, reliable, and reusable than modules with low cohesion. Other benefits such as ease of design, ease of integration, ease of testing, ease of monitoring, and ease of deployment can be achieved with a loosely-coupled and highly-cohesive architecture. Below is a visual depicting the coarseness of monolithic, service oriented and microservice applications.
Monolithic applications represent the worst case scenario when considering cohesion and coupling. A monolithic application is a single-tiered architecture where multiple layers are tightly coupled and multiple components run in the same process. A single data store is utilized throughout the application. Monolithic applications also exhibit very low cohesion since the entire block of code is deployed as a unit. Monolithic architectures require the entire program to be recompiled and deployed every time a change is desired due to their inherent inter-dependencies.
The middle ground between a monolithic and microservice architecture is a service oriented pattern. Service oriented architectures are alike to microservices in the way that modules focus on a business activity, and are much smaller in scope then an entire monolithic application. Service oriented architectures are alike with monolithic applications in that they utilize a single data store. While focused around functions, these modules are much courser grained than a microservices architecture where service components are usually single function services. Service oriented modules all communicate through an enterprise service bus. In the event of a requests backing up due to a slow service, it is possible that the enterprise serial bus could become a single point of failure that affects the entire application. As a result, service oriented architectures exhibit higher cohesion than a monolithic application, but also tighter coupling than microservices. For a more detailed analysis please read our article on microservice vs soa architectures.
Microservices represent the loosest coupling and highest cohesion when compared to service oriented and monolithic architectures. Each service is independent in handling its function, messaging, and data storage. The primary focus of a microservices architecture is to facilitate DevOps and CICD by building autonomous and independently deployable modules.
|Size||Highly interdependent services||Smaller interdependent services||Very small function-oriented independent services|
|Granularity||Single unit - Tightly coupled with low cohesion||Moderately coupled with moderate cohesion||Loosely coupled with high cohesion|
|Ease of Deployment||Must build and redeploy entire application||Requires modifying the monolith||Can independently build and deploy each service|
|Remote Call Overhead||Low/None communication overhead||Low communication overhead||High communication overhead, many remote calls|
|Speed of Deployment||Very slow deployment speeds||Slow deployment speeds||Rapid and continuous deployment|
|Persistence||All services in a monolithic application share data storage||All services in SOA share data storage||Each service is free to choose its own data storage|
|Ease of On-boarding||Difficult to on-board new developers||Semi-difficult to on-board new developers||Easy to on-board new developers|
|Polyglot Programming||Implement a single technology stack||Can utilize different technology stacks per service||Can utilize various technology stacks per service|
|Communication Method||Many methods exist||Communicates through an enterprise service bus||Communicate with lightweight protocols like REST|
|Scalability||Can be very challenging to scale as application becomes larger||Can be challenging to scale||Extremely scalable through use of containers|
Below is a high level overview, For a more detailed analysis, read our article on microservices advantages. When a microservice architecture is utilized for the right reasons, and implemented properly, they can yield enormous benefits over a monolithic architecture. The benefits that can be realized by a microservices architecture are:
While there are several advantages to decoupling a monolithic application into microservices. There are some disadvantages that you should know about before making the switch. Most issues associated with microservices are due to the complexities introduced by a growing number of independent services. Some of the challenges that business face when utilizing a microservices architecture are:
With the right tools, processes, and preparation, the issues associated with microservices can be overcome. For a more complete analysis, here is an article on microservices disadvantages.
A microservices architecture isn’t the right choice for every organization or every application. For new applications it is often best to start with a monolithic application, and the decouple the monolith into microservices after the application concept has been proved and has grown substantially in size. The reason for this is that monolithic applications are much simpler in terms of communication, security, and monitoring complexity when compared to microservices. Monolithic applications also tend to come at a lower cost in terms of overhead and latency related to the increase in remote calls with microservices. For these reasons, start-ups should weigh the advantages and disadvantages of starting with a microservices architecture.
Once a monolithic application has scaled and it becomes increasingly challenging and expensive to manage, scale, and deploy; a microservices architecture begins to make sense, and the advantages begin to outweigh increased complexity and overhead.
Culture also play a huge part in determining whether an organization will achieve success with a microservices initiative. A microservices initiative will thrive in a culture that:
Microservices bring a cultural shift to organizations that are organized hierarchically and with strong centralization. They share with lean thinking the emphasis on accountability, team autonomy, distributed leadership, and decentralization. You can almost entirely eliminate dependencies on the knowledge and influence of key individuals—and the bottlenecks that result when they leave or change roles—by bringing enablement and intelligence to teams of people who collaborate in a goal-driven, shared-values process.
Microservices were designed to work alongside CICD and DevOps. Because of their small size and independence, companies that utilize this architecture can benefit from deploying new features to users much faster than with monolithic and SOA patterns. To fully realize the benefits that microservices can offer and reduce the challenges associated with their increased complexity, automation of testing, monitoring, and deployment is an absolute requirement. Organizations that embrace and have a strong understanding CICD and DevOps practices are best equipped to successfully decouple their monoliths.
In a monolithic and SOA architecture, a single data store must be utilized across all services. Unfortunately, the large data volumes involved in larger applications feature data that have extremely varied characteristics and requirements for processing. A single data store is often not the ideal approach to structure and process all the sets of data that can be collected by an application.
In a microservices architecture, each service is able to utilize its own data store, leaving developers free to choose the database type that best fits the characteristics and processing requirements of the service. The ability of an application to choose different database technologies for individual services is known as polyglot persistence.
Below is an example of what data persistence looks like in a monolithic, service oriented, and microservices architectures.
Containers allow individual services to be deployed independently, and without the unnecessary requirement of having to deploy a full embedded OS as with virtual machines. With containers, services are encapsulated with a lightweight run-time environment. Each container includes everything required for the service to run. This makes containers a good fit for microservices as it increases the speed at which applications can be deployed, increases fault resistance, and enables them to work across platforms. By far the most popular tool for building, storing and running containers is Docker.
Ok, so you have your containers. Now what? Now you will need a centralized way to efficiently arrange, coordinate and manage your services to align with business requests. This is accomplished with a container orchestration tool. These tools enable systems to scale automatically, and reduces the time required to deploy multiple instances of a single application. There are several container orchestration tools on the market. Currently, the most popular container orchestration tool is Kubernetes. Kubernetes is often used in conjunction with Docker to orchestrate Docker containers.
Microservices do not have to be scary or challenging. Since microservices and container orchestration is so new, often times the most difficult part of a microservices migration is finding experienced talent to lead your team. A good place to start is with our article on getting started with microservices. This is where Tiempo Development can help.
Tiempo Development has provided consultation and software development support on many clients microservices initiatives. If you are struggling with your microservice migration, or want a second opinion on your techniques and strategies, we would love the opportunity to help. Please drop us a line below, and we will contact you shortly about your microservices project.