Avoid complex infrastructure when building simple things

3 suggestions on how to stay simple and avoid complexity

“You don’t understand — as soon as I install consul, set up service discovery for my microservices, build my own containerized continuous integration pipeline to build my code from source using my custom language-specific Dockerfile and set up my highly available production database my system for deploying code to production will be so simple.”

“How many people are in my team? Oh, it’s just me. But one day..”

Sigh ;-).

There’s a lot of complexity in things we use to reduce complexity. This is worth noticing. Three examples:

When to use Micro-services

When it makes things easier to maintain than just deploying a simple monolithic app. If you can easily deploy a monolithic app (i.e. you’re one small team and it’s not an enormous app), you probably should. Micro-services have a significant infrastructure complexity cost over simple monolithic apps. Service discovery, multiple components, orchestration — these things are not free, they blow up, and you have to fix them, and maintain them. Pay this cost only if a monolithic app will not scale.

When to run your own Database

For local development, go crazy. For real production use.. I think you should avoid this until you’re the size of business that someone else will do this for you. If this seems controversial do the math: include backing it up, patching it, keeping it highly available, the time spent not working on your differentiating features etc. There are plenty of datastore services available that will do all this for you and let you focus your limited time on your app, and they’re really very cheap when you consider the actual cost of running a production database. Write your app so that the cost of moving to your own database later if you need to is unlikely to be high. Managing a simple web app instead of managing a web app, a production database, a message queue etc is a big win.

Aside: But How can I Trust Someone Else to Run My Database?

How can you trust them to run your IaaS / blob store / load balancer / container registry etc etc? It’s 2017, we’re all relying on cloud services other folks maintain now.

When should I use Containers?

Look, my actual day job is writing containers. I love containers. Containers are amazing. 90% of developers shouldn’t need to deal with them.

Use a platform that will let you push code and will take care of packaging it, patching the Operating system, binding services, routing logs, load balancing etc etc. If you’re writing that platform, containers are a great tool. If you just want to take code and run it in production, they’re a distraction. There are platforms such as Cloud Foundry (disclaimer: which I work on and love!) that entirely hide the containers, or platforms like Deis Workflow that sit on top of Kubernetes, see if there’s a hosted version that fits your needs. Look at “Serverless” systems like AWS Lamda, maybe they’re all you need. AppEngine is worth a look, though you can end up a bit coupled to the platform. Containers are a great tool for building a PaaS, if you can just use an existing PaaS you might save a lot of time and complexity.

The important exception to all these rules

Are you building this for fun, just to learn, as a hobby or because you’re working for a massive company that genuinely has these problems? Or, are you writing a persistent distributed service or something that really really needs custom orchestration? Go crazy, enjoy!

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!