(no title)
dwill-mdcloud | 1 year ago
You have hit the nail on the head here. Our base hypothesis is the only way to solve this problem is to start with a self-service approach. If I deploy an RDS instance and nobody ever connects to it, it will never have an issue. The moment a Dev starts firing N+1's at it, I have to get up at 1am. Developers need to have ownership and accountability for their infrastructure without having to become absolute cloud experts.
Our goal is to enable Ops teams to build catalogs of solid building blocks that developers can build into novel architectures and safely own and operate. The collaboration between Ops and Dev is delegated to software and eases this friction.
> It looks like a functional platform and another "Cloud defaults are too scary? Here is a sane default option."
I would push back on this notion. An Ops team builds reusable modules that match their reliability and compliance requirements. You _can_ use modules we have created but we expect that you own your IaC modules. They will conform and evolve with your organization's best practices.
The DevOps is bullshit article is the inspiration for making a platform that manages the relationship between Dev and Ops which I think separates us from our competitors in the space.
otterley|1 year ago
What you’re describing is the Holy Grail of being able to simplify a complex system without sacrificing functionality, security, performance, cost optimization, observability, etc. This dream has been around a very long time. People keep attempting to solve the problem (because, well, there is potentially money in it) and they’ve all failed in the long run (although some vendors got wealthy until the customers saw the light). cfengine yielded to Chef/Puppet/Ansible; Terraform is a mess; VMWare is the walking dead; and K8S will probably see a similar fate once people burn out on it.
The problem is the age-old one of leaky abstractions and jammed-up controls. Sure, an abstracted database component might be adequate for a simple workload, but as soon as the component reaches the limits of the abstraction, you’re stuck. You can’t get your hands dirty and solve the problem. And if you can, you might as well throw the abstraction out and configure the component natively.
On top of that, you cannot effectively abstract the observability of complex workload components. These are often highly specialized pieces of software for which the metrics are not only different, but the values of which have different meanings.
Anyway, if you figure out how to crack this nut, I applaud you. But it’s been tried before, many ways. I’m not optimistic.
dwill-mdcloud|1 year ago
I think the way we approach abstraction is fairly different from other Ops tools on the market. We are product engineers first. We are trying to pull in a lot of what makes product engineering work to the ops side. Our guidance on abstraction is very usecase driven. Instead of having an S3 module, you have a public website bucket, a landing zone bucket, and a CDN bucket. This prevents the module from outgrowing its usefulness.
If it is possible to crack this nut, we will need people like you to give us the guidance to do it. We should jump on a call, no sales. I can walk you through the platform and you can tell us why we are crazy for trying!
sgarland|1 year ago
This will never happen. You can’t own something you don’t understand.
Ops and Dev are different roles for a reason, and the only reason we’ve shifted away from that is to accelerate profits; yes, you can spend your way to growth, and yes, you can run massively complex systems on hardware you have never seen, nor understand. That doesn’t make it a good idea.
dwill-mdcloud|1 year ago