Launch HN: Massdriver (YC W22) – Self-serve cloud infra without the red tape

Appreciate the feedback! We actually just changed our pricing about a week ago. We used to do individual seats, but we found that smaller teams—especially those without a dedicated ops function—typically weren’t at the stage where they needed an API layer between devs and infrastructure.

For early-stage teams, a PaaS or ClickOps usually makes more sense. Massdriver really starts providing value when a team hits the point where devs need self-service, but ops still needs to enforce standards and visibility without becoming a bottleneck.

That said, we do have a free tier beyond the two-week trial for open-source projects, non-profits, and some partners. Happy to add you to it if you want to try it out—would love to be wrong about earlier-stage teams, but just haven’t seen it yet!

> Why did you decide to go with diagramming as a solution?

I had a similar idea. I have enough experience with visual programming environments to be wary. Here are my thoughts on why it might be a good approach here: * It would be possible to take a whiteboard scribble and turn it into a real system. Combining this with the services available in the cloud, you end up with something really powerful. It all comes down to the level of abstraction supported. You have to be able to draw boxes at a level that adds value, but also zoom in to parameters at the service/API level as necessary. * I've worked on a team that was responsible for designing and maintaining its own AWS infrastructure. Along with that comes the responsibility for controlling cost. The idea of having a living architectural diagram that also reported cost in near real-time is really helpful, especially if you could start to do things like project cost given a level of traffic or some other measure.

Once you have a decent library of TF modules, and an understanding of the networking and compute fundamentals, and an understanding of the services offered by your cloud provider, you have something really powerful. If a service can help accelerate that, it's worth it IMHO.

I'm here for the questions!

> * You want to simplify infrastructure, but there's a new learning curve here. Why did you decide to go with diagramming as a solution? What other methods did you evaluate and discard?

We try to make it so both teams have to learn as little as possible. For the ops team, we are built on the tools those teams are familiar with terraform, helm, ansible, etc. Our extension model is also ops-oriented. You add add'l provisioners by writing Dockerfiles, you enforce pre-validations with JSON Schema (this is the best we could come up w/, but figured it was a safe bet ops-wise since its a part of OpenAPI). For devs, they dont have to learn the ops teams tools to provision infrastructure, they just diagram. Massdriver was originally a wall of YAML to connect all the pieces, but it felt fumbly (and like everything else).

I wanted to make a VR version like something youd see in a bad hacker movie, but Dave told me not to get ahead of myself. :D

> * How does an organization with existing infrastructure implement Massdriver?

Depends on if they have IaC or not. If they have IaC, they publish the modules. If their IaC has a state backend, its usually just good to go, if they are using localfiles for state, we offer a state server they can push state into.

If teams dont have IaC, we run workshops on "reverse terraforming" or "tofuing" and also offer professional services to codify that stuff for you.

> * How do you handle edge cases, custom configurations, complex logic, etc.? For example, workflows that use custom scripts or some other form of band-aid.

As noted above, its all based off common ops tooling. Lets say you wanted to use a new sec scanning tool for IaC and we don't have it in our base provisioners, you can write a dockerfile, build the image, then you can include that scanning tool in any of your massdriver configs. We also have folks doing day-2 operations with the platform. Things like database migrations and whatnot. The lines in the graph actually carry information and can push that info across different tools, so you can do things like have helm charts get information from a terraform run. You can build a provisioner with say the psql tool or a helm chart running bucardo and use it to set up replication between an old and new postgres instance.

> * The visual approach could make it too easy to piece together infrastructure without understanding the implications. How do you prevent developers from creating poorly architected systems just because you make it simple to connect components?

The lines and connections are actually a type system that you can extend (also based on JSON Schema). That way ops teams can encode common things into the platform once. ie. this is how we authenticate to postgres, its an AWS secret, security gruops and these IAM policies. All of that information flows across the line into the other module. The modules reject invalid types so common misconfigurations _cant_ happen. It also lets you "autocomplete" infrastructure. Lets say I'm a dev and I want to deploy a database. I can drop it on the canvas, since massdriver understands the types, it'll automatically connect it to a subnet that dev has access to.

> * When things go wrong, how do developers debug issues at the infrastructure level? Do they reach out to ops?

They may, we have a lot of stuff built in though to make the system as truly self-service (through day 2) as possible. There are runbooks per module so ops teams that have built out a module around a use case can put in common trouble shooting steps and its all accessible from the same graph. Alarms and metrics also show up there. Ops teams can also publish day-2 modules to the catalog, so developers can drag and drop common one-off tasks for maintenance onto their canvas and perform it.

Thanks! And ... you're right!

Massdriver isn’t aimed at pre-funded startups. Early-stage teams are often better off with a PaaS or setting things up manually until ops challenges become a bottleneck.

Our pricing (5-seat minimum) is intentional to dissuade smaller teams. The real value kicks in when teams need self-service. Ops teams build the modules (not us), and Massdriver acts as the interface. Developers diagram what they need, and Massdriver provisions using the ops team’s standards. This keeps developers focused on building while giving ops visibility and control over what’s deployed.

> 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.

Discussed a couple times here:

DevOps Is Bullshit (2022) - https://news.ycombinator.com/item?id=36354049 - June 2023 (278 comments)

DevOps is broken - https://news.ycombinator.com/item?id=33274988 - Oct 2022 (348 comments)

Seats are for any user of the UI and they aren't bound to a person, so you can reassign them as necessary.

For larger teams we do buckets of seats with price reductions per-seat as the team size goes up.

We don't rate limit deploys - as that would make you less agile, we don't charge based on resources because that penalizes teams with stable infrastructure.

We know ops budgets can be tight, we're ops engineers, so we try our best to make the pricing work well for those budgets.

Hey! How's it been? I followed you on bsky a few days ago!

Glad you liked it! Yeah, the typed connections are a big part of what makes Massdriver powerful. It makes sure infrastructure components integrate right without devs having to worry about all the low-level details.

We're expanding the graph metadata with a querying system coming out of alpha soon that lets you ask stuff like "Where are all my t3 instances in production?" or "Which services are using a kubernetes version less than 1.25" Makes it way easier to understand what’s running where.

And since it’s all API-first, it’s easy to write quick scripts for reporting or automating changes across environments.

I love the idea of high-level intents and abstractions. They’re tough to get right, but when they click, they make dev teams move way faster.

Cloud APIs mix operational and developer concerns, which is part of the problem. A single API call for something like a database forces you to think about instance types, failover strategies, and security settings when all a developer really cares about is, "I need a database that can handle X traffic and supports Y extensions."

I’m actually working on a write-up about abstractions for a CNCF infra white paper and would love to get your thoughts. A lot of teams struggle with the balance between standardization and flexibility, and it sounds like you’ve thought a lot about this too. Let me know if you’d be up for a chat.

Also, here’s a post I wrote about it recently:

https://www.massdriver.cloud/blogs/the-case-for-abstractions...

It hits our public health check. We don't have a dedicated page for our different systems, but this is on our radar.

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!

Yeah, there definitely is. Ping me @ cory @ massdriver.cloud

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.

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

If I become a billionaire from this, that's my next startup.

Thanks, restructured the docs site recently. Updating now!

Kelsey is a technical advisor to MassDriver. He introduced them on this live chat: https://www.youtube.com/watch?v=LKmKxKafdS0