Skip to content
Search

Microservices

lastmod 2025-09-02created 2016-03-289 edits

Subfields of microservices

A microservice is a software development technique — a variant of the service-oriented architecture (SOA) style — that structures an application as a collection of loosely coupled services. In a microservice architecture, services are fine-grained and the protocols are lightweight. The benefit of decomposing an application into several smaller services is that it improves modularity, makes the application easier to understand, develop, and test, and makes it more resilient to application erosion. It enables parallel development by letting small autonomous teams develop, deploy, and scale their respective services independently. It also allows the architecture of individual services to emerge through continuous refactoring. Microservice-based architectures enable continuous delivery and deployment.

Things to consider when moving to MSA

"Monolith > apps > services > microservices"

  • First, this is not a rule; it's just what I think. Anyone who has built large distributed systems knows it never works exactly like that and you have to adapt
  • Second, stage matters
    • If you're a 5-50 person company, just go Monolith
    • If you're a 10,000 person company, you'll have all of the above. But here's how my thinking has changed from before..

First, definitions

  • monolith - xyz.com
  • apps - abc.xyz.com
  • services - support apps/the monolith, core infrastructure, core compliance functions, may not be written by app teams (maintained by infrastructure)
  • microserivces - a few hundred lines of code, mostly one-offs, could/should be a library or SDK

Why? : basically because of "Speed & Risk"

  • It's easier for the whole dev team to develop in one big app (think of the entire site as a Rails app)
  • The distributed system you will inevitably have as you grow is already hard to reason about, even without hundreds of inherently risky microservices
  • If you go fully micro, you have to introduce new concepts to deal with the sprawl
  • Bespoke infrastructure services or microservices are the extreme form of debt. Code is debt, but services are the extreme version of it. Think about what that means. Make them leverage points
  • Distributed systems engineers hate duplication, so when something happens in multiple places, they think "let's pull this out and make a microservice"
  • In theory this is right, and it's fine up to a dozen or two. But beyond dozens, or when used across a large company, it becomes an organizational problem rather than a technical one
  • What I'm saying may feel like a false dichotomy, but there really are technical challenges with microservices, and even more organizational problems

What I worry about

  • (Unless unusually led by a CEO from an IT background) infrastructure always gets the short end of the priority stick
  • Too many services generally cause ownership and boundary problems
  • More tools get introduced to deal with the many microservices
  • Most importantly, each microservice that should have been a library or SDK introduces risk into production

What I generally recommend

  • Keep the Monolith as long as possible
  • Start services from what infrastructure needs, not from the app development side
  • If you must split the Mono, break it into big apps, not small services
  • Think of each new app as a virtual wall within the company
  • Prefer libraries over microservices where possible

See also

Favorite site

References

  1. Monolithic_to_Microservices_Architecture_with_Patterns_and_Best_Practices.pdf ↩

author Zer0 sitemap