[HN Gopher] Show HN: SetOps - Run containers, databases and more...
___________________________________________________________________
Show HN: SetOps - Run containers, databases and more in your own
AWS account
Author : latebird22
Score : 31 points
Date : 2022-06-07 14:19 UTC (8 hours ago)
(HTM) web link (www.setops.co)
(TXT) w3m dump (www.setops.co)
| oakct wrote:
| 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?
| latebird22 wrote:
| 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 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
| melony wrote:
| Crowded space! Flightcontroller, qovery, Architect. Competition
| is stiff, I am interested to see where your product is heading.
| tobi_tobsen wrote:
| 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.
| superb-owl wrote:
| > 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.
| lukeramsden wrote:
| 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.
| _whiteCaps_ wrote:
| Have you seen https://github.com/cloudfoundry/cf-for-k8s?
| latebird22 wrote:
| 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.
| latebird22 wrote:
| 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.
| superb-owl wrote:
| Here's a few examples of policies/needs that I've seen
| companies run up against at scale. K8s does a great job
| solving them.
|
| * 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 :)
| latebird22 wrote:
| 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.
| codegeek wrote:
| 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 ?
| latebird22 wrote:
| 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.
___________________________________________________________________
(page generated 2022-06-07 23:01 UTC)