Founder Stories: Kate Heddleston of Opsolutely (YC S16) | Hacker News Reader

Founder Stories: Kate Heddleston of Opsolutely (YC S16)

blog.ycombinator.com

86 pointscraigcannon14 comments

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

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

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

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.

I'd counter that it isn't about the magic button but about the right visual interface for making decisions. Interfaces, whether it's a piece of Java code or a web GUI or something, are very hard to get right. But when you have the perfect interface for something things just flow.

IMO the problem with CLIs is that they are so explicit with their feedback you have to know exactly what the command does and can rarely intuitively predict what the right next command should be. And what if your CLI has to be used by a second language english speaker? git rebase –onto <basecommit> HEAD~1 HEAD? Eventually it digresses to long lists of magic black box commands to get your OPs running. Cough every Kubernetes demo ever.

Theres a million dollars for the first anthropologist with a deep understanding of human nature to apply their trade to devops. It's not a magic button. It's not a CLI with a -h that reads like a text book. It's something we haven't thought of yet because we're so buried in our own world and established ways of doing things.

Git is actually a great example - if you just memorize a few magic git commands you really aren't using the tool correctly and can end up in state that is unrecoverable (at least to you, the magician). Better to spend an afternoon understanding how git works (again, mostly) and be equipped to survive such circumstances.

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.

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.

I'm fairly certain the "understanding the stack" argument has been sufficiently addressed by Carl Sagan: 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.

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.

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.

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 [1]: http://now.sh

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

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.

Reply on news.ycombinator.com