Microservices: Unpacking the Hype

icons representing various Microservices

Rapid progress in the realm of DevOps and the onset of the container deployment revolution has inspired new software architecture paradigms once unthinkable for developers. Previous generations of applications were deployed using tedious manually driven processes on expensive computing devices. With the advent of containers, robust deployment tools and cloud computing, the ability to deploy dozens (or even hundreds) of discrete application parts or microservices have become viable for organization of all sizes. Microservices help promote looser integration and targeted scalability, eventually saving money in terms of hosting costs while still scaling to meet demand. Artemis Consulting uses microservices-based architectures heavily in its Federal projects, to deliver digital transformation and legacy systems modernization. 


Microservices are an architectural pattern used to segment applications into loosely coupled modules that interact with each other using an API. The goal of this design is to encapsulate core business capabilities into a single service that focuses on doing one thing only, and doing that one thing really well. This simplicity promotes reusability across multiple business contexts where services can be aggregated to enable new types of development opportunities though the principle of composability. 


Microservices are deployed independently which can improve developer productivity since they are no longer running or deploying an entire application stack with each build cycle. The rise of containerization technologies, like Docker and Podman, makes it easy to create deployable images of microservices modules and independently scale them as needed. Production environments can increase resources to a particular subset of microservices to meet traffic demands without scaling the entire application. Microservices also benefit from deployment isolation which means if a service fails other parts of a larger application can continue to operate as long as they are not dependent on the failed service.


Before Microservices gained popularity within the enterprise software community, the majority of applications were developed using monolithic software patterns. In the monolithic approach, a single codebase will contain multiple layers of an application and any number of services needed to operate it. Monoliths often pack the presentation layer, service layer and data layer for several services into one distributable unit. As the complexity of a monolithic application grows, so does the codebase which in turn creates more demands on development environments and can hinder productivity. Scaling monoliths in production environments is done horizontally, which means each new deployment utilizes the same number of underlying resources. Teams working on monolithic codebases can also face challenges as the code is more tightly coupled and CI/CD environments are designed to process the entire application through pipelines rather than individual components. 


  • Scalability: Services are individually deployed and resources can be allocated proportionality based on demand. This fine-grained optimization of production environments brings cost savings and greater flexibility to adapt to traffic trends.
  • Ease of Use: The simple nature of microservices means code is more concise and the problem domain being solved is more clearly defined. This helps developers better understand the intent of a particular service in order to extend or reuse it.
  • Polyglot Technology: Since microservices communicate via standardized contracts, organizations can choose to host services built from any programming language, allowing best-in-class design opportunities. It’s not uncommon to see organizations using a combination of Java, Python and Node backends communicating over HTTP/S protocol or messaging systems.
  • Fault Tolerance: Dynamic hosting environments can quickly recover when a microservice fails since applications are deployed as discrete services. Microservices are also easier to monitor and manage.


  • Debugging: Larger systems often use complex orchestration between services. Tracking down an issue requires all of the services in question to be hosted in a way that is accessible to advanced tools used for analysis. The services being tested often depend on other unrelated services that also need to be available during testing. This creates complicated environments that are difficult to host on local developer machines. In CI/CD environments, developers can more easily update and deploy the services they are testing, but gaining insight into problems often requires black box testing via API clients or parsing through numerous log files.
  • Intraservice Complexity: As applications grow, the number of payloads traveling between services grows with it. Understanding how these pieces of data travel through a complex web of services can be time consuming and difficult to trace.
  • Transaction Isolation: Robust ACID transaction managers have long been available to monolithic architectures that can easily roll back database changes when something goes wrong. Since microservices operate independently it can be difficult (or sometimes impossible) to revert changes that occurred prior to a break in the chain of services.  
  • Deployment Synchronization: When multiple microservices are modified in tandem and other dependent applications like front-end UIs depend on these changes it can be tedious to walk all required changes through SDLC practices that involve pull requests and complex CI/CD pipelines. 
  • Developer Productivity: Individuals or small teams of developers can struggle to maintain all the configuration and deployment requirements needed to orchestrate even a small number of microservices. Monolithic applications offer faster iteration for smaller teams while microservices benefit larger organizations that have teams working in parallel. 



An API Gateway provides a single-entry point into a microservices application and allows for intelligent routing of requests from different types of clients. For example, if an organization has both desktop and mobile client applications the API Gateway can detect the type of client from the incoming request and route all or a subset of requests to services built specifically for that client. API Gateways can also be used for security by verifying credentials before a request is routed to destination services. 


If a microservice fails during the orchestration of a synchronous operation across multiple services, the resulting impact can cascade upstream to other callers and cause resources to be allocated for extended periods of time. This latency can quickly exhaust pools of resources and hold threads that could be processing other requests. Circuit Breakers work as a proxy between service calls, ensuring that when a failure threshold has been reached other services upstream can fail quickly and gracefully. 


Traditional distributed systems run services at fixed locations and APIs are consumed using these well-known endpoints. Microservices applications are often deployed using virtualized or containerized environments where service availability and endpoints are changing dynamically. Microservices deployments can use an API Discovery service to maintain a registry of available microservice instances. Client applications make requests to a router that then uses this registry to forward requests to an available microservice instance. 


The use of microservices in enterprise computing is a hotly debated topic. The old guard argue that deployment complexity and fragmentation of codebases bring an unnecessary burden to technology teams and slow down the development process. Supporters will say that isolating code into distinct business domains enhances reusability and prepares applications for massive scale via container-based deployment. One thing is certain, microservices offer an attractive alternative to monolithic architectures, and the tools needed to build and maintain them are steadily increasing in efficiency. Artemis Consulting will continue to use microservices architectures as appropriate to meet client needs.