[HN Gopher] Show HN: Porter Cloud - PaaS with an eject button
___________________________________________________________________
Show HN: Porter Cloud - PaaS with an eject button
Hi HN! Porter Cloud (https://porter.run/porter-cloud) is a Platform
as a Service (PaaS) like Heroku, but we make it easy for you to
migrate to AWS, Azure, or GCP when you're ready. Like Heroku,
Porter takes care of a lot of generic DevOps work for you (like
setting up CI/CD, containerizing your applications, autoscaling,
SSL certificates, setting up a reverse proxy) and lets you deploy
your apps with a few clicks -- saving you a lot of time while
developing. However, as you probably know, there's a downside:
platforms like this become constraining if and when your app takes
off and you need to scale. The time you saved while developing can
get pretty expensive once you're paying for a lot of users -- and
the platforms tend to try to keep you locked in! Our idea is to
give you the best of both worlds: use Porter Cloud for as long as
it saves you time and development cost, but at any time you can
press the "eject button" to migrate your app to your own AWS,
Azure, or GCP account as you please. We make it seamless to break
out, so you're no longer subject to the rigid constraints of a
conventional PaaS. You can migrate in a few simple steps outlined
here: https://docs.porter.run/other/eject. A bit of background: we
first launched on HN almost 3 years ago with our original product
(https://news.ycombinator.com/item?id=26993421,
https://porter.run), which deploys your applications to your own
AWS, Azure, or GCP account with the simple experience of a PaaS.
Since then, we've helped countless companies migrate from a PaaS to
one of the big three cloud providers. Most of them had gotten
started on a PaaS in the early days to optimize for speed and ease
of use, but ultimately had to go through a painful migration to
AWS, Azure, or GCP as they scaled and ran into various constraints
on their original PaaS. Interestingly, we learned that many
companies that start on a PaaS are fully aware that they'll have to
migrate to one of the big three public clouds [1] at some point.
Yet they choose to deploy on a PaaS anyway because outgrowing a
cloud platform is a "champagne problem" when you're focused on
getting something off the ground. This, however, becomes a very
tangible problem when you need to migrate your entire production
infrastructure while serving many users at scale. It's a "nice
problem to have", until it isn't. We've built Porter Cloud so that
the next generation of startups can get off the ground as quickly
as possible, with a peace of mind that you can effortlessly move to
one of the tried and true hyperscalers when you are ready to scale.
We are excited to see what people build on Porter Cloud. If you've
ever dealt with a migration from a PaaS to one of the big three
cloud providers, we'd also love to hear about your experience in
the comments. Looking forward to feedback and discussion! [1] By
"big three clouds" we mean the lower-level primitives of each cloud
provider. We don't mean their higher level offerings like AWS App
Runner, Google Cloud Run, or Azure App Service, since those run
into the same PaaS problems described above.
Author : sungrokshim
Score : 138 points
Date : 2024-05-23 16:47 UTC (6 hours ago)
| palashkulsh wrote:
| Really good concept
| neeleshs wrote:
| Cool concept. In my experience, the biggest headache/expense is
| data migration, and not software migration. As long as the stack
| is vendor neutral, it's not the long-poll, though it is
| gruntwork.
|
| In the SaaS world, maybe this will be useful to run managed cloud
| services? (That is, customer A wants a private instance in AWS
| and customer B wants it in Azure)
| sungrokshim wrote:
| Yes data migration is definitely the most gnarly part. We
| regularly migrate databases with zero downtime using Bucardo
| (we detail it here: https://www.porter.run/blog/migrating-
| postgres-from-heroku-t...) and will be addressing this part of
| the migration in the ejection process in the future as well.
| saisrirampur wrote:
| Crunchy Bridge seems to make the data migration simple too -
| https://docs.crunchybridge.com/migrate/heroku_dump_restore
| pil0u wrote:
| Hey thanks for sharing.
|
| You mention 3x cheaper than Heroku, but the pricing page
| specifies $10 per month GB RAM, $20 per month vCPU.
|
| I'm having a hard time to compare with Heroku with that
| information. Also, what about Postgres hosting?
| jusrhee wrote:
| Founder here - the "up to 3x cheaper than Heroku" depends on
| the exact compute profile, but as a point of reference, Heroku
| pricing starts at $250/mo for a single 2.5 GB RAM instance on
| their Performance tier (https://www.heroku.com/dynos).
| Generously assuming that you get 2 dedicated vCPU cores, the
| equivalent Porter cost is ~3-4x cheaper
|
| Edit: Porter Cloud also supports Postgres and our in-your-own-
| cloud offering just uses RDS under the hood for AWS
| mushufasa wrote:
| I looked into porter at the time we were migrating from Heroku to
| AWS! I thought it would have been a great solution if it was
| mature when we first started on heroku.
|
| At this point, I have to ask: what's your business model? The
| reason heroku never made it easy to migrate is the incentive you
| point out.
|
| What's yours?
| theturtletalks wrote:
| They charge for managing the kubernetes instance that's running
| on your infrastructure. What's cool is that you can stop using
| Porter once everything on AWS/Azure/GCP is set-up and you're
| not locked in. You just have to manage the cluster yourself.
| sungrokshim wrote:
| yup exactly. we also offer volume discounts on Porter as you
| scale so the cost grows logarithmically as opposed to
| exponentially. Our philosophy is that we should win on merit
| not inertia. If the customer doesn't continue to see value,
| you can offboard and start managing devops on your own.
| mushufasa wrote:
| I meant: what's the business model for Eject specifically?
| Why make it easy for customers to leave (aside from pre-
| empting buying-decision concerns)
| mushufasa wrote:
| To wit, I ask because:
|
| 1. key to a buying decision: I see the documentation for Eject
| and it looks good, though like any product you'll only able to
| support it over time if it makes business sense for you
|
| 2. I'm interested in this challenge generally cross-industry
| for companies that sell 'get off the ground' services to
| startups, on a high margin usage-based model. It's a business
| model with a constant sword of Damocles, because if your
| customers do well they would have to leave.
|
| AFAIK the only real solutions
|
| - technical lock-in, either by making it concretely hard or
| "soft" hard (introduce a whole training regime for employees
| based on your systems with idiosyncratic concepts and
| terminologies, so the human skills aren't transferrable)
|
| - build out a kitchen sink featureset including niche products
| specific to enterprises (a lot of GRC stuff), so they'll keep
| paying you high margins at scale (this is AWS's journey.)
|
| - invest/take equity in your customers (this is only a partial
| solution but if they leave at least you'll capture some upside.
| See: Peak6/Apex & Robinhood)
|
| - capping your fees to a flat upper rate (this will destroy
| your own expected customer LTV though you keep the customer)
|
| - lock-in long multiyear contracts (this is also a partial
| solution)
|
| - become an IP troll (e.g. oracle badgering it's legacy
| customers)
|
| - deliver revenue or addressable markets to your customers that
| they wouldn't otherwise be able to get (no iOS developers
| choose it *because of* Xcode or Swift; it's the marketplace)
| jusrhee wrote:
| I'd like to reframe this a bit (Porter co-founder btw). The
| way we see it, the core value of many PaaS solutions is the
| reduction of DevOps overhead by allowing teams to focus
| engineering resources on product and not generic infra
| maintenance tasks.
|
| Most of our existing users are companies that are already
| using Porter in their own AWS/GCP/Azure because they want to
| reduce time spent on cloud management as they continue to
| grow. Companies like Heroku exclusively provide this service
| in a hosted cloud environment where they also resell the
| underlying infrastructure to you (similar to Porter Cloud),
| but we want to be flexible in delivering the same value on
| any cloud provider.
|
| If we're doing our job, we will continue to automate enough
| generic DevOps work where Porter is delivering value even as
| you scale in your own cloud. We have a good number of late-
| stage startups (and even some public companies) that have
| DevOps teams in place using us precisely this way to handle
| core parts of their infra and application lifecycle
| management.
|
| Porter Cloud is intended as a way to "get off the ground,"
| but our staying value lies in continuing to reduce the same
| DevOps overhead even once you're running in your own cloud
| account
| bkitano19 wrote:
| Had this exact problem (Heroku Postgres to RDS) at my old co.
| Data migration went as bad as it possibly could (dropped indices,
| foreign keys, everything but the data itself). This would have
| saved us months of pain.
| davedx wrote:
| It's a great idea, but the pricing seems high - $30/month
| minimum? I'm running 3 apps on Fly.io and I'm still so low in the
| pricing that they're invoicing me $0. I will pay for the
| convenience of a PaaS - but not that much.
| simple10 wrote:
| Looks useful! Pricing page is a bit confusing IMO. It's unclear
| at a quick glance what the features/benefits difference is
| between Developers Cloud and Business (bring your own)
| offerings.
|
| Worth noting startups under $5M funding can apply for a year of
| free services. There's a link on the pricing page to apply.
| sungrokshim wrote:
| not sure where you saw $30/month minimum! There's no minimum
| spend on Porter, and you just pay for what you use as low as a
| 0.1 CPU and 1MB RAM. We do not have a free tier however.
| davedx wrote:
| Pricing page (developers). How can you have less than 1 CPU?
| sungrokshim wrote:
| You can adjust resources down to 0.01 vCPU and 1MB RAM
| granularity. Price is prorated accordingly
| hahahacorn wrote:
| We migrated from Heroku to Porter at work (at my behest). Still
| one of the better bets I've taken.
|
| There is definitely still some more devops overhead compared to
| Heroku, and I wish the product was a bit more mature. But even at
| ~$18k/mo on Heroku spend we're now spending less than half with
| Porter. Other than myself and the other engineer who were
| responsible for the migration, the rest of the team really got to
| keep their work flows and there was little impact except for
| swapping some tools.
|
| We had a messy, poorly documented web of micro services and shit
| too, the Porter team made the migration surprisingly easy all
| things considered. I'll work with them again if I ever scale past
| a $10k/mo Heroku bill (post enterprise contract) with another
| team.
| sungrokshim wrote:
| Great to hear that!
|
| > I'll work with them again if I ever scale past a $10k/mo
| Heroku bill (post enterprise contract) with another team.
|
| We built Porter Cloud so you can just start on us from day 1
| and migrate to the Porter you're used to when you're ready,
| without spending much effort on the migration :)
| michaelmior wrote:
| Sounds like an interesting tradeoff. I noticed that the link to
| GitHub in the footer 404s however. I was hoping this was OSS.
| com wrote:
| The old repo looks like it's been renamed to
|
| https://github.com/porter-dev/porter-archive
|
| They've probably forked the cloud product, and are leaving the
| old OSS version up?
| malyk wrote:
| At HomeLight we migrated from Heroku to Porter and it has been
| great. The team has been super helpful, the platform as stable as
| you can get, and the cost savings have been tremendous.
|
| I'd highly recommend Porter as the place to go to get started
| these days. I don't see any reason that we will migrate away in
| the next few years, if ever.
| bshul-silkline1 wrote:
| Please support AWS GovCloud!
| wmab wrote:
| Congrats on the launch guys! This is a great feature, in a world
| where most companies try to increase lock in!
|
| Huge fans of Porter, we've been using them for a number of years
| at Woflow and they've helped us scale effortlessly.
| scottmessinger wrote:
| Very cool! As someone pointed out, your github repo says it was
| archived: https://github.com/porter-dev/porter-archive Naively, I
| would think Porter cloud would just be a managed version of your
| porter-dev/porter-archive. Could you talk about how it's a
| different product than before? Did the code base change
| significantly?
| jusrhee wrote:
| Our archived repo functioned as more of a Kubernetes-centered
| dashboard - Porter Cloud is intended to offer a more complete
| PaaS experience including spinning up non-application resources
| like databases
| localfirst wrote:
| How does this compare to Coolify/CapRover
| sosodev wrote:
| Is the eject button the only thing that makes Porter more
| appealing than something like Fly.io or Render? They too automate
| a lot of stuff but for a better price.
| paulcarroty wrote:
| Credit card paywall, so I'd recommend to check Render or Koyeb
| for these people who prefer to save their time.
| MobileVet wrote:
| I have never quite understood this value proposition (maybe I am
| not the target audience?) The point of PaaS is to avoid DevOps...
| making a PasS with an eject just feels orthogonal to the value
| prop of the main business. Ejecting seems like a low probability
| event as they CHOSE PaaS in the first place. (unless the money
| got really high)
|
| We included Porter in our post-Heroku research and chose Render.
| We have loved Render and expect to be with them for quite a while
| (as we were with Heroku). If they happen to go south as Heroku
| did, we will find another PaaS... we will not 'eject' to bare
| metal or self configuration on AWS.
| latchkey wrote:
| I personally don't get it. You can start on GCP today, without
| being tied to GCP much at all. It isn't even expensive to do so.
| Is there something I'm missing here?
|
| Cloud Functions are just a http handler with no hard dependencies
| on GCP.
|
| Cloud Tasks are just a handler and the tasks just hit your Cloud
| Functions.
|
| Cloud SQL is just postgres.
|
| You connect your github with actions that CI/CD auto deploy to
| the above.
|
| If you do it that way, you're pretty much dependency free and can
| move anywhere else if you need to.
| dangoodmanUT wrote:
| You're just like the dropbox launch just use ftp guy
| latchkey wrote:
| Ouch, that's an absurd comparison. Instead of commenting
| nonsense, how about explaining to me how I'm missing the mark
| here?
|
| Let's break it down a bit...
|
| "Porter takes care of a lot of generic DevOps work for you
| (like setting up CI/CD, containerizing your applications,
| autoscaling, SSL certificates, setting up a reverse proxy)."
|
| All of this is done for you on GCP with the aforementioned
| services.
|
| "Porter Cloud for as long as it saves you time and
| development cost, but at any time you can press the "eject
| button" to migrate your app to your own AWS, Azure, or GCP
| account as you please."
|
| Why add an additional service, and set yourself up for having
| to "eject", when you can just start off on the right foot to
| begin with?
| benatkin wrote:
| It looks like Preview Environments could be a part of it.
| It seems costly though.
| adenta wrote:
| talk to me about GPU's? I saw some gpu_node config stuff in your
| documentation a couple days ago.
|
| If Porter can host GPU's, that's a superpower render.com doesn't
| have.
| kiney wrote:
| Any plans to support eject to on-prem or bare metal hosters like
| Hetzner?
| chadsix wrote:
| There's a separate project Cloud Seeder [1] which is completely
| open source and gives you 1 click server appliances and IP
| addresses on-premises. Disclosure, I work there.
|
| [1] https://github.com/ipv6rslimited/cloudseeder
| jusrhee wrote:
| At the moment we only support the major hyperscalers since
| they're the most common ejection destinations, but we're
| considering adding more options. No concrete plans for this at
| the moment though
| jedwhite wrote:
| We migrated microservices from Heroku to Porter, and also from
| standalone VMs and K8s running on AWS to Porter. As a coder
| trying to do both dev and devops on a tiny team, it was life
| changing for me.
|
| The key benefits for a small startup team are:
|
| 1. Effortless CI/CD: Deploying services on K8s clusters across
| different clouds becomes trivial. Setup a dockerfile in your
| repo, point Porter at it, deploy. We mostly run APIs behind AWS
| API Gateway.
|
| 2. Startup credits: You can use your existing credits on AWS,
| Azure etc.
|
| 3. Zero lockin: You can deploy in parallel and switch service
| providers.
|
| 4. Devops expertise: The Porter team have given us next-level
| hands-on support and help to figure out how to run things
| optimally. A lot of sensible defaults are built in. As a coder,
| they have knowledge of how to scale services effectively that (to
| be blunt) I couldn't match no matter how much time I spent trying
| to learn it as a lay person.
|
| If you're a K8s and devops master, you probably don't need this.
| If like me you're a programmer with limited devops skills looking
| for the fastest and easiest way to just solve deployment and
| scaling, Porter is close to magic. Plus they have one of the most
| helpful and friendly teams I've worked with anywhere.
|
| (edit for typo)
| terpimost wrote:
| Why just big 3? How about Digital Ocean?
___________________________________________________________________
(page generated 2024-05-23 23:00 UTC)