Microservice introduction

Christopher Woodward Christopher Woodward
Introduction to Microservices
Photo by rawpixel on Unsplash

What is a Microservice

Beyond the media-hype surrounding microservices, a microservice architecture is simply a variant of the Service Oriented Architecture (SOA) pattern where applications are built from a suite of services.

Similarities to SOA

In both architectures, each service:

  • Is responsible for providing a subset of the applications overall features.
  • Can communicate with other services across a network through a well-defined API.
  • Can be developed using the most appropriate technology.
  • Can be a data consumer, producer or both.
  • Responsible for persisting its data.
In both architectures, developers work with both distributed architectures and distributed data and must contend with the complexities of inter-service communication.

Differences from SOA

Sharing

SOA is built on the "share as much as possible" idea. This high degree of sharing leads to an unnecessary, and undesirable coupling of code between services. Microservices take the extreme opposite approach. By sharing as little code as possible, each microservice is more independent and has more freedom to choose how it implements its features.

Service Reuse

SOA places great importance on business functionality reuse. One of SOAs guiding principles is the Service Reusability principle with the stated goal of creating services that can be reused across the enterprise. Microservices embrace the Domain Driven Development concept of "Bounded Contexts" with each service being designed exclusively for a specific context within an application. In microservice architectures, the focus of every services is placed strictly on application functionality and not enterprise reuse.

Governance

SOA imposes common governance and standards across services. The motivation behind this is related to the Service Reusability principle which treats each service as an IT asset governed at the IT administration level. Microservice architectures relax services governance and place a greater focus on collaboration and flexibility. Each microservice development team is responsible for the governance of the services it develops. In short, microservices are independent and self-governing.

Communication

SOA uses an Enterprise Service Bus (ESB) for all inter-service communications. Microservices can use whatever communications mechanism is most suitable. Whether direct communications between services via REST or Message-driven, each microservice is free to decides the best mechanism to communicate with other services and the outside world.

Microservice Application Architecture Characteristics

Broadly speaking, microservice architectures generally decompose an application into individual microservices aligned across functional areas with each service executing in a separate process. Each service is responsible for implementing its set of functionally-related features as well as for managing its state. To manage state, each service has its own database.

Independent service deployment has several benefits:

  • Each service's lifecycle is managed independently.
  • Changes to the services (e.g., new features, defect fixes) can be implemented and deployed without the need to coordinate with other services (provided the public interface doesn't change).
  • Since each service exists in a separate process, the crash of an individual service won't bring down the entire application allowing other features to continue.
This service independence facilitates continuous deployment, and as we will address in the next article, greatly enhances our ability to scale the service in response to load.

As mentioned previously, all access to a service's state is mediated through its API. This isolation provides a firewall around the service's data and is intended to prevent other services from directly accessing or modifying its state. Services are loosely coupled via the service's API allowing eache service's underlying implementation to change without affecting its consumers. By isolating data persistence, the service has the freedom to manage its persistence without regard to any other service. Isolating the persistence mechanism on a per-service basis allows the service to change the internal data representation and potentially even its technology without external coordination.

Microservices communicate with each other through both synchronous(HTTP/REST) and asynchronous (Message Bus) mechanisms. This approach gives developers the flexibility to choose the most suitable mechanism for the needs of a service.

With a microservice approach, each team focuses on implementing, deploying, and managing a subset of the broader application's functionality when building a service. This structure provides teams with freedoms that would have been difficult or impossible to realize in monolithic applications. Because each service is, in essence, its own application, each service can be implemented in the most suitable languages using the framework for the requirements. This freedom extends to data persistence as well, allowing alternate database technologies (e.g., relational, document, graph, etc. ) to be employed when the team deems them more suitable. From deployment scheduling, to implementation and persistence selection, each service is empowered with the freedom to choose its best path.

Finally, By executing in unique processes, each service achieves a high degree of execution isolation. This isolation, coupled with the use of networking, gives each service the freedom to execute in a separate container, server, or potentially a different data center. This freedom of location provides an operational flexibility that is unachievable with monolithic architectures.

Summary

We've learned that microservices are a form of distributed system that decomposes an application's functionality into a suite of services that in the aggregate constitutes the application. While similar to SOA, microservices focus only on the functional needs of its application and is not concerned with re-use across the enterprise.

Microservices are self-governing rather than centrally governed and allow for greater granular scalability through service replication to provide for better resource utilization.

Coming Up

At the core of microservices is the notion of isolation. In the next article, we will discuss the principles of isolation and how microservices help us achieve them.