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 as possible. Why? no-ops and not the infrastructure running it. Focus on our product An infrastructure that about it. scales without needing to do anything , with reduced incident alerts of servers going down, traffic spikes and security issues. Happier lives I used to laugh at people using services like — these people know nothing about how things work... but actually, they don’t always have to, at least not when starting out. Heroku There are a few ingredients to a no-ops infrastructure, the first is using a 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 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. static web application FaaS (* — Endlessly as in “AWS can handle this”) What tools are we using? I can recommend the following: is a CDN for static web applications. Netlify connects to a GitHub repo, builds and deploys our static site to locations around the world. Netlify 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 , and others. We use Apex and local tooling to run the code locally. AWS Lambda Apex Serverless by 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 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. Now zeit.co Now manages our relational database. Almost no operations needed, but is the main focus of dev-ops currently. AWS RDS There are some things that are still not solved: Static web applications may 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. take more time to load . 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. Authentication on static web applications isn’t great and you’ll probably need to write custom scripts to run them on your machine. 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. Working locally with Lambdas isn’t the easiest Localstack 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.