|
|
|
|
|
|
by matt2000
1871 days ago
|
|
|
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! |
|
|
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).