What are Microservices?

Photo by IA-Photoshop.

Microservices is a popular topic in software architecture as organizations are keen to conduct application development using microservices architecture. Let me break down microservices in a very simple way.

The various software on your computer is an example of traditional applications. When we need to create a traditional application, we would create a new coding project and add functionality to that software development project. If more functionality is required, you simply add more code. The architectural style of having a single application is known as monolithic architecture. What begins as a small-code base ends up as a large, complex, and unmanageable code.

To solve this issue, development teams were recommended to split functionalities into modules based on business capabilities. These small, independent, and reusable parts were focused on performing a smaller functionality. Instead of having a complex code-base, the code is broken into smaller modules and the application is composed of them. Although the functionality is broken down, the user still composes these modules to form a single application. This doesn't solve the issue either as we still had all the deployment and runtime issues that came with traditional applications, such as downtime (if even a single service does not work properly), and the need to maintain and deploy a single, complex application at once.

Over time, developers moved to web applications that run on a web server. The result of the execution of the remote machine could be accessed from your web browser. How does this change things? Now we have an organized, structured, and modularized code that is composed to create one monolithic application. The code and the deployment are still the same, but the end result is still a single, monolithic application. With time, web app development started becoming more complex due to the introduction of new, interesting features. Complexity needed to be handled not just on the side of code management and implementation, but also in the runtime or execution. 

Why Did We Need to Change from Monolithic Applications?

• Difficult to deploy large applications: When you make a small change, the entire application needs to be tested with each change prior to deployment, making it difficult for larger applications in the process.
• Complex to scale - Online ecommerce sites have very unpredictable traffic spikes. During a sale, traffic is usually very high and when the sale ends, it decreases. Thankfully, now we have elastic servers which increase the number of application servers when traffic rises and retires them once it subsides. Consider an ecommerce website that is deployed as a monolithic application. During a sale, there is a traffic spike in the shopping functionalities (adding to cart, checking out, payment, etc). In the case of monolithic applications, all functionalities, instead of an individual service, need to be scaled horizontally (the entire application needs to be duplicated) unnecessarily even though some functionalities are not used.
• Difficult for developers to collaborate - If one developer changes the database schema, it might break others.

Considering all these disadvantages, developers looked for a better way. 

Rather than having the application combined into one monolithic application and deployed into one machine, why not split the application into smaller mini-applications or small services instead? Thus, we were introduced to the Microservices architecture. These mini-applications, or smaller services are organized around business capabilities, independently deployable services, loosely coupled, and can be developed using different programming languages. In a microservices architecture each service runs its own process. These multiple services communicate with each other over the network and together work as the overall application. 

In order to easily understand the concept of Microservices architecture, let us borrow an analogy from automobile manufacturing using the distributed supply chain methodology.

In the past, a car was a monolithic operation. Both the assembly line and the production of parts were hosted within the same facility. A narrow specification was used to produce the parts, and these were shared among different cars. In order to accomplish this, a generic and flexible car design was required to facilitate assembling and the reuse of generic parts. A single person or development team was in charge of building all the parts of the vehicle at the same time. One part had to be completed to work on the other. This slowed and delayed production.

With time, the monolithic architecture now needed to change to a distributed model. Car manufacturers started focusing more on part specifications and quality. They decided to come up with a design that was flexible enough to create new product parts with higher quality, and would satisfy the specifications of different types of cars. More development teams decided to get involved and focus on each part separately.

What Did the Industry Gain as a Result?

This increased agility and reusability. With the new approach, manufacturers can quickly design and create new product parts. Each of the higher-quality parts are then assembled to create the final car. This led to faster production of vehicles, fewer redundancies, and production of parts with higher quality and efficiency. 

So, how is Microservices architecture similar to the car manufacturing analogy?

Microservices are a way of breaking your application into a series of standalone, independent applications that can be run on different hardware or server instances. The “car” is the ultimate software product. Each part of the vehicle acts as a microservice. In Microservices architecture the team thinks of the output as a product and not a software development project. The advantage of this view is developers see the big picture and create a flexible design. Each part is responsible for its own functionality similar to a microservices architecture where individual services will be responsible to perform its own independent functionality while managing its own database. The vehicle parts are the microservices that users need to compose to make the software product. 

You might wonder whether microservices architectures are the same as Service Oriented Architecture (SOA) that existed a decade ago. Although it is quite similar in style, they are significantly different due to the focus on enterprise service bus (ESB) which is used to integrate monolithic applications. In Microservices architectural style, we care about the components or the service’s specification and not where the service is deployed, hosted, or which technology or frameworks are used to implement the individual services. 

Coming back to the ecommerce website example, developers can create a shopping catalog application just for the respective functionality and deploy it on a separate server. Order processing will be on another server, and user profiles will be on a third server. When the user wants to see the shopping catalog, the UI application makes a REST API call to the catalog application’s API and requests for a product list. The API returns the list and the UI application returns a response with the product list. These mini-applications or microservices talk to each other over the network by calling each other’s APIs. 

These mini-applications are typically called microservices. Microservices architecture is a pattern for organizing computer systems into services that can scale with demand. These communicate with each other over REST APIs and work together to provide the functionality of your product. By designing services this way, users don't have one application to build and deploy, but can have several, mini-applications responsible for doing small functionalities that need to be built and deployed separately, and work together at runtime to complete your actual application. Microservices architecture gives developers the freedom to independently develop and deploy services.

What are the Benefits of Microservices Architecture?

• Flexibility: Service developers of each team can focus and excel on building their own services that can be deployed independently.
• Easy maintenance: If a component is identified as faulty, it can be replaced without impacting other parts in the system.
• Flexible scaling: Required components of the system can be scaled independently, reducing cost and risk to other components.

Just like there are many advantages, there are a few challenges when considering the Microservices architecture.

• Complexity - Due to the multiple applications or services, there are more components to deploy and it is important to realize how these services discover each other. Communication between services can be complex. An application can include dozens or hundreds of different services, and they all need to communicate securely. Debugging becomes more challenging with microservices. When an application consists of multiple microservices, and when each microservice has its own set of logs, tracing the source of the problem can be difficult.
• Service discovery -In a microservices architecture, service instances can change dynamically as a result of upgrades, scaling, service failures, and even service termination. With microservices it is important to ask, How does the service know which REST API endpoints to call in which environment? Developers should consider if they need to hardcode the URLs or have a process around a service discovery.
• Skill - Skilled development teams are needed to carry out and implement the necessary services.

Answering these questions is a way to decide whether you need to implement microservice architecture. This is important as Microservices architecture is not a “one-size-fits-all” solution for all applications. 

The microservices concept is extremely helpful in Cloud computing or SaaS (Software as a Service). The distributed approach can be used to build products by assembling services offered to a certain specification without focusing how those services are created or deployed. At present, Container technologies support a flexible service deployment model. Container providers such as Docker and container orchestration systems such as Kubernetes are leaders in supporting the concept of containerized service or application deployment. Service mesh is a layer of infrastructure that is dedicated for communication between individual services. 

We believe that when managed correctly, microservices can be the agile remedy to the complex monolithic architecture that often drains time and energy from their companies and their employees.