How can slim.ai help you create production-ready containers quickly? I speak with CEO, John Amaral to find out how.

Transcript

Chris Ward 0:02
Welcome to another chinchilla squeaks. If you’re joining for the first time, I have changed the name of the show recently, I just realized you also need to change the name of the problem. When you change the name of something, you suddenly notice all the places you need to change the name. Being a busy week of interviews most because of cube con, which was last week, but it takes a while for me to catch up. And today is no exception. I think you might be my one. Oh, I have a couple more in next few weeks. But my guest today is john ammeraal of slim AI. So hello. How you doing? Job? Good, Chris. Thanks for having me. So slim AI v the tagline is developer tools to help create production ready containers? Quickly? What is what is what does that mean? What’s let’s let’s begin with Firstly, you know, what, what is some what is the developer trying to do? That they cannot do right now effectively that slim AI helps?

John Amaral 1:04
Sure. Well, in, in the age of cloud, native software creation, development, deployment, etc, right, we we first, you know, assume that, you know, Kubernetes is the sort of cloud native operating system and containers are the unit of software these days. Meaning that, in that scenario, developers are writing code like I always have, which power the application and then at some point, they render that code into the form of a container. And then sets of containers become services, and then services become applications, and, and so on. And then that process of going from the code that I wrote, I’m a developer, I’m expert at that, and how we have been to putting those bits inside of a Docker container and then shipping it off into the production environment. Well, that goes along quite a journey, create, build, deploy, run in basic terms, and somewhere along the line, you’re interacting with the folks, the DevOps folks, the SRS, etc, whose job it is, is to know everything about that infrastructure, maybe less about the app that the developer builds and, and Firstly, the developer knows everything about the app, and they know less about the infrastructure. And that infrastructure is, you know, increasingly complex, making containers that are trivial, it’s pretty easy to make a Docker file, you put some code in a container, and it just runs typically in your environment. But there’s chapter and verse in our industry about container best practices. And they typically talk about activities around building containers that are smaller and more secure, where you have control of what codes inside that dependencies aren’t going to creep in, changes in dependencies aren’t going to creep in and disrupt the integrity of that container, everything from worrying about software supply chain, and what’s in your container to Well, let’s not run things in production that shouldn’t be there, because they will run faster, they’ll deploy faster, etc. So the idea of production ready containers is really how well can an organization’s developers produce an output that is ready to run under those criteria. It’s small, I understand the software, etc. And that’s really the the bit about production ready containers.

Chris Ward 3:13
Okay. And so under the hood of all of this seems to be just found on GitHub is Docker slim, seems to be the foundation. So what is going on? I mean, this is open source. So I guess we can talk about it, what’s going on there? What is?

John Amaral 3:31
Great question. And it’s really the genesis of at the heart of the genesis of our company. So myself and my co founder, Kyle quest set about the journey to build his company, like about a year ago. And, but but prior to that we’ve worked together as, as co executives, and leaders, and architects and technologists at several companies building very large SAS properties, and quite successful ventures together. And, and Kyle is as insatiable optimizer meaning that he, he loves to make his developers work better. And when we are, we call ourselves a developer for his company, it’s all about making the devs successful and really passionate about that. And several years ago, he he was encountering a conundrum in the development of his own work. And as developers work, which was developers were spending more and more time in his organization, producing working in these sort of DevOps, I’d say workstreams you know, the bits about making their stuff run and the infrastructure right. And, and that, you know, we have DevOps engineers, of course, that’s all good, but but he was finding more and more difficulty doing the production ready container. Things that I was talking about earlier, developers just didn’t have the capabilities. They didn’t have the know how they didn’t want to do it, etc. So he said about building a tool called Docker slim and one of the problems was basically Clearly made containers smaller and more secure for all the reasons I mentioned earlier. So he had an idea about how he might be able to do that. Our history is we worked in a lot of very large security software companies and building these big SAS projects. And he, he imagined using some of the techniques that he learned as a as a serious software security technologist. He employed this idea that if I insecurity, we want to know, all the bad parts of software that’s in that’s running somewhere, find the bad stuff, right? The minute I look at this from the app, location, composition perspective, what if I could turn that technology around, like the ideas and and find all the parts of a container that should be there, but none of the other stuff. So use that lens created a hackathon project I think it was for one of the Docker cons if I remember correctly, and and he was able to produce Docker Slim’s you know, basically the genesis of Dockers in its first code. And basically, it’s pretty simple. You have a container as an input, it’s an arbitrary container, say it’s a container, that’s one gig in size, we call it the fat container, right? And, and Docker slim, takes that container and analyzes it both statically and dynamically, which is means it sort of analyzes everything that’s inside it, and then it runs it and watches it run. And, and when it’s turned on, it allows a developer to stimulate it with arbitrary tests, it has a mechanism for doing that, and it runs it in the Docker daemon, etc. When it’s done doing those observations, it, it can produce a number of very insightful artifacts, like a report about exactly what was running in that container or report about the bits that it thinks you need to run that container. And it can also output a, a, another container, which is, is the functional set that it found to be necessary for it to run minus all the things it didn’t like about it, it reorganizes the container, it produces a new output container. And it’s very successful at producing minimized output containers that are functionally the same as the input container. And it does that by observing what code needs to run in there, and files etc. And so he has continued to evolve that project diligently forever. And again, it sort of back, you know, a year ago or so, we were talking about it, you know, we’ve of course, have worked together a lot and are very friendly. And we said, you know, this is interesting, and, and aside on that is, it’s got, you know, more than 10,000 stars, it’s got more than 200,000 downloads, we think there’s, you know, 10s of 1000s of people who have and are still using it. So it’s become a very popular tool for developers who, who need to make their containers smaller, faster, and more secure. And the security commentary, it can produce automatically a set comp and app armor profile. So you don’t have to go through and make the whitelist yourself. People find that convenient. Say you have vulnerabilities in a container, like it’s not typical for base images you find to have hundreds of vulnerabilities. Oftentimes, we run it through the system, app plus container, check it,

reduce it produce an output, check them on our abilities, they’re oftentimes 10 or 100 times less than the input because a lot of the vulnerabilities are found in files you don’t even need. And so this tool is become a really streamlining component and folks workflows who have adopted it, to, to get them to not have to do the grunt work really, of, of hand minimizing it’s, you know, say you have a vulnerability in a file, you go and look at that file, that file is, you know, some some, you know, arbitrary name, you don’t know what part of the OS it’s from, you don’t know if you actually need it, developers struggle with the with this, I’d call it infrastructure centric parts of their job, which are how to make their container smaller. So that’s what it is. And it became the sort of Genesis or nucleus tack that we started the business on the business has a much bigger vision than this, but it is a piece of the puzzle for us. And it’s a very successful piece of the puzzle.

Chris Ward 9:12
It reminds me in some respects, there used to be more in the past. The Docker image kind of analyzes where it would show you all the bits and all the dependencies, were part of it but does something smarter with it.

John Amaral 9:27
There are lots of great singular tools out there that do that. And and Docker slim has some capabilities like that to kind of show you what’s going on. Yeah. Yeah, that that’s, you know, we’ve we’re trying to not only give you a toolings for observation and an analysis, but then also give you these automatic outcomes that saved a lot of time.

Chris Ward 9:48
Some of the results you list here, or the repository list here are quite amazing. It seems that Ubuntu is particularly guilty, which will make sense there’s a lot of other stuff included in there. For 132 megabytes to 14. And then you get things like Alpine which have been intentionally developed to be slim 66 to 34. Which, I mean, it’s still not bad. But of course, it starts much smaller.

John Amaral 10:16
There’s an interesting, there’s an interesting thing we’ve learned recently, as we, as we watch developer behavior, and and what they want. And again, I categorize this as a developer first company really focused on making life great for developers less friction, you brought up a boon to an Alpine right. And I think there’s an interesting philosophical shift that can happen when you when you think about making some of these, these these optimizations more automatic, Alpine, the both of these are great operating systems and, and, and are really good at what they’re for. I think the interesting thing that we’ve we’ve learned is that developers want low friction and fast, you know, highly agile development. And that means like, using the tools, they want, that we don’t intend to change anybody’s workflow with this with our with our strategy for our business, it’s really about, you know, helping developers work the way they want to work to give them outcomes, they would have to do a lot more work to get Ubuntu, for instance, is interesting. And it’s a fabulously good operating system for developers, right? It’s, it’s a great tool, a great operating system for building these kind of building apps fast getting them to be highly performant and getting them to be highly. With high integrity. developers who use the Docker slim ideas would rather start with a fat operating system than a small operating system, the beginning because that’s what they want. Yeah, when you when you start with something, a base image, it’s really small, you have as you develop on it, and you change the composition of the app, you oftentimes find there are things missing in the operating system that you need, as a foundation for your app. So So this idea of I curate the smallest possible base image by hand, initially, I add the bits I want, usually turns into the developer has a break fix cycle to reconcile they, they will have to, like, add the dependencies they need. And oftentimes, the breaks are not simple. It’s the operating system piece you didn’t understand you need it in the first place. So start with a one to an operating system I love and then add your app, and then use a tool like Docker slim, to turn that into something very small, start big and then winnow down. Yeah. tends to make developers go faster. Yeah, I mean, that’s the cool thing.

Chris Ward 12:37
Yeah, I have a tendency to do the same thing. When I’m kind of messing around with things you just kind of chucked dependencies left, right and center, like oh, worry about it later, worry about it later. And then you start to optimize.

John Amaral 12:49
That’s right. And, and, and what precisely the pattern that Kyle was trying to address with designing this tool, which is let developers do what they love, what they want, the way they love, and then take all the friction out of having them get to an output that the DevOps and infrastructure folks will love as well. So it’s kind of like a best of both worlds.

Chris Ward 13:07
So let’s focus on simpler AI, then, what does your What does? Or what will I get the impression that might be the bigger the more of the question slim.ai, add to, to takistan. Because at the moment, I go to the website, it says get the app, it takes me to the hub repository. So what’s coming next? What’s the next

John Amaral 13:26
thing? Yeah, great question. So we are, we’re building upon a vision for creating even more capabilities, workflow tooling, that will help developers along this journey to building and producing and deploying, you know, these these awesome containers, right, and sets of containers as apps. And as we’ve, and we are an open source fruits company. So I wouldn’t call us per se, an open source company we are, we are a software company that has open source software as an important part of its of its portfolio. We’re in the process right now, building a broader platform, a sass platform, it’s actually in private beta. So it’s invitation only beta. And, and, and it’s Its job is to is to sort of make it simpler for developers to interact with containers wherever they are. And so there are a lot of use cases that live around the around this theme, which is, as a developer, I need to understand and find containers that are best suited for me to start my app and the starting points for those containers where they lived. Before I I sort of decided to they’re the ones I want could be in public in public repositories, like on Docker Hub, which has, you know, the world’s containers on it, especially the lots of the public starting points. And and then it could be inside of my our company’s repos that are maybe on Amazon ECR, etc. I’ve got to kind of know where everything is today. The repos are desperate. Oftentimes, developers lack tools To go and seek those containers, and to easily understand what’s inside them, to be able to record that organized containers, what I’m describing is really, you know, if I use common kind of references, think of an idea of a system that can can touch everywhere containers are produced and can live, it’s sort of like a, like a sass platform that can reach in touch, Google, Amazon, etc. And, and it can also give you inline processing that allows you to interact and optimize containers as you as you seek them. So one, one part of our platform is this almost Google Search like capability for containers, I can go to the command line and say, view j s, and it will search everywhere you you’d like to look for a container, it automatically analyzes the container for you, when you search, it produces a very complete view of that container, what’s inside it, observations about it, what are the software operating systems, and then from that, you can organize that container into sets with other containers. And now you can use that as a as a sort of a management plane for for controlling, optimizing, etc, those containers. So, really, what we’ve noticed is, there’s a lot of manual bookkeeping, manual effort, complex infrastructure to get to what I just described, we want to simplify that for you. And of course, one of the capabilities will be this optimization opportunity that we already have with targets.

Chris Ward 16:35
So I found a couple of blog posts that sort of illustrate what you’re aiming for here. So one of the things actually that intrigued me was you’re talking about container best practices. So is this gonna be almost like container linting, or something like that?

John Amaral 16:53
That’s that’s part of it. Actually, the actually the Docker slim tool has a kind of emergent, call it a very early form of linting. And it actually, it has several, several core functional sets. One is this optimization thing I described earlier. It also has a command button called X ray, which is a very good container internals analysis tool. And by the way, these core capabilities are some of the basis for the underlying processing in our in our, in our I’ll call it SAS platform, and, and then it has a rudimentary linter that we expected to build out more of, and that will allow you to like really assess the composition of a container and give you recommendations in the long run. It’s not quite up to that today. But it’s an emergent feature. It has some profiling capabilities as well. So yes, the answer is, we want to be a tool that has a lot of generic insights that it generates on your behalf. So rather than just giving you analysis and you make a decision, we want to have those, those best practices, objectives in mind have an opinionated system that says, hey, by the way, I see what you have there. You can do better. And, and here’s how and if you want, he was a tool that helps you Yeah, and be sort of the big the the the sort of benevolent uncle for every container all the time. So for instance, we want to be that friend that says, hey, by the way, I saw that you, you didn’t reference that container quite right. And you’re likely to get a dependency problem. If, if that persists, you might want to change the reference in the in the in the Docker file to this or we might change it for you, and so on. So we’re, we’ve always got your back on making containers better, even when externalities affect the future benefit of that of those of that software, which means the developer has to think a lot less about, you know, like, what if risks and long term?

Chris Ward 18:45
Yeah, yeah. And then one of the other parts I see, which I think is something that you covered already was here, the ability to sort of search across multiple repositories, or sources or containers to find ones that I suppose slim AI, recommends, I guess, is kind of the principle there.

John Amaral 19:11
Possibly, yeah, we do intend to in our current form of our of our private beta, we have these, what we call collections, we’re going to find a better name for them. But it’s basically starting point sets where we say, Hey, if you’re thinking about building a web app, this might be a good place for you to start, because we know other people have had success doing that. And we’ve analyzed those containers and they seem seem good. But we also give you free, you know, the, the freedom to explore, it’s actually more discovery than search because we do give you tools to make decisions for yourself pretty rapidly. So we want users to be able to seek from whatever source they like, that’s certainly something we were striving for. And the second is is to give them as much shortcuts or tooling as possible to help them go fast, and making those decisions. It’s pretty normal for DevOps in a in, I’d say a moderately, you know, advanced organization. It’s often true that there are sets of developers and DevOps folks whose job it is, is to kind of figure out what the right starting points are. For any new app we build on containers, we want to make that super simple for people. Because we know that that’s a lot of difficult work, it could be easier.

Chris Ward 20:23
It’s interesting, because in the interface that you present in some parts here, like the overview of different images, reminds me a little of I don’t know, if you remember, kite Matic, which used to be the kind of unofficial it was kite Matic, the unofficial, like Docker, gooey for developers, that kind of got acquired by Google and then rolled into the kind of now dashboard, they have Docker desktop. But it lost a few things on the way that kite Matic used to have. I actually have to go seek it. Now I want to go. It’s basically folded into Docker desktop, but a few features got lost on the way which are kind of what some of what you have a little here bizarre.

John Amaral 21:09
I guess I imitation is the greatest form of flattery. I yeah, we haven’t seen that. But you know, we, there are lots of lots of analogs, you know, we because we’ve, you know, we’ve got great, I’ve got gray hair, and we’ve watched to look at a lot of tools over the years, you know, you can’t help but, but emulate the battle. For sure, there was I think, a tool from our CTO, Kyle, who’s, you know, far greater guru with all this today. Um, he, he references an old tool he used many years ago from Norton, which was I think Norton commit, I forget the name of it, but it was a tool, basically, that you could look at everything on your operating system, and it had he references as a pretty cool example of a easy, you know, for a developer and easy to use interface. And so, I think, you know, we, we do a lot of user testing, and I really just goal is to find something that, you know, users can navigate through quickly, developers can navigate through quickly and feels familiar. So yeah, you know, the there’s only so many ways to make an explorer. But yeah, I love to see what you’re talking about.

Chris Ward 22:10
I don’t think it exists anymore. So you are not? I don’t know, you’ve got me. Intrigued now. Still? Oh, actually, the website still exists. But it now part of the Docker toolbox? No, got it you possibly still fighting? Back in the Time Machine and see if I could find it. Yeah. And then I suppose the most important part of this that relates to what semis is bringing is the Explorer, partly, you can see how the container is built, which alludes to what I said earlier about some of these analysis tools that you used to get the different layers and things like that. But and then this x ray pass, so this, this x ray thing is kind of intriguing, it’s kind of hard to see as well, because there can be potentially so much. My screen shows you how much detail there is, right? So what is showing it it’s visualizing the entire container build in it, you know what I can do? I always forget, I can actually do this, especially for the video. People, I’m actually Oh, and I have it open in a different browser, forget about that. But there’s a there’s a blog post link that people can find. And there’s the X ray. So you explain what that is, because you’ve mentioned it a couple of times. And I’m trying to understand quite, I suppose more how it helps developers,

John Amaral 23:39
right? The way if you’re a developer seeking to understand or debug container, and these are two pretty common patterns that developers have to follow one is I in the container best practices, right? The literally, if you distill the 10 or so documents that exist out there from from all the major cloud providers, etc, you would find that early on, and those documents would say, understand your public container, right? So that’s really a discovery problem, right? And what you need to do when they mean understand it, they don’t mean necessarily understand how it would function. They mean understand, like, how it’s made and built, because the composition of a container has lots to do with how well it caches, for instance, or how fast it is, at when you make any code change to rebuild that container. You know, how the layers are organized? Are there any licensing bits in there that you might not want?

Chris Ward 24:36
To forget about actually, this is right.

John Amaral 24:37
Yeah. Does it have the tools you need? Like does it have bash? Does it have package manager? Does it have the right versions of software in there? It’s, it’s, you know, containers make it really easy because of their portability and their admin city to just get running. Right. But But basically, you know, software lifecycle required, you know, best practices require that you really Understand your software, which is fun. So, so this tool, our goal is to make that job really easy and fast, you want quick insight and rapid decision making opportunity. So in our and as some of the references that are out, there aren’t even our latest version of this, these analysis tool suite. But but X ray at its basic provides this this raw and analytic framework for understanding in detail what these containers are. And then in our platform that we’re that we’re beta with, we take that that insight and we distill it into, and we take that that knowledge, the details of the container and how it’s built. And we turn it into insights that a developer can rapidly understand. For instance, one is a simple just what operating system am I talking about here? And it’s not always easy to do that by just looking at a Docker file. It also what are the dependencies in here? What are the environment variables in here? What are the layers, what’s in those layers? Can I search them, for instance, in our latest version of the Explorer, you can see this new view that gives you almost like free text search capability inside the container. So you can say license at the command line, and get a listing of all the licenses. And so what we hear from users we do a lot of user testing is it’s the fastest way they’ve seen to grok a container to really get to know it quickly. And that helps in if you’re evaluating a dozen different containers, you can really cut down workload to do that. And when we see others using it, which I’ve used myself and I are developers do and others is what happens if something changes with a dependency in a container, etc. And that container is broken, how easily can you compare it to its predecessor container and make a distinction about what changed? Miss change insight is an important part of the feature set that we’re developing, which is, you know, I’ve got a broken container, the old version work this one doesn’t. I don’t know what changed, helped me. That’s another another goal of this x ray capability.

Chris Ward 26:59
And See also adding command line interface which makes perfect sense. And that’s good to see. The other thing that intrigues me. Yeah, exactly. The command line, it’s important. When you’re sending an API, what kind of uses are you expecting people to use the API to the various features you offer for?

John Amaral 27:23
Sure part of this, I mentioned earlier that we want to be a platform that can extend and being engaged with any system you have that, that that handles or produces or records containers. So part of the slim.ai developer platform is this is this capability to interact with, say, for instance, ci CD systems, ci CD systems produce containers, that’s an output, we want that we want interact with that. So you could either do that through basically, what we what you do is use a bar API’s to interact with, with these containers, with with your ci CD system, and it can record containers in our system, or send them to us or take them or retrieve return containers through that mean. So effectively, it’s an interface that allows developers to integrate our functions or capabilities with anything they want. We’re actually in process of building a, what I call an epi agent, which is, which is a piece of software that will you know, will give the code away to or or, you know, personally share freely. And, and that will allow developers to then use that abstraction to interact, but the API’s are really there for integration purposes. And

Chris Ward 28:33
it actually earlier that we are going one, one thing I noticed in the UI that potentially I suppose comes out the API as well and starts to make this make a lot more sense is you can actually, as far as I could see, you could output an optimized Docker file from the process. So you kind of feed all your inputs in, use the CIC D pipeline to actually then get like the final Docker image that goes

John Amaral 28:54
to the final Docker image. That’s exactly the workflow we see users doing they, they have their ci CD producing containers the way they always have. But they end up with a container that that they wanted them act on, understand, optimize view, check differences, etc, they’ll, they’ll pipe that to us. And one way you can do that is to pipe it to our cloud through our API’s. And then we optimize it, we record what we learned and now you can use all of our tools, the software tools that we have, and and then we return the container back to the CI CD system. There are ways you could do it in line to with our, with some with some of our downloadable software. But but then you go about your business of now. vulnerability, scanning that container, testing that container, and can smaller containers are faster to scan VMs. So you speed up your ci CD time, and all that and that helps developers go faster as well. I should have mentioned earlier that you know we were still in a phase of our of our, of our, of our development of our life cycle where we are trying interacting with people But now closely to evolve our features. We don’t have anything for sale yet, we’re still in, in free software mode and, and, and evaluation mode, I call it you know, beta phase, we will, we will have, in our, in our future always have free open source software that will continue to maintain, we expect to have a free tier SAS software that folks can use with the free open source together and get continuous value from. And then our goal in the future is to have, you know, obviously, commercial software, but that is, you know, that, you know, developers can will, will benefit as they as they grow their value from us. So we really want to make sure we’re building software that developers can just use and benefit from.

Chris Ward 30:50
And so when do you think the SAS offering will be an initial release? What sort of timeline

John Amaral 30:57
we’re expecting to get to what I’d call a sort of a public open beta? You know, this summer? So that’s probably, yeah, it’s, you know, something like that. We’re pretty pragmatic, you know, we, it’s sort of like, you know, when it’s good enough when you see it, right, and, and we’re continuing to work that way. We’re very, you know, we don’t, we want we want to build something developers love and we’re really ardently committed to that. So it’s more developers that interact with us and the more love we can give them and, and just learn from them. The more I think we’ll build stuff that that works, and so far, so good with Docker slim, it’s really popular people love it. And, and we get a lot of great feedback and that community has been wonderful to us to help us.

Chris Ward 31:45
Excellent. JOHN Amaral of slim AI, and unsurprisingly, you can find more@slim.ai Thanks very much for joining me.

John Amaral 31:55
Really appreciate your time. Thanks for the opportunity to join