Andrew's Digital Garden

12 fractured apps

Docker + [[12factor]] apps are a great combo. However, people often use Docker containers as VMs, creating unnecessarily large VMs.

Additionally, too many developers use poor startup processes. Too many assumptions lead to an unclean startup. e.g. relying on a pre-existing database that may or may not exist in time.

Subtly broken applications make developers reach for tools like Ansible or Puppet immediately. This is a mistake. It's a band-aid solution solution to mask you not following a 12 factor app. Instead, most things can be solved by good old fashioned programming. e.g.

  • Don't require a config file, use environment variables
  • Retry the database until it's up, instead of using deploy tools to mandate it exists prior
  • etc.

Don't add additional complexity when you can fix the root cause. Don't rely on a 'happy path' for your application to successfully startup.

Remember, ship artifacts not build environments.

Don’t get me wrong, using an entrypoint script is ok for applications you don’t have control over, but when you rely on custom entrypoint scripts for applications you write, you add another layer of complexity to the deployment process for no good reason.

Everything in this post is about improving the deployment process for your applications, specifically those running in a Docker container, but these ideas should apply almost anywhere. On the surface it may seem like a good idea to push application bootstrapping tasks to custom wrapper scripts, but I urge you to reconsider. Deal with application bootstrapping tasks as close to the application as possible and avoid pushing this burden onto your users, which in the future could very well be you.

https://medium.com/@kelseyhightower/12-fractured-apps-1080c73d481c

[[architecture]] [[deployment]] [[docker]] [[infrastructure]] [[ops]]

12 fractured apps