tobi_tobsen

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

That's a good question!

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.

I think you could anticipate my answer as a co-founder of SetOps :D

Haha, that's true!

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.

Hey HN! I’m Tobi, Co-Founder of SetOps.

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.

Checkout https://www.setops.co/, it's like Heroku for your own AWS Account

AWS makes our life easier in many ways. But, as it often happens, in an attempt to address all possible needs, it ended up with just too many features to keep an eye on. Newbies or small teams that cannot have a dedicated AWS admin, may get lost or spend too much time managing and configuring it. Here are tips for setting up an AWS account from scratch.

An AWS Application Load Balancer (ALB) can host up to 100 applications with 25 different TLS certificates. However, if you wanted to share this ALB, you'd need to watch how many apps you assign to it. If you tried to use it across Terraform projects, you'd need to expose its ID. At best, it's additional work. More often, this is too much work. Thus, it's more economical for most cloud engineers to create dedicated resources and let the client pay the bill.

Our way is AWS-native and allows for maximum efficient sharing – without complicating it for the user. When you can share a single ALB between 25 to 100 apps, the large cost saving comes in.