PlanetScale CEO on Cloud-Prem and Climbing the Engineering Ladder

Sam Lambert is CEO of PlanetScale, a MySQL-compatible serverless database provider. Before PlanetScale, where he served as chief product officer, he was VP of engineering at GitHub.

In this interview, Lambert talks through several subjects tied to cloud native software delivery models, such as what good serverless looks like, who ought to operate Kubernetes, and the rise of “cloud-prem” — a deployment model that blends the advantages of on-prem software and SaaS products. He also discusses what it was like to become a non-founder CEO, plus his guidance on when and how to transition from engineering into management.

---

What is cloud-prem?

You’ve described what PlanetScale is doing — at least its not pure-SaaS offering — as “cloud-prem” computing. How would you explain that phrase?

SAM LAMBERT: Cloud-prem is a newer model — basically the cloud native answer to on-prem. In the past, companies have generally had to choose either an on-prem solution or a cloud solution, and trying to support both has usually been extremely hard. At GitHub, we faced that same tension between running github.com and also selling GitHub Enterprise as an on-prem product. With the cloud product, we needed to push and ship continuously. Making releases around that was a really hard problem, and creating architectures for both meant we were not serving the on-prem product as well as we might have; it was simply very tough to execute.

When we joined PlanetScale, we chose to be cloud-only, but of course you can’t simply do that with a database product or with software that has strict compliance needs. So with cloud-prem, we basically place the data plane of our product into a VPC controlled by the user, while they rely on our control plane to coordinate it and we operate it. It effectively feels like you are just working with a normal cloud SaaS product, but the data stays in your account. Your security team can inspect it, and they have the confidence and trust of keeping it inside their infrastructure, without the drawbacks of having to patch, release, and run on-prem software themselves.

There is another benefit too: if you are a large customer with a strong negotiated price with Amazon, for instance, you still pay that rate and preserve your committed Amazon spend inside your account.

What sort of resistance do you see? There are some hardline SaaS and on-prem organizations out there …

We can offer you pure SaaS, where we keep the data in our account, and people are totally happy with that. The real objection comes when people only want on-prem. But the cloud-prem model is really beginning to land. We have regulated companies using the product because they see the twin advantage of keeping data local so security or compliance is satisfied, while also avoiding the burden of managing it.

That is why this model is so unusually compelling and such a moment in time: Because it sidesteps the issue of companies not wanting to do on-prem — and of it being an old, dead model, basically — while still largely satisfying the requirements that on-prem would.

Still, yes, you do face resistance at times. Some companies simply will not trust SaaS software, but the cloud is rapidly eroding that. Like, you don’t get to choose when or how Amazon updates S3 and improves S3; it just happens. It is all about earning trust from many customers that you are the right company to handle a specific job for them, and helping them become more comfortable with that.

Developers can be quite strong-minded about the databases they choose. How does the cloud-prem deployment model affect developer experience?

It is more that the deployment model removes the blockers. You can’t create the best developer experience when you’re shipping on-prem software. You can’t keep improving continuously. You can’t manage quality, availability, uptime — all of those things are part of the experience. If you are not managing the service yourself, it is very difficult to deliver such a high level of experience.

A major blocker for SaaS-only, naturally, is that some users need to keep data under their own control. A major blocker for on-prem may be scalability. So the cloud-prem model is more of a way to remove those blockers and offer everyone the best of both worlds.

Who should run Kubernetes?

What role does Kubernetes play in your deployment model? And what do you believe Kubernetes should generally do for something like a cloud-prem deployment?

Kubernetes lets us deploy into customer environments in a highly standardized way, and it appears the same as the Kubernetes cluster we operate internally. Architecturally, we are also built on Vitess, which runs on Kubernetes and was created on Borg, the predecessor to Kubernetes at Google. So, by design, it is very self-healing. If you lose pods or lose infrastructure, it heals itself pretty much; failovers are not something you need to handle manually.

In our model, users do not have to run the Kubernetes clusters that we deploy. We do not use the model of deploying onto an existing Kubernetes cluster, which some on-prem vendors do as a way to try to make it easier. I am skeptical that it is any easier, honestly.

Most people do not need to run Kubernetes. It is a strong backend for infrastructure providers, but I do not think it is necessarily the best deployment mechanism for most companies. I think many people have gone down that path and found little or no value in doing it.

Is there a scale at which it starts to make sense, in your view? Or a specific use case, like running an internal platform team?

If you are doing what we do, where you want to simplify infrastructure and have something that is flexible like Kubernetes, then it is great. But that level of flexibility is so open-ended that if you are simply building, say, an ecommerce company that wants to host a website, you do not need Kubernetes in the backend to do that.

It is very broadly adopted, and I think many people try to build these internal platforms and view Kubernetes as a way to have simple internal infrastructure. That is just not the case; it does not go far enough with the end-user experience. People should use the cloud for what it does best, and let the clouds and people like us run Kubernetes as a way to simplify what we do.

But surely there’s some threshold where an organization is large enough to make running something like Kubernetes in-house worthwhile, right? Like what you were doing at GitHub?

If you have a lot of hosts to look after — and we’re talking about thousands of machines, which is not many companies — and you want infrastructure that is a bit more self-healing or can take advantage of a huge fleet of machines, that gives you the flexibility to deal with these things.

I think the question every company should ask, regardless of the technical decision, is: Does this set us apart for our customers? Is there an end-user story or requirement that improves because we run and operate this infrastructure ourselves? And if the answer is no, then you shouldn’t do it with any technology at all.

Basically, almost nobody can now make a case for hosting their own Git. It’s just absurd not to spend the ridiculously small amount of money to let GitHub or GitLab handle it for you. That debate is over; there’s no advantage to doing it yourself. As serverless and technology in general improve, that boundary keeps shifting for everyone. You’re just not going to build an internal database team or ops team that is better than service providers like us.

And even if you could, how would the users know? What would it change for your user base? Very little — 99.9 percent of the time, they do not care about your stack. Every company should mostly just do the things that affect the needle for its own users and use as much managed infrastructure as it possibly can.

Security, serverless, and AWS

How do you think security and data privacy concerns are changing, especially for SaaS providers?

Everyone cares about security. It’s something we have to treat extremely seriously as a company that stores people’s data. One pattern I’ve noticed is that companies are seeking their compliance certifications much earlier than they used to. Now you basically have to get SOC 2 certification almost right away, or you’re not going to be able to compete. (If you want a good piece of reading, Fly.io wrote a blog post on SOC 2 that’s worth checking out.)

And more broadly, companies are very enthusiastic about certain capabilities that are now table stakes, like single sign-on authentication, audit logs, and proper revocable access tokens.

For example, if you accidentally commit your database credentials to a public GitHub repository, we revoke them immediately so people can’t access your database. That’s the sort of thing that used to happen — people would push their AWS credentials into an open source repository and then their account would suddenly be used for Bitcoin mining and they’d rack up tens of thousands of dollars in charges, or their data would be out on the internet

My hot take, ultimately, is that security is a user experience issue and it’s very foundational. It’s hard to be secure if you make it hard for your users to do the right thing. If you make security non-default, and something people have to remember and configure, they’re more likely to make mistakes. So, for instance, you cannot connect to PlanetScale in a non-encrypted way — you can’t. People want that because they want to be lazy or because they want to do things in particular ways. We simply don’t allow it. The outcome is that nobody can screw up and send their data in plain text over the internet. That, again, is part of user experience.

You mentioned serverless earlier. What’s your working definition of serverless?

The way I explain it is that good serverless products should only expose what you absolutely need to control in order to get things done. If you uploaded a file to Dropbox and they asked you, “How many servers would you like us to keep this on so that it stays highly available?” You’d be like, “Isn’t that what I’m paying you for?” Is that the promise of the cloud? The cloud should be a lot more than just adding vCPUs and memory, but in the cloud.

Serverless asks, “What is the unit of value for the user? What does the user want to do?” And it doesn’t make them do anything beyond that. So, for me, it’s an optimistic movement that heads toward simplicity and better product design.

How would you describe the relationship between your company and cloud providers right now? Is “frenemies” an accurate description?

It’s interesting, because we compete in some ways, but we also drive a lot more usage to their platform. For customers running our managed, cloud-prem version, we work with Amazon reps so that people don’t leave for Google; they stay on Amazon and they use our software. So the reps still get a ton of consumption, we get our share of that whole deal, and it’s great. I think they’re slowly going to move backward and let companies like us be the end-user experience. And ultimately they’re still winning, because they are still selling servers at larger and larger volumes.

But we’re in this interesting middle stage, where they’re not just big box retailers. They still do compete with us on certain products, but it’s getting much harder because, now, for every one of their services — and there are hundreds on Amazon — there are five hot young startups competing against it. And it’s going to get very tough to care about that many users and use cases and keep it scaling.

Moving from IC to management

Unrelatedly: You weren’t the CEO of PlanetScale at first. How did your move from CPO to CEO happen?

When I joined, the company was doing things a little differently. We were doing hosted Vitess, which was the old product we had. I decided I wanted to build an amazing database product with Vitess at its core, where Vitess was the underlying engine, but not the final product. So we basically threw away the old product and built this new one, and it became very successful. And then I hired a lot of people from my previous company, GitHub, and people I knew well.

At that point, a lot of the company and the culture were people who had come to work with me — to work together again — so a double shift in the culture and the product came in through what I wanted to do. The last logical step was to align everything under that vision. That’s why I became the CEO.

It was a straightforward handoff that got done very, very fast. I mean, our founders are excellent. They launched the company, they built it, and then they passed it on, like many founders do. Some companies should have made that change much earlier, really.

You moved up at GitHub pretty fast too, from DBA to VP of engineering. What’s your guidance for making those kinds of shifts well, and for deciding whether moving into management is actually the right choice for you personally?

First, if you’re at a company where you only get influence by becoming a manager, you’re at the wrong company. A lot of people leave an individual contributor role and become a manager just to stay in the room, and that’s awful for themselves and it rarely helps anyone there.

My advice is to become a manager if you deeply care about people and about the results that great people can produce. You can go too far the other way, where you are only a people manager and do not care about the work. I think, in the end, you want to see great things get built, and you do that through a culture and by empowering people. So if those are the things you care about and can create, become a manager.

I really cared about those things. I came to GitHub as an engineer, and I had an impact there and loved it. And I knew that to scale, and for us to keep doing great engineering, we needed strong management. I wanted to build a high-performing culture with great engineers. So I started doing that, and we made a lot of changes. The company grew, but I kept working very steadily with people I knew were doing good things, and from there I just kept growing up.

You always get asked to do more. If you’re the kind of manager who is not always trying to climb the ladder — but instead simply does what you said you would do, stays collegial while doing it, helps people win, and pushes people forward — you naturally get invited into bigger rooms. That happened over time. And then eventually, yes, I was leading a large team there as a VP because I always did exactly what the business needed, stayed with it, worked hard, and empowered people.

And the thing I’m most proud of is how many people came from GitHub to PlanetScale because they knew that. You know what I mean? They didn’t have to. To me, that was a sign that I had shown I could consistently do what I said I was going to do as a leader. People came for that.

As an aside: Very often, managers ruin companies. We wrote a management manifesto that lays out how we feel about that role.

If you’re an IC looking to transition into management, what’s the first step?

I think you have to start learning to think sociologically about the dynamics of the team and the people around you, and how you can influence how people work together as a team. Becoming a tech lead, for example, has a lot more social dynamics to it than just writing the best code. You have to think about things we depend on, the people we depend on, and how we are shaping our organization to reflect the work that we’re going to do — without having to get into the thoughts and feelings of people and actually managing them. So a good way is to try and lead a project that has a lot of cross-functional work and dependencies, and requires people functioning well together, to see if you have the ability to inspire people to get their work done as a group.

If you can do that successfully, then you can start to learn the skills it takes to actually work with people well and be their manager. Because that’s a hard role; it’s a role of servitude. People put their careers in your hands, and that’s something you have to take very seriously. If you can’t handle the idea that your mistakes will mess with people’s careers, and that people truly depend on you, then it’s not for you.

If you think you can do it and want to help people become better versions of themselves, dig in.