[HN Gopher] Migrating from Heroku to EKS
___________________________________________________________________
Migrating from Heroku to EKS
Author : sunguroku
Score : 54 points
Date : 2023-06-14 15:22 UTC (7 hours ago)
(HTM) web link (blog.hellolanding.tech)
(TXT) w3m dump (blog.hellolanding.tech)
| mrj wrote:
| 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 wrote:
| 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 wrote:
| Hi, CEO of Qovery here - the same business model for us as well
| - per active user using the product.
| sunguroku wrote:
| 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).
| 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.
| fideloper wrote:
| It's not super important to your point (altho it goes towards
| pricing I suppose) but Fly doesn't resell a public cloud, but
| instead owns/rents hardware racked in a bunch of regions.
| mrj wrote:
| > 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.
| sunguroku wrote:
| If you're an early stage startup, you certainly are our
| target demographic - for startups with less than 5M in
| funding, we also offer a startup deal where you can get
| $10k in credits from us (you can apply from our pricing
| page). If you have any cloud credits on AWS or GCP, which
| is fairly easy to get as a startup, along with this deal
| you can effectively use a PaaS for free because the infra
| runs in your own cloud account.
|
| 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.
| suryao wrote:
| 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 wrote:
| 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.
| sunguroku wrote:
| Co-founder and OP here. First off, it's worth mentioning that
| we did not ask the customer to write this blog post in any way.
| It was a write-up that taught us a lot about the adoption
| journey of our own product, so I just thought I'd share it on
| HN (honestly surprised that it made to the front page).
|
| 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.
| DancerOfFaran wrote:
| Oh so it is content marketing from Porter.
|
| 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.
| sunguroku wrote:
| > 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.
|
| 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!
| itake wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| whakim wrote:
| As someone who hasn't used Porter, it would be awesome if you
| could follow up this oh-so-snarky response with some actual
| concrete information?
|
| * 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.
| zoomzoom wrote:
| If you want to use ECS on AWS, or use Cloud Run (+GKE if
| needed) check out withcoherence.com. In many ways it's similar
| to Porter as a "PaaS in your cloud" experience - but
| importantly it is not k8s based. Happy to discuss Heroku
| migration with anyone who's curious!
| DancerOfFaran wrote:
| The part I like about Coherence is that they aren't
| pretending to be more than the UI/DX layer around things that
| are free and open-source.
|
| 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.
| njpwerner wrote:
| 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]. I've been using it for years on top of EKS
| and have been able to defer hiring a dedicated dev ops person.
___________________________________________________________________
(page generated 2023-06-14 23:01 UTC)