dwill-mdcloud

I appreciate the feedback! We will continue to consider that.

We had a free tier for years, but we saw over and over that the organizations that gained value with Massdriver had skin in the game. They wanted to focus Ops culture around our self-service model and paying kept them focused on adoption.

We want to accommodate everyone who wants to manage Ops better and will continue to figure out how we can best do that Whether that is OSS, education or a better free tier.

What can I say, we are dreamers who have suffered as both Ops and Dev.

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!

That's a fair assessment of the problem. I appreciate the thought you put into it. I think compiling all of those experts will be difficult for companies until they are fairly large. We hope to push out requiring that expertise for as long as possible. But in an ideal world, I don't disagree with you.

There are probably some dashboards that can give you that information easily. Where having the graph is interesting is scripting something that can test changes to a widely used module. With all of your config behind an API you could pull the live config of every instance of that module, run your change against it, and then trigger a deployment of each one of the modules in isolation with the new code. The least interesting part of the API is search.

We have a 2-week free trial. That can be extended for you if you need a longer POC period. We also have some deals for early-stage companies we can talk through. Book a demo with us and let's talk through your use case!

I am unsure what you are getting at. Our platform is all about Ops and Dev being separate jobs, but operating at a greater scale. Ops produce modules that can be consumed by Developers. Developers control the scale of their infra while Ops encodes security and compliance in the module. It seems like this would be the ideal model in this instance. If it is not, what does the ideal look like in your opinion?

You have really hit the nail on the head with what we were going for! Cory and I, very early on said "We draw this stuff, agree on it, then go build it in TF which is where the problems start".

We imagined a world where you could go into architecture review and come out of that meeting with staging stood up and ready to run your application.

This makes sense for infra because it's mostly config management and API calls. Visual programming is rough because control structures are soo hard to visualize.

Thanks for letting us know! We will look into that.

I wouldn't say Ops wants control, it's we want to stop being paged after hours because Devs yolo stuff into production without a care in the world. Not sure tooling will fix that.

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.

Being great at DevOps means lots of Production experience. The level of experience required to go from thinking about working software (code) to running software (Production) is immense. That's why it is so hard to level up DevOps talent in the current dichotomy. In a silo DevOps engineers won't run enough software to understand their customers (the engineers in your org).

Thanks for this Dave! It's so hard to find great information about observability outside of what is built in to APMs.