The blueprints of a “no-ops” startup

I love doing ops, I really do. There’s nothing like setting up servers, choosing my favorite Linux distro, upgrading those servers, making sure they scale, configure the right amount of open file limit, SSH authorization and install all the needed stuff.

Oh, wait — there’s Docker now. Just write a Dockerfile, build it, send it to the docker repository, then configure auto-scaling groups and attach docker images to them, don’t forget we need to build it and wire it to our CI. A little bit of hacking to run them for dev, oh — we also need to orchestrate all of them. Well, it’s all so simple. I wonder why my colleagues find it difficult and I have to do all the work and explain all the time.

Now seriously. I really love doing ops/dev-ops, it has all the nice things I like about computers. You have a problem, you fix it, your team loves you for making everything work better. This is the problem with dev-ops and small startups, it can suck too much of your time.

For my current startup, I decided to go the most no-ops as possible. Why?

1. Focus on our product and not the infrastructure running it.
2. An infrastructure that scales without needing to do anything about it.
3. Happier lives, with reduced incident alerts of servers going down, traffic spikes and security issues.

I used to laugh at people using services like Heroku — these people know nothing about how things work... but actually, they don’t always have to, at least not when starting out.

There are a few ingredients to a no-ops infrastructure, the first is using a static web application and removing the Node.js/Rails/whatever layer for the website. When hosting static files, there’s less room for ops. The second is using a FaaS solution for dynamic actions and APIs. These are functions that run as needed, so they can scale endlessly* and should cost less than running a server 24x7.

(* — Endlessly as in “AWS can handle this”)

What tools are we using? I can recommend the following:

Netlify is a CDN for static web applications. Netlify connects to a GitHub repo, builds and deploys our static site to locations around the world.

AWS Lambda is a FaaS solution. We use this for background processing jobs — no need to keep servers up. It works as advertised, but isn’t the easiest to work with. Some open-source projects aim to abstract this complexity like Apex, Serverless and others. We use Apex and local tooling to run the code locally.

Now by zeit.co deploys code to immutable servers and scaled them internally when needed. While I wish to run all code as FaaS, it is easier to see it as one app. We deploy our Node.js API server to Now and it works well. There’s an option to move the entire Node.js app (powered by Hapi.js) to one FaaS, but we don’t currently use this.

AWS RDS manages our relational database. Almost no operations needed, but is the main focus of dev-ops currently.

There are some things that are still not solved:

• Static web applications may take more time to load as all the JS needs to be loaded first. A solution based on servers can be a Universal/Isomorphic/Server-rendered app which breaks the idea of static hosting. Web workers can be used to cache data and app shells for perceived performance gains.
• Authentication on static web applications isn’t great. First the app needs to load, then we figure out with the API server who’s the user and only then we can show them the correct page: login page or the app itself.
• Working locally with Lambdas isn’t the easiest and you’ll probably need to write custom scripts to run them on your machine. Localstack is an open-source that mimics AWS environment, but I believe the solution should be to abstract away the running Lambdas rather than simulating AWS itself.

The services I mentioned all run on AWS behind the scenes, but abstract the dev-ops away. I wonder if this abstraction can hold forever or at some point, a move back to AWS itself will be needed.

If you enjoyed this post, click the ❤ and share it.