paint-brush
Stop spending engineering effort solving problems you don’t haveby@doctor_julz
1,841 reads
1,841 reads

Stop spending engineering effort solving problems you don’t have

by JulianMarch 10th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

This post comes from a place of frustration. I apologise in advance.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Stop spending engineering effort solving problems you don’t have
Julian HackerNoon profile picture

This post comes from a place of frustration. I apologise in advance.

If you are writing a web app — a great web app, a fantastic web app, THE BEST EVER WEB APP — you do not need a container orchestrator. You need a PaaS. You do not need 5 different ways to deal with rolling out new versions of your app. You do NOT need to be able to configure and tweak your database. Do not manage your own database! You do not need etcd. For everything that is holy: do not install consul. You do not have these problems. These are not your problems. Do not buy yourself these problems.

Here’s a quick cheatsheet to help you avoid these things:

How To Package and Orchestrate App Updates

Look. You’re writing a web app. Put your data in a service someone else maintains. If you’re using Amazon, RDS seems good. Or, if you’re using Cloud Foundry (on BlueMix or PCF or GCP or wherever), bind a database service (mysql is fine).

Now, what you have left is a simple, stateless web app. Let the platform deal with packaging and upgrading that app. Your app doesn't have state and is a simple web app so this is easy.

Please, don’t create a custom rollout strategy or (are you kidding me now?) a ReplicationController, don’t build a “docker compose file” or a “pod” with redis and mysql in it, or an “operator” to deal with upgrading it. Don’t use chef or puppet unless you’re ordering food or performing in a children’s show (why are you reading this?). Push simple web apps. Use a platform that makes that easy. This should be easy.

How to Manage and Upgrade Production Databases

Don’t manage production databases. Use a service provided, scaled and maintained by someone else. Use a service BACKED UP by someone else. Worry about changing this when this becomes a real problem for you (Hint: you will know when this is you). Again, any good platform will make this easy.

How to Do Service Discovery and Manage Quorum

Are you trying to give me a heart attack? Do not do this. You’re writing a web app. You’re a small business or a large business and you’re writing a web app for all that is holy do not invest time in service discovery. Do not run etcd. Do not run zookeeper. Do not run consul. Consul is great if you need to manage a distributed micro-service system. You do not need to do this. Don’t do this. Just push your damn web app to a damn platform, OK? Ok.

Post-Script: What to do if you ARE writing a complex micro-service-based stateful distributed application that actually needs quorum and service discovery

Write a simple web app instead. Thank me later.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!