What Is a Microservice? Small, Independently Deployable Services
A microservice is a small, independently deployable service that owns a single business capability and talks to other services over the network.
Microservices split a system into many small services, each with its own codebase, data store, and release cadence. Instead of one big deploy, you deploy dozens of services on their own schedules. That independence is the whole point, and it is also what makes the CI/CD story more interesting than a single monolithic build.
What makes a service a microservice
A microservice owns one capability end to end: its own code, its own database or storage, and a clear API boundary. It can be built, tested, and deployed without coordinating a release with the rest of the system. Communication happens over the network, usually HTTP or a message bus.
Why teams adopt them
- Independent deploys: one team ships without blocking others.
- Targeted scaling: scale only the hot service, not the whole app.
- Technology freedom: each service can pick its own stack.
- Fault isolation: one service failing need not take down the rest.
The CI/CD shift
A monolith has one pipeline; a microservice estate has one pipeline per service. That means many small, fast builds instead of one slow one, but also more pipelines to maintain, more artifacts, and a need to test how services behave together, not just in isolation.
New testing burdens
Unit tests stay simple, but you now need contract tests and integration tests to catch breakage across service boundaries. A change that passes a service own pipeline can still break a consumer, so testing the seams becomes as important as testing the code.
Deploy coordination
Independent deploys are a benefit until two services must change together. Backward-compatible APIs, feature flags, and careful ordering let you ship services one at a time. Without that discipline, "independent" deploys quietly become coupled ones.
Microservices on managed CI
Dozens of small services mean dozens of frequent pipeline runs, which is exactly where queue time and cold starts add up. Managed runners (like Latchkey) keep warm capacity ready so a burst of per-service builds picks up immediately instead of waiting in line.
Key takeaways
- A microservice is small, owns one capability, and deploys independently.
- Many services mean many pipelines and a stronger need for contract and integration testing.
- Backward compatibility is what keeps "independent" deploys actually independent.