https://getporter.dev/ https://convox.com/ https://atomizedhq.com/
And closely related:
https://humanitec.com/ https://www.okteto.com/ https://www.env0.com/
And then old options like:
https://dokku.com/ https://caprover.com/
And maybe:
https://swarmpit.io/ https://coolify.io/ https://www.bunnyshell.com/ https://platform9.com/
And probably a dozen more. It's kind of wild.
I'm excited to see so much interest in making Cloud Native more accessible. Companies like Qovery and FlightControl make awesome products too, of course. This is not a winner-takes-it-all problem because the market is huge and infrastructure is diverse.
Great developer experience is a win for everyone.
That said, we believe that Coherence is unique in being integrated from dev all the way to production (it concludes cloud IDEs natively), being dashboard (vs CLI) based, and having a strong opinion about what environments types you need and how they relate to each other. This lets us reduce the CI/CD and integration work needed to use this on your team by 10x.
Similar to SetOps (which looks like an awesome product, btw) we don’t bet 100% on k8s as the only answer and believe in leveraging cloud-provided abstractions as much as possible. Agree with the sentiment that this is a big space and won’t have a winner-take-all outcome.
We’re in a closed beta, so if you’re interested in giving it a spin please get in touch!
I have really mixed feelings about this response.
On the one hand, I 100% agree - vanilla k8s is not prod-ready, and you need to do a _lot_ of work to figure out some things, especially around persistent storage (but load balancing and certs are a pretty solved problem).
But the line "you don't need to care how we run containers" bugs me. Maybe your two-person start up doesn't need to know, but eventually you will grow to the point that you _do_ need to care how things are running, and need control over it. This is why so many companies end up outgrowing Heroku and have to go through an expensive migration.
What I'd love to see is a "batteries-included Kubernetes", which allows me to slowly take control over more and more of the stack, until I'm a 1000 person company and ready to run my own clusters.
And there are a lot of companies which do not become the next Unicorn and need an easy way to manage their container workloads.
SetOps currently uses ECS since it comes with no additional overhead costs for the management plane/API and does the container management job well enough. However this is not a definite decision and ECS could be replaced in the future. The main point is that there is a simple abstraction for users managing the workloads and that the "backend" is interchangeable.
* Understanding which workloads share a node's memory/CPU, and isolating certain workloads for security reasons
* Running specific workloads on specific instance types (e.g. with GPU or extra CPU)
* Configuring network policy between workloads
* Airgapping certain workloads
* Setting priority levels for different workloads, so some scale more rapidly while others have to wait for a new node to be provisioned
* Customized scaling behavior (e.g. based on the depth of a queue or latency metrics)
* Multi-region support for DR
I could probably go on :)
Not everything is a stateless HTTP microservice. Solutions like ECS start to fall apart when you try to run stateful workloads, especially when the lifecycle of the workloads needs to be coordinated to prevent loss of availability or data (i.e. cannot tolerate 2/3 of the containers being knocked offline at the same time). AWS does not offer a managed datastore (e.g. RDS) for every datastore, and many of the datastores it does offer (e.g. MSK) are "let's tick this box in the quest for covering all our customer needs" but not cost-effective for production workloads.
Maybe, as a product, you make a decision to tell your customers, when you need to run something like that, go hire DevOps and migrate off. But you'll be more credible if you're up-front with what kinds of workloads you don't intend to support, so that customers who have a strategic vision for engineering can say, hey these guys will be great for me for the next few years, now I'm more likely to buy in.
Is this not desirable for others ? All the solutions that I see are focussed on containerizing (I get that to an extent). But I would personally want a service on top of AWS that abstracts away setting up EC2, load balancers, auto scaling, RDS etc etc. Does it have to be kubernetes ?
Choose your stack and beanstalk deploys to a load balanced, autoscaling group in your VPC. You can attach a RDS when you choose your stack. And all resources can be managed separately or through CloudFormation. Beanstalk also supports container deployments.
From the website > "You can simply upload your code and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring. At the same time, you retain full control over the AWS resources powering your application and can access the underlying resources at any time. There is no additional charge for Elastic Beanstalk - you pay only for the AWS resources needed to store and run your applications."
I can share a slide of one of our presentations right now which roughly shows the inner workings of SetOps in your AWS account: https://static-media.setops.co/infra/aws-components.png
BUT, it takes 24 separate commands to launch a "quick start" rails app. Hopefully this is just a alpha/beta experience, and the idea is get these going a little easier?
And once I launch it, what AWS resources are being used? How much should I expect this quick start rails app to cost me? Having a hard time figuring that out.
Regarding the AWS Resources being used: The cost estimation feature is on the roadmap, telling you how much exactly one Project costs. And showing you in advance how much more changes will cost.
Using SetOps starts with base costs since we need at least one EC2 instance + database running and some other services. The base costs are ~130$, including your first apps. But launching your first 10 containers doesn't bring many additional costs, so running some apps are quite cost-efficient.
Someone else already stated here that something is missing in the docs regarding the services provisioned in AWS. We will deliver that! For now, I can show you this slide from the internal pitch deck: https://static-media.setops.co/infra/aws-components.png
Also you have some potential for saving money by over-provisioning your workloads on the actual compute instances, which is, as far as I can see, is not possible with Cloud Run.
Is SetOps using Kubernetes (EKS) or ECS?
Heroku is awesome; I started my dev career with it as well. But for us, a digital agency, it didn’t scale very well, mainly price-wise. AWS solved the pricing issue but made our dev teams slow since they did not know the in-and-outs of AWS and therefore relied on the DevOps team, which became a bottleneck for new projects.
During this time, the idea of SetOps was born. We imagined a tool that empowers developers to run their applications in the cloud to ship apps faster. But it needed to be flexible enough to fulfill all our customer’s requirements. So our key target group is Devs & DevOps alike. By providing a web interface, CLI and API, it can be used by devs and automated CI/CD systems.
Unlike other players like Heroku with SetOps users deploy to your own AWS account – keeping ownership and control of their infrastructure, allowing them to leave SetOps as they please and profit from AWS saving plans which might save a lot of money.
Two important topics to us are reliability and cost-efficiency. By using AWS ECS, managed load balancers, autoscaled EC2 instances, and redundancy across data centers, the infrastructure and, therefore, the deployed applications are highly available and self-healing. By sharing resources as much as possible – like one load balancer for multiple apps and shared database instances – SetOps can save some additional bucks.
If there is a use-case that SetOps does not support, it can be extended by additional AWS resources and external cloud services like MongoDB Atlas via VPC peering. Also, a reason to deploy to one’s own cloud account.
Although user-facing SetOps is currently an imperative infrastructure tooling, under the hood, we use a JSON definition of a so-called stage (a collection of apps and services) which we pass to Terraform to ensure that the state in the cloud account always matches the desired state. This allows for fixing broken AWS configurations as well.
Long story short: if SetOps sounds interesting, check out setops.co. We are looking forward to your feedback and use-cases.
