_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
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
DrBenCarson wrote 21 hours 43 min ago:
Before taking some of these comments in earnest, remember that the hn
readership has a bias
But I do think you need to have a better free tier or consider going
open source if you want to pick up momentum
dwill-mdcloud wrote 20 hours 35 min ago:
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.
DrBenCarson wrote 9 hours 41 min ago:
Right on. I just donât have a way to fiddle with it. Iâm an
engineer at heart but sometimes involved in procurement
decisionsâif I canât poke around self-serve, Iâm not likely
to pay
IMO your free tier doesnât need to support organizations, just
individual hobbyists
ahmedsalah wrote 1 day 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 1 day 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 1 day 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 1 day 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 1 day ago:
I love all of the contextual metadata, huge potential here
bzmrgonz wrote 2 days 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 2 days ago:
Thanks for letting us know! We will look into that.
stackskipton wrote 2 days 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 2 days 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 2 days 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.
otterley wrote 21 hours 2 min ago:
> 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.
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 wrote 20 hours 40 min ago:
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!
sgarland wrote 1 day 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 1 day 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?
sgarland wrote 1 day ago:
Just as choosing the correct algorithm, the best library, or
the optimal design pattern for a given task is complex and
important, so is choosing, configuring, and managing infra.
The hyperscalers have convinced people that you donât need to
know how to run a database, you can just use RDS et al. You
donât need to know how to manage K8s, you can just use EKS.
This is dangerously untrue, because those tools are good enough
that most people can get them going and theyâll work
reasonably well, right up until they donât (especially
RDBMS). Then you hit edge cases that require you to have a
solid understanding of their architecture, as well as Linux
administration â for example, understanding how Postgresâ
bgwriter operates, and how it is affected by disk IOPS and
latency, not to mention various kernel-level tunings. None of
this matters in the slightest with small DBs, say, < 100 GiB.
It may not even matter at larger scales depending on your query
patterns.
The various DB offerings (Iâm going heavily on the DB example
because thatâs my current job) like Neon and Planetscale
mostly have the right idea, IMO â stop assuming devs know or
want to do ops work. They want an endpoint, and they want
things to be performant, so have automatic schema and index
reviews. Critically, in this model, devs are not responsible
for nor accountable for the infraâs performance (more or
less; discussions on schema design and its impact on DB
performance aside). In other words, this has separated ops and
dev.
I say theyâve mostly got it right because they do still allow
you to make bad decisions, like chucking everything into a
JSONB column, using UUIDv4 as a PK, etc. Realistically a
service would fail if they tried refusing to allow that
flexibility, so I get it.
For an in-house solution, though, this can be the case. The old
school, rigid mentality of having to ask cranky graybeards to
add a column had an extremely powerful benefit: bad decisions
were much less likely to occur. Yes, itâs slower, and
thatâs a good thing. Everywhere Iâve been, bad decisions
made in the name of velocity have come calling, and itâs a
nightmare to fix them.
In summary, I like the idea of Massdriver quite a bit,
actually; I just donât think itâs a good idea nor accurate
to say that it allows devs to be responsible for their own
infra, because they largely donât want that, nor are they
capable. Not for lack of intelligence, but lack of experience.
Let specialists be specialists. You want a DB? Ask the DB team,
and donât get mad when they tell you your proposed schema is
hot garbage. You want more compute? Ask the infra team, and
donât be surprised when they ask you if youâve profiled
your code to determine if you actually need more.
dwill-mdcloud wrote 20 hours 49 min ago:
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.
siliconc0w wrote 2 days 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 2 days 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 2 days 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 2 days 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 1 day 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 1 day 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 2 days ago:
Is there any way for me to submit a module or co-author one with you
guys for my cloud service?
coryodaniel wrote 2 days ago:
Yeah, there definitely is. Ping me @ cory @ massdriver.cloud
MadsRC wrote 2 days 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 2 days 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 2 days 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 2 days 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 2 days 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 2 days 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 1 day 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 2 days 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 2 days ago:
Thanks, I appreciated the questions!
tnolet wrote 2 days 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 2 days 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 2 days ago:
damn thought it'd be a space launch platform
coryodaniel wrote 2 days ago:
If I become a billionaire from this, that's my next startup.
written-beyond wrote 2 days 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 2 days 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 1 day 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 2 days 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 2 days 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 1 day ago:
Never heard of the phrase, "NIH culture" before. What does that
mean?
card_zero wrote 1 day ago:
That's "not invented here". HN could really benefit from a
glossary of acronyms.
coryodaniel wrote 2 days 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 1 day 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 2 days ago:
Just an FYI: If I select "Features" / "API First" on your page, I end
up at a 404.
coryodaniel wrote 2 days ago:
Thanks, restructured the docs site recently. Updating now!
JojoFatsani wrote 2 days ago:
How much do you have to pay Hightower and Majors to show up on the
About Us page?
zellyn wrote 2 days 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 2 days 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