1/1/2024 0 Comments Heroku vs ec2 pricingWhat happens if that EC2 instance dies suddenly or your EBS disk disappears, do you have point-in-time recovery for that DB? What about if you get an influx of traffic and suddenly need to scale beyond what a single server can do (which is admittedly pretty high). That's OK for a side project, but Heroku's selling point is that it's both easier to setup than that, and also has the resiliency, scaling and features you need for a proper production app. (If your startup does some mega processing jobs like ML then yeah you will want to use something like EC2) I will always pull aside CEO's and tell them that their engineers want the best for the company, but that is only from their vantage point, the likely don't even know the companies inner financials, so how can they tell you something is "cheaper".įocus on your companies core competencies first, get users, make money then let your engineers build their dream devops setup. I've shown non technical CEO's in small startups to scale, rollbacks, view logs and restart their servers themselves. How many times have you seen developers recommend upgrading from Ruby to Go because of speed? When all they had to do was add some partial indexes or something to their database. Most developers scale resources too early and don't go for easy wins like slow queries and any other latency related problems. This all works from the get go with Heroku. pipelines, red/green light deployments, backups, stability etc Generally I will see small to medium startups that hire 3 devops engineers who barely have the bandwidth to setup a fully fledged deployment system e.g. If you start comparing ec2 micros to Heroku dynos you already don't understand what Heroku offers. I still recommend that most startups use Heroku.Įngineers always complain about speed and price. i have high respect for how operateable Heroku is. there's still a lot of ease of use to Heroku that's potentially will be underrated and/or lost by the oncoming generations. too too much of this effort had to go into creating buildpacks & supporting language environments very very carefully very actively, that ability to stealth-containerize an app & not even notice is so much of the special sauce that makes this a hard, hard & eternal problem (because langauges/envs keep changing). ![]() Heroku's really simmered it down to something that made extremely natural sense. i'm sure some of these tools better match the simplicity of the Heroku model, corresponding branches to environments, which makes so so much sense, but so far i feel like such attempts are still basically unknown. but this idea of having a bunch of source that can deploy itself, simply, is still extremely rare even among the alpha-geek #gitops types. There's a bunch of other tools, & i'm frankly not familiar enough. flux2 is the rage, it's all over the alpha geek's efforts, but it's usually used by someone carefully authoring a fairly complex Helm file, then building out a significant Flux2 HelmRelease object (ex: ). There's just not that many folk trying to tame deploys on k8s via gitops. but, Heroku &al have a lot of value left. drop what you're doing & use a cross-system object-storage/"apiserver" & control-loops to automate everything embrace desired state management & thank me latter. I think nowadays with k8s being what it is, and with all the tooling around it and increasing industry expertise-not to mention managed offerings-Heroku is going to have a hard time. It still sticks in my head as an example of where somebody did everything "wrong," yet they still did it, and it ended up being extremely valuable to the company. We even modularized it enough to support deploys to either Mesos/Marathon or early Kubernetes. Somehow this spaghetti-behemoth actually worked, and I spent the next year fixing bugs and adding features. ![]() ![]() Furthermore, it was the dev's self-admitted first Go project (previously he worked in Java). Many places (especially the CI code) it self-invoked to access other subsystems. It had everything from Jenkins scripts to a near-complete Mesos/Marathon client to to local Docker support built in. So one of the DevOps team reimplemented the Heroku CLI as a massive, self-invoking Go monolith. The devs had gotten used to the ease of Heroku deployments and Kubernetes wasn't yet a thing. Along those lines, a few years ago I joined a company where they had just switched from Heroku to direct-AWS hosting for their infrastructure (to save $$).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |