One app or many services?
Published Updated
This is the Learning Atlas from Orbit. Get your invite
Concepts and methodologyBuild/deploy toolingHostinginfrastructuredatabases
-
Step 1: Monolith
Why this matters here
Begin with one deployable app to understand the simplest ownership and release boundary.
In short
An application whose main features are built and deployed together as one unit.
-
Step 2: Microservices
Why this matters here
Split only when independently owned or scaled services justify the added coordination work.
In short
An app design made of separately running services that own focused responsibilities and can be deployed independently.
-
Step 3: Service discovery
Why this matters here
Separately running services need a way to find each other when their addresses change.
In short
A way for running services to find the current network address of another service.
-
Step 4: Kubernetes
Why this matters here
Then explore a platform for managing containerized services, without treating it as a requirement for every app.
In short
An open-source system developed by Google for automating the deployment, scaling, and management of containerized applications across massive clusters of servers.
-
Step 5: Distributed transaction
Why this matters here
Examine why a checkout spanning separate data owners makes all-or-nothing updates difficult.
In short
A coordinated unit of work that changes data across multiple systems and aims to keep those changes consistent.
-
Step 6: Saga pattern
Why this matters here
Finish with local steps and compensating actions for workflows that cannot share one atomic transaction.
In short
A multi-step workflow of local transactions with compensating actions that address earlier completed steps when a later step fails.