Swapnil Bhartiya: Hi, this is your host Swapnil Bhartiya and welcome to another episode of Let’s Talk About Kubernetes. And this is a special series for KubeCon and my next guest is once again, John Amaral, co-founder and CEO of Slim.AI. John it’s good to have you back on the show.

John Amaral: Swap I’m so happy to be back from KubeCon. It’s exciting.

Swapnil Bhartiya: Let’s talk about Slim.AI, what do you folks do from the perspective of container optimization?
John Amaral: Slim.AI offers solutions that automatically optimize the composition construction of containers. We also provide a unique set of tools that allow developers to understand what’s inside their containers, how they’re built, what metadata is in there, what settings are there. It gives some deep insights about that and how the containers relate to the application they’re building. With our tools, developers can help make their container size better, perform better, lower their costs, security, deployment times, et cetera. So, the idea is can we get to container best practices that make production great containers easy, but from a developer’s desk looking out so, rather than doing it after the fact we’d like to make containers better earlier and our users tend to find that it’s possible with Slim.

Swapnil Bhartiya: Can you also talk about what was the driver behind starting Slim? Because you’ve co-founded the company, you’ve just kind of touched upon the container optimization but you saw a serious problem. You were like “hey, this has to be solved and to an extent that I need to start a company.”

John Amaral: That’s right. Myself and my co-founder Kyle Quest, we’ve been working together for many, many years in various companies and been responsible for product development teams, very large development teams, hundreds two thousands of engineers in the past… big operations. We saw over time the complexity for developers to build Cloud Native apps kind of continue to go up as more technologies came to bear, as they had to go from traditional methods into containerized software delivery. The tools and knowledge they need to build apps that are ready to run in prod became more difficult and with the responsibility shifting toward them to build things that are ready to run, we found there was a gap there. Our own engineers were suffering those problems, where they could write code like they used to, but now getting that code to run into various environmental constructs with infrastructure becoming more and more complex and more difficult. The role of the engineers become harder in delivering on the software they write at their desk into the infrastructure.

So, we wanted to build a company to kind of fill that gap and make developer experience for containerized apps awesome for developers, because we knew our developers were struggling to do that. My co-founder Kyle, invented an open source project called DockerSlim to kind address some of the things he was facing for himself and his team with building prod ready containers. DockerSlim became very popular, has more than 11,000 stars on GitHub, it’s been downloaded 350,000 times. Tens of thousands of developers use it to make building smaller, cheaper, more secure containers easily. They don’t have to be infrastructure experts, they don’t have to be container experts. They build the software they want using the container they want, but then this tool helps them understand and optimize it without a lot of heavy lifting on their part. That became the understanding that we got about… wow developers need this stuff and they like it. So let’s see if we can find a broader opportunity and we did, and that’s how we founded the company.

Swapnil Bhartiya: Excellent. Thanks for sharing the story and history of the company. Now let’s fast forward to the present, today you are at KubeCon. Tell us about your presence at the event. What are the things that you’ll be talking about? At the same time, what are the things that you’ll be gathering from the event?

John Amaral: Sure. We’re focused on a few things this week and certainly always at KubeCon it’s great to see the other vendors out there and understand the technology landscape. And it’s also great to talk to developers, that’s what I love to do. I still write code, I’m a developer myself. We’re building products for developers. Seeing lots of them here is really exciting and it’s great to be back in person. From a company focus perspective, we have two major things we’re doing this week. One is because we’ve got this great experience working with containers and we’ve got lots and lots of users using our containers, we’ve been gathering a lot of information about the state of the shelf for containers and we did a pretty cool study this week. We analyzed the top 100 most downloaded containers on Docker Hub.

And we did a pretty comprehensive analysis of our perspective on what we learned when we studied security perspective, compositional, how long it takes to scan them, how long it takes to build them. We did a whole bunch of quantitative analysis using tools we have and our core technology and some open source tools as well. And we learned a ton about what those containers look like and how they behave and how ready they are for production from a developer’s point of view. So if I’m a developer trying to build something with that container, what should I expect to know about that? And what are the experiences I’ll have? And, and we published a pretty nice report about that. We’re going to do a Twitch about it this week, but that’s available now and it’ll be on our website. We’ve got some really tremendous insights we want to share with the developer community, get their feedback.

The second part is, about three months ago, we released our SAS platform, developer experience platform. And we’ve had a lot of users on there now in our early access mode. And we’ve gotten a ton of feedback and we’d like to share what we’ve learned there and get folks to give us their feedback about that and start to get more people to understand and use it. And those are the two big objectives for us this week.

Swapnil Bhartiya: You do have some very strong opinions about certain things. And one is of course, shift left. You look at it from a totally different perspective. So I want to, once again, talk about what is your take on shift lab? And it also sometimes makes me feel that hey, the way most people are doing it, they’re doing it wrong. So how would you advise to do it right?

John Amaral: Well, I think that shift lab is like a double-edged sword and makes for the introduction, I think it’s excellent. So on one hand right? We know that when we put power in developer’s hands to make decisions, to have self-service, to be able to build things the right way, that creates good results for organizations because they understand the application they’re building the best, they understand how to make that application fit and, and produce the outcomes that the business needs. But at the same time they’re also facing challenges because as we continue to evolve the way we build Cloud Native applications, they have to learn a lot more. They have to learn about things like Kubernetes. They have to learn about things like infrastructure. They have to learn about things like containers.

So their job has become more complex and difficult. So when we take, for instance, I had an interesting example. One of the people that are close in our community with us told us the story about the transformation they made to containers and the struggles they had when they were taking their Python and our based analytical applications and going from passing code to the infrastructure DevOps people to passing containers. And what happened was in that transformation, the work to containerize the apps that were already existing became the duty of the engineers… the developers. Now there’s some big advantages to doing that, but there’s also some struggles developers face because more and more of their time gets distracted away from writing code that powers the app to becoming part and taking part in some new activities that are unrelated to that, but necessary.

So and what happens typically when you shift work like that left, you often forget to give developers tooling capabilities, understanding, and a frictionless experience as they have to take on more of those jobs. So you shift work left, you shift power left, but you often leave them without enough capability and tools and, and streamline workflows so they can do that quickly and easily without becoming experts. So my perspective is, if you’re going to shift left, you need to make sure that you empower developers with the right kind of capabilities to make that job not too much of a heavy lift, to lower friction. So I think one perspective I have is it should be… if you’re going to shift left, you need to remove friction. And we’re all about trying to do that for developers with a great developer experience in some of that work that continues to push toward them.

Swapnil Bhartiya: One more thing I want to talk up to you about and I’m kind of interested in your [inaudible 00:08:43] is that when we talk about [inaudible 00:08:46] we do talk about breaking down old silos of story, networking, all the different teams. But fast forward, and you were just mentioning that we should make it easy for developers but we have been trying to bridge all the gaps, we’re trying to build the DevSecOps, DevOps. So basically what we’re trying to do is that there are no silos, but we still actually have silos. We’ve created new silos, right? We talk about DevSecOps which is security teams that are totally different teams and then we talk about NetOps and all those things. So when we do talk about shift left, and we still have those silos. Talking about it on paper is something different, but actually implementing in organizations is totally different. So what do you see there? And what is your perspective on helping customers? Because no matter how much we talk about cultural shift, it’ll take time to actually make that shift happen in reality.

John Amaral: That’s right. It’s absolutely still a problem and it’s persisted and as you’ve mentioned, it tends to change shape right? You end up with one old silo, you break it down, you make it better. You create new technology, create a new silo. And these things tend to move around the organization. We feel a consistent pressure to move backwards from infrastructure towards the developers. An example of that is the work that’s happened over the years from the transformation, from bespoken infrastructure, infrastructure is a service making that programmable, which means you can push it more into the developer realm. Now, HashiCorp came along and other companies like them and created new patterns for how you program infrastructure. Now you’ve got a programmable nature, makes it more of a software problem, right? We continue to turn things into software problems.

One of the things that’s important when you do that is you create a fabric for being able to convey context about the work you’re do. I think that’s kind of a silo breaker in its own, right? It’s not enough for you to help developers build better applications, but it’s also important that you help them convey the essence of what they’re trying to accomplish so that other teams can work with them in a collaborative way. For instance, I’ve made this observation several times in my development teams. Developers know a lot about the apps and much less about the infrastructure typically in the modern silo world. Infrastructure and DevOps people know lots about the infrastructure and relatively, compared to developers, less about the app they’re trying to fit there. So you’ve got this kind of the problem of fitting an app to the infrastructure, this kind of back and forth that has to happen.

What we want to do is shorten that cycle so that when a developer codify how the app should work, they do it a way that’s easily conveyed through APIs and through a system that allows you to work from the same set of records. And today if you look at how apps are articulated, for instance, where you’ve got source code that lives in GitHub, you’ve got containers that live in registries, you’ve got somewhere in their tribal knowledge of how all those pieces fit together, somebody has to turn that into a Docker compose or a Helm chart to articulate how it should run. And then you’ve got the expression of the infrastructure. There’s no real good way to be able to associate all of that stuff in a way so that the handoff from Dev to Ops is simple. And I think we’re trying to bridge some of that gap with tooling that helps you build those relationships, codify those relationships so there are simple ways to convey through APIs and through a common framework.

And I think when in more… as developers solutions mature, they tend to get this connective tissue and I think we’re just early in some of these transformations. And the one of the complicating factors is that while our world is changing fast, you look at CNCF map of technologies, and it’s like new things coming all the time, and you come to a place like KubeCon and you learn something new every time. It’s hard to keep up with those technology transformations because they’re so quick. And I think we need to be able to provide some framework for keeping track of all this. And that’s part of what we’re on a mission to do.

Swapnil Bhartiya:Right. You touched upon so many point that I love, you talked about getting away from bespoke environments and then that is different than you have to also deal with the tribal knowledge and then creating technical debts. So if you look at the adoption of containers in the enterprise space, you still have all these problems there. Right? So as you also mentioned that in your KubeCon, so you’ll be talking to a lot of companies, you’ll be talking to partners as well, and you’ll be a lot of [inaudible 00:13:10] users as well. So one what are things that you will be looking at, especially to understand the problems of users so that of course you can help them in. So talk about the trends that you are kind of looking at together, more insights on these problem areas.

John Amaral: Yeah. You touched on I think an important concept. First of all, containerization is still accelerating, right? The use of containers as the basic unit of software and cloud native is happened and Docker and other formats have become ubiquitous in the De facto standards. I think of Kubernetes as the cloud native operating system that’s sort of winning the war as well and it is the place where these containers go to run. And I think if you look at the only interesting area that I’m hoping to understand more and we’re trying to put some focus on is this idea of how containers come together after they pass through the CI/CD pipeline to become something that you can run. So it’s interesting. I see a lot of teams struggle in that space.

There’s nothing equivalent to like GitHub in the post build artifact space of a development pipeline. So you’ve got GitHub, which has very well worn paths to being consistent and being manageable. You write code, you do a Pi, you do yml, you merge, you code, you pull a request, you review that. GitHub organizes the key components, it’s there. And then you build, right? And that’s been GitOps’ something that’s very well worn with developers. They understand it. They know how it works. As soon as those artifacts get built, there’s a zone between what’s built and what’s deployed where you kind of… the industry doesn’t have kind of a formal way or a well worn way to associate how the pieces come together to become an app, and can you manage it in a Git kind of model?

Is there such a thing as a pull request? Against the set of containers living in a registry, the artifacts that go along with it, there’s no one place to look. And so that zone’s a little hazy still. And I think the industry struggles with the bookkeeping, the accounting, the certainty, for instance, supply chain around containers, interesting problem. Right? You’ve got containers coming from all sorts of places that form together in your built fabric to become a new container, right? You build off a base image or did somebody do a Pi against that base image? To say, I approve that base image perfectly. It’s just these areas, that gray zone is not well organized. It’s not… there’s not a emerging singular pattern for doing management in the post artifact space. And I think there’s a lot of conversations going on in that area.

There’s a lot of trends. For instance, Google has kind of started to focus on their artifact registry, which has some bearing on that. You can keep… for instance, you can associate Helm charts with sets of containers. I mean, this is like a simple thing but it’s a very powerful concept. We want to do more of that. That’s a space we’re looking and I’d love to see what others are thinking there and see if standards emerge and also see what the top minds in the industry are thinking about how we can transform around that area.

Swapnil Bhartiya: John, thank you so much for taking time out today. And of course, talk about the event. I wish I was there. So it’s good, it’s kind of… seeing even from your eyes, those very early on, but thanks for sharing those insights about the trend that you’re seeing in the space and the problem areas that you are trying to solve. And as usual I am excited to have you back on the show and I look forward towards our next conversation. Thank you

John Amaral: Always a pleasure Swap, looking forward to keep calling as well. Wish you were here, maybe next time. And I look to more time with you in the future. Take care, have a great day.