Migrating from Heroku to EKS
blog.hellolanding.tech
blog.hellolanding.tech
This is like a case study in what not to do and I think a future followup to this post will read like a mea culpa. The level of complexity they took on unwittingly is massive, and it seems like little research was done if they chose EKS -- which is easily the worst Kubernetes offering of any of the big cloud providers. Wonder what their billing will look like next month.
Folks getting off Heroku: do yourself a favour and either go to Fly.io + Dockerfiles, use a fully managed service like Render, use ECS in AWS, or if Kubernetes + major cloud is the important part for some inexplicable reason: use GKE.
* What is the "unwittingly massive" level of complexity that they took on? Sure, k8s is complicated, but isn't the promise of this platform that it abstracts away all of that complexity? After all, AWS is very complex but we don't say that Heroku users are unwittingly taking on huge amounts of complexity, do we?
* Why the assumption that "little research was done if they chose EKS"? Perhaps the company is already using AWS for other stuff? Doesn't the promise of a managed platform mean that you don't actually have to deal with EKS or GKE directly?
* Your alternative platform suggestions don't really take into account their stated reason(s) for switching off Heroku - optimizing for scaling and lack of devops knowledge. Fly.io or Render are awesome but I wouldn't choose them for a rapidly growing company as they're essentially straight replacements for Heroku. I'm a big fan of ECS but it certainly requires some devops know-how - you better be comfortable setting up the entire AWS networking stack or want to commit energy to learning. I don't know the right answer here but it seems very use case dependent.
I've touched on this in the other comment, but I'd like to once again reiterate that Porter is not meant for small scale projects that do not warrant the scalability of something like Kubernetes. We actually advise many people getting off Heroku who are interested in Porter to use Fly.io or Render instead, because for most individuals who are running projects that do not anticipate scale, those platforms make more economic sense.
Porter is designed for companies, not individuals. The base infrastructure Porter provisions alone is around $300, so if your spend on Heroku is less than that, it's more affordable to stay on Heroku or use a platform like Fly.io/Render. For companies who are running at decent scale, however, we've found that Porter starts making sense earlier than you'd think, because cost on platforms like Heroku starts increasing rapidly as you scale beyond a certain point (e.g. a single Performance L dyno on heroku already costs around $500/mo). This particular customer has actually been on Porter for more than a year and had no fluctuations in their billing.
In comparison to ECS, our customers actually tell us that Porter is easier and more developer friendly than ECS (many of our users migrate from ECS as well, not just to improve scalability but for the better developer experience - we wrote about it here: https://www.porter.run/case-study/why-woflow-moved-from-ecs-...). There's no denying that Kubernetes is complicated - do most startups need Kubernetes? Absolutely not. But if it's actually easier to use than something like ECS and as easy as Heroku, why not deploy on the most robust, industry-standard orchestrator that you can customize later and leaves no stones unturned for the future?
Porter supports GKE as well as EKS, and which k8s offering you use under the hood is largely unimportant to the end user because Porter abstracts k8s anyway. Migrating from a platform like Heroku to Porter is just a few hours of work.
I'm not interested in litigating Porter (which I imagine is awesome) vs. other systems, but it does seem like your target market are dev teams which are light on DevOps skillsets, because you can run these systems for free with a modicum of DevOps chops on the team.
That doesn't make this story any less puzzling from a technical decision-making standpoint.
Managing infrastructure at scale is not trivial (otherwise, why would full-time devops engineers exist?), and that's why platforms like Porter exists to help companies scale more easily with fewer devops resources. It's the same reasoning as why so many developers like yourself use Fly.io - you could run your applications for free on an EC2 instance instead of paying fly.io/heroku/render a margin on top of it if you have a modicum of devops chops. Yet clearly, these platforms are bringing enough value in the axes of developer experience and reliability that justifies the additional cost for you.
RE your comment in the other thread about there being open source options: it's worth mentioning that Porter is also open-source (repo here: https://github.com/porter-dev/porter). If you want to use Porter purely as a UI on top of your own infrastructure that you are managing yourself, you are more than welcome to take it out on a spin with our OSS repository!
Fly.io is insanely cheap, but you pay for that in stability. My health checks fail a few times per month. I was also annoyed they forced everyone to upgrade to their v2 infra and pricing.
With that said, our core systems are still on GCP and we use Fly exclusively for Next.js UIs so the comparison is to systems like Netlify and Vercel, both of which are far less reliable in our experience, and far costlier (Netlify is at the point of nickel and diming people).
They also changed regions during the migration. My db (hosted in a different app) was in LAX, but the new machines were in SEA.
I'm so not a fan of what YC has done in the last year by funding every "Heroku killer" under the sun without calling out the elephant in the room that Heroku was the accessible DX into AWS, and nothing more. That stuff all exists in the open source world.
But the pricing looks curious. Their "default infrastructure" is $300 a month set up in AWS plus usage costs on Porter. It's already 6x what I'm spending on Heroku, why would I pay usage costs per CPU to Porter if they're not running any CPUs?
Honest question really because I'm interested, it just seems far out of line price-wise. I would totally pay for help managing infrastructure, just not server usage. It would make more sense to pay for the things I'm actually using or a fee per developer.
The value you get from Porter is the same as these platforms: with the clusters plugged into our internal system, our team monitors your infrastructure and owns its reliability so the end user can just focus on the application. Other platforms that also run in the customer's own cloud, such as Red Hat OpenShift, has similar resource based pricing models.
On this note, we offer an option to bring your own Kubernetes cluster and connect Porter to it. In this case, the end user manages their own infrastructure and Porter purely acts as a UI on top of your own Kubernetes cluster. Accordingly, for this use case, pricing is based on the number of user seats instead of resource usage. Many of our customers who use Porter in this capacity often have their own DevOps teams that manage the infrastructure and use Porter purely as a means to simplify deployment for their developers.
It's also worth mentioning that Porter is not meant for small workloads or hobbyists. If your spend on Heroku is less than $300, we actually do not recommend using Porter and have advised many users who were interested in Porter to use platforms like Render and Fly.io. Porter is designed for companies - mostly startups - who actually need to scale their applications and have sufficient budget for their cloud infrastructure.
Hi, thanks for the reply and congrats on everything you've built. I am your target demo I think, an early stage startup that's just starting to get traction. I'm expecting costs to increase soon and that's a big motivating factor to getting off Heroku.
So I'm stuck with either doing all this yaml junk myself or something like your solution. But it is definitely not something I would consider if I'm going to run into those escalating costs that you mention.
A gui / guided kubernetes could be just the thing though.
Also just to clarify, our pricing structure is designed to increase more slowly as you scale. We offer volume discounts above a certain resource usage, so that your cost increases more logarithmically rather than exponentially.
That's the model we use at argonaut.dev. We charge a flat fee per developer and you pay the AWS bills to AWS or GCP (using credits ideally). We settled on this because it is transparent and does not lead to any surprises in billing, especially for startups which are our core target.
We have customers who have evaluated and chosen us for our flexible CI/CD pipelines, transparency, and pricing. We also help setup other infra dependencies you might have like managed databases, redis on aws and gcp.
cat ./yaml/applications/kubernetes-dashboard.yaml | ./scripts/kubectl-apply.sh && ./scripts/run-argocd-sync-and-wait-pipeline.sh "kubernetes-dashboard"
We're building a similar service with the aim of being a comprehensive platform across managing cloud infra across stable envs like staging and prod (rds, s3, elasticache, opensearch etc. on aws and cloudsql, gcs, gke, memorystore on GCP) and app deployments onto kubernetes on those environments.
Some things we have heard from talking to customers are that they prefer a single tool to manage their cloud infra, setting up (stable) environments, CI/CD (push to deploy from github/gitlab), kubernetes runtime (EKS, GKE) and app deployments.
I understand that kubernetes is a divisive topic on HN because kubernetes is overkill for a lot of companies and can become complex. That said, there are companies which have a genuine need for something like kubernetes and find working with aws/gcp a chore. We might be restricting our market but adding value to such teams is what we are betting on at the moment.
What would be the most valuable to you if you are in the market for a tool such as Argonaut? I'd love to shape our product to be genuinely useful for folks here.
OP: we’re you able to get this working?