_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
DIR Launch HN: Massdriver (YC W22) â Self-serve cloud infra without the red tape
ahmedsalah wrote 10 hours 9 min ago:
Really interesting approach to streamlining IaC. I was wondering, have
you considered a free tier or trial option (maybe limited to a few
boxes or a single environment) for early-stage teams? I'd love to play
with it and maybe migrate our infra next quarter.
dwill-mdcloud wrote 10 hours 5 min ago:
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!
xyzsparetimexyz wrote 13 hours 41 min ago:
Pet peeve but I hate it when people named something lame after
something much cooler. Same problem with Ansible, Raytracter etc. It
feels like you're compensating for how lame the product is.
aetherspawn wrote 14 hours 22 min ago:
This is cool but you need to figure out how to add a free tier, for
less than 5 boxes and 1 env or something like that. Thereâs no way we
would spend this money unless we were boiled like a frog in a pot and
just went with it because we didnât want to go back.
And $500-1000/mo is way too much, thatâs more than a 10 person
company spends every month on their entire CRM.
By pricing yourselves so high what youâre telling people is hey
weâre a startup and we don't expect to scale big, and what Iâm
thinking is hey maybe this is risky having our critical infra tied up
with this startup.
loveiswork wrote 15 hours 12 min ago:
I love all of the contextual metadata, huge potential here
bzmrgonz wrote 20 hours 32 min ago:
YOU SHOULD KNOW AVG flags the site with malvertisement, one of the api
calls I think. You might wanna do a site scan to make sure.
dwill-mdcloud wrote 20 hours 28 min ago:
Thanks for letting us know! We will look into that.
stackskipton wrote 21 hours 8 min ago:
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 ( [1] ) blog article though. It prompted a great
discussion.
URI [1]: https://www.massdriver.cloud/blogs/devops-is-bullshit
dang wrote 19 hours 20 min ago:
Discussed a couple times here:
DevOps Is Bullshit (2022) - [1] - June 2023 (278 comments)
DevOps is broken - [2] - Oct 2022 (348 comments)
URI [1]: https://news.ycombinator.com/item?id=36354049
URI [2]: https://news.ycombinator.com/item?id=33274988
dwill-mdcloud wrote 20 hours 55 min ago:
> 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.
sgarland wrote 13 hours 14 min ago:
> Developers need to have ownership and accountability for their
infrastructure without having to become absolute cloud experts.
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 wrote 12 hours 54 min ago:
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?
siliconc0w wrote 22 hours 22 min ago:
What we've developed that is similar is a meta-layer above terraform to
take high-level intent and use that to generate terraform which is then
committed to git and auto-actuated.
This is nice because it's still all using git and you can continuously
merge in updates as the 'best practice' definitions in the intent get
updated. It allows teams to maintain their own customizations and
eventually promote them to up to the intent level to capture them as a
best practice so other teams can benefit from them.
coryodaniel wrote 22 hours 5 min ago:
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:
URI [1]: https://www.massdriver.cloud/blogs/the-case-for-abstractions...
zellyn wrote 22 hours 43 min ago:
Having watched and participated in an online call (mentioned in another
comment here), there were two big things that were strikingly cool
about MassDriver:
* It turns the connections between components owned by different IaC
tools/systems into _typed_ JSON. Think patch panels, where the
connections are fully typed.
* Kelsey mentioned that you can introspect on the metadata in the live
system using absolutely anything you want, down to just bash scripts.
So it's _very_ hackable
coryodaniel wrote 22 hours 34 min ago:
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.
Aeolun wrote 15 hours 12 min ago:
Isnât that something youâd easily get out of any IaC tooling
dashboard?
Iâll admit a graph query makes it easier, but the information is
there.
dwill-mdcloud wrote 10 hours 1 min ago:
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.
jedberg wrote 23 hours 7 min ago:
Is there any way for me to submit a module or co-author one with you
guys for my cloud service?
coryodaniel wrote 22 hours 54 min ago:
Yeah, there definitely is. Ping me @ cory @ massdriver.cloud
MadsRC wrote 23 hours 10 min ago:
This is quite interesting.
What does a seat entail? You talk about self serve (I love it!), but
would the users that self-serve take up a seat? Or are seats just for
the folks creating the modules?
coryodaniel wrote 22 hours 56 min ago:
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.
varun_chopra wrote 23 hours 20 min ago:
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 or some other form
of band-aid.
* 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?
* When things go wrong, how do developers debug issues at the
infrastructure level? Do they reach out to ops?
TYPE_FASTER wrote 20 hours 34 min ago:
> 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.
dwill-mdcloud wrote 20 hours 16 min ago:
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.
coryodaniel wrote 22 hours 41 min ago:
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.
no_circuit wrote 7 hours 58 min ago:
The VR version of network management already existed [1]. It was
called CA [2] Unicenter TNG. It really could use an update with
some rendering with Unreal Engine! :D
Unrelated but could be confused with what was seen in Jurassic Park
as "Unix". [1]
URI [1]: https://archive.org/details/vw_ca-unicenter-tng-demo
URI [2]: https://en.wikipedia.org/wiki/CA_Technologies
varun_chopra wrote 21 hours 22 min ago:
> 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!
coryodaniel wrote 21 hours 20 min ago:
Thanks, I appreciated the questions!
tnolet wrote 23 hours 21 min ago:
Wanted to check your status page to get a feeling for stability. Is
your status icon in the footer hard coded, or is there an actual status
page?
coryodaniel wrote 22 hours 55 min ago:
It hits our public health check. We don't have a dedicated page for
our different systems, but this is on our radar.
ge96 wrote 23 hours 30 min ago:
damn thought it'd be a space launch platform
coryodaniel wrote 23 hours 29 min ago:
If I become a billionaire from this, that's my next startup.
written-beyond wrote 23 hours 39 min ago:
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 Startups
being able to afford a $500/mo fee. For funded ones that's highly
approachable but their problems with their IaC wouldn't be as visible.
Honestly, in smaller teams you can get pretty far with just setting
thing sup through your cloud providers web console and just focus on
what your building.
Since the fee is kind of steep, what's the justification for this. Is
it that the workflow improvements would significantly improve
productivity which would justify the cost or is the service itself
expensive to run and maintain.
coryodaniel wrote 23 hours 33 min ago:
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.
Aeolun wrote 15 hours 18 min ago:
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.
written-beyond wrote 22 hours 2 min ago:
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 recommend you guys to them because managing
deployments from over a dozen teams located around the world is
hell for them. However they have an extensive private cloud setup,
would your solution be as applicable to them as it is to companies
running on public clouds?
reachableceo wrote 21 hours 3 min ago:
If this is for the company I think it is for, they wonât use
this as they have a very strong NIH culture.
written-beyond wrote 8 hours 24 min ago:
Never heard of the phrase, "NIH culture" before. What does that
mean?
card_zero wrote 8 hours 12 min ago:
That's "not invented here". HN could really benefit from a
glossary of acronyms.
coryodaniel wrote 21 hours 50 min ago:
It is a single source of truth, but only what is managed through
the platform.
Private cloud isn't the best experience right now, its possible,
but it requires our platform being able to 'get inside' so we
either need a control plane exposed to us or a VPN connection in.
Self-hosted is our #1 requested feature, so we are cranking away
at it. Its in alpha, and we're looking for testers/feedback.
Would love an intro!
withinboredom wrote 9 hours 58 min ago:
When you get self-hosted up and running, you may also want to
consider open sourcing the private cloud portion as well. Think
of it more as a marketing thing. Many companies <5 people tend
to either go all-in on the cloud, or their own servers if
bootstrapping. For teams on the cloud, they don't need your
product, yet. For teams who are running their own private
clouds, they do. Eventually, they'll grow into the cloud and
bam, they start paying you.
It's a long game, but might be worth it.
hkwerf wrote 1 day ago:
Just an FYI: If I select "Features" / "API First" on your page, I end
up at a 404.
coryodaniel wrote 1 day ago:
Thanks, restructured the docs site recently. Updating now!
JojoFatsani wrote 1 day ago:
How much do you have to pay Hightower and Majors to show up on the
About Us page?
zellyn wrote 23 hours 41 min ago:
Kelsey is a technical advisor to MassDriver. He introduced them on
this live chat:
URI [1]: https://www.youtube.com/watch?v=LKmKxKafdS0
zellyn wrote 22 hours 50 min ago:
fwiw, the part in that demo where they add one type of object, and
it automatically added the necessary related objects due to the
inputs and outputs being typed is :chefs-kiss:
DIR <- back to front page