There are good reasons why people love a good set of rules about how to go about their jobs. Here’s a new one: 12 Factor Micro-Services. It’s part of the enthusiasm for containerizing everything, and it seems to live off the energy produced by the eternal tension between development and operations.
- Codebase: One codebase tracked in revision control, many deploys
- Dependencies: Explicitly declare and isolate dependencies
- Config: Store config in the environment
- Backing Services: Treat backing services as attached resources
- Build, release, run: Strictly separate build and run stages
- Processes: Execute the app as one or more stateless processes
- Port binding: Export services via port binding
- Concurrency: Scale out via the process model
- Disposability: Maximize robustness with fast startup and graceful shutdown
- Dev/prod parity: Keep development, staging, and production as similar as possible
- Logs: Treat logs as event streams
- Admin processes: Run admin/management tasks as one-off processes
I find this an odd list. I don’t per-say have much issue with it, but are these really the top twelve things to keep in mind when designing the modern cloud based monster?
For example that point about codebase. We all build systems out of many many 3rd party components, which means there are numerous codebases. Why would that modularity be appropriate only at the project or firm boundary?
Which brings us to the question of how you take on fresh releases of third party components, and more generally how you manage refresh to the design of the data stores or the logging architecture, or the backup strategy. All these are pretty central but they aren’t really on this list.
Which maybe why this is a list about “micro-services.” Which again, I’m totally on board with. And yet, it seems to me like a fetishization of modularity. Modularity is hard, it’s not cheap, and damn-it sometimes it just is not cost effective. This is not about the dialectic between dev and ops, this is about the dialectic between doing and planning, or something.
It is like the way people assume there is optimal size for a function when it is the outliers that are full of interest.
Generally when designing the outliers are.
Meanwhile, who says I can’t have teasers after my blog postings:
- Here’s a sweet argument for life’s origin predating the planet’s formation.
- I wonder what he’d say about Codeplex today, and Github.
- see?