Managed vs Self-Managed
Trading control and unit cost against operational attention.
5 to work through
-
intermediate
A platform runs several self-managed stateful systems. What evidence should decide whether to move to managed services?
2 min answer -
intermediate
A team is deciding whether to keep using a managed service or bring it in-house. What trigger should govern the decision, and what asymmetry usually settles it?
2 min answer -
intermediate
A team is deciding whether to run a database, broker or search engine itself or to use a managed service. What actually drives the decision, and which arguments are usually wrong?
2 min answer -
intermediate
Under what circumstances would you self-manage a message broker rather than use a managed service, and how would you justify it?
2 min answer -
advanced
Your team runs a large self-managed streaming cluster. Two engineers hold most of the operational knowledge. A managed alternative exists. How do you decide?
2 min answer
5 terms in this topic
Decision Trigger
A number or condition agreed in advance that would cause a decision to be revisited - which converts a permanent choice into a monitored one and prev…
practiceFully-Loaded Comparison
Comparing options with engineering time, operational burden and opportunity cost included rather than infrastructure and licence prices alone - which…
practiceManaged versus Self-Managed
Whether to run a component yourself — a decision that should default to managed and require a specific articulated reason to deviate.
practiceOperational Burden Assessment
Quantifying the ongoing engineering effort a self-managed component requires, so it can be compared honestly with a managed service's price.
case-studySpotify: Trading Kafka Operations for a Managed Service
Spotify moved its event delivery backbone from self-managed Kafka to a managed pub/sub service, choosing to buy back operational capacity rather than…
Neighbouring topics
Architecture Decision-Making
General material on making and recording architectural decisions.
Architecture Decision Records
One decision, its context, alternatives and consequences, kept immutable.
Reversibility
One-way and two-way doors, and buying optionality deliberately.
Build vs Buy
Differentiation, five-year TCO, and the exit cost of each option.
Monolith vs Microservices
A team-topology decision far more often than a technology one.
SQL vs NoSQL
Decided by access patterns and query flexibility, not by data volume.
Sync vs Async
Whether the caller's outcome depends on the callee's response.
Strong vs Eventual Consistency
A per-operation decision, resolved by what a stale read would cost.
Serverless vs Containers
Spiky and event-driven versus sustained throughput.
Single vs Multi-Region
Driven by RTO, RPO and residency rather than by ambition.
Centralised vs Distributed
Shared platform leverage against team autonomy.
Performance vs Cost
Buying latency, and knowing what the last millisecond is worth.
Reliability vs Complexity
Mechanisms that add availability and add failure modes.
Security vs Usability
Varying control by the value of the action rather than uniformly.
Delivery vs Maintainability
Fast in the cheap places, careful in the expensive ones.
Deciding Under Uncertainty
Bounding the downside and buying information cheaply.
Trade-off Analysis Methods
ATAM, scenarios, and naming the points where qualities conflict.
Technology Selection
Evaluating options against drivers rather than against enthusiasm.
Decision Practice
Thresholds, review, supersession and keeping the log alive.