After its introduction around 2004, Microservices have gained much traction in Industry and Government. Some primary adopters of Microservices include Industry giants Netflix, Uber, Spotify, Amazon, and Meta. In Government, adopters include the Environmental Protection Agency (EPA), General Services Administration (GSA), and the Department of Agriculture (USDA). Industry businesses such as Netflix are run in their entirety with Microservices. Microservices provide a basis for modern custom Cloud-First/Native applications. This article will examine Microservices’ definition, benefits, uses, and architecture.
Microservice architecture is a variant of the Service-Oriented Architecture (SOA) structural style in Software Engineering. Microservices are an architectural pattern that arranges an application as a collection of independent, loosely-coupled, fine-grained services communicating through lightweight protocols. A Microservice stands on its own; in other words, Microservices are independent. A Microservice can also be used along with other Microservices to accomplish broader tasks; in other words, Microservices are loosely coupled. The scope of a Microservice has small/limited functionality and is hence termed fine-grained. This means that, for example, if an application needs to keep track of customer orders, then a possible Microservice scope would keep track of just customer contact information. Methodologies such as Domain-Driven Design (DDD) are used to find the right balance for Microservices functionality. Microservices also communicate through lightweight protocols such as Hypertext Transfer Protocol Secure (HTTPS) with Representation State Transfer (REST) Application Programming Interfaces (APIs), e.g., https://domain/version/microservice/data. An overall application is built using several or many Microservices – essentially breaking the application up into pieces that can operate independently rather than as a single entity.
One of the goals for Microservices architecture is to have small self-contained teams that can develop and deploy their microservice independently. This is achieved by reducing dependencies, allowing developers to evolve their Microservices with limited user restrictions, and for additional complexity to be hidden from users. Consequently, organizations can develop software with fast growth and size and use off-the-shelf services more efficiently. Communication requirements are reduced. These benefits come at a cost to maintaining the decoupling. Interfaces need to be designed carefully and treated as public APIs. One technique used is having multiple interfaces for the same service or various versions of the same service to not disrupt existing service users. Microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features.
Microservices stand in contrast to monolithic architectures, where all processes are tightly coupled and run as a single service. This means that the entire architecture must be scaled if one application process experiences a spike in demand. Adding or improving a monolithic application’s features becomes more complex as the code base grows. This complexity limits experimentation and makes it challenging to implement new ideas. Monolithic architectures add risk for application availability because many dependent and tightly coupled processes increase the impact of a single process failure.
In contrast, in a Microservices architecture, an application is built as independent components that run each application process as a service. These services communicate via a well-defined interface using lightweight APIs. Services are made for business capabilities, and each service performs a single function. Because they are independently run, each service can be updated, deployed, and scaled to meet the demand for specific tasks of an application.
Microservices do not compete with or replace Low/No Code solutions. Rather, Microservices and Low/No Code can be seen as complementary technologies. In contrast to Low/No Code solutions, Microservices are used when a high degree of customization is needed, e.g., Section 508 full compliance. However, Microservices and Low/No Code have areas of overlap. In fact, in some cases, Microservices are as cost-effective based on Total Cost of Ownership (TCO) as Low/No Code with Analysis of Alternatives (AoA) with similar time-to-market characteristics. A Microservices Reference Architecture is shown in Figure 1 below. Within the architecture, a front-end web application makes a REST API call via a browser to a Microservice. The Back-end Web service then handles the browser’s HTTPS request. Back-end Web service can be implemented with open-source commercial-off-the-shelf (COTS) components like Apache. The Back-end Web service then routes the request to an API Gateway, which maps the request to a particular Microservice for processing.
Figure 1 Microservices Reference Architecture
API Gateways can be implemented with open-source COTS components such as Netflix Zuul or services such as the Azure App Service. Depending on the level of reliability needed, Microservices can be run in dual-redundant mode with failover. This is true of data services for the Microservice itself. For the API Gateway to map a request to a Microservice, the Registration
Common Service is used. A Registration Common Service can be implemented with open-source COTS components like Netflix Eureka. The API Gateway also monitors the heartbeat of a Microservice and determines if a failover needs to be triggered. Microservices make use of Common Services such as:
· Directory for Authentication and Authorization can be implemented with services such as Azure Active Directory.
· Web Analytics for usage data can be implemented with services such as Azure Monitor.
· Serverless Computing for small, infrequently used functionality scheduled on-demand and can be implemented with services such as Amazon Web Services (AWS) Lambda.
· Secrets/Certificates for connection/communication can be implemented with services such as Azure Key Vault.
· Storage for long-term data retention can be implemented with services such as AWS S3 Glacier.
· Distributed Logging/Tracing for application debugging can be implemented with services such as Azure Monitor or Amazon MQ or open-source COTS such as ActiveMQ and Elasticsearch, Logstash, and Kibana (ELK) stack.
· Artificial Intelligence / Machine Learning (AI/ML) for metadata tagging and other functionality can be implemented with services such as AWS ML.
· Messaging between Microservices and Common Services can be implemented with services such as Azure Service Bus.
· Agile Management to manage development projects/programs and can be implemented with services such as Jira or Azure DevOps.
· Continuous Integration / Continuous Delivery (CI/CD) to automate release and deployment and can be implemented with services such as AWS Pipeline.
· Containers for faster deployment and resource efficiency and can be implemented with services such as Azure Kubernetes Service (AKS).
Centennial Technologies Inc. has applied Microservices at the Environmental Protection Agency (EPA) and other Federal agencies. We have the experience and subject matter experts to help your organization analyze, architect, implement, develop, deploy, and operate Microservices. We can also help you tailor the implementation of Microservices to your organization’s needs with the right balance between open-source COTS, Software as a Service (SaaS), and Platform as a Service (PaaS) to yield faster time-to-market, scalable, and resilient applications.
Point of Contact
Sidney Antommarchi
Director of Solutions
sidney.antommarchi@centennial-tech.com