The document discusses microservices, miniservices, and monolith architectures. It provides an overview of each approach, including their advantages and disadvantages. Microservices are described as small, independently deployable services that use lightweight protocols. Miniservices are a middle ground that relax some constraints of microservices. Monoliths are single applications but the document notes they can be implemented with agile practices. The author concludes there is no single best approach and the optimal solution depends on each project's specific needs and timeframe.
It’s big, it’s bulky, it’s hard to update, but you can kinda figure out what it’s trying to do. It’s the Monolith.
They’re tiny, they only do one thing, they’re easy to replace and upgrade, but you have to monitor them constantly and good luck trying to see the big picture. They’re microservices.
They’re different sizes ranging from big to huge, they’re legacy and modern all mixed together, and they make a purist’s head swim, but they’re very practical. They’re macro and miniservices.
Could be clean layers with excellent software architecture…
If UI tightly coupled to business logic layer which is tightly coupled to the database, this is another form of “monolith”
Can also think of the business logic layer itself as a monolith
No parts are easily reusable (if at all)
Changes to any part ripple throughout entire app
Can’t scale individual functions without scaling everything
TX: no XA, Saga, or other excruciating pain
Change:
- May need to involve UI, business logic, and database teams to make a small change
- May require too much knowledge for one person to make a change alone
Lock-in:
not easy to change languages, platform, tools, etc
Deployment
- Big machines, lots of disk, complex configuration (RAID, clustering, HA, etc.)
- big/manual installation process is common
Must coordinate all teams, dependencies, versions before integrating/deploying
Easy to get out of sync with staging environment – need scrubbed prod data, but hard to get securely
Before jumping into *services, let’s talk about how it all got started: SOA.
Term coined 2011, used more in 2014.
An e-commerce site might have a “get shipping price” microservice.
Conway’s Law
Term coined 2011, used more in 2014
Consider workflow systems (e.g., Camunda) instead of rolling your own state machines and Saga patterns.
Evolutionary refinement over initial perfection
Evolutionary refinement over initial perfection
Evolutionary refinement over initial perfection
Evolutionary refinement over initial perfection
Evolutionary refinement over initial perfection
Evolutionary refinement over initial perfection
Evolutionary refinement over initial perfection
Small problems: easier to understand, explain, innovate, communicate
Small teams: agile, less communication overhead on each team, teams own dev, QA, operations, and support
Small solutions: faster dev, QA, debugging, deployment, smaller resource footprint, fault isolation
Best tools for the job: Each service can be implemented with best fit: language, framework, platform, data store, build & dev tools, easier to evolve over time (add/replace services using latest tech stacks)
Communication: allow sync? Resiliency patterns? Sync: considered harmful due to multiplying downtime (cascading timeouts)
Protocols: REST, HTTP, messaging, gRPC?
State management: eventual consistency, Saga pattern, Kubernetes StatefulSets, AWS services, data stores on VM’s
Cross-team coordination: versioning, SLA’s, status, notification procedures, service replacement/responsibility splitting and changes, deploying features that require changes to multiple services
Deployment: Kubernetes, serverless, nanoservices, service mesh
Operations: logging, tracing, monitoring, metrics, reporting
Cognitive load:
Function call network latency, message formats, load balancing, fault tolerance
Code bakes in assumptions about environment that may be out of date
Service explosion
Big picture, catalog, searchable registry, duplication
Lots of tech ecosystems, implementation languages, etc. – cognitive load
Team dynamics: easy to focus on your own serve to detriment of overall project
Automation: Too many moving parts for manual intervention/workflow
DevOps: Development team supports services in production, deep monitoring w/triggers, self-healing (e.g., Kubernetes scheduling), anti-fragility, etc.
Embrace failure: Constant state of partial failure is the norm in a large busy system – need timeouts, retries, circuit breakers, bulkheads, and the like
API management: required for any solution that exposes API’s to the public Internet and extremely useful even for internal-only API’s.
E-commerce site might have a ”shopping cart” miniservices that provides availability, pricing, and shipping capabilities.
Data store sharing: transactions become much easier (possible), fewer issues with eventual consistency
E-commerce site might have a ”shopping cart” miniservices that provides availability, pricing, and shipping capabilities.
Data store sharing: transactions become much easier (possible), fewer issues with eventual consistency
Culture: Extended team doesn’t have to relearn everything they know about application development and deployment (don’t pay the ”microservice premium”)
Business value: develop and deploy services independently, but don’t sweat the details of perfect functional decomposition and granularity of every inner API (e.g., can break “bounded context” restriction for convenience/performance/orchestration/maturity). Most important: can share data sources!
Communication: not forced into completely async, message-driven, full isolation, service mesh-based architecture