[HN Gopher] Launch HN: Porter (YC S20) - Open-source Heroku in y...
___________________________________________________________________
Launch HN: Porter (YC S20) - Open-source Heroku in your own cloud
Hi HN! We are Alexander, Justin, and Trevor from Porter. We're
building a Kubernetes-based Platform as a Service (PaaS) that
deploys applications on your own cloud provider. Specifically,
Porter provisions a Kubernetes cluster in your own cloud account
and lets you deploy and manage applications on it through a Heroku-
like PaaS layer. And although applications deployed via Porter run
on Kubernetes, no knowledge of Kubernetes is necessary to use
Porter. Here is our repository (https://github.com/porter-
dev/porter) and website (https://getporter.dev). There was also an
HN thread about us a few weeks ago, posted by someone who
discovered us (https://news.ycombinator.com/item?id=26587637 -
thank you OP!). We have known each other since high school/college
and have been working on projects together full-time since 2020.
When YC funded us in S20, we were building a remote development
platform for teams on Kubernetes (kinda like repl.it but for
microservices in particular). This was a more enterprisey product
and we got burnt out by the slow sales/iteration cycle (we had zero
experience with sales, let alone enterprises). So we decided to
pivot a few months after demo day. When we were struggling to get
traction with the original direction, we learned a ton by talking
to engineering teams that are using Kubernetes (k8s). One thing we
noticed is that there's an increasing number of startups who start
on a PaaS like Heroku and end up migrating to k8s later as their
applications "grow out" of Heroku, due to constraints in
networking, performance, security, etc. While Kubernetes is great,
it incurs a ton of engineering overhead. For teams who don't know
k8s at all, learning everything from scratch is daunting and time-
consuming. Even if there are devops engineers on the team who are
familiar with kubernetes, adopting k8s slows down developer
velocity because other developers always need the devops engineers'
help to troubleshoot the slightest application issues. While we
were working on our previous product, we discovered that some
companies even built internal development platforms (IdP) that are
much like Porter, in order to help developers deploy and
troubleshoot their applications without help from the devops
engineers. Our goal with Porter is to create a platform that is
truly as easy to use as Heroku, without compromising the
flexibility of k8s. There are many self-hosted PaaS's that came
before Porter, such as Flynn, Tsuru, Dokku, and CapRover, which
were all created before Kubernetes changed the DevOps landscape.
While these are great lightweight options for smaller projects, a
PaaS built on top of the k8s ecosystem comes with many benefits
such as scalability, stability, configurability and
interoperability across cloud providers. We believe that k8s is the
best system to deliver a PaaS on, and we're not alone - many of the
new hosted PaaS's are also built on top of k8s, although that's an
implementation detail that is usually not advertised to the user.
We want to not only deliver the PaaS experience on top of
Kubernetes, but also give users full ownership/control of the
underlying k8s cluster by running it in their own cloud. How it
works: we spin up a k8s cluster in your own AWS/GCP/DO account and
let you deploy and manage applications on it through a Heroku-like
abstraction layer. For teams using a PaaS like Heroku, Porter can
be a drop-in replacement that you don't "grow out" of. And although
our abstraction layer covers most use cases, we let those who want
to customize go freely under the hood to interact with the
underlying cluster. In each cloud provider, we provision the
standard managed k8s offering (e.g. EKS/GKE/DigitalOcean
Kubernetes), so the clusters we provision are perfectly compatible
with kubectl and any other k8s tooling out there. It's even
possible to connect Porter to an existing k8s cluster--this isn't
the primary use case we're building for at the moment, but we'd
love to discuss it in the comments if anyone is interested. In
terms of implementation, we've built Porter around the Helm
ecosystem, and every application you deploy is packaged as a Helm
chart. For those who want more visibility, we've built features
like "devops mode" that lets you visualize and manage the Helm
charts and its underlying k8s objects. We've published Porter to
be fully open source under the MIT license. We provide a hosted
version that is currently in open beta, but it's also possible to
run Porter locally. It's worth clarifying that on the hosted
version, the applications you deploy through Porter still run in
your own cloud. What is hosted by us is only the PaaS layer, not
your applications. We plan to release a self-hostable version of
the PaaS layer itself in the near future, packaged as a Helm chart.
We do not support this yet because self-hosting the PaaS layer
inevitably incurs devops overhead and requires some knowledge of
k8s, and we are currently focused on those who just want the Heroku
experience without having to deal with k8s in any way. In terms of
pricing, we are still figuring out the specifics. Our goal is to
not charge individual developers/small startups but instead draw
revenue from larger teams based on usage, and with premium features
that are geared towards collaboration. Existing PaaS's like
Heroku/Netlify have solid examples of such premium features -
review apps, pipelines, and Role Based Access Control are a few
examples that we also consider to be potential premium features on
Porter. That said, we are currently focused on laying out the
stable foundation of the platform, so these premium features are
further down on our roadmap. Thank you so much for reading and
we'd love it if you could give it a try: https://github.com/porter-
dev/porter. We'll be hanging out in the comments to hear any ideas
and feedback you may have. If you have any experiences related to
what we've built, we would love it if you could share them below.
Very much looking forward to learning from you!
Author : sungrokshim
Score : 161 points
Date : 2021-04-30 13:49 UTC (9 hours ago)
| resouer wrote:
| Really nice project, and really hoping these efforts could make
| devs lives easier! Alibaba indeed built a OSS project named
| KubeVela (https://kubevela.io) with similar goal though with a
| bit different approach:
|
| 1. Modeling all platform capabilities with Helm/CUE modules, so
| essentially a PaaS built with Helm/CUE.
|
| 2. Self-service workflow based on above LEGO-style components.
|
| 3. No specific add-on system, so just Helm charts.
|
| We also auto-gen forms based on Helm/CUE, it's great more and
| more products are leveraging this capability and wider ecosystem.
| sungrokshim wrote:
| It's great to see enterprises like Alibaba build out these
| types of internal developer platform (IDP) around Helm. We've
| talked to the engineers who built out these IDP's at different
| companies because we wanted to build a generalized solution
| that is not specific to one company's devops culture. We hope
| to democratize IDP's to smaller companies who can't afford to
| build things out themselves internally!
| sreejithr wrote:
| Great idea! I'd totally use this if it had Azure support. Is
| Azure support on its way?
| jusrhee wrote:
| Yup, we're rolling out support for Azure and some other cloud
| providers in the next few months!
| mwcampbell wrote:
| On the one hand, I don't want to post a shallow dismissal on your
| big launch day. On the other hand, this does look like something
| that's been tried a dozen times before. To name one example,
| Convox (https://convox.com/) started out using ECS on AWS, but
| more recently switched to being a multi-cloud platform on top of
| Kubernetes. Cloud66 has also tried a few things in this space.
| What sets Porter apart from other products in this apparently
| crowded field?
| kybernetikos wrote:
| I played with convox a little and a month later discovered I
| unexpectedly owed AWS a rather large sum of money. For small
| projects I'm now happy running caprover on dedicated hosts
| where I understand the cost (and it's really quite small).
|
| One way porter could interest me would be if it incorporated
| best practices for me not to get fleeced by the cloud operator.
| sungrokshim wrote:
| We've encountered this from our early users and are
| definitely looking for ways to incorporate transparency of
| cost. AWS is particularly opaque when it comes to pricing,
| and I'd love to hear any ideas you have in things that would
| help you better understand costs. What comes to mind is
| integrating with something like InfraCost (YC W21)...
|
| That said, for small projects we are adding support for
| cheaper independent cloud providers very soon. We've talked
| to folks at both Vultr and Linode, which provide
| significantly cheaper k8s offerings, and are working with
| them right now!
| mwcampbell wrote:
| > AWS is particularly opaque when it comes to pricing
|
| How so? Doesn't AWS break down the cost of each resource
| you consume? I suppose it's difficult to predict all of the
| little costs that will add up though.
| akh wrote:
| Co-founder of Infracost here, happy to help with
| integrations if needed. Regarding smaller cloud providers,
| someone from our community is adding Scaleway, such
| providers usually have pricing that is an order of
| magnitude simpler than AWS/GCP/Azure.
| sungrokshim wrote:
| Yes let's talk!
| evoxmusic wrote:
| Hey greetings from Romaric :)
| [deleted]
| foxbarrington wrote:
| Deis Workflow (now Hephy) is another one that didn't last. This
| is an area I'm very interested in, but I worry there isn't
| enough of a critical mass to support tech like this.
| rubiquity wrote:
| Yes there was also Skyliner.io and I had one coincidentally
| named Surfliner 3 years before that which I killed before
| launching. What I've learned is that in this particular space
| there are two kinds of developers: the ones that don't want to
| run anything and the ones that want to run everything
| themselves.
| sungrokshim wrote:
| This was our biggest hesitation when we were first evaluating
| the idea - we thought companies want to either "outsource"
| devops completely by using something like Heroku, or hire a
| devops engineer to do the devops work, obviating the need for
| a platform like this.
|
| However, we were surprised to find that a lot of our users
| actually fall in the middle - they want to run things in
| their own cloud, but don't want to deal with the complexity
| of k8s. Perhaps the biggest change in the last 3 years is
| that k8s became a popular option even for startups - adoption
| of k8s has been "trickling down" and now the k8s user base is
| increasingly composed of those who "know the basics of k8s,
| but don't want to deal with all of its complexity". We've
| found that a platform like Porter fits in with that type of
| demographic, and we are optimistic that there are more of
| these companies based on our current data.
| sungrokshim wrote:
| No worries, this is a valid point and does not come off as a
| dismissal. As you said, there are many PaaS's built on
| Kubernetes. And they lie in a spectrum of abstraction: on one
| end, there are OpenShift and Rancher that requires knowledge of
| Kubernetes to some extent. On the other end of the spectrum,
| there are hosted PaaS's like Render that look more like Heroku,
| and the user does not even know that their applications are
| running on Kubernetes. In my opinion, at least as it currently
| stands, Cloud 66's Maestro and Convox fall somewhere in
| between.
|
| Our goal with Porter is to create a platform that accommodates
| both ends of the spectrum. And this is motivated by seeing
| companies develop internal developer platform (IdP) that I
| mention in the post - we want to create a platform that
| abstracts k8s away to the extent of Heroku's DX while
| accommodating the DevOps engineers' need for
| flexibility/configurability on top of k8s. This is why we
| invested in features that optionally give the user more
| visibility into the underlying k8s cluster and helm charts.
|
| By default, Porter looks and works just like Heroku. With
| "devops mode" turned on, Porter looks more like OpenShift and
| Rancher. Essentially, there are two user personas we are
| building for: an application developer with no knowledge of k8s
| and the devops engineers who need to help the application
| developers and often even build out an IdP. We are focused on
| the former for now, but I think what distinguishes us from the
| other k8s based PaaS's is our commitment to building the mature
| version of Porter to accommodate the latter.
| mwcampbell wrote:
| Thanks for that response.
|
| Do you have any plans to cater to devops engineers who want
| to use infrastructure as code tools such as Pulumi or
| Terraform to manage both their Kubernetes cluster and their
| other cloud resources (e.g. AWS RDS database) with one tool?
|
| Also, just so you know, the abbreviation IdP (with that
| particular capitalization) is already a term in security,
| particularly in the context of single sign-on; there it
| stands for identity provider. Edit: I suggest IPaaS as an
| alternative.
| abelanger wrote:
| Co-founder (Alexander) here.
|
| > Do you have any plans to cater to devops engineers who
| want to use infrastructure as code tools such as Pulumi or
| Terraform to manage both their Kubernetes cluster and their
| other cloud resources (e.g. AWS RDS database) with one
| tool?
|
| Yes, this is a request that we've gotten from current
| users, and we'd like to release a Terraform module in the
| next two months that allows users to provision a cluster
| compatible with Porter for this exact use-case. We're also
| thinking about releasing a Terraform module that can
| install a cluster hosting the PaaS layer for fully on-prem
| use-cases. This wouldn't be too hard to do considering our
| cluster provisioner is packaged as a Terraform runner and
| we use Terraform to manage our infrastructure internally.
|
| Also, we're going to open-source our provisioner in a
| separate repo at some point soon, and we're thinking about
| using Pulumi to get slightly more control over the
| automated infrastructure provisioning (using Pulumi's
| automation API: https://www.pulumi.com/blog/automation-
| api/). So I wouldn't be surprised if we released something
| more native to Pulumi as well, but we have to look into it
| more.
|
| > Also, just so you know, the abbreviation IdP (with that
| particular capitalization) is already a term in security,
| particularly in the context of single sign-on; there it
| stands for identity provider. Edit: I suggest IPaaS as an
| alternative.
|
| I thought I recognized that abbreviation -- I believe we
| picked it up after reading an interesting article about
| various internal dev platforms[1] (to be fair, that article
| uses the capitalization IDP).
|
| [1] https://www.infoworld.com/article/3611369/how-to-build-
| an-in...
| matt2000 wrote:
| First, congrats on the launch! Glad to see more products in this
| space. Now, some questions :)
|
| I've looked at many of the attempts similar to this over the
| years and while you hear "you don't need to know how to operate
| K8S" you are in fact operating K8S and when there's a problem
| suddenly all this complexity is revealed. If Heroku has a
| problem, it's pretty clear where the responsibilities lie, but
| with this it's your code but my deployment so I'm kind of on the
| hook. What are your thoughts on that?
|
| How would you compare to something like app platform at Digital
| Ocean?
|
| Thanks!
| jusrhee wrote:
| > I've looked at many of the attempts similar to this over the
| years and while you hear "you don't need to know how to operate
| K8S" you are in fact operating K8S and when there's a problem
| suddenly all this complexity is revealed.
|
| You're definitely right to flag that there's a fine line
| between a useful and leaky abstraction of Kubernetes as a PaaS.
| Since Porter expects you to deploy services by linking up a
| GitHub repo or Docker container, our responsibility is the same
| as a service like Render which also delivers a Heroku-like
| experience on Kubernetes. Fwiw at least half of our users are
| teams that have no existing familiarity with k8s and they're
| able to use Porter treating it purely as an implementation
| detail.
|
| > How would you compare to something like app platform at
| Digital Ocean?
|
| The main difference on the flip side is that app platform locks
| you out of deeper control of the underlying infrastructure if
| you ever want it (say, for configuring a production
| environment): https://docs.digitalocean.com/products/app-
| platform/#when-no.... Also, I suppose it goes without saying,
| but the abstraction we provide has the benefit of being cloud-
| agnostic and is the same regardless of where your environments
| are hosted (DO, AWS, GCP, etc).
| cloudcodes wrote:
| Porter looks really nice, kudos on open source.
|
| Also, lots of companies in this area, was talking to folks behind
| Octad (https://octad.io) who are doing similar stuff too.
|
| I also wonder how will it all play out in 1yr and how it would
| impact customers. Almost all these cos are on the similar
| tangents - Render (self hosted), Qovery, Convox, Platform.sh,
| Octopus.com, Reploy, Releasehub, etc etc.
| sungrokshim wrote:
| The advent of k8s really gave the PaaS providers the luxury to
| focus on the platform layer rather than creating the infra
| layer from scratch. The market is early and we're excited to
| see what innovation each of us is going to bring to the table!
| pixel_tracing wrote:
| I think my major hesitation is your pricing model, I don't want
| to be surprised by some bill and that is the biggest turn off
| from your product.
|
| I just want to peacefully launch my side projects without being
| "locked" into a vendor or framework that will start charging me
| on a random day after it was free.
|
| That's why I opted out of porter and learned to deploy and build
| my own automation pipeline.
|
| Please change my mind porter guys.
| sungrokshim wrote:
| Pricing discussion is always tough for startups because the
| pricing model evolves so quickly and so often. As I address in
| the post, we are still figuring out the specifics and we
| completely understand that some users will be turned off by
| this - we apologize for this uncertainty. I am aware how naive
| and hand-wavy this sounds, but we genuinely mean it when we say
| our goal is to not charge smaller companies and indie devs. We
| are not maliciously avoiding the pricing discussion because we
| want to "surprise charge" users later.
|
| It is simply too premature to settle on pricing at the moment
| because we do not have enough data on the "bigger users", who
| will likely comprise most of our revenue. We have no intent to
| go out of our way to squeeze revenue from smaller users hosting
| side projects - quite frankly, the addressable revenue of that
| user segment is just too low compared to that of larger
| businesses for us to even fight that battle.
| mstipetic wrote:
| does anyone have any insight what's with all these companies
| coming out of yc that are just open source implementations of
| currently successful projects? there's been at least 5 now
|
| is there some reasoning behind it or are we running out of ideas?
| sungrokshim wrote:
| Building open source comes with a bunch of technical benefits
| like my co-founder mentions, and I don't think the recent trend
| is a result of YC startups "running out of ideas". It's
| somewhat like food companies going organic - at first organic
| food was a special thing, but organic food is becoming
| increasingly common because every company is doing it. (or
| maybe it's just at my grocery store :) )
|
| We decided to go open source quite naturally for the benefits
| that Alexander mentions, but we are also aware of the business
| benefits that OSS brings. Open source/open core is increasingly
| becoming a standard in the devtool world and as the other
| comment points out, there is a certain degree of natural
| selection at play. To gain traction as a devtool company and
| drive bottoms-up growth, building in public helps tremendously
| these days, because developers almost don't want to use closed
| source products. Although the rise of "open core" and
| commercial open source projects does come with a bit of tension
| with open source purist ideology, I think this trend is
| something we should welcome as an industry. But this trend
| definitely isn't just a result of running out of ideas like
| Disney's endless real life remakes :)
| eterps wrote:
| Natural selection?
|
| Most devs try to avoid a lock-in situation. Having an open
| source option for the base functionality with additional paid
| features is something you can compete on.
| abelanger wrote:
| > does anyone have any insight what's with all these companies
| coming out of yc that are just open source implementations of
| currently successful projects? there's been at least 5 now
|
| I can't speak for other companies, but we didn't look at Heroku
| and think to just create an open-source competitor. We thought
| of the idea after interacting with companies that migrated to
| Kubernetes that wanted their Heroku experience back, and later
| decided to be open-source. So I don't think our core value
| proposition stems from the open-source aspect, but it made
| sense for a lot of reasons -- unique to our product/team we
| felt that open-source was appropriate for a tool in the cloud-
| native ecosystem and since all three of us are developers, it
| was our natural inclination.
|
| On the technical side, being open source has come with a bunch
| of benefits thus far -- we get detailed bug reports since our
| users are developers, we get a channel where devs can keep tabs
| on our progress, it gives us a public log where we explain our
| decision-making in the specs for various features, and it
| forces us to be better technically. We had to create a
| development process rather than just push code (when we worked
| on projects in the past, we didn't follow best practices with
| regards to PRs, documenting issues, reviewing code and testing
| changes, because we were solely focused on immediate velocity,
| which we would have regretted if those projects ever got off
| the ground).
| freedomben wrote:
| Off topic, but my last name is Porter and a couple years ago I
| tried to register the domain porter.dev but it was taken. I'm
| guessing you probably tried to do the same :-D
| nerdyyatrice wrote:
| Can someone please list the existing "Heroku" on K8s PAAS (I know
| about a dozen on top of my mind) and compare with them one by
| one?
| faitswulff wrote:
| How useful would Porter be for teams that have little to no
| Kubernetes experience?
| sungrokshim wrote:
| Teams with little to no k8s experience are the type of users we
| are primarily designing it for! The advanced features like
| "devops mode" is completely optional and only useful if you
| want to expose yourself to the complexity of k8s.
| steventey wrote:
| Have been using Porter for about 2 months now and all I can say
| is how impress I have been with the team's ability to ship new
| features + updates while also keeping up with their fantastic
| customer service! Have very high hopes for them and would
| definitely recommend betting on them early!
| evantahler wrote:
| We are early Porter users, and it strikes the right balance of
| being being "full service" to get you started quickly but then
| letting you tweak what we need in custom ways as you grow.
|
| The setup was simple - EKS cluster created for you (or you can
| use your own), automatic bot instrumentation to build and push
| containers for you, Heroku-like "git-ops" etc.
|
| But, under the hood they made the (IMO) wise choice to use each
| cloud's tooling as much as possible so you can modify things as
| needed. For example, the EKS cluster on AWS is in a regular
| autoscaling group. Persistent drives for containers (if you opt-
| into them) are regular EC2 block devices, etc.
| dchess wrote:
| How does this compare to Dokku?[1] I've been using that for a few
| years now with minimal lift/maintenance. I'm wondering what the
| trade-offs are of something like this?
|
| [1]: https://dokku.com/
| sungrokshim wrote:
| If you're running small projects, Dokku is a cheaper option
| compared to running a k8s cluster. Porter helps you leverage
| all the benefits of k8s like scalability, scalability,
| configurability, and is great for multi-cloud environments due
| to interoperability - these are all useful when you're dealing
| with projects at a larger scale.
| eterps wrote:
| Does Porter support having isolated environments per git branch
| like Quovery?
|
| https://docs.qovery.com/docs/getting-started/what-is-qovery/...
| sungrokshim wrote:
| Yes it's possible to do that on Porter. When you deploy an
| application, you choose which branch you want to deploy from
| and we build/deploy the application on every push to the
| specified branch. Under the hood, we write a GitHub actions
| file in your repo, so it's completely flexible and up to the
| user to configure how branches map onto environments (i.e.
| whatever is possible on Github actions is possible on Porter).
|
| We also plan to support a more out of the box behavior by
| adding integration with GitHub's recent deployment feature:
| https://docs.github.com/en/rest/reference/repos#deployments
| arvindamirtaa wrote:
| I had the pleasure of speaking with the founder way back when
| they were super early. Was really impressed but didn't have a
| very good use for it for me.
|
| So glad to see them grow into what they've become today :)
| EncoreApp wrote:
| To get the cluster up and running using AWS EKS, it costs
| $0.10/hour which means at a minimum you're spending $72/mo
| ($860+/year) to just run the cluster and not the underlying
| resources. How do you justify this and compare against other
| options like Qovery?
| joshjhargreaves wrote:
| I've self-hosted Dokku on Digital Ocean before with decent
| success: https://github.com/dokku/dokku. It's pretty nice for
| the scale of pet projects.
| sungrokshim wrote:
| Yes Dokku is an awesome option for smaller projects. The
| maintainers are great!
| nrmitchi wrote:
| Your point is valid, but 2 things:
|
| > One thing we noticed is that there's an increasing number of
| startups who start on a PaaS like Heroku and end up migrating
| to k8s later as their applications "grow out" of Heroku, due to
| constraints in networking, performance, security, etc.
|
| They seem to be particularly targetting users who are migrating
| off of Heroku (and are migrating to 'their own' Kubernetes) due
| to cost, at which point $72/m is likely a tiny drop in the
| bucket.
|
| Second, I agree with you that the EKS pricing is extremely
| restrictive for small projects, and _especially_ for projects
| that require multiple clusters. But that is kind of a gripe at
| AWS and their Kubernetes offering, rather than Porter. They
| appear to support other Kubernetes cloud offerings, so just use
| DigitalOcean 's (DOKS) if you don't want to pay for your
| control plane.
| marcinzm wrote:
| Practically speaking for a company that's doing well in any way
| $70/month is basically nothing. Not every product needs to
| cater to every potential user and they seem to be catering to
| users who have some amount of money.
| SkyPuncher wrote:
| Even without a ton a money, I would pay for this in almost
| any startup environment.
|
| As an early stage founder, my time would be way more valuable
| than $70/month. I need to do as many (practical) things as I
| can to focus on delivering the unique value of my product.
| cultofmetatron wrote:
| if you're running any kind of reasonably large deployment
| serving real customers, $72/month is NOTHING. my startup is
| dropping more than 1k/month already without including our
| devops guy's retainer!
| sungrokshim wrote:
| When compared to non k8s-based PaaS solutions like Heroku,
| using a managed k8s offering like EKS can be expensive. For
| those who are running small scale projects, k8s is an overkill
| and the benefits of scalability and stability might not be
| enough to justify using Porter.
|
| However, the underlying EC2 machines added to the $72/mo
| management fee on EKS is relatively cheap, and we've found that
| if you are using more than 4GB RAM/4 CPU on Heroku, the cost on
| EKS starts getting cheaper than Heroku (at scale, using EKS is
| substantially cheaper than Heroku). That said, we are actively
| working on partnering with independent cloud providers with
| cheaper k8s offering for those who are running small projects.
| At the moment the cheapest option is to use Digital Ocean with
| Porter, which can be as cheap as $35/mo. With regards to
| Qovery, AFAIK, Qovery also runs EKS and does not yet have the
| option to use cheaper cloud providers like Digital Ocean.
| evoxmusic wrote:
| Hi, I am Romaric, co-founder of Qovery. We do support Digital
| Ocean (https://docs.qovery.com/docs/using-
| qovery/configuration/busi...) as well as AWS
| (https://docs.qovery.com/guides/tutorial/how-to-deploy-
| your-a...). We plan to support Scaleway and GCP in Q3 and Q4
| 2021. Here is the roadmap https://roadmap.qovery.com
| sungrokshim wrote:
| Ah, this must have just been released, thanks for the
| correction. I was going off what's listed on qovery's
| repository [1] - It says "In Progress" next to Digital
| Ocean, you might want to update it along with the docs!
|
| [1] - https://github.com/Qovery/engine#-plugins
| evoxmusic wrote:
| Oh yes. Thank you. And good job for porter guys.
| mushufasa wrote:
| Hello! I'm currently using Heroku and exploring a switch due to
| technical limitations with Heroku.
|
| My team is evaluating porter versus alternatives like Qovery and
| Skaffold. What is your pitch on Porter versus other attempts to
| replicate the magic of Heroku with kubernetes on a directly
| controlled cloud?
| sungrokshim wrote:
| Skaffold is a bit different from Porter and Qovery because it's
| mostly a tool for development on Kubernetes, and its primary
| goal isn't to make deployments as easy as Heroku on k8s.
|
| I describe this in more detail in the comment above, but I
| would say the biggest difference between Porter and Qovery is
| that we intend to make Porter a platform that accommodates not
| only those seeking the magic of Heroku in their own cloud, but
| also the devops engineers who want to customize and "opt-in" to
| be exposed to the underlying complexity of k8s. Please give the
| above comment a look and lmk if you have any lingering q's.
| evoxmusic wrote:
| Hi - thank you for asking - I am Romaric, Co-founder of Qovery.
| Give a try to both product and pick the one is best for you.
| Porter and Qovery respond to two different purposes. Qovery
| offers a free plan for individual developer and a generous
| business plan (free up to 10 apps). Have a good day. Romaric
| jusrhee wrote:
| Yup, we don't plan to support a fully-hosted alternative to
| something like Heroku/Render where your applications run on
| our cloud.
| sfc32 wrote:
| A short video of how it works or more screenshots might be a nice
| addition to the repo.
| btzo wrote:
| github and documentation[1] have more screenshots
|
| [1] https://docs.getporter.dev/
| brap wrote:
| After just skimming through the landing page, one thing I want to
| point out:
|
| I absolutely love the fact that they simply show me what the
| product looks like. Often times you have to dig through docs and
| "features" pages just to get a glimpse of the offering. Here it's
| front and center, screenshots are right there in your face, can't
| miss it even if you want to.
|
| To other SaaS developers, I say: SHOW ME THE DAMN PRODUCT!
|
| The only step up from this is to have an _interactive_ ,
| radically simplified version of the product embedded in the
| landing page, with dummy data I can play with it, just to get a
| feel of the product. Obviously this is much more difficult to get
| right.
| sungrokshim wrote:
| Thank you! That's a great idea, at the moment you need to go
| through cluster provisioning to get the feel of our product -
| we were looking for ways to make the product more accessible
| without having to provision an entire cluster in your cloud
| (was playing with the idea of demo accounts). We'll take this
| into consideration when we update our landing page next time.
| Thanks again :)
| g_p wrote:
| I'd second this. Too many developer-facing products focus on
| the call to action being to curl-bash something, without
| showing them what it is.
|
| Showing off the product with clear screenshots is a real
| differentiator for me - I can understand far more quickly
| what you're offering from that visual.
|
| Making that interactive (in a minimal sense) would be a great
| next step - demo accounts are nice, but a working demo in the
| actual page itself would be really powerful - someone looking
| at the screenshot wondering if it has X option can click it
| and see for themselves.
| gramakri wrote:
| > The only step up from this is to have an interactive,
| radically simplified version of the product embedded in the
| landing page
|
| Just having a live demo link would be great.
| infocollector wrote:
| Any chance you could add Azure support as well? Perhaps there is
| something particular that is making that harder?
| sungrokshim wrote:
| We've talked to the folks at Azure recently, and Azure support
| is on its way along with a few other cloud providers!
___________________________________________________________________
(page generated 2021-04-30 23:00 UTC)