14 ms·

Migrating from Heroku to EKS

73 points by sunguroku 3y ago

rcarmo 3y ago
Nice, but... Anything simpler that one can deploy atop one's own K8S? There were a few dokku-inspired things that would generate the right manifests and leverage the same build packs, but things seem to have stalled on that front and "simple" solutions are thin on the ground.
- josegonzalez 3y ago
  Dokku [deploys to Kubernetes](https://dokku.com/docs/deployment/schedulers/kubernetes/ https://dokku.com/docs/deployment/schedulers/kubernetes/) with an officially maintained plugin and we have a few folks actively using it.
mrj 3y ago
Porter looks cool and I would love to not hand roll kubernetes stuff. 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.
- suryao 3y ago
  Founder of Argonaut (yc backed as well) here. 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.
- ev0xmusic 3y ago
  Hi, CEO of Qovery here - the same business model for us as well - per active user using the product.
- sunguroku 3y ago
  Co-founder here. Thanks for asking this - we get this question a lot and have tried our best to address it in the FAQ section of our pricing page (https://porter.run/pricing https://porter.run/pricing). Infrastructure provisioned by Porter is constantly managed by Porter so that the end user does not have to worry about the details of maintaining a Kubernetes cluster. In this regard, our pricing structure is identical to traditional platform as a services like Heroku, Render, Fly.io, or Vercel, where the respective PaaS provider is effectively charging a margin on top of their own cloud resources on AWS/GCP. This form of leasing out the PaaS provider's AWS/GCP infrastructure to end users also often results in rapidly increasing costs especially as you start hitting scale on hosted platforms like Heroku. 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.
  - mrj 3y ago
    > our pricing structure is identical to traditional platform as a services like Heroku ... often results in rapidly increasing costs especially as you start hitting scale 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.
- MuffinFlavored 3y ago
  > Porter looks cool and I would love to not hand roll kubernetes stuff. cat ./yaml/applications/kubernetes-dashboard.yaml | ./scripts/kubectl-apply.sh && ./scripts/run-argocd-sync-and-wait-pipeline.sh "kubernetes-dashboard" What am I missing?
suryao 3y ago
Hey folks - I am the founder of argonaut.dev (YC S21). 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.
DancerOfFaran 3y ago
So they went from Heroku buildpack-based ops, to Kubernetes on EKS, through a 3rd party orchestration service? The post is essentially just content marketing for Porter. 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.
- itake 3y ago
  > Fly.io + Dockerfiles 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.
  - DancerOfFaran 3y ago
    I've felt like v2 is MUCH better than the v1 system, and pricing is still much better than alternatives. 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).
    - itake 3y ago
      I'm more annoyed that I had to deal with the change. The migration took a couple hours and I'm still not sure if I configured it correctly to mirror the v1 setup I had. They also changed regions during the migration. My db (hosted in a different app) was in LAX, but the new machines were in SEA.
      - mrkurt 3y ago
njpwerner 3y ago
I would encourage anyone looking at porter that needs more flexibility, a deeper feature set, a more extensive cli, and/or flatter pricing structure to check out convox [https://convox.com https://convox.com]. I've been using it for years on top of EKS and have been able to defer hiring a dedicated dev ops person.
pharmakom 3y ago
No mention of how components can be tested together or released atomically. OP: we’re you able to get this working?
holografix 3y ago
What a missed opportunity to migrate to Cloud Run.

73 points by sunguroku 3y ago

Nice, but... Anything simpler that one can deploy atop one's own K8S? There were a few dokku-inspired things that would generate the right manifests and leverage the same build packs, but things seem to have stalled on that front and "simple" solutions are thin on the ground.

josegonzalez 3y ago
Dokku [deploys to Kubernetes](https://dokku.com/docs/deployment/schedulers/kubernetes/ https://dokku.com/docs/deployment/schedulers/kubernetes/) with an officially maintained plugin and we have a few folks actively using it.

mrj 3y ago

Porter looks cool and I would love to not hand roll kubernetes stuff. 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.

suryao 3y ago
Founder of Argonaut (yc backed as well) here. 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.
ev0xmusic 3y ago
Hi, CEO of Qovery here - the same business model for us as well - per active user using the product.
sunguroku 3y ago
Co-founder here. Thanks for asking this - we get this question a lot and have tried our best to address it in the FAQ section of our pricing page (https://porter.run/pricing https://porter.run/pricing). Infrastructure provisioned by Porter is constantly managed by Porter so that the end user does not have to worry about the details of maintaining a Kubernetes cluster. In this regard, our pricing structure is identical to traditional platform as a services like Heroku, Render, Fly.io, or Vercel, where the respective PaaS provider is effectively charging a margin on top of their own cloud resources on AWS/GCP. This form of leasing out the PaaS provider's AWS/GCP infrastructure to end users also often results in rapidly increasing costs especially as you start hitting scale on hosted platforms like Heroku. 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.
- mrj 3y ago
  > our pricing structure is identical to traditional platform as a services like Heroku ... often results in rapidly increasing costs especially as you start hitting scale 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.
MuffinFlavored 3y ago
> Porter looks cool and I would love to not hand roll kubernetes stuff. cat ./yaml/applications/kubernetes-dashboard.yaml | ./scripts/kubectl-apply.sh && ./scripts/run-argocd-sync-and-wait-pipeline.sh "kubernetes-dashboard" What am I missing?

suryao 3y ago

Hey folks - I am the founder of argonaut.dev (YC S21). 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.

DancerOfFaran 3y ago

So they went from Heroku buildpack-based ops, to Kubernetes on EKS, through a 3rd party orchestration service? The post is essentially just content marketing for Porter. 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.

itake 3y ago
> Fly.io + Dockerfiles 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.
- DancerOfFaran 3y ago
  I've felt like v2 is MUCH better than the v1 system, and pricing is still much better than alternatives. 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).
  - itake 3y ago
    I'm more annoyed that I had to deal with the change. The migration took a couple hours and I'm still not sure if I configured it correctly to mirror the v1 setup I had. They also changed regions during the migration. My db (hosted in a different app) was in LAX, but the new machines were in SEA.
    - mrkurt 3y ago

njpwerner 3y ago

I would encourage anyone looking at porter that needs more flexibility, a deeper feature set, a more extensive cli, and/or flatter pricing structure to check out convox [https://convox.com https://convox.com]. I've been using it for years on top of EKS and have been able to defer hiring a dedicated dev ops person.

pharmakom 3y ago

No mention of how components can be tested together or released atomically. OP: we’re you able to get this working?

holografix 3y ago

What a missed opportunity to migrate to Cloud Run.