Live data from Hacker News

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

news.ycombinator.com

31–40 of 61 posts

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

#31

Earlier quoted context omitted.

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

> You add add'l provisioners by writing Dockerfiles, you enforce pre-validations with JSON Schema That's really neat! Thank you for answering my questions and all the best with your launch!

Thanks, I appreciated the questions!

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

#32
As SRE/DevOps/Ops type, I took a look because I've sat with salespeople with your competitors. It looks like a functional platform and another "Cloud defaults are too scary? Here is a sane default option."

>The hard part isn’t just technical, it’s socio-technical. Ops teams want control, devs want speed, and compliance creates friction between them.

You got that right and I'm not sure another tool is going to fix it.

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.

I love your (https://www.massdriver.cloud/blogs/devops-is-bullshit) blog article though. It prompted a great discussion.

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

#33

Earlier quoted context omitted.

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…

So does mass driver become a single source of truth for all information about my companies entire cloud or does it only maintain a track of what's been deployed through it. I have a friend whos a manager at a large e-commerce company who's teams entire responsibility is to oversee all matters regarding their private and public cloud usage. They also manage and maintain services for internal use. I would love to recom…

If this is for the company I think it is for, they won’t use this as they have a very strong NIH culture.

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

#34

As SRE/DevOps/Ops type, I took a look because I've sat with salespeople with your competitors. It looks like a functional platform and another "Cloud defaults are too scary? Here is a sane default option." >The hard part isn’t just technical, it’s socio-technical. Ops teams want control, devs want speed, and compliance creates friction between them. You got that right and I'm not sure another tool is going to fix it.…

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

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

#35

Oh boy, I have so many 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? * How does an organization with existing infrastructure implement Massdriver? * How do you handle edge cases, custom configurations, complex logic, etc.? For example, workflows that use custom scripts…

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

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

#38

Oh boy, I have so many 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? * How does an organization with existing infrastructure implement Massdriver? * How do you handle edge cases, custom configurations, complex logic, etc.? For example, workflows that use custom scripts…

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

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.

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

#39

As SRE/DevOps/Ops type, I took a look because I've sat with salespeople with your competitors. It looks like a functional platform and another "Cloud defaults are too scary? Here is a sane default option." >The hard part isn’t just technical, it’s socio-technical. Ops teams want control, devs want speed, and compliance creates friction between them. You got that right and I'm not sure another tool is going to fix it.…

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)

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

#40

Congrats on the launch! I'm not a seasoned DevOps professional but I'm usually the one who ends up provisioning or setting up VMs, serverless stuff and DBs. I just don't understand the product. You make reusable TF modules that have security and policies baked in. Engineers use a UI to hookup those modules and Massdriver does the deployment work for you. Sounds like a godsend for big teams but I don't see pre-funded…

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…

How do you intend to get any adoption with pricing like that? I’m certainly not going to drop several hundred dollars to see if your product is better than any of the freely available IaC tools.

Not trying to critizice, just don’t understand how this works. I’ve got my company to pay for Pulumi after several years of usage, but I needed to be able to use it to get that far.

Post reply on HN