HACKER Q&A
📣 edtech_dev

Those of you who don't use K8s, what are you using for deployment?


Looking to choose a deployment stack for our startup. It's a fairly standard web app + db + queue setup, and would need some basic failover strategy.

I am in the camp of engineers who feel that while k8s might be useful at some scale, it is unnecessary complexity for most; I am adamant about not using it. And so, I thought I'd turn to the community to get a sense of the current landscape and get suggestions for some good options to use in 2024.

  * What's your current deployment stack? Would be very helpful if you can describe the process/tools in detail.
  * How happy are you with it? If you could start from scratch, what would you change?
  * How do you handle test/staging environments?
  * Where do you deploy?

  👤 JojoFatsani Accepted Answer ✓
Been using K8S, but I agree it can be overkill in a bootstrap phase. I have been at startups that launched on Heroku, Nomad, Elastic Beanstalk, and Elastic Container Service. I’d recommend Heroku out of those - it’ll be cheaper than a DevOps hire until it isn’t.
👤 gregjor
AWS EC2 instances for a big web app. RDS MySQL database instances. Identical setups for development/test, staging, production, with dev/staging using different databases and not allowed to process real payments and so on. Every developer has their own work instance. Deployment is `git pull` with an occasional database schema update/migration done with SQL and tested like any other code. Scripts automate most of this.

I wouldn't change anything. I prefer the control of managing the server at the OS level, but I'm not interested in managing hardware anymore so AWS can do that.

👤 jamesfinlayson
I use AWS's Elastic Container Service with Fargate. We have three AWS accounts (dev, test and prod) - we build the containers in dev, build one for test when we've tagged a release and then push that one to prod. Deployment is using Serverless (we pass the container tag through to the CloudFormation).

It works well enough - no complaints. This is a fairly simple use-case though (immutable API containers) - maybe you'd have more problems if you tried putting the database and queue systems in ECS.

👤 synack
I have an ansible playbook that does "git pull" in the right directory and restarts the daemon. I run it whenever I need code deployed, but it wouldn't be difficult to rig up to a CI system.

The EC2 instances are managed by terraform. Debian AMIs with a cloud-init script to get them bootstrapped with ssh keys and such to the point where ansible can run.

Yes, there are better options but with a team size of < 5, this works fine and there's really not much that can go wrong with it.

👤 nullindividual
Azure WebApp + Azure SQL Database (or psql or mysql or cosmos w/ or w/o mongodb compat) + queue service of choice, i.e. ServiceBus. Everything highly available/multi-region with automatic failover. Azure Front door or Azure App Gateway, WAFv2 in front of the WebApp.

CI/CD from ADO or GHE to the appropriate service. Separate instances for dev/stg/prd.

I much prefer to manage PaaS than deal with an OS at any level.

👤 flybayer
We use https://www.flightcontrol.dev to deploy to AWS Fargate with auto deploys, multiple environments etc (I’m cofounder of Flightcontrol)
👤 nickstinemates
Nix+Tilt