
Founder Stories: Kate Heddleston of Opsolutely (YC S16) - craigcannon
https://blog.ycombinator.com/founder-stories-kate-heddleston/
======
venantius
(context: I used to be a senior engineer on Airbnb's deployment infrastructure
and have also met Kate in person)

I think Kate and the rest of the team at Opsolutely are building the right
product to solve this problem - she's extremely well informed about where the
technological landscape is currently and is building something that represents
best practices (in particular, being able to configure and ship Docker
containers directly onto a hosted k8s infrastructure).

The real challenge here is that the market is bifurcated - on the one hand,
products like Heroku or AWS' Elastic Beanstalk mean that smaller firms don't
really need to do too much work to get a simple deployment set up, whereas on
the other end (e.g. Airbnb) deployment becomes so specialized that there's
basically no way for a third-party firm to address the peculiar needs that
have emerged. I suspect that Opsolutely (and other firms in this deployment-
as-a-service) space are going to need to figure out how they cut into this
market as early in their client's infrastructure build-out as possible.

~~~
morgante
> The real challenge here is that the market is bifurcated

This is spot on and has been one of the biggest challenges in building my
startup. [0]

The way I've been approaching it has been to build less of a platform so much
as an engineer-as-a-service. Our primary output is code and pull requests, so
it works into existing automation. I'm really curious to see how Opsolutely is
tackling this though.

[0] [http://getgandalf.com/](http://getgandalf.com/)

------
kt9
IMHO the most important thing for opsolutely to figure out is whether they're
focusing on the Enterprise or the SMB space. The reason is that will dictate
the direction of their product and the features, integrations and customer
experience.

The requirements for enterprise are _very_ different from the requirements for
small companies.

I say this from experience running a deployment automation company focused
primarily on the enterprise
([https://www.distelli.com](https://www.distelli.com)) and we made a decision
early on to focus on the enterprise. Making a decision early on helped us
focus on the target market we're going after and we have actively built stuff
for the enterprise because of that decision.

------
siliconc0w
Not a fan of the 'one button deploy'. People treat this as a UX problem when
it really isn't. By creating magical buttons you're just abstracting a lot of
hidden complication, not removing it. The functionality of an application is
governed by an often complex interaction of code, configuration, and various
types of persisted and ephemeral state that needs to be understood by the
operator.

Often the best UX for controlling this complexity is a CLI tool. The CLI is
not your enemy.

~~~
iEchoic
I agree that deployment isn't a UX problem, but I think having a one-button
(or one-command) deployment process is a goal that leads to more reliable and
safer deployments.

The vast majority of consumer applications can (and should) be able to deploy
in one command. There's complexity behind deployments, but it's complexity
that's almost always best handled by automation.

~~~
siliconc0w
Automating complexity doesn't remove it, it just hides it and adds some
overhead (code that needs to be tested, debugged, and maintained). The
operator of the tool should be power users who (mostly) understand what the
tool is doing behind the scenes. Magic buttons encourage people to 'trust the
tool' when you really shouldn't. Tools are stupid.

Just trying to pop some of the mythology surrounding this stuff. Automation is
not a cure-all. You should definitely do it, because operating by hand isn't
at all better, but you should probably still know what you're doing and 'magic
buttons' can discourage this.

~~~
groby_b
I'm fairly certain the "understanding the stack" argument has been
sufficiently addressed by Carl Sagan:
[https://www.youtube.com/watch?v=7s664NsLeFM](https://www.youtube.com/watch?v=7s664NsLeFM)

We're building abstractions so people can build on top of it. And yes, that
includes trusting your tool. When's the last time you ran JTAG debugging on
your CPU? Did you use a scope to verify it worked correctly?

You should probably have a somewhat decent understanding of the layers close
to what you building, but there are plenty of applications where deployment is
far removed from what you actually build. That's where the "magic button"
matters.

~~~
siliconc0w
In the Apple Pie scenario, you'll find most apple pie enthusiasts can go down
the stack a few layers. They'll talk about important aspects of the right
flour, the apples, etc.

In the specific case of opsolutely you're in a tight spot because there are
several better abstraction options available than your closed source invite
only tool. Kube and Mesos both offer better support and tooling and both have
several options for an extensible and automated software deployment lifecycle.

------
wallflower
I loved this weird dream. Reminds me of a sequence from Inside Out where the
characters turn into 2D or 1D.

> CS 107 is systems programming and I had a nightmare during that class,
> during finals week. I had a dream that I was a struct, which is this really
> simplistic object. I had a dream that I was a struct and I hadn’t properly
> cleaned up my memory. I was out of memory and had a segfault and my brain
> was full and I wouldn’t be able to learn anything else for the week of
> finals. It was a terrible nightmare.

------
mxstbr
I'm very excited about the work Zeit[0] is doing in the deployments space.
Their flagship product, now[1], does deployments with a single command. What's
even cooler is that each deployment is immutable and gets a unique URL that
you can then alias to your canonical URL after testing.

They haven't been around for long, so some important features (teams) are
still missing, but all of the things they put out are of the highest quality
so I'm expecting a lot of great things in the future!

(note: not affiliated with them other than being a huge fan and happy
customer)

[0]: [https://zeit.co](https://zeit.co) [1]: [http://now.sh](http://now.sh)

------
makmanalp
Also check out her excellent talk (and blog posts!) on engineering
environments and practices, and how they affect diversity. It was an eye
opening talk for me at the time because it made me pay attention to practices
I knew were broken, but didn't really understand the scale of the effects of.

[https://www.youtube.com/watch?v=kNke_4WOWAU](https://www.youtube.com/watch?v=kNke_4WOWAU)

------
jansho
Offtopic but I just want to say that I'm really happy to see that YC is
becoming more gender-balanced. I've been following the videos on startup
school and in the last office hour session, there was at least one female
cofounder per team.

