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.
> Isn't it just Kubernetes under the hood? That's not the right question...Kubernetes is just one of the building blocks for easy and secure app deployment. It is not a one-shot answer for day two operations such as reliable databases, load balancing, backups, certificates, and data security...With SetOps, you don't need to care how we run containers – you'll profit from the sensible choices and long hours our infrastructure experts spent to make sure it runs well.
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.
Interesting thought. I can see your case for some growing companies. However I'm not sure if you would always need Kubernetes for this. What would you like adjust when we grow into a 1000 person company? I think you have still similar requirements like autoscaling, resource allocation, zero-downtime deployments etc. This is also possible without direct access to the container management.
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.
You are totally right. For these specific use cases you probably want full control. :) I guess if you have these requirements a tool like SetOps, which simplifies the management, might not be the right fit then.
Although some of these requirement, like running specific workloads on specific instance types, could easily be implemented.
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.
They do have Batch, which IIRC was originally only for ECS, for that scenario.
It's quite horrible in many ways but not I don't think any of it is really because the ECS model is somehow inherently unsuitable for stateful long-running workloads, it's Batch being a bad product.
Both ECS and Batch are just leaky abstractions enough that some unknown unknown or forgotten nuance will come along and bite you when you least need it and make you question the value proposition.
It's funny you mention that. I'm currently a bit stalled (mostly for lack of time/motivation, but trying to get back on it very recently) trying to build exactly that. I'd be very curious what you think of the premise I've outlined on my landing page [0]. Basically, I have built the same thing a half dozen times and I want to do it for more people, for less money individually. And as part of the bootstrapping and DX, provide training on all the components, how to use them, and why I chose them. Ultimately you should be able to walk away eventually if I've gotten my part right. Or don't, if I can continue adding value at a rate you think is worth it.
There is very little on this page. The bios are cut off on the Team page, the landing page is basically just a blurb. I much prefer sites that enable immediate demos of the thing in question, or at least something that gives me a better sense of what the value-add is. The site itself reminds me of consultancy sites more than a 'product' oriented startup page. Just my $0.02
You're not wrong, and that's the part I'm working on now. I've honestly mostly just used this page to suss out what I want to do, but apparently I could do better about communicating what it means to me. I'm guessing a video demo would be helpful, plus actually being able to take it for a test run. I'm pretty stoked about what I have, but it's just not quite ready to do much other than a video demo.
I'd hoped the intro page was enough to get the idea across in general, but it sounds like I need to improve there.
This also makes sense as somebody who has never deployed to or operated k8s - I want the most prod-ready and batteries-included cluster config, which I deploy myself on my own infra, and can then customise as and when I need to, and learn as I go.
My experience with tools like these on Kubernetes, even with something stable and widely used as e.g. certmanager, is that in the end something still breaks and you still need to get familiar with all the building blocks. In comparison if you use managed services like the AWS Certificates service you have less friction and less risk for something to break.
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.
It is a crowded space! We track over 100 related companies in the competitive set at Coherence (withcoherence.com) - where I’m a cofounder.
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!
We worked hard to resolve the most common pain points when using the cloud in production:
For developers, we are the parrot on their shoulders: with our Production Readiness Check, you have the peace of mind that you didn’t forget something mission-critical for your production deployment. For example, we ensure that you configured backups for all your services, that you didn’t open unnecessary ports, and many other best practices. The Production Readiness Check is a smart checklist that analyzes your deployment. Much better than the compliance paper pile you usually deal with.
For the business people, we worked hard to offer accountability features missing from existing PaaS and cloud providers. Cost estimations are a core piece of SetOps so that developers see how expensive their deployment is. AWS sends you a hard-to-read invoice. Imagine getting a PDF from our monthly billing feature: it automatically tracks each client’s usage and calculates the cost accordingly.
Nice project! Just a note of feedback: for a service that advertises with transparently deploying resources to my own AWS account, it is surprisingly difficult to find out to what AWS services the various concepts in setopts maps to. Given that I would be the one paying for any mishaps and overprovisioned resources, it would be good to have a reference for this. Maybe I missed it?
Thank you so much for your feedback. You are not mistaken – it looks like our documentation is currently lacking some of these details. We are going to improve on that within the next days.
I donno. I am looking for a simpler solution on top of AWS that abstracts away setting up the services with configuration but doesn't necessarily use containers for everything and def. not Kubernetes.
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 ?
It sounds like you might benefit from AWS Beanstalk which feels like a configuration widget built on top of CloudFormation - https://aws.amazon.com/elasticbeanstalk/
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."
That's exactly the idea with SetOps: using all these components under the hood but abstracting it for the user with a much simpler management. You could give it a try in the demo environment if you like.
I want to love this. I think we desperately need the "new heroku" and this touches on that.
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.
Sure, this is only the start. Internally we have a definition file; the CLI is, so to say, the fancy editor for it. We plan to open up this definition in a JSON or YAML file.
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
First of all Cloud Run only provides the workload / container part of an application. SetOps also does more like managing databases, storage, backups, monitoring, network security, etc.
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.
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.