Transcript:

Emily: Hi everyone. I’m Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product’s value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn’t talk about them. Instead, we talk a lot about technical reasons. I’m hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you’ll join me.

Emily: Welcome to The Business of Cloud Native. I'm your host Emily Omier. And today I'm chatting with Jón Eðvald. And, Jón, thank you so much for joining me.

Jón: Thank you so much for having me. You got the name pretty spot on. Kudos.

Emily: Woohoo, I try. So, if you could actually just start by introducing yourself and where you work in Garden, that would be great.

Jón: Sure. So, yeah, my name is Jón, one of the founders, and I’m the CEO of Garden. I've been doing software engineering for more years than I'd like to count, but Garden is my second startup. Previous company was some years ago; dropped out of Uni to start what became a natural language processing company. So, different sort of thing than what I'm doing now. 

But it's actually interesting just to scan through the history of how we used to do things compared to today. We ran servers out of basically a cupboard with a fan in it, back in the day, and now, things are done somewhat differently. So, yeah, I moved to Berlin, it's about four years ago now, met my current co-founders. We all shared a passion and, I guess to some degree, frustrations about the general developer experience around, I guess, distributed systems in general. And now it's become a lot about Kubernetes these days in the cloud-native world, but we are interested in addressing common developer headaches regarding all things microservices. 

Testing, in particular, has become a big part of our focus. Garden itself is an open-source product that aims to ease the developer experience around Kubernetes, again, with an emphasis on testing. When we started it, there wasn't a lot of these types of tools around, or they were pretty early on. Now there's a whole bunch of them, so we're trying to fit into this broad ecosystem. Happy to expand on that journey. But yeah, that's roughly—that's what Garden is, and that’s… yeah, a few hop-skips of my history as well.

Emily: So, tell me a little bit more about the frustration that led you to start Garden. What were you doing, and what were you having trouble doing, basically?

Jón: So, when I first moved to Berlin, it was to work for a company called Clue. They make a popular period tracking app. So, initially, I was meant to focus on the data science and data engineering side of things, but it became apparent that there was a lot of need for people on the engineering side as well. So, I gravitated into that and ended up managing the engineering team there. And it was a small operation. We had more than a million daily active users yet just a single back end developer, so it was bursting at the seams. 

And at the time running a simple Node.js backend on Heroku, single Postgres database, pretty simple. And I took that through—first, we adopted containers and moved into Docker Cloud. Then Docker Cloud disappeared, or was terminated without—we had to discover that by ourselves. And then Kubernetes was manifesting as the de facto way to do these things. So, we went through that transition, and I was kind of surprised. It was easy enough to get going and get to a functional level with Kubernetes and get everything running and working. The frustration came more from just the general developer experience and developer productivity side. Specifically, we found it very difficult to test the whole application because we had, by the end of that journey, a few different services doing different things. And for just the time you make a simple change to your code to it actually having been built, deployed, and ultimately tested was a rather tedious experience. And I found myself building tools, bespoke tools to be able to deal with that, and that ended up being sort of a janky prototype of what Garden is today. And I realized that my passion was getting the better of me, and we wanted to start a company to try and do better.

Emily: Why do you think developer experience matters?

Jón: Beyond just the, kind of, psychological effect of having to have these long and tedious feedback loops—just as a developer myself, it kind of grinds and reduces the overall joy of working on something. But in more concrete material terms, it really limits your productivity. You basically, you take—if your feedback loop is 10 times longer than it should be, that exponentially reduces the overall output of you as an individual or your team. So, it has a pretty significant impact on just the overall productivity of a company.

Emily: And, in fact, it seems like a lot of companies move to Kubernetes or adopt distributed systems, cloud-native in general, precisely to get the speed.

Jón: And, yeah, that makes sense. I think it's easy to underestimate all the, what are often called these day-two problems, when—so, it's easy enough to grok how you might adopt Kubernetes. You might get the application working, and you even get to production fairly quickly, and then you find that you've left a lot of problems unsolved, that Kubernetes by itself doesn't really address for you. And it's often conflated by the fact that you may be actually adopting multiple things at the same time. You may be not only transitioning to Kubernetes from something analogous, you may be going from simpler, bespoke processes, or you might have just a monolith that didn't really have any complicated requirements when it comes to dev tooling and dev setups. So, yeah, you might be adopting microservices, containers, and Kubernetes all at the same time, and I can say a lot of good things about Kubernetes, but it leaves, definitely, a lot of gaps in terms of the experience, especially for the application developer. 

So, you have these different kinds of developers, and we're kind of gradually, and somewhat clumsy sometimes, moving from a world where would have the application developer, and then you would have the operators, and you would kind of throw things over a fence. And now we're trying to fuse these a little bit, and you end up with this combination of different people with different strengths, and different skill sets and the [00:07:03 infra], and often termed DevOps engineers—I know that makes some people cringe. It's just what we see out there, that's a job title that we’re seeing more and more—they are at home with this sort of a thing, and they maybe have time and patience to tinker with something like Kubernetes, whereas your application developer, they just want to get that feature out. So, you end up with these two different disciplines where one is basically trying to unblock the other. And we’re definitely made progress. And I like to think what we are building helps, and all the other tools that are kind of overlapping in our space. But I still see a lot of this frustration with both having to adopt this more DevOps mindset, and also just the frustrations with Kubernetes specifically, and all the actual technologies that are in play these days.

Emily: And to what extent do you think this sub-optimal developer experience is about a skills gap?

Jón: I think that's definitely a part of it. I mean, we have both current and prospective customers in all kinds of different companies coming from different backgrounds, and some more old school and rigid than others. And I would say, for companies where the divide was really crisp—like, you had the application developer, and then you had the operator—then basically the mentality, understandably, for the application developer, they just want to work on their code, and not have to worry about networking ports, and ingresses, and all the low-level primitives of Kubernetes. It’s a whole new thing to learn, and the perception is that it's more getting in the way of them getting stuff done. They don't really need the power for their immediate needs. The power is maybe something that the operator really enjoys, and has a strong need for.

Emily: Do you think tools like Garden help close the skills gap?

Jón: I think so. It definitely makes it more palatable at the start; it's easier to get going, you get some guide rails, and you get some higher-level abstractions that are maybe familiar to you, so you're not completely overwhelmed by all the different options, and flags and whatnot that you need for all the Kubernetes, YAML, et cetera, and you can ease into it. So, I think that's really helpful. Another thing that I think is really helpful is, so instead of this separation—[00:09:33 crowbar] separation between developer and operator, people coming from the operations side, part of their role now is to empower the developer, so the developer becomes their customer. I think it, in some sense, always was that way, but now they are more focused on the developer experience, and unblocking, and creating, often, these internal tools and internal abstractions that buffer this skills gap, I guess, a little bit. 

And we see all kinds of variations on how people actually go about it. With Garden, what we hope to achieve is for—there's usually a team that is responsible for the developer experience of an organization, and they can just hand tools like that to the team. And maybe there's a little bit of a dotted line between what the application developer is responsible for and what they should know, but they should still be familiar enough with the concept so that they can start to perceive the infrastructure and the general systems architecture of the application as part of the application and not this separate concern. Yeah, I mean, I definitely would hope that were helpful in this regard.

Emily: Yeah, and I was going to ask, actually, what your opinion about this is, you know about how familiar an application developer actually needs to be with Kubernetes.

Jón: I think unless there is substantial investment at their company in abstracting these things away from the developer, they need to have at least a cursory understanding of how all this set up. Maybe they're not responsible for actually making the Kubernetes manifest, maybe they're working in some kind of a templated fashion, or they have a little bit of a buffer between the low-level configuration of everything and what they're working on in a day-to-day, but they'll get stuck pretty quickly and it will create a lot of friction if they just don't know at all how the thing works. I think it's also just important for any, kind of, distributed systems developers to understand what the primitives are, even if you don't know which flag to use for this and that to actually achieve what you want to achieve, understanding the dynamics and understanding—you know, as a developer, you're meant to understand basically how a computer works, you know, the general layout of a computer, CPU or memory, and you have some notion of how the network works. This is maybe a layer on top of that similar to how you are familiar with how an operating system works, you should have basic familiarity over how Kubernetes works and just the general layout of a cloud-native ecosystem. Which I think is reasonable.

Emily: And then when we think about business stakeholders in a company, so people who are outside of the IT department, how do they perceive this challenge? Do they understand how developers might struggle with moving to Kubernetes? Do they understand the stakes of getting developer experience right?

Jón: I think a lot of the time they find out in the process. I think, for better or for worse, this cloud-native ecosystem was kind of jumpstarted, and people were sold on the idea a little bit before it was actually palatable for day-to-day development and actually running in production. So, you have an ecosystem running around trying to make this into a pleasant experience, but part of that meant that there have been—especially the early adopters, I can only imagine, but even companies adopting Kubernetes now, yeah, they maybe have the wrong picture of what it actually takes to do this successfully, and we've definitely seen—I mean, I'm kind of in that group myself. I adopted Kubernetes fairly early on. Well,-ish; it was about three years ago. 

And once you get past day one, as it were, there is a lot of surprises, and I think that could have done with a little bit more education, and maybe the motivation to get people on board kind of clouded that a little bit. No pun intended. So, yeah, I think it's more common than not that people have had to find that out along the way. Maybe that's probably getting better now. I think people have a—both the tooling is actually better so that gap isn't as wide as it was, but also to general awareness, I think there's enough stories out there where people have really struggled with the adoption, and struggled with productivity somewhere along the way, or after the adoption process. Yeah. Does that answer the question? [laughs].

Emily: Absolutely. And actually, I'm curious, what were some of the surprises for you?

Jón: I'm still surprised every now and then. I've been working, I’ve been developing against Kubernetes, full-time pretty much—well, to the extent that I can develop full time over the last couple of years—and worked with it as an end-user before that, and I'm still finding new and interesting ways in which something can fail. And just a simple example, just the act of deploying a single service onto Kubernetes, you need to write up a few different YAML files. Doing that in a secure manner is not exactly obvious, and is nowhere near secure by default, so you have to, kind of, discover that, or pay some security providers to really help you with that. The number of ways in which a service deployment can fail is just—it's still—it keeps rising. [laughs]. I found a new one just yesterday. Like, “Oh, actually, here's an interesting condition. I hadn't come across that before.” 

So, the abstractions are fairly low-level, and you have to be able to navigate that. And I would much prefer higher-level abstractions that encapsulate all the—even if it's just encapsulating all the different failure modes of starting a container, that would be super helpful. But I think that's one thing that people keep stumbling on. And just to deploy a single service, there's a lot of different bells and whistles that you need to be kind of faintly aware of, and they—you will keep discovering them as you keep working with it. It's been both an interesting experience, and it's definitely put a lot of life into this developer ecosystem, but it's also been quite frustrating since myself and a lot of other developers out there are stuck having to deal with this and discover all these different things gradually. Does that make sense?

Emily: Absolutely, but I'm going to ask another question, which is, what about pleasant surprises?

Jón: I think I mentioned one earlier. One of the pleasant surprises is how quickly this ecosystem has formed, and a huge community of people, and really putting a lot of effort into making the whole experience better, and adding any functionality that doesn't come out of the box, as it were. I think it's been really interesting to observe that ecosystem manifest. Yeah, I think that's probably the most interesting positive thing that comes to mind. I think it's been interesting to see all kinds of different, ostensibly competing companies work together in many ways. 

Just the general power of the open-source movement has definitely come to light which has been great. I feel like the attitudes just in our user community, and the user community generally—just go to the Kubernetes Slack, or you have discussions on GitHub issues or all kinds of, you know, one or more of these open-source projects and ecosystem. Like, just general morale, and helpfulness, and collaborative nature has been really interesting to watch, and I’ve really enjoyed that.

Emily: I'm going to ask, just sort of a very different question, which is, I always like to ask my guests what their job actually entails. Everyone has a job title, and it doesn't always provide lots of visibility into what you actually do during the day. So, what does somebody like you, who's the CEO of a startup, what do you actually do when you get into the office? What does your day actually look like?

Jón: So, it has evolved a lot. Let's put it that way. And I wear many hats for sure. So, my background is I'm an engineer, that's kind of my comfort zone. I can write code and I can think about systems and all of that jazz, and that comes naturally to me. So, in my CEO role, I've been learning a lot on the go. 

So, these days, a lot of my time, I've spent maybe 30, 40 percent of my time coding these days, which is just about average. Sometimes it's a little bit more, sometimes it's almost not at all. And that's probably going to fluctuate and, over time, decrease. I think the most important part of my role is to generally engage with the ecosystem, and that involves reading, talking to people, talking to investors, talking to other people in my industry, talking to customers, kind of trying to build a mental map of this world we live in, and try and figure out how that translates into our product roadmap for us, and try and communicate what's important, what's urgent for the team to think about. So, I'm kind of this liaison between the external world and the internal world that is our team in many different ways. I think that consumes a lot of my time. 

And then working on content, working with our marketing manager, joining sales calls, supporting customers, working with our designer trying to figure out what's our brand identity, and how should that evolve. Yeah, I’m kind of a nexus of a lot of different things, which I really enjoy. Sometimes exhausting, don't get me wrong. But yeah, I like to think that I'm connecting dots.

Emily: So, I wanted to also ask a little bit more about what Garden does, and particularly how is the testing that you do, how is it different from what you would get in just a normal CI tool?

Jón: Right. So, testing is definitely—it was always part of the picture when we started. I think when we started working on Garden, we maybe tried to solve too many problems. That's pretty common startup mistake, I guess. And we're focusing more and more on testing. And so, I'm happy to elaborate on that. 

So, the way people do testing today—and this I derive from both personal experience and talking to a lot of our current and prospective customers—it's very common to, well A) not to it in any meaningful way. That's surprisingly common still, or to unit test the individual components of an application. But that falls short in a number of different ways when working with just microservices in general. And in these cloud-native scenarios, you tend to have a lot of different moving parts. And what we're trying to address is how easily you can test your application end-to-end; how you can spin up your own ad hoc instance of an application, the full application with all the different services, even the ones you do not working on; and how you can write tests such that they actually test the interaction between services and not through mocking and stubbing them, or bending over backwards to do these contract testing and things like that. 

That certainly helps mitigate these things, but the cloud-native ecosystem actually bring—and Kubernetes, and just the declarative nature of how we define and deploy applications today—actually creates a lot of opportunities. You can now feasibly spin up a whole instance of an application with all different services that comprise your back end, and you can run tests from within there. And Garden really helps to make that efficient and easy to use for developers. So, the comparison to CI naturally comes up, and Garden in a certain sense blurs the line between a developer tool that you use in the inner loop or locally from your laptop, and the process that happens in your CI. We don't aim to replace CI; that's a pretty saturated market. We just want to focus on the testing and previewing side of it. 

And what Garden does, which is unique, is that it allows you to describe every part of your stack, how it's built, how is deployed, and how it's tested, and we compose this into what we call the Stack Graph. So, we have this directed graph of all the different things that need to happen between just a bunch of Git repositories and a fully running, tested system. And where that comes in really handy is when you make a small change—you push a pull request or you're just testing locally by yourself—we know which parts of your stack actually are affected by that change, so you don't need to run a full battery of all of your different tests, you end-to-end tests. You can actually just automatically trigger the few parts that need to be rebuilt, redeployed, and retested. So, it's making it viable to actually run integration tests and end-to-end tests as part of your development workflow, and it also makes it much easier for the developer to cross between the inner loop—working on the code themselves—and getting it to pass through CI because that's often an arduous process, just getting things to pass testing in CI, because it may work fine on your laptop, or you may only have a small subset of the system that you're working on, and then you have to make another commit and push to get, and then the CI pipeline runs again. That can take an arbitrarily long amount of time. And instead, you can just run Garden test, or run a specific test suite from your laptop and have it work much the same way in CI as when you're developing locally.

Emily: Do you have anything that you can think of that you'd like to add about this general topic of the surprises and misconceptions that come up around cloud-native and Kubernetes?

Jón: It's generally been a pleasant experience. And it's been really motivating to see all this activity in this space. There's definitely lots of activity, lots of small startups and big companies trying to figure out better ways to do things. And I think it's fun to be a part of it. I think, who's to say how it's all going to shake out, but I don't remember it being quite like this pre-cloud-native, and I'm very much looking forward to, at the end of this journey, that we as an ecosystem kind of are going through that we will have something that really materially changes how we develop distributed systems, not just in the context of Kubernetes—because that's a specific technology that works for a specific type of customer—but rather taking it further and keeping this collaborative note, even when we go past what's the technology of the day.

Emily: All right, so one bonus question, what is your favorite engineering tool that you could not live without? Or I should say that you could not do your work without? Maybe you could live without it.

Jón: Well, yeah, exactly. Yeah. I think probably the most central tool that I have in terms of my development is Google. The thing is, as a developer, there's just no way you can know all the things. You don't remember every API. Like, I keep looking at the same thing over and over again, and being able to have all this information just at my fingertips, I think that's something that I would—well actually both have a hard time living without, and engineering without. 

And notable mentions, I've really enjoyed working with [00:25:33 VS Code] as of late. We code in TypeScript, which is slightly unusual, but I've also become a fan of that. There's probably a number of smaller tools that I'm forgetting to mention that I use all the time, but just being able to find whatever I need at any time, that's probably the most revolutionary thing to come up over the last decade.

Emily: Where could listeners connect with you or follow you?

Jón: So, I'm on Twitter, not the most active on Twitter, but I'm always—if you follow me, I probably just follow you back and try and get into the conversation that way. You can reach me there directly. Also, if you just want to ping me—so on Twitter, @jonedvald, just my name as it's printed. You can find the community for Garden itself through our website, Garden.io. We have a Slack channel on the Kubernetes Slack, just #Garden. And yeah, please reach out. I'd love to chat. If you're interested in using Garden or not, I'm always trying to be more engaged with the community, and that doesn't have to be Garden-related necessarily.

Emily: Well, thank you so much for joining us on The Business of Cloud Native.

Jón: Thank you so much for having me.

Emily: Thanks for listening. I hope you’ve learned just a little bit more about the business of cloud native. If you’d like to connect with me or learn more about my positioning services, look me up on LinkedIn: I’m Emily Omier, that’s O-M-I-E-R, or visit my website which is emilyomier.com. Thank you, and until next time.

Announcer: This has been a HumblePod production. Stay humble.