[HN Gopher] Open source Heroku Like Platform on premises
___________________________________________________________________
Open source Heroku Like Platform on premises
Author : markomunich
Score : 202 points
Date : 2021-03-26 00:50 UTC (22 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| hardwaresofton wrote:
| Awesome to see this project -- this is one of the use cases that
| really emphasizes/shows off the benefits of choosing Kubernetes
| as an ecosystem -- it's possible to build things like this on k8s
| because it has concerned itself with a nauseating amount of the
| mechanics (and abstractions thereon) of application development
| and delivery.
|
| If I didn't know any better I'd expect both fly.io and Render to
| be build on Kubernetes, and I feel like I could build Cloud Run
| in a weekend with Kubernetes (with decent isolation and actual
| global reach as well) -- there is a tremendous amount of value in
| the ecosystem just waiting to be used for projects like this.
| sofixa wrote:
| > and I feel like I could build Cloud Run in a weekend with
| Kubernetes (with decent isolation and actual global reach as
| well) -- there is a tremendous amount of value in the ecosystem
| just waiting to be used for projects like this.
|
| Well you can, because Cloud Run is using Knative behind the
| scenes, so you only need a web UI
| tebbers wrote:
| The DigitalOcean App Platform is built on Kubernetes as well:
| https://thenewstack.io/digitalocean-app-platform-eases-kuber...
| hardwaresofton wrote:
| They're also probably one of the least-bullshit k8s providers
| as well -- DO has always very pragmatic and it really shows
| through in their offerings.
| fuddle wrote:
| This looks great!
| amir734jj wrote:
| After login the back button doesn't work.
|
| Login -> GCP -> back button -> page crashes
| malobre wrote:
| Looks great, However I'm getting an error while setting up:
| $ porter connect kubeconfig Error: code 500, errors [could
| not write to database]
| abelanger wrote:
| Apologies for the super vague error message here: this happens
| when the CLI is unable to read some required data from your
| kubeconfig or the kubeconfig contains an integration that we
| don't support. Mind if I ask which Kubernetes provider you use?
| (This comes up most often when the Kubernetes provider uses an
| exec-based auth mechanism).
|
| It'd also be easier to debug in our Discord if you post to the
| #help channel there!
| malobre wrote:
| I investigated a little bit and it was a problem with
| certificates, the internal error message was "could not
| resolve kube integration (x509)". I was using a single-node
| k8s cluster hosted on Digital Ocean that I created myself.
|
| I'm a beginner when it comes to k8s so I ended up just
| provisioning from the dashboard, everything's working now :)
| cdbattags wrote:
| Just got {"code":403,"errors":["Could not read
| cookie: are cookies enabled?"]}
|
| when trying to sign in with GitHub on Safari on iOS. Any advice?
| abelanger wrote:
| Hmm, I'm unable to recreate on Safari on iOS. Perhaps try on a
| desktop browser?
| mdasen wrote:
| This looks really cool. I see from your website that you're a YC
| company. Do you mind if I ask what your business plan is?
|
| I feel like I'm always cautious around stuff like this because it
| seems to be an area where a lot of people have a tough time of
| making a business out of it and a lot of tools somewhat get
| abandoned in the space. Flynn has been discontinued recently.
| Deis has been gone for a while. Dokku still hasn't moved past
| single-machine, though it does seem to be seeing more life.
| Eldarion's Kel is gone. Rancher's Rio looked cool, but it seems
| to have been abandoned quite quickly with most work seeming to
| drop off a little over a year after it was created (and zero
| commits in their repo in almost 5 months). It feels like the
| open-source PaaS space is littered with attempts that then went
| away as fast as they came.
|
| I think part of the issue is that if one actually makes a good
| open-source PaaS, there's little pain to solve via value-added
| services. If one creates something that is hard to understand,
| then there's lots of consulting/support/etc. money one can grab.
| I guess I'm just left wondering: will this become another Rio or
| Kel or Flynn or Deis? If it doesn't, does that mean that some
| large restrictions will happen like a limit of 10 machines?
|
| I _really_ want an open-source PaaS to succeed. I 've just seen
| so many struggle to figure out how to achieve that. This might be
| sounding more negative than it's meant, but how would you quell
| my doubts? There's no "pricing" page or something that would tell
| me what you're expecting people to pay and for what - and without
| pricing, I don't know how you'll stick around.
|
| Again, it looks super cool, but I do worry about open-source PaaS
| systems.
| sungrokshim wrote:
| Hi, I'm one of the co-founders of Porter. First I wanted to
| clarify that the OP is not affiliated with Porter - but thank
| you OP for putting us on HN! This was a pleasant surprise.
|
| As for the business plan, the honest answer is that we are
| still figuring out the specifics. That said, the goal is not to
| charge indie devs/small teams but charge for features that are
| geared towards collaboration/useful for larger teams.
|
| You raise an excellent point about how a truly good open-source
| PaaS shouldn't have a lot to charge for support. We completely
| agree with this, and we don't intend to draw revenue from
| support (as you flag, this model has a bit of tension with
| building an easy to use, automated platform).
|
| We believe that there are a ton of things that can be done that
| is useful for teams, and there's solid evidence for this on
| existing hosted PaaS's like Heroku, Netlify, etc. Review apps,
| pipelines, RBAC are few examples of these paid features on
| hosted PaaS's that we also consider to be potential premium
| features on Porter.
|
| As for the comparison with other PaaS's that came before us -
| Flynn, Dokku, Deis and Tsuru were built prior to the advent of
| k8s. Afaik, a lot of their effort was spent on building the
| system layer. This has obviously changed with k8s, so we have
| the luxury to focus on the platform layer and make innovations
| there, instead of using our resources on building the system
| layer. I do not have insight into why other k8s based PaaS
| (like Rio, Kel, and Hephy workflow) have been discontinued, but
| one notable difference is that we intend to make Porter a true
| Heroku-level PaaS that doesn't require familiarity with k8s,
| rather than becoming a PaaS that saves time and overhead for
| those who already use k8s.
|
| Hope this answered your question!
| mdasen wrote:
| Yea, I think it does.
|
| I'm glad that you're not looking at support as a primary
| revenue source since that seems to be the kind of thing that
| leads to companies not wanting to fix pain points because
| those pain points are what people pay support contracts to
| handle. That's just a horrible tension because there's no
| reason to eliminate complexity. An enterprise company with a
| giant support contract just gets a support engineer to solve
| that complexity for them and it pushes everyone else to buy a
| support contract to get you to solve things.
|
| As someone working on a small team and trying not to burn
| cash, it feels like so much has become expensive since the
| "old" days of VPSs. Part of that is that people are
| accustomed to CI/CD, zero-downtime deploys, etc. Those are
| kinda table-stakes in a sense now. Many things are "solved"
| if you're willing to pay Amazon or Google higher margins, but
| it's tough if you're trying to build something user-friendly
| and lower-margin on your end (I mean, ultimately, it probably
| means that we should be pivoting toward something higher
| margin, but we love what we're working on).
|
| I definitely think RBAC can be a great differentiator between
| "small team" and "people who should pay us". At some point,
| you go from startup where people trust each other to "we need
| to be responsible and only some people get access to some
| parts". At the point that you're paying dozens of engineers,
| it seems reasonable to send some money to your PaaS provider
| that helped you get there and keeps you humming.
|
| I think mentioning RBAC really gets me on the "oh, yea...that
| makes sense. It's great and happy for a team of 3 looking for
| that awesome Heroku experience and fighting cash burn and
| when they hit a dozen or so engineers and are getting revenue
| and scaling up, $5,000/mo probably seems like nothing to pay
| for RBAC". I really hadn't thought much about "what" might be
| a good up-charge without either making the platform crappy
| for free users or something people wouldn't pay for. Heck,
| make SSO a paid add-on. Companies will pay so much for SSO
| while a small team of a few people can easily be like "yea,
| you just have a different password in the PaaS". I mean, Okta
| is worth billions just trying to solve SSO.
|
| Those both feel like features that companies making real
| money wouldn't hesitate to fork over cash for while someone
| working on a side project or a startup trying to become
| ramen-profitable can avoid.
|
| It definitely quells my worries of "will they decide that
| it's limited to 3 machines" or "will they decide that high-
| availability is just an enterprise feature" or "will they
| disable Let's Encrypt for free users". I mean, there are so
| many ways that a product can go into the "this is basically
| just trial software unless I pay" bin.
|
| I think pointing out that you're post-dating k8s by a decent
| amount is a great point too. A lot of things like Portainer
| pre-date k8s (and lots of things we take for granted now-a-
| days like Let's Encrypt) and now have Docker, Docker Swarm,
| and k8s modes that they're looking to support. Building as
| the ground is shifting underneath you isn't easy - you're
| building when k8s is pretty well-established, Helm seems
| established, etc. You're not trying to figure out where
| containers are going. You're not worried about Docker Swarm,
| Mesos, etc. You're just trying to make it fun and pleasant
| for people.
|
| Since you're here, one thing that I would say is that it
| would be nice if there was an easy "get a basic k8s setup on
| these servers I have" automated into your thing or a small
| doc of how you think it should be setup to start. I see that
| one can choose between AWS, GCP, DO, or "I already have k8s",
| but it would be nice to see something to get over that hurdle
| outside the three blessed platforms.
|
| Best of luck to you over the coming months!
| yebyen wrote:
| Deis Workflow is not abandoned! Just changed names, and teams,
| (but it's still my grandfather's axe!)
|
| https://web.teamhephy.com
|
| If porter-dev is selling managed hosting platform services,
| they already have a stronger business model than Deis did
| (which was, I guess, to get acquired by Microsoft and
| subsequently never provide any form of managed version of
| Workflow)
|
| I don't know what Deis Labs business model is/was to be honest
| but it seems to have been a success, :-) there are worse
| footsteps to follow in
| mdasen wrote:
| Cool, it's great to know that it isn't abandoned.
|
| I'm not sure why you'd say that their business model was a
| success. They were bought by Microsoft for Azure. I guess I
| wonder if a PaaS company can survive without getting the
| profits off renting the machines to people. Amazon, Google,
| and Microsoft all have PaaS options based around the idea
| that it comes bundled with the compute, not as a standalone
| open-source thing for you to use on any platform.
|
| I guess the question is whether Porter's business plan is
| "make enough that a company that owns a cloud wants to buy
| us". Oracle could probably use a nice PaaS platform and team.
| Maybe DigitalOcean would like to beef up their PaaS offering
| by acqui-hiring a team with proven knowledge.
| yebyen wrote:
| Well, they built Helm which is reasonably successful and
| carries on their legacy with a large community following.
| They proved themselves to be among the top experts in the
| space and got some of the most solid financial backing you
| can imagine as a result of their efforts; the remaining
| Deis / Azure folks moved up the value chain, to build AKS,
| which is also pretty successful and has a large client
| base.
|
| They built Workflow which was IMHO incredibly popular with
| those that used it, but, from discussion I had with the
| folks that moved on leaving Workflow behind, it wasn't
| "pressure from above," or anything like that; they simply
| went where the market forces were pulling, and opted to
| work on what they thought would have the most impact.
|
| Team Hephy has never really had the aspirations to be a
| business, just to preserve the capability to go on using
| Workflow on newer generations of K8s. We develop and
| maintain it because we like using it, we don't need it to
| change in major ways, and so we aren't really concerned
| about its commercial viability (which Deis certainly was.)
|
| So, without the SaaS offering, what is the best outcome for
| a company that develops Workflow? You build up a base of
| customers who were all too cheap to use Heroku, and once in
| a while a breaking change from K8s upstream means they
| depend on your support, but only if they are conscientious
| about upgrading...
|
| I don't think that means there isn't or wouldn't be any
| market for Heroku-compatible competitors, not by a
| longshot. I have no idea if it's a viable market, but I
| still hear a lot of groaning about how hard it is to use
| Kubernetes often, and at least twice a year I see someone
| trying to invent Deis PaaS again. The "Kubernetes On-
| Ramping" market is still very ripe.
|
| How does it go? "I'm convinced the majority of people
| managing infrastructure just want a PaaS. The only
| requirement: it has to be built by them." https://twitter.c
| om/kelseyhightower/status/85193508753294540...
|
| I haven't tried this new one out yet, but I definitely
| will. Have to scope out the "competition" and see what the
| grass is like on the other side. I hope it is greener
| there!
| sandGorgon wrote:
| There is also OpenFAAS - built on top of k3s
|
| https://github.com/openfaas/faas
| frenchman99 wrote:
| Heroku and Porter are more like a PaaS (Platform as a Service).
| Not sure FaaS can compare here. A PaaS could include a FaaS
| offering, but not the other way around.
|
| Unless you can deploy something like Postgresql to a FaaS. If
| that's doable, I'd like to read more about it.
| WrtCdEvrydy wrote:
| You can't deploy Postgres to FaaS, however you can deploy
| open OpenFaaS on Caprover / Porter and then deploy octo-cli
| functions.
|
| I do wonder if hosting dqlite inside of OpenFaaS would be
| possible as it's just distributed sqlite which is just a
| file...
| freeqaz wrote:
| I have long pondered an answer to this question. There are
| some hacks for various DB mechanisms. But nothing truly on
| par. It's a business opportunity if anybody crack this!
| damsta wrote:
| Take a look at CapRover, really lovely piece of software!
| https://caprover.com
| malka wrote:
| Caprover is awesome for personal projects, but lack enterprise
| features.
| jopsen wrote:
| I hate to be that guy, but 2FA is a pretty important thing,
| context:
| https://github.com/caprover/caprover/issues/493#issuecomment...
|
| I'm leaning towards just paying for heroku, because it's
| managed.
| gingerlime wrote:
| CapRover is cool, although at least last time I looked at it,
| it felt more suitable for personal hosting. In a way it
| promoted point-and-click interactions over scriptable, CD-type
| deployments.
| netcyrax wrote:
| It actually offers both point-and-click _and_ CD-type
| deployments (through webhooks). But yeah, not the most
| powerful piece if you are looking for CD /CI. Still more than
| good-enough IMHO.
| AlphaSite wrote:
| Isn't this basically the idea behind cloud foundry?
| yebyen wrote:
| Are you aware of Hephy Workflow by any chance? (Nee Deis
| Workflow)
|
| If so, are you aware of the Porter project which is built on
| CNAB, (by I believe many of the same folks?)
|
| https://deislabs.io/
|
| I am with Team Hephy, and for the record I think this is super
| cool what you've done. I just think it's an awfully great
| coincidence that the name is so close to something else so nearby
| in the same space!
| abelanger wrote:
| I was unaware of the Hephy Workflow/Deis Labs background, but
| yes, porter.sh has come up recently and we are aware of this.
|
| For some clarification, Porter was initially started as a
| remote dev solution (similar to Github Codespaces) as part of
| the S20 YC batch, which operated in a very different space.
| When we pivoted to the current PaaS solution, we kept the same
| company name/domain, but didn't think to check on the name
| collision after we pivoted.
|
| We're going to address this at some level, whether it be a name
| change or much more explicit clarification in our Github repo,
| since we're also unhappy about the name collision. Sorry for
| any confusion this may have caused.
| yebyen wrote:
| Not a problem for me, congratulations on the launch!
| jasfi wrote:
| Does Porter have any functionality for managing DBs?
| dbeech wrote:
| Aiven.io might be a nice solution for this alongside Porter.
| (Aiven is my employer, for transparency!)
| abelanger wrote:
| For proper DB management (backups, patching, scaling) we
| usually recommend RDS, Mongo Atlas, etc.
|
| That said, we do support running a basic instance of Postgres,
| Redis, or Mongo: https://docs.getporter.dev/docs/add-ons-1.
| gingerlime wrote:
| Looks really neat. We have a not-super-trivial rails app that I
| want to move to docker one day, but kinda scared to make the
| jump. We're already using docker for development, plus even have
| a home-grown docker-compose setup for ephemeral labs, but it's
| clunky at best.
|
| This seems like something that might provide a simple jumping
| board hopefully... Also bumped into fluxCD[0] recently which also
| looks interesting.
|
| [0] https://github.com/fluxcd/flux
| sungrokshim wrote:
| It's not necessary for you to dockerize your app to use Porter.
| Porter uses buildpacks to automatically build your apps if it
| can't detect a Dockerfile.
| gingerlime wrote:
| Thank you. The docker part isn't the barrier for us, but
| rather all the other moving parts that glue stuff together,
| eg load balancing, custom nginx directives we have, static
| file serving/caching, deployments, datadog integration etc
| ... not to mention just the paralisys of choosing something
| amongst the sea of options out there :)
___________________________________________________________________
(page generated 2021-03-26 23:02 UTC)