Convox's company blog covers deploying apps to AWS, containers, ECS and EFS challenges, and its Heroku-like open source platform.
Commenters bring up Convox as a Heroku-like option that is easier to set up than Kubernetes and builds on AWS services like ECS and RDS.
For context, we have a different AWS account for each environment (production, staging, etc.) and have as much parity as possible between them (although resource sizes might vary - for example different RDS instance sizes for staging vs. production). All of our services run on AWS ECS and CI is done through CircleCI.
Our deployments start with a Github PR needing to have 2 approvals from peers and have all CI checks pass. Once the PR has been approved it can be merged into master which will trigger CI workflows again with the additional step of deploying the changes to staging and building a new release for production. The author of the changes can then verify they work as expected and promote the release in production or rollback their changes if things aren't working.
All of our AWS resources are created and tracked through Terraform but services are created through Convox[1]. We use Convox to create "releases" (ECS task definitions), manage their lifecycle (creation, promotion, releases, rollbacks, etc.) and it's CLI is pretty convenient (promoting a new release is as simple as running `convox releases promote <ID>`). That being said we've had some shortcomings with it and have outgrown it's flexibility. We'll be starting our migration into k8s early next year but it's worked great for us for the past 2 years.
[1] https://convox.com
I use Convox (http://www.convox.com). It is backed by ECS which gets me out of the infrastructure game for the most part and the CLI interactions in Convox are similar to heroku style commands so the learning curve is much simpler than deploying and learning my own Kubernetes or OpenStack or ECS configurations. They've also thought of the other things you need like environment based secrets(uses DynamoDB and KMS behind the scenes), as well as external load balancing, TLS, RDS integrations and more with single simple commands.
They also have CI/CD out of the box and builds can be triggered in your existing cluster with a 'convox build' or triggered on pushes to your private github repos.
Overall, unless you have a team that actually sees benefit in managing your own container and cluster manager(you better be big), id recommend embracing Convox, or something like it. The complexity still exposed by Kubernetes, OpenStack or ECS is still significant.
Interesting to see more competitors to Heroku popup. Kind of amazing how the big cloud providers still haven't solved this problem.
Heroku still has one of the easiest setups of anyone on the market, and they've just been coasting in recent years. Poor container support, auto-scaling is naive, random routing (see rap genius), no health checks, pricey, etc.
Previously Deis built a Heroku like service on top of Kubernetes, but they got acquired by Microsoft, and the product has since atrophied.
Convox[0] seems similar to Qovery, with the added ability of self-hosting (UI is closed source though).
I think Qovery not having a UI is a deal breaking for many. Heroku's CLI, UI, and API is a killer combo.
[0]: https://convox.com
Question for mitchellh or others at Hashicorp:
Will "zero configuration" be a feature/goal in your next attempts at this abstraction? Was this one of the things that made building Otto so challenging?
A few months ago when I tried Otto I found the "zero configuration" idea off-putting. In fact, I couldn't even get a basic Python app to work because there was no way for me to install libmysqlclient[0]. There really was no way to configure anything in Otto.
FWIW, we ended up using Convox[1] and loved it.
[0] https://webcache.googleusercontent.com/search?q=cache:9QfCNXO52GsJ:https://github.com/hashicorp/otto/issues/400+&cd=1&hl=en&ct=clnk&gl=us
[1] https://convox.com/
Not every product needs AZ from the start (specially for small teams or solopreneurs), in most cases you'll be doing over-engineering. And in the use cases you need AZs and do it right new tools like convox* are really easy to use and can save you a lot work. It's never been this easy to manage your own infrastructure.
During the years I've used ssh, puppet, fabric, ansible, capistrano, cloud formation, etc for managing servers and infrastructure. And I think that the main benefit of any PaaS, AWS Lambda or AWS API Gateway is (obviously) that they're time saving and abstract the internals. In fact I use them in several small projects.
* https://www.convox.com
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?