Sam Lambert is CEO of PlanetScale, a MySQL-compatiable serverless database provider. Prior to joining PlanetScale (then as chief product officer), he was VP of engineering at GitHub.
In this interview, Lambert discusses a number of topics related to cloud native software-delivery models, including what good serverless looks like, who should run Kubernetes, and the emergence of “cloud-prem” — a deployment model that combines the strengths of on-prem software and SaaS offerings. He also shares his experience becoming a non-founder CEO, and his advice on when and how to make the move from engineering to management.
FUTURE: You’ve described what PlanetScale is doing — at least its not pure-SaaS offering — “cloud-prem” computing. How do you define that term?
SAM LAMBERT: Cloud-prem is a new model — the cloud native solution to on-prem, basically. Traditionally, companies have had to either have an on-prem solution or a cloud solution, and straddling both is traditionally very difficult. At GitHub, we had this tension of running github.com and also selling GitHub Enterprise as an on-prem solution. With the cloud product, we had to be able to push and deliver continuously. Cutting a release based on that was a really difficult task, and building architectures for both meant that we were not delivering the on-prem solution as well as we could have done; it was just very arduous to do.
When we came to PlanetScale, we decided that we wanted to be cloud-only, but, of course, you can’t just do that with a database product or a product that has strict compliance requirements. So, with cloud-prem, we essentially deploy the data plane of our product into a VPC managed by the user, where they use our control plane to orchestrate it and we manage it. It essentially feels like you are just using a regular cloud-based SaaS product, but the data resides within your account. Your security team can audit it, and they feel the safety and the trust of having it within the boundaries of their infrastructure, without the downsides of having to patch, release, and manage on-prem software themselves.
There’s one other added benefit, which is if you are a large customer with a great negotiated rate with Amazon, for example, you get to pay that rate still and keep your committed spend with Amazon inside your account.
What kind of pushback do you get? There are some diehard SaaS and on-prem shops out there …
We can give you pure SaaS, where we host the data inside our account, and people are completely fine with that. The real pushback is if people just want on-prem. But the cloud-prem model is really starting to resonate. We have got regulated companies using the product because they see the double benefit of keeping the data locally so security or compliance is happy, but also not having to manage it.
This is why this model is so uniquely awesome and a real moment in time: Because it gets around that problem of not companies not wanting to do on-prem — and it being an old, dead model, basically — but still mostly meeting the requirements that on-prem would.
But, yeah, you still meet resistance sometimes. There are some companies that just won’t trust SaaS software, but the cloud is rapidly doing away with that. Like, you don’t get to decide when or how Amazon updates S3 and makes S3 better, it just happens. It’s all about building trust with a lot of customers that you are the best company to manage a particular job for them, and helping them get more comfortable with that.
You can’t build the best developer experience when you’re shipping on-prem software. You can’t continually improve. You can’t manage quality, availability, uptime — all those things are part of the experience.
Developers can be pretty opinionated about the databases they use. How does the cloud-prem deployment model speak to developer experience?
It’s more like the deployment model takes down the blockers. You can’t build the best developer experience when you’re shipping on-prem software. You can’t continually improve. You can’t manage quality, availability, uptime — all those things are part of the experience. If you don’t manage the service yourself, it’s very hard to create such a high level of experience.
A major blocker for SaaS-only, of course, is the need for some users to keep data under their control. A major blocker for on-prem might be scalability. And so the cloud-prem model is more like a mechanism to get rid of those blockers and give everyone the best of both worlds.
What’s the role of Kubernetes in your deployment model? And what do you think should be the role of Kubernetes overall for something like a cloud-prem deployment?
Kubernetes allows us to deploy into customer environments in a very standardized way, and it looks the same as the Kubernetes cluster we run internally. Architecturally, we’re also based on Vitess, which runs on Kubernetes and was developed on Borg, the predecessor to Kubernetes at Google. So, natively, it’s very self-healing. If you lose pods or you lose infrastructure, it heals itself pretty much; failovers are not something you have to consider manually.
In our model, users don’t have to run the Kubernetes clusters that we deploy. We don’t do the model of deploying onto an existing Kubernetes cluster, which some on-prem vendors do as a way of trying to make it easier. I’m skeptical whether it is any easier, honestly.
Most people don’t need to run Kubernetes. It’s a great backend for infrastructure providers, but I don’t think it’s necessarily the right deployment mechanism for most companies. I think a lot of people have gone down that route and found little or no value from doing it.
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 there a level of scale where it begins to make sense, in your opinion? Or a particular use case, like running an internal platform team?
If you’re doing what we do, where you want to simplify infrastructure and have something that is flexible like Kubernetes, then it’s great. But that level of flexibility is so open-ended that if you are just building, say, an ecommerce company that’s trying to host a website, you don’t need Kubernetes in the backend to be doing that.
It’s very widely adopted, and I think a lot of people try to build these internal platforms and they see Kubernetes as a way of having simple internal infrastructure. It’s just not the case; it doesn’t go far enough with the end-user experience. People should be using the cloud for what it’s best for, and letting the clouds and the folks like us run Kubernetes as a way of simplifying what we do.
But surely there’s a point where an organization has a large enough footprint to justify running something like Kubernetes internally, right? Like you were doing at GitHub?
If you have a lot of hosts to manage — and we’re talking thousands of machines, which is not many companies — and you want infrastructure that’s a little bit more self-healing or can leverage a large fleet of machines, it helps you have the flexibility to handle these things.
I think the question for every company, no matter what the technical choice, should be: Does this differentiate for our customers? Is there an end-user story or requirement that is made better by us running and managing this infrastructure? And if the answer is no, then you shouldn’t do it with any tech at all.
Like, basically no one now can justify running their own Git hosting. It’s just crazy to not spend the ridiculously low amount of money to have GitHub or GitLab do it for you. It’s a settled argument; there’s no upside to doing it yourself. As serverless and just tech, in general, gets better, that line is moving everywhere for everybody. You’re just not going to build an internal database team or ops team that is better than at service providers like ourselves.
And even if you did, how would the users know? What would it do for your user base? Very little — 99.9 percent of the time, they do not care about your tech stack. Every company should pretty much just do things that move the needle for their own users and leverage as much managed infrastructure as they possibly can.
Security is a user experience problem and it’s very fundamental. It’s hard to be secure if you make it tough for your users to do the right thing.
How do you see security and data privacy concerns evolving, especially for SaaS providers?
Everyone cares about security. It’s something we have to take extremely seriously as a company that hosts people’s data. One trend I see is that companies are going for their compliance certifications way sooner than they used to. Now you have to get SOC 2 certification pretty much immediately, otherwise you’re not going to be able to play. (If you want a good bit of reading, Fly.io wrote a blog post on SOC 2 that’s worth looking into.)
And, in general, companies are very keen on certain capabilities that are now table stakes, such as single sign-on authentication, audit logging, and proper revocable access tokens.
For example, now, if you accidentally check your database credentials into a public GitHub repository, we immediately revoke them so that people can’t get access to your database. That’s the kind of thing that used to happen — people would push their AWS credentials into an open source repository and then their account suddenly is being used for Bitcoin mining and they’ve run up tens of thousands of dollars in bills, or their data is out there on the internet
Ultimately, my hot take is that security is a user experience problem and it’s very fundamental. It’s hard to be secure if you make it tough for your users to do the right thing. If you make security non-default, and something that people have to think about and configure, they’re more likely to make mistakes. So, for example, you cannot connect to PlanetScale in a non-encrypted way — you can’t. People want it otherwise because they want to be lazy or they want to do things in certain ways. We just don’t make it possible. The result is that no one can mess up and send their data in plain text across the internet. That, again, is part of user experience.
For every [cloud provider service] — and there’s hundreds on Amazon — there’s 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.
You mentioned serverless before. What’s your working definition of serverless?
The way I describe 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 says, “What is the unit of value to the user? What does the user want to do?” And it doesn’t force them to do anything more than that. So, for me, it’s an optimistic movement that goes toward simplicity and better product design.
How would you assess the relationship between your company and cloud providers right now? Is “frenemies” a fair description?
It’s interesting, because we compete in some ways, but we also bring lots more usage to their platform. For customers running our managed, cloud-prem version, we work with Amazon reps so that people don’t leave to go to Google; they stay on Amazon and they use our software. So the reps still get loads of consumption, we get our take of that whole deal, and it’s great. I think they’re slowly going to move backward and have companies like us be the end-user experience. And ultimately they’re still winning, because they are still selling servers at greater and greater volumes.
But we’re in this interesting middle phase, where they’re not just big box retailers. They still do compete with us with certain products, but it’s getting much harder because, now, for every one of their services — and there’s hundreds on Amazon — there’s 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.
If you’re the type of manager that’s not trying to climb the ladder all the time — but just gets done what you say you are going to do, and you’re collegial while you do it, and you help people win and you push people forward — you just naturally get brought into bigger rooms.
Unrelatedly: You weren’t the CEO of PlanetScale to begin with. How did your shift from CPO to CEO come about?
When I joined, the company was doing things a little bit differently. We were doing hosted Vitess, which is the old product that we had. I decided I wanted to build an amazing database product that had Vitess at its core, where Vitess was the underlying engine, but wasn’t the final product. So we kind of 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 folks that I knew well.
At that point, a lot of the company and the culture was people that had come to work with me —to work together again — so a double shift of the culture and the product came in through what I wanted to do. The last logical thing was to align everything under that vision. That’s why I became the CEO.
It was a simple transition that was done and dusted very, very quickly. I mean, our founders are great. They started this company, they built the company, and then they handed it off like a lot of founders do. Some companies should have done this way sooner.
You also moved up the ladder at GitHub pretty quickly, from DBA to VP of engineering. What’s your advice for making those types of transitions successfully, and also for deciding if a move into management is the right one?
First of all, if you’re at a company that requires becoming a manager to have any influence, then you are at the wrong company. I think a lot of people leave an individual contributor role to go and be manager just to remain in the room, which is terrible.
My advice is to become a manager if you care deeply about people and care about the results that great people can achieve. You can go too far the other way, where you’re just a people manager and you don’t care so much about the work. I think you ultimately want to see great things get built, and you do that through great culture and empowering people. So, if you care about those things and can build those things, become a manager.
I really cared about those things. I joined GitHub as an engineer, and I had an impact there and I loved it. And I knew that to scale, for us to continue to do great engineering, we needed great management. I wanted to build a high-performing culture with great engineers. So I started doing that, and we had a lot of changes. The company grew, but I just very consistently worked with people that I knew were doing good things, and just grew up from there.
You always get asked to do more. If you’re the type of manager that’s not trying to climb the ladder all the time — but just gets done what you say you are going to do, and you’re collegial while you do it, and you help people win and you push people forward — you just naturally get brought into bigger rooms. That just happened over a period of time. And then eventually, yeah, I was running a large team there as a VP because I just always did exactly what was necessary for the business and stuck in it and worked hard and empowered people.
And the thing that 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. That was, to me, a sign that I had shown that 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 can’t handle the idea that your mistakes will mess with people’s careers, and that people truly depend on you, then [management is] not for you.
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.
Views expressed in “posts” (including articles, podcasts, videos, and social media) are those of the individuals quoted therein and are not necessarily the views of AH Capital Management, L.L.C. (“a16z”) or its respective affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation.
This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/.
Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.