This article draws on publicly available information about microservices architecture, including concepts discussed in coverage of Red Hat’s 2017 microservices survey conducted with Red Hat JBoss Middleware and Red Hat OpenShift customers. Original source: meritalk.com.
The Problem with Monolithic Architecture
For decades, Federal agencies and large enterprises built their software the same way they built their headquarters: as massive, rigid, monolithic structures. A single large application — a benefits payment system, a tax calculation engine, a warfighter logistics platform — would grow over time, accumulating complexity, technical debt, and fragility. When one component failed, the entire system could collapse. When demand spiked unexpectedly, the only answer was to buy bigger hardware.
Before the DevOps movement and agile development practices took hold, software teams had little choice. Large applications could not easily be decomposed and distributed across teams or infrastructure. Resource bottlenecks — whether from the database, memory, or network — would choke the entire stack with no clean way to scale only the affected part.
What Microservices Are
A microservices architecture structures an application as a collection of small, loosely coupled services. Each service implements a specific, well-defined business capability — a tax calculation, an authentication check, an inventory lookup — and communicates with other services through simple, well-defined interfaces, typically lightweight APIs.
- Independent deployability: Each microservice can be built, tested, deployed, and scaled independently of every other service.
- Technology flexibility: Different services can use different languages or data stores if the team chooses.
- Fault isolation: A failure in one service does not automatically cascade and bring down the entire application.
- Team autonomy: Small, focused teams own individual services end-to-end, reducing coordination overhead and enabling faster iteration.
As David Egts, chief technologist at Red Hat, put it: instead of one large team working on one large application, you can have small teams working on different microservices — and all they have to worry about is their own service.
What the Data Shows
In the fall of 2017, Red Hat conducted a survey of Red Hat JBoss Middleware and Red Hat OpenShift customers to understand how organisations were adopting microservices. The survey explored adoption patterns, perceived benefits, key challenges, and competitive advantages.
According to that survey, 69 percent of respondents reported using microservices for both new greenfield applications and for re-architecting existing legacy systems. This dual use — not just for new projects — suggests that microservices deliver value at multiple stages of an organisation’s IT transformation, not only when starting from scratch.
Why Microservices and the Cloud Are a Natural Fit
Cloud infrastructure is built around elasticity — the ability to provision and release compute resources rapidly in response to demand. Microservices are architecturally aligned with that model in a way that monolithic applications are not.
Consider a practical example: an online retailer runs a sales tax calculation service. On a high-traffic day like Black Friday, that single service receives an enormous surge of requests. With a microservices approach running on a cloud platform, the organisation can spin up additional containers running that specific service to absorb the load — and then scale them back down once traffic normalises. No capacity is wasted during quiet periods, and no users are turned away during peaks.
In the era of mainframes and Unix servers, the only path to more capacity was purchasing larger hardware. Cloud-based microservices replace that model with dynamic, on-demand scaling — and the same principle applies to government agencies managing variable workloads.
Cloud platforms can also automatically shift microservice containers to healthy servers when underlying software or hardware fails, providing continuous availability without manual intervention.
The DevOps Angle: Continuous Delivery at Scale
Microservices architecture is not just an infrastructure concern — it has direct implications for how DevOps teams work. The goal is simple to state and difficult to achieve: deliver quality software faster. Microservices support that goal in several concrete ways:
- Faster release cycles: Because services are independent, a team can release an update to the payment service without waiting for a full application deployment cycle.
- Reduced blast radius: A bug in one service does not necessarily require rolling back the entire application.
- Parallel development: Multiple small teams can work simultaneously on different services without blocking each other.
- Continuous integration and delivery: Each microservice can have its own CI/CD pipeline, enabling truly continuous deployment across a large, complex system.
Challenges DevOps Teams Must Address
Breaking an application into microservices is not the end of the work — in many ways, it is the beginning. DevOps teams adopting microservices need to address a range of new operational concerns:
- Service orchestration: Managing dozens or hundreds of services requires a container orchestration platform such as Kubernetes or Red Hat OpenShift to handle scheduling, scaling, and health management.
- Observability: Distributed systems are harder to debug. Teams need robust logging, distributed tracing, and monitoring across all services.
- Data management: Each service may own its own data store. Keeping data consistent across services adds architectural complexity.
- Network complexity: Service-to-service communication introduces latency and failure modes that do not exist in a monolith. Service meshes can help manage this.
- Security: Each service endpoint is a potential attack surface. API authentication, encryption in transit, and least-privilege access controls must be applied consistently.
Once these operational challenges are addressed, the result is a highly agile network of services that teams can deploy, scale, or retire independently — and that agencies can adapt quickly to changing requirements or usage patterns.
On-Premises vs. Cloud-Based Microservices
Microservices can be deployed both on-premises and in the cloud. For organisations with strict data sovereignty or compliance requirements — common in government environments — on-premises container platforms provide many of the same architectural benefits. However, cloud-based deployments offer additional advantages: elasticity is easier to realise, managed services reduce operational burden, and multi-region deployments for high availability are more accessible.
Hybrid approaches — running some services on-premises and others in the cloud — are also viable and increasingly common for agencies navigating complex regulatory environments.
Key Takeaways for Agency DevOps Teams
- Microservices decompose large, fragile monoliths into independently deployable, scalable units aligned with specific business capabilities.
- The architectural approach supports continuous delivery pipelines and autonomous team structures — core DevOps principles.
- Cloud elasticity and microservices are complementary: scaling individual services on demand reduces waste and cost while maintaining availability.
- Adopting microservices requires investment in orchestration, observability, and operational tooling — breaking up the monolith is only the first step.
- Both new projects and legacy modernisation efforts can benefit from a microservices approach.