EPISODE 1606

[0:00:00] ANNOUNCER: This episode of Software Engineering Daily is part of our on-site coverage of KubeCon 2023, which took place from November 6th through the 9th in Chicago. 

In today's interview, host Jordi Mon Company speaks with Darren Sheppard, who is the Chief Architect and Co-Founder at Acorn Labs. 

This episode of Software Engineering Daily is hosted by Jordi Mon Companys. Check the show notes for more information on Jordi's work and where to find him.

[INTERVIEW]

[0:00:38] JMC: Darren is here as the Chief Architect of Acorn. That title has a purpose, right? You are the architect for reasons? Right? Reasons.

[0:00:46] DS: Yeah. I mean, it's like I'm allergic to the title of CTO. Because like I just fundamentally believe it's just more business-oriented. It's like it is relate - it's somewhere like business touches technology, but it's fundamentally a business position. You're going to be doing more spreadsheets and PowerPoints if you're a CTO.

[0:01:04] JMC: Do you think the same of CIOs, by the way? Chief innovation officers? Do you know what they do? 

[0:01:11] DS: Oh, man. I probably think even less of it. No. A CIO is more of like they need to run the internal - no. Is that the COO? I don't know. I don't even know what they do. But if you have innovation in your title, it's usually the worst. 

[0:01:22] JMC: Yeah. But I do like, as I was saying before, the architect in the chief architect title. Because it's true. I think that that person knows the breadth and depth of the codebase of the product, of the service, whatever this person or this company is building. And is in charge of I think the main characteristics of what software in a startup should conform the solution that a startup like Acorn is building. That is, well, resiliency. But mostly, I think flexibility and anything that allows it to evolve into what product market fit or product niche it's actually trying to cover. Would you agree with that vision of an architect? 

[0:02:00] DS: Yeah. I mean, because I'll also say a lot of architects are just kind of BS or whatever. But it's like why I like the term or whatever the title is it fits a little bit more of what I - I very much want to build the technology I enjoy. I see a bunch of technical issues. I want to fix them. I very much like building the technology. Kind of controlling - owning the whole solution end-to-end. 

But I do very much like kind of the business side of it too. It's like understanding what's the business objective? And then building the technical solution for it. It's like it's kind of the business side gives you the problem and then I can basically come up with a solution. 

And I very much - I've spent my entire career in like kind of these orchestration systems and stuff. It's like I fundamentally kind of like these big systems. It's like multiple things talking to each other and stuff like that. And so, it's like building these larger things.

[0:02:45] JMC: I mean, I don't want to jump. Because I want to do something, talk about something before we jump into the core of this conversation. But I find it funny. I thought your background would be in development, application development at the top layer of the tech stack. Because the framing, the positioning of Acorn is that Kubernetes is too complicated. And I thought, "Well, these guys must be all developers and "hate"." They don't hate, but they are very critical of Kubernetes because they come from precisely the other world. Because Kubernetes is meant for infrastructure people. But you guys have grown professionally in the infrastructure space yourself. 

[0:03:18] DS: Yeah. And so, I sit in a very weird position where it's like I kind of fundamentally relate more with a developer. But I've always worked in infrastructure and build infrastructure systems. It's like I got into Linux when I was young. And I very much loved Linux. And then like I got to a point where, in order for me to do more with Linux, I had to learn programming. And that's how I got into programming. 

And then like once I got into programming, then I got started doing that more as a career. And so, I learned Java and I did Java development. I was a Java developer in a big financial company, but I have a background in Linux. And so, then I started doing all this weird automation of infrastructure and stuff because I was frustrated with the CI systems. How slow they were. 

Well, CI wasn't actually a thing back then. This was like the birth of CI actually. I don't know if cruise control was one of the systems. That was a big deal. Was it ThoughtWorks? They were the ones who kind of coined a lot. 

[0:04:09] JMC: Yeah. They had a system called, I think confusingly enough, Go. Wasn't it? 

[0:04:14] DS: Yes. Yeah. I think something. Yeah. 

[0:04:16] JMC: Yeah. [inaudible 0:04:16] or something. Yeah.

[0:04:17] DS: Yeah. It might have just been called Go. Yeah. And then like Antill. I worked with all those things. And so, it's like I've sat in this weird position where it's like I understand infrastructure, but like I'm not fundamentally an ops infrastructure person. And like I worked at a hosting company. And I learned that firsthand of like working with a bunch of infrastructure people of like trying to understand the difference of mindset. 

Because I was building a cloud system, like their cloud offering. And so, I was taking CloudStack. Taking that software and try to turn into a product. And so, I was working with the infrastructure team. And so, it's like I understood like how Linux works. How the networking, the VLANs, the switches and programming all this stuff. But fundamentally, I'm a developer. 

And so, I have that kind of this weird persona where it's like I work in this realm and I understand it. But I also am not - I don't fit in. It's like I don't like - and I think that's also like why you might see Twitter and whatnot is like complaining about Kubernetes. It's like I understand it's a beautiful system. I understand why it is and everything. But I'm coming at it from a user and more from a developer perspective. Because that's like just my personality and whatnot. That's kind of more the fence I sit on. 

[0:05:25] JMC: Yeah. By the way, your career is similar to many other founders. When you were describing right now the different stages of your career, it did remind me of Adam Jacobs, the founder of Chef. He described it I think a while back - I mean, probably in many places, but in a podcast interview that I listened to a few months ago. And it's kind of similar. By the way, before we would jump into Acorn, I wanted to praise your online persona. The way you conduct yourself online. Have you ever had any controversies with Adam himself on Twitter? 

[0:05:54] DS: I go back and forth. Just more recently - one of our employees at Rancher left and then went to his startup. And I was good friends with him. And then - 

[0:06:01] JMC: Chef. No. No. No. Sorry. The one he's doing now. 

[0:06:04] DS: Oh, System Initiative. He's doing that startup. And so, because of that, I became more of aware of what he was in. Then I started interacting with him on Twitter. And I very much enjoy - and I think we might disagree on quite a few things, but I really enjoy the conversation back and forth with him. I really enjoy him.

[0:06:20] JMC: This is my point. It was not only about praising you and the way you conducted yourself, but the environment in which you are open to criticism, about your own stuff, about other stuff. And how that has actually been a bit maybe not under threat. That's probably too exaggerated. Much of an overstatement. But it has certainly not been praised enough, right? 

We are here at KubeCon in which many other values of open-source have been put into practice and praised and supported, collaboration, inclusion, many other things. But I think that exchange of ideas in even from an antagonistic perspective has not been - which is a fundamental tenant of collaboration, I would argue, and so forth. 

And I really like that you go about with what it seems like a bit of a rogue facade, a bit of a trolly facade. But the fundamental underlying spirit and environment, which Adam also represents and many others, is there. And I really think that that exchange of ideas is really good for the open-source ecosystem. I'd like to praise you for that. Yeah.

[0:07:19] DS: Oh, thanks. I mean, what I do online and Twitter or whatever, it's just like I'm always coming everything from a user perspective. It's like if I'm complaining about a piece of technology, it's because I'm trying to use it. Usually, I see some value in it. I want it to work. And I can't get it to work. And I'm frustrated. And it's like why is it so difficult? It shouldn't be this difficult. 

And so, it's like - the things I complain about online is like I think I'm definitely not correct most of the time. There are a lot of things I'll say that are probably like not right. But it's at least valid feedback and that, "Hey, users are frustrated." It's like there's something valid about my frustration even though my conclusions could be wrong. You know? 

[0:07:58] JMC: Yeah. The motivation is absolutely valid and legitimate. Yeah. 

[0:08:02] DS: Yeah. But it's also like why like I'm at a startup or I found a startup is it's like I just fundamentally get frustrated with things. And then I'm also very kind of like naive in thinking like, "Oh, there's a better way. There's got to be a better way." And I'm kind of stupid enough to try it. And a lot of times it doesn't work out. And sometimes it does.

[0:08:19] JMC: I honestly think this is very common. I did an interview just a few hours ago with Santiago Torres-Arias from Purdue University. He's one of the co-creators and co-containers of several projects on the security side. That would be in-toto TUF, the update framework. And Sigstore. Signature storage, I think. 

And I find it fun because the motivations for those people to create those projects were not fundamentally selfish or trying to sort of like scratch their own itch or solve their own niche problem. But they were genuinely from the get-go. A bit broader and more for the greater good. Right? Which, by the way, doesn't make any difference. Because most of the projects in the CNCF I think originated from the motivations you just described, which is I find this technology X, whatever it might be, Kubernetes, Prometheus, whatever, frustrating. And I want to do this thing this way. 

And then it turns out that if I open source, it turns out that many other people had the same problem and they want to contribute and so forth. I don't see any difference in the original motivations as long as we collaborate and open it and release it to the open and to the community. What do you think about that? 

[0:09:32] DS: Yeah. That's why I fundamentally love it. I mean, it's like my entire career and everything. I start off an open source. I've built companies on open source. It's like I love open source. And I love trying to solve things and then just putting the information. The biggest thing to me about open source is people have all these different opinions on like what's the right way to run a community and stuff like that. 

To me, all I really care about is that the ideas get out there. It's like you solved a problem. Put it out there. Because me, also, I'm just frustrated when I see something as proprietary where just like I want to know how it was done. And that drives me nuts. But like I just love the sharing of ideas and stuff like that. And then how you build a community and stuff. And so, I do like obviously more open source license that allow people to pick up your work and use it and stuff. But yeah, I think open source, it's fundamental to kind of everything that I do. In Acorn too. 

[0:10:15] JMC: Yeah. Exactly. Acorn took a lot of inspiration from Docker. We were talking about that when we realized that the microphone was off. Please describe what are the areas in which Acorn leverages a lot of the Docker spirit and user experience, developer experience. And then where it sets apart and is different.

[0:10:34] DS: Yeah. I mean, when I look at things - because, one, I just love Docker. That's kind of like I got into creating Rancher, that co-founding that company was - I really saw there's something in Docker or whatever. And so, I have a lot of admiration for what they created. And they really created a beautiful user experience. 

Whatever they were able to do, they were able to package up like the existing technologies of containers and stuff and put it in a way. It's like kind of slightly tweak it or whatever and put it in a way that just really clicked with people. And it was clear. When people saw Docker, it was like, "Oh." Some light bulb went off of like I could use this to accomplish something. 

I take a lot of inspiration from looking at their solutions of how they did things. And so, Docker and Docker Compose are still very successful for developers on the laptop and everything. And so, what Acorn has done is basically taken a lot of inspiration of that of like really compose. Compose is still a very successful system. 

And so, basically, we've modeled a lot of the user experience off of the way Compose works. [0:11:31] JMC: But you think that compose is limited in a way, right? 

[0:11:34] DS: Yeah. It's like the fundamental thing of like - we were talking about this before of kind of like how the industry and everything is. There's a big disconnect between - 

[0:11:42] JMC: Yeah. We should maybe focus - before we jump into what sets Acorn apart from the inspiration it took from Docker Compose, let's focus again probably on another controversial topic, which is the positioning of Acorn or at least the context that Acorn goes about setting is that Kubernetes is freaking difficult. And that developers should literally not give a damn about it. Because it's too complicated. 

[0:12:06] DS: Well, it's not that they shouldn't give a damn about it. It's that they don't. 

[0:12:10] JMC: Well, okay. You're acknowledging a reality there. 

[0:12:12] DS: Yeah. They don't necessarily want to either. That's kind of like a reality at the moment. They don't necessarily want to touch it. Because it's not a system for them.

[0:12:21] JMC: What is difficult about it? In your own experience and potentially other areas that you've - the feedback that you've collected from everyone that you personally don't perceive as difficult from Kubernetes, but that people report that is difficult from Kubernetes.

[0:12:32] DS: It's like if you go back to kind of like - it's like where did Kubernetes come from and everything? It's like if you look at the ecosystem of like when Docker came, it's like Docker appealed to the developers. It was widely popular. It created this huge demand within companies of like I want to put containers in production. It's like we needed a production solution. And that's where Kubernetes came along, which was like, "Okay. Well, how do I run the containers in production?" But the thing about Kubernetes was it was very oriented towards the enterprise IT. 

[0:13:00] JMC: I should ask you, by the way, were Swarm and Mesos any simpler but less enterprise-grade?

[0:13:08] DS: Yeah. This is the thing is, is like Mesos was just too complicated. It was too difficult for people. Because it was a beautiful - it was a very good scheduler. It did scheduling very well. The problem was it was very difficult to get workloads on it because it had this framework model that was just too difficult for people to leverage. You had to do all this coding. 

There are a couple of startups who tried to layer things on top. But fundamentally, they didn't - the architecture and design just didn't really resonate. Swarm was on the side of like user experience. It made a lot of sense. Because it kind of like was much more towards like Docker Compose and everything. It's a much better like user experience, but it kind of lacked the insight that Kubernetes had of like how to run a very good platform. 

It's like when you look at Kubernetes, it's like it's based off of all of this experience of Google, of like Borg and all those things or whatever. And so, it's like people don't realize how insightful the design of Kubernetes is. Because like I was saying like my background, I built orchestration systems. It was just like I was trying to solve the little problem with my Dev team. I would build these dumb little orchestration systems. 

I spent a lot of time building orchestration systems. And it was like I had no theory or I didn't know what the right ways to do it. I just wrote the code. And then slowly over time, I developed better patterns. And when I saw Kubernetes and I started digging into the code, it was like, "Oh, my gosh. This pattern that I was kind of developing, I could see that they had like the next evolution of that pattern." It was like, "Oh, that makes sense." They had clearly refined and understood the best way to do it. And because I already had figured out some crappy way to do it. 

It's like there's so much insight in Kubernetes that people take for granted. They just don't know. Because like now we just have it and it just seems obvious. Swarm actually lacked that. And so, that was - it was like Kubernetes was just fundamentally a better platform. 

And then when you took Google with all this insight on how to build a system and then you bring in Red Hat, that was the perfect marriage. It's because like Red Hat understood IT so well.

[0:15:01] JMC: Yeah. And by IT, you mean enterprise requirements. Right?

[0:15:03] DS: Yeah, they understand enterprise. And so, they're able to basically just like take this - I think I said it's like they basically created like enterprise catnip. It's like it was so good for enterprise of like it perfectly matched the IT model. 

What happened in the industry was you had the demand of developers wanting containers and then all the focus shifted to enterprise to build clusters. And so, they spent all this time building clusters. Making sure we have policy, and RBAC, and security. And all the stuff we're focusing on IT building this thing. 

And then you have to start bringing the applications on board. And so, where we are now, as most companies, they've got like 20, 30% of their workloads on Kubernetes. And they've put a lot of effort on getting their workloads into Kubernetes. And they've all figured out that developers want nothing to do with Kubernetes. It's too difficult. Because they have to put a platform on top of it to get them on top. 

It's like Kubernetes is an amazing platform, but it was never built for humans. It was built to build a platform on top of it. And so, that's what we've lacked from an industry is the platform on top that actually caters towards the end goal of I want to run an application or a specific use case. Whatever your use case is. It just happens to be enterprise. A lot of the use case can to be pretty much very similar like how you want to run applications. 

[0:16:18] JMC: That gap is what Acorn is trying to solve. Right? In a way, you just describe from a developer perspective is the beginning, the first touch point, which is - well, you didn't mention it. But the Acorn file, which emulates, mimics, takes a lot of inspiration from the Docker file, right? 

But then there's another component that is the - well, I mean, please. Yeah, describe that and how it operates, interoperates with the Acorn runtime that is running in the cluster.

[0:16:41] DS: Yeah. So, like the basic. It's like what we're saying. We took a lot of inspiration from Compose. And we're basically trying to solve this problem of like we've got this amazing production platform, Kubernetes, that's completely disconnected. From development like the Docker experience completely exists on the laptop. Docker, desktop is great. They have Docker, Docker Compose. But it's completely disconnected from the rest. 

And so, if I take that user experience of Docker Compose and we've mimicked that - we couldn't use the syntax exactly. There's kind of too many warts there. But it's like it takes all the inspiration of like a same experience. And so, that's what our Acorn file. 

From an app developer, app team, they can describe - they have their Acorn file, which describes their application. they can use that Acorn file to develop their application in the same style of Docker Compose. But the big difference with Acorn is once they've developed it locally on their laptop or whatever, they can then build that into an application, like into an actual application image, an OCI artifact that they can now build that whole thing and then push it to production. 

The exact same thing they're developing is now connected to production. They can now push that forward. And then, of course, there's like little things that have to be different about production. You want this setting in Dev. You want this setting. But the Acorn file allows the teams to express all of the differences, and environments and things like that. 

But everything from a very high-level application perspective. Not the low-level Kubernetes resource and the very technical details. It's like more from application requirements. 

[0:18:06] JMC: Yeah. Because you're describing before, how does actually that work nowadays? Let's say that a user is trying to do that with Docker and Kubernetes. He or she would need to define a lot of things for that to happen. A lot of things in Kubernetes, right? 

[0:18:19] DS: Yeah. It's like if you look at a Docker Compose where it's like I have this simple app. I want to run a Docker Compose. I'll create a service in there, which is like a container. And maybe I create two services. Something simple. And so, that's very simple to understand. That same thing, if I want to replicate that in Kubernetes, like all the same functionality, whatnot. You're talking about, just for the one service, I need to create a deployment, which internally creates like a replica set and a pod. But I need to create a deployment. I'll create a service for that. Some config maps. Probably some secrets. That gives you kind of like your base. But then you need to look at the security. So you have a network policy. Some might have some Istio policy in there too or Cilium. Something like that. Then on top of that, if you want to expose like a HTTP, you might have some ingress. You have an ingress. 

It's like those couple little lines of like I just want to run this container turns into all these real technical details. And so, it's like it's weird that it's so complicated, but there's good reason for all that complexity. But the key thing is, is like the developer or the application owner, they only express like one requirement. And from that requirement, you can then derive all the rest of it. And that's kind of like what Acorn is doing. It's like we can take all that high-level information and then create all the low-level technical details on top of Kubernetes. Because it's tailored to the use case that we understand, which is like running containerized applications.

[0:19:34] JMC: And taking care of that side of the house is the runtime. Correct? 

[0:19:38] DS: Mm-hmm. 

[0:19:40] JMC: Okay.

[0:19:40] DS: The way our product is separated is like we have the Acorn runtime, which is fully open source. You can run it on any Kubernetes cluster. All of the beauty of Acorn comes from the runtime. We also have the Acorn.io, which is the managed experience of that. 

We give you a fully kind of serverless. Like you can't see the servers. Not Lambda functions. But like you get a full experience where you don't see clusters. You don't see servers. We fully manage all the infrastructure and everything. The user can just come in and see Acorn and run applications. We have that. That's our SaaS experience that we launched that just two weeks ago. You can go try that out. 

And then we also sell that basically kind of to enterprise of like this is the experience you can give to your app teams internally. And so, when you look at that thing - going back to the Acorn runtime. What the Acorn runtime is, is the runtime is actually technically Kubernetes. Kubernetes is a thing that actually makes everything happen. 

The Acorn runtime is more of like a dynamic translation of like we take the Acorn file that you've specified your Acorn file. That gets that metadata from the Acorn file. Gets packaged in the application image and the associated Docker images. It's all linked together one in signable OCI artifact. 

The Acorn runtime reads all that metadata and then at runtime renders all the Kubernetes resources. And this is fundamentally different than, let's say, like Helm. The way like Helm would work.

[0:20:59] JMC: Yeah. Exactly. What would be the difference? Yeah. 

[0:21:01] DS: Helm is like basically everything is pretty much determined ahead of - you run Helm, which then basically spits out a bunch of Kubernetes resources. And it's kind of it's all static. It's like if your cluster changes - let's say you have a new version of Istio or a new version of Kubernetes. Or I decided like I don't want to use Cillium. I want to use you know Calico or whatever. Something like that. You have to change those Helm templates. Because it's all bundled in there. 

We do everything dynamically at runtime. We're taking the high-level metadata and then we perfectly tailor it to the infrastructure. Depending on how you have your cluster and infrastructure set up, we can do the right thing. And this is all just built off of like Kubernetes architecture and stuff. The beautiful thing is - because like one of the problems companies have in general is like something like upgrading Kubernetes is difficult. And because when you upgrade Kubernetes, you have to upgrade Kubernetes, plus all the components on Kubernetes, plus all the applications. And they're all linked together. 

Because your Helm chart that is for your app might have an Istio policy in there. Therefore, it has some implicit dependency on Istio. And if Istio changes, what's the impact on the application? It's like what we're doing in Acorn is we're making a very strong delineation between kind of the infrastructure side and like the application metadata side. 

And so, by making this strong delineation, we can completely separate out infrastructure that it becomes like we can upgrade it seamlessly. We can manage it. If you're on Kubernetes 125 or 128, it doesn't matter to like the Acorn user. And we can seamlessly change it all under the hood. 

Because like just adding that little bit of like structure of separating the two layers, it gives us all this flexibility. Because today, that's one of the problems with Kubernetes, is that like you're basically mixing kind of like application metadata and whatnot with infrastructure metadata. 

And so, it's all mixed together. And so, it just comes with problems. It's like when you try to upgrade the lower-level thing, it has this trickling impact. And so, that's some of the complexities people are having. 

[0:22:53] JMC: What's the feedback from the community and the months that it's been in alpha and beta? And now, in the last two weeks of general availab - 

[0:23:01] DS: I mean, we just launched like two weeks ago. The feedback has been great. the thing with Acorn is it's a little difficult in that like we show people Acorn. We're like this is the vision of Acorn and what we're doing with it or whatever. And they're like, "That's great. I want to use it now. Is it ready for production?" 

It took us a while to like get to a point where it's like - because people have immediate needs for this, this solution. It's like we can't just give them like a beta something where like - the bar is really high in terms of a product we have to deliver. Normally, the way we've always done startups, like we'll work on something for a month or two and we'll throw it out there and get some feedback. But like we had to put a lot more effort into building a complete solid platform. 

And so, that's what we have, we've launched right now, is we have a pretty solid platform. And so, the feedback has been great. But it's kind of like we are just starting though. Because normally, within like - I was saying like we would like spend like two to three months to get something out there to get feedback or whatnot. It took us more like a year. Because it had to be this real solid platform. 

But now we're at the point where it's like, "Okay, we really want to start getting the users getting feedback." Because there's a lot of cool things that like where we're going with this platform. 

[0:24:04] JMC: Any immediate requests that you've gone, like, "Hmm. Yeah, that sounds interesting. I'll explore it." Something. Any immediate insights from the community so far? 

[0:24:13] DS: Well, there are different areas. One of them has been - the interesting thing has been this idea of kind of like - with Acorn, you can run your containers. But one of the big problems is like, "Okay. Well, how do I get a service?" My application needs a database. I need RDS. How do I provision that? 

And you don't want people going back to like falling back to Terraform or whatever. Because that gets kind of more into the infrastructure realm of like it's like how can the application teams be more like self-service of like I just want a database? 

And so, we built out a very nice framework where you can basically plug in any service. I can launch and I can just in the Acorn file say like I want an RDS database. And it will give you the database. We created a service. It's kind of like a service brokering. It's a very lightweight version of service brokering. 

From the Acorn file, you can say like, "I want this database." But one of the requests that's come is like people actually want a - it's kind of like a more standardized interface of like instead of saying I want RDS or I want this cloud-hosted service, they just say - they want to be able to say like I just want MySQL. 

And then at runtime I'll get like whatever is the best version of it based on whatever - some other configuration or criteria. Basically, when I run this application in the development, I can use the low-cost, simple, just run a MySQL container. Because that's cheaper and faster. Whereas when I move to test, I want to use like the RDS, more mimic production whatever. But I still want to use the serverless version because it's cheaper. But then when I go to production, I want to use Aurora Cluster. Right? that's one of the interesting feedbacks we've gotten is like building up more of a concrete - it's kind of like a service interface of like - 

[0:25:45] JMC: Yeah. Yeah. I see what you mean.

[0:25:47] DS: Because it's like I want this service - because it's like at the end of the day it's like I want Redis, Mongo, MariaDB. These common persistent services. But there's a lot of different ways to get those and there's a lot of ways to manage them. Can I have a common interface? And then depending on the environment, I get the Azure version, or I get the AWS version, or I get the - that's one of the feedback. One interesting thing that we're working on right now.

[0:26:08] JMC: How is the road map being built in the sense that how is Acorn and yourself balancing the community feedback versus your own vision? Do you have a very strong opinionated way? Are you actually casting the widest net possible right now and capturing everything so that it informs fully your roadmap, which is empty of any own vision? 

[0:26:34] DS: You're saying like your vision or your opinion. Fundamentally, the things that have been like successful with, say, Rancher, or K3S, or things like projects that I've done, it does actually come down to our opinion. A lot of it was just like our opinion on - but our vision is not so much on necessarily the problems we're solving. Or exactly, it's like the opinion comes in like how we solve the problem that the user is presenting. 

[0:26:59] JMC: Yeah, the experience. Right. The developer experience.

[0:27:01] DS: How do we - our roadmap or whatever. It's like it's completely user-driven. And right now, we're very much just focused on users. Not like enterprise big deals, sales or whatever. It's like we really much want like the average developer user. Not so much - I don't want to go directly to like the enterprise IT right now and sell it to them. Because they have very specific requirements to optimize their cost or whatever. 

And it's like I want to make sure we build a platform that really caters more towards the application developer. And so, our road map is completely based off of like putting this in front of them and saying like, "Hey, look. We think this is better. Try it out." And if I see them struggle, or they don't like it, or they can't accomplish it, then it's like, "Okay." Then we just completely go off of that.

And so, that's where we are right now, is we've built this online experience. You can run it open source. I think it's more difficult for you to get up and running with open source because you have to know Kubernetes. I do prefer people to go to the SaaS version because you can get into it immediately. But try it out. And if it doesn't work - that's what I want to hear. I want to hear like from people like if it doesn't work. Or if they don't think - the worst thing that you can tell me, the biggest failure to me is like I tried to use it and it was confusing. It's like if it's confusing, then we failed. I want to build a system that's like intuitive, and simple and makes sense to that application persona, which I know they fundamentally think different than an infrastructure team. 

[0:28:16] JMC: Yeah. Would it run in a con cluster, which by definition is quite easy to install? Would it defeat the purpose of it running in a proper Kubernetes cluster? 

[0:28:26] DS: No. No. It doesn't at all. It's very easy. If you want to do the open-source route or whatever, you can just download the CLI. You just type Acorn. Install. It'll install. We have different guides on dealing with the nuanced indifferences between different like kind, or Docker desktop, or what - that's the problem of like with the kind of the Kubernetes, is like there's no kind of standard base for Kubernetes. 

And it's to the point that like this was actually one of the successes of K3S, is that K3S was like it wasn't just a Kubernetes distribution. But it also had a lot of like kind of batteries included components of like it gave you an ingress controller, and a storage solution, and a - and we made sure that all the APIs work. That doesn't exist across the board. 

For example, if I use KinD today, I'm pretty sure there's no ingress controller by default. We fundamentally need an ingress controller because you want to expose HTTP. It's like there are little instructions of it. Run this command to itself. That's kind of the bummer thing about the Kubernetes ecosystem, is that like even though you can easily run it on your laptop, no one is the same. Docker desktop, K3D, Minikube, KinD. They're all slightly different. 

And then it's like also, as I was saying before, it's like if I'm an app developer, I really don't care that much about Kubernetes and don't want to specifically learn it. That was a big barrier to us of like when we open source. We open source run time last year. It's like I want to make this much better for app teams or whatever. But if they have to first install it and run it on Kubernetes themselves just to try it out, that doesn't make any sense. It's like, first, be an expert in Kubernetes and go through the hell of understanding like - it's like, "Oh, why is my DNS not resolving?" And it's like, "Oh, because this stupid - flip that setting this way." That was one of the key things of like to drive the adoption why we built like the SaaS of I just want to give people the full experience, the ideal experience out of the box. But under the hood, it's all Kubernetes and it will run anywhere. It can go on Edge or whatever. And because it's open source, we can just do it like kind of package the solutions in a lot of different ways.

[0:30:12] JMC: I don't want to put you in an awkward spot. Because I'm guessing that since you mentioned before that you will be - Acorn will be present at AWS Reinvent, which is happening I think in two weeks' time. I'll be there too. But can you give us a hint of what's going to be announced there? Is it possible? 

[0:30:30] DS: I mean, an AWS crowd is pretty obvious or whatever. We're doing a little bit. We'll be doing some Lambda integration to show that. Because Lambda's a big - I'm not actually 100% sold on Lambda. But we did a really cool - we've done a really cool integration with Lambda to try to make that development experience better. 

Because one of the big problems of Lambda in AWS is the development experience. It's very hard. But it's really cool from a runtime perspective. We've done some like interesting things there. But then, also, for the AWS crowd, it's really just like showing, "Look, we can run this on EKS clusters." 

It's like we have native EKS support. And so with our product offering, we will fully manage all the EKS clusters for you. It's like the Kubernetes layer becomes like just completely turnkey. Because the beautiful thing is like once you standardize on Acorn, like the infrastructure layer becomes very predictable. Extremely predictable. 

It's like the clusters we run, they're fully autoscaling. The user - we have an abstraction that allows the users to kind of say what different class of infrastructure they want. If you want like compute optimize, or memory optimize, or GPU, we have an abstraction in Acorn to allow the users. And then we just auto-scale all the node groups and stuff like that. 

It's like we basically make the EKS stuff - we make it very easy. And there's nothing easy about EKS. It's a great product. But there's nothing easy about EKS. 

[0:31:47] JMC: I'll let you know that Docker is coming back hopefully to CNCF soon to have a booth. 

[0:31:53] DS: Oh, wow. That would be exciting.

[0:31:54] JMC: Yeah. Because Acorn certainly sounds like you guys are taking the step forward in the experience that Docker laid out years ago. And feels like very, very interesting. I wish you the best as a company. And yeah, hope to see you soon. And I would like to thank you for being on the show twice in less than an hour. And hopefully, you can forgive me for that. But yeah, Acorn seems like a very, very interesting product. 

If anyone wants to reach out to you, by the way, where can they find you? 

[0:32:24] DS: Well, me personally, I'm on Twitter. That's pretty much. I build the cloud on Twitter. That's where you can find me. And then company-wise, acorn.io. That's the best. And then we're all of our stuff's on - 

[0:32:35] JMC: The demo is right there. Right? 

[0:32:36] DS: Yeah. If you go to acorn.io, you just need a GitHub. It's free. You can go in. I mean, the product we give away. We have a sandbox environment where you can just try out Acorn. You can run anything you want. It'll be there for two hours then we delete it. There's no credit card sign-up. You can try it out. 

[0:32:51] JMC: And that's Kubernetes cluster with a runtime installer. Right? 

[0:32:54] DS: Yeah. You don't need to know absolutely anything about Kubernetes. You can just basically start. And then we have this really cool feature in the app that's called Playground, which have you ever seen like a Go Lang playground or like - we have a thing like that where it's like online. You can actually create, put in an acorn file and it will build the application in public. You can kind of fool around with the Acorn file and it automatically builds it and runs the application. 

You can just fool around with that and then you get a URL and you can click. And so, it's kind of fun to fool around with and just get an idea of what's capable with the system.

[0:33:25] JMC: Well, I encourage everyone that's listening to this to either reach out to Darren if needed or mostly to play around in the playground with Acorn. Because it seems like a very, very nifty idea that I would argue sits upon not only a ton of experience from the founders like Darren just described, but also solid ideas of - solid descriptions of the gaps that right now developers are experiencing. Because I would argue so too that many, many are complaining about the complexities of Kubernetes. And I think there's a huge, huge opportunity there. 

Yeah. Again, I wish you the best. And thank you so much. 

[0:33:58] DS: Yeah, thank you. It was fun.

[END]