Slim.AI CEO John Amaral explains what it will take to make building container applications simpler. The video and a transcript of the conversation are below.
Recorded Voice: This is Digital Anarchist.
Mike: Hey guys, thanks for the throw again. We’re here with John Amaral, who is the CEO for slim.ai. They have put together a new advisory board and they have a platform for implementing best practices, for building container applications using a SaaS platform. John, welcome to the show.
John Amaral: Hey, thanks a lot, Mike. Appreciate the opportunity to be here.
Mike: I’m afraid that you guys aren’t a household world just yet. So why don’t you take a couple and describe exactly what is it that you guys do to enable people to build out some best practices for building container applications?
John Amaral: I will. So slim.ai is a combination of an open-source and SaaS provider, of offerings that relate to optimizing, understanding, analyzing, and building better containers. I started with a project called DockerSlim, which is a pretty popular open-source project, hundreds of thousands of downloads, tens of thousands of users.
And what that allows you to do is users can download it, run it on their desktop, against their Docker desktop images, and it can tell them all sorts of things about how those are composed and it can actually shrink them. So it can remove stuff that’s not used by watching containers run, while they’re running, observe what software inside them is necessary, it removes the right stuff.
And we’ve got lots of developers who use that to make containers smaller and more secure. Less software equals more secure as a few other things it does. What we’ve done since the inception of the company slim.ai is build off of that technology and create a SaaS platform that is really all about developer tooling to give them better ability to understand, analyze and view what’s inside containers so they can make better choices about security, make better choices about composition.
And we’re evolving that to include automatic optimization and a bunch of other technologies that allow you to put your software in a container and create something that’s way better for production based on container best practices. Usually container best practices are all about understanding what’s inside of a container, making sure it’s only the software you need, securing it, removing vulnerabilities, and also making sure that it runs with the right kinds of properties and metadata and all that. So our tools allow users to do that easier and take some of the manual work out of that and build production, great containers faster.
Mike: Cool. What exactly does a best practice look like for building those applications? And I know you put together this advisory board, then that may still be something and a work in progress, but we have best practices for other frameworks. Is it different for container applications or what should people expect or be looking for?
John Amaral: Yeah, we have some good references in our blogs about this. And container best practices have been published by many of the companies related to infrastructure, infrastructure, the service, Docker, for instance. Most folks with the registry or infrastructure as a service, they’ve published, “Hey, these are the things you should watch out for to build containers that are ready for production.”
And usually includes things about security profile, composition, how the containers design, how the layers are. Really, it’s about building them that are less likely to run slowly, less likely to cost more meaning reducing costs in how they run, speeding up their path through CICD. Best practices address this end more.
And as I was mentioning earlier, it usually starts with five or six things in common if you look across all these different publications on container best practices. The first one is if you’re using a public container, understand the software that’s inside it so that you’re not inadvertently publishing something you shouldn’t be, maybe a bad license or so, open-source license or publishing something that is inherently insecure or opens up up your container to a greater risk service.
The second is minimize the software that’s in it. Well, it’s the core to the first one I just said. It’s like, know what’s in it and only shape the parts that you you need. The third is reduce the number of vulnerabilities in that container, which is easier said than done for most developers. I mean, it’s one thing to know of vulnerabilities there, but to know if you can remove it well, how would I remove it, by patching maybe, but sometimes you can’t patch.
So what do I do then? Do I port my software some other way? And so on. And it goes down to list things about, how do I structure my container so that it builds faster? All of these things that help developers have higher velocity in getting things to prod and make sure you have something secure and fast and cost-effective in prod.
We have an advisory board. Those guys are, and that’s the focus of I think this conversation. We’re a developer first company and on a mission to help developers build better cloud native software. We’ve selected from some of the industries who’s who on those topics. So we have a number of the board members who are experts at building communities for developers.
We have others that are experts at building software and building products that are designed for developers. And they help us shape our approach to building these products, to address the kinds of concerns we care about and our users care about.
Mike: We hear a lot about developers and people are trying to recruit developers with a more friendly environment for cloud native. What do you think is the challenge right now? We have millions of people who are developers, who are using containers, but we have millions more who are not. So what is the challenge with creating the developer experience for people in a way that attracts more developers or becomes more accessible?
John Amaral: Yeah. So, one thing we’ve observed, especially through the tens of thousands of folks using our DockerSlim product, and that is, developers I think, they don’t want tools, they want to be a carpenter. They want they want the capabilities. They don’t want a magic wand. They wanna be magicians.
So, I think a lot of the tools are just that, they’re tools that require developers to understand the subject matter that they’re operating in, in a way that is a heavy lift for lots of developers, ’cause there’s lots of new stuff cropping up all the time. The second is, many of them don’t take developer experience in mind to make those tools easy to apply to the way they work.
Lots of times developers have to kind of fit new things into their environments. We’re trying to take a holistic approach to making sure that when we build something for a developer, first of all, it creates utility in an area that’s of importance to them. It’s something that’s either friction or pain or makes them go slow. For instance, I mentioned creating production grade containers.
Lots of folks lack the deep expertise in container knowledge to do that. So we’ve tried to produce tools that don’t require you have that expertise, that provide you with insight intuition and even automated actions that do the work that you could do if you had this amazing background in container composition, but you don’t. So how can we help you do that?
So I think it’s a combination of purpose fitting the capabilities to the developer’s pain and making it something accessible and easy to use. And I think that’s what the real successful companies, building developer experience tools, platforms, and capabilities have done, really fit it the way developers wanna work and make them expert without being experts.
Mike: Do you think that maybe we have gone too far where we have DevOps platforms built by engineers without the needs, or the experience with the developer in mind? And maybe we need to take a giant step back if we want to think about developer productivity, about how maybe those platforms get in the way of that conversation. What do you think?
John Amaral: Yeah, I think there’s some of that. I think we’ve been sort of as an industry and building cloud native software working our way backwards from the infrastructure. You think about it, years ago, we had IT teams that racked servers. Right now we have Amazon, AWS. And then once Amazon, AWS came, I personally run lots of developing teams.
We had engineers that were experts at writing Ansible scripts to automate those, but it was a kind of a very bespoke thing. And now we have tools like HashiCorp and Pulumi that help us abstract that. It’s kinda working its way back from the infrastructure and towards the developer’s desk.
There’s been lots of innovation at the developer’s desk too, but I think there’s still maybe a last frontier of tying the idea of developer productivity to beyond their desk, to helping them create software that’s ready to run. And that that’s part of where my company’s really focused on.
And I think it comes down to understanding what pain a developer faces from their desk looking out. It’s about a developer empathy thing, I think we’ve got, in DevOps, you’ve got this notion of DevOps engineering and all the practices around CICD. A lot of these are designed as pipelines that are built for the purposes of just, it’s plumbing that’s fit to make something work in the infrastructure where the infrastructure minded folks know all about.
They’re trying to make an application work there that the developers know all about. And this is like lost in translation zone that’s kind of covered over by or adapted by CICD. I think the next horizon is to really make the impedance mismatch between how my app works and runs, it’s in the developer’s head, fit perfectly with how the infrastructure wants to run. Really bridging that together in most enterprises is still a hard thing to do.
And I think there’s two sides to that. It’s the developer empathy for the application and how it should run, and there’s the DevOps empathy for what’s practical to run. And I think bridging that gap and informing both sides with tools and techniques and process that really streamline that to take the sort of hard work out of it so that you focus on the most important things is gonna be a new wave.
And you see it with the ideas of developer experience platforms. You’re seeing this now, which are basically impedance matches between, how do I get my app to run over there? Or how do I get myself to be able to build an app that’s ready to run, and more. But I think there’s a lot to that, Mike. I think it’s a good question.
Mike: How do you think this whole Shift Left movement is working out for developers? It seems to me depending on your perspective, if you are maybe on the right side of that equation, it feels more like you’re shoving stuff left. And are developers gonna look at all that and say, “I got a million things to do myself,” and are they gonna push back soon? And what is the right balance between shifting left and maybe landing in the middle somewhere?
John Amaral: Yeah, I think Shift Left only works if it doesn’t mean just push work left. That’s a challenge. I think if you take a look at the CNCF’s apology of cloud native technologies, this is like a page that’s so giant, I can barely fit it on my 30 inch monitor. One way to look at that is, yeah, we’re making lots of progress in technologies that will help us build.
The other way to look at it is, with that progress comes a lot of stuff that doesn’t talk to each other, a lot of new technologies that developers have to learn, the DevOps people have to learn. A lot more complexity in my infrastructure, yeah, we moved faster than we ever did. I can create a server that runs my software in five minutes, but to get that to run at scale and production grade, it’s really hard.
And what I see developers telling me is, I have to learn a lot of new technologies, and every day I’m faced with new challenges in areas that I’m not an expert at, for instance, how do I make my containers more efficient, or how do I get them ready to run? And how do I get them through my pipeline?
And yeah, this idea of Shift Left, I think in its best form is really about giving developers the capability to produce software that will work and go through CICD quickly and make it to the other side and be a great application running in production great cloud. Where it falls down is when it requires them to do a lot of extra steps and learn a lot of new things to do yet another job that is sort of not in the core of what they wanna do.
And remember, most developers just wanna write code and build the app that drives the top line of the business. Everything else looks like friction to them. But if you’re sitting in a DevOps seat, it’s like, well, I need to make this run in production. And that’s a hard job too. And so I think that’s part of that impedance mismatch problem that I was talking about.
It’s like, how do you let developers, from the very beginning, fit their software into something you know will run well. And that’s about container best practices, but it’s hard to do and easy to say, today.
Mike: Do you think this whole process is gonna get more automated as we go along? And maybe that’s part of the secret sauce for the middle. Yeah, how much do I need to know as a developer about the environment? How much do I need to know about security? Or can we find some way to maybe just embed all that stuff into the platform in a way that automates things, and let’s the developer to your point, right coat?
John Amaral: Certainly that’s what we’re trying to do at slim.ai. We’re trying to help augment existing workflows, like what you do in CICD with a system that has a sort of intelligence enough to know how to optimize things for you, so that you don’t have to do. It’s basically taking some of that work that’s shifting left on optimization for the infrastructure, optimization for security.
I produce some software, it’s containers. Maybe I ship that, and I try to get that into prod, but eventually I get some feedback that says, “Well, you’ve got something wrong with that implementation as it relates to how it could run in the environment.” What we hope, and I think will happen is that there will be systems that are designed to overlay and work with the existing systems that will flag those things early in the life cycle while you’re developing.
Produce a container, it says, “Hey, if you restructured it this way, it would run better in prod. It would run faster.” Or, “If you restructured it this way, it’ll have less risk from a security perspective.” You do that automatically. What you really want is it just to happen, like when you run in a platform as a service, you write some code, it just goes there and works.
The problem is that most organizations, especially organizations that build their own infrastructure, don’t have what’s the equivalent of what maybe Heroku would’ve been for a developer who’s trying to build something at a small scale. So I think, yes, I think this will evolve to become very automated and very self-service for developers.
And a lot of the difficult, I’d say detailed work of fitting some great code to become a great running app will just happen. And that’s part of the vision of what we’re trying to do at some of that AI, is produce tools that help you do that quickly.
Mike: So, John, other than hanging out on your website, what’s your best advice to folks about how to get started or how to take this up a few notches and make it feel more like an industrial process versus what today often comes across as a craft that’s hard to scale.
John Amaral: Yeah. And I think there’s a few things that can happen. I think certainly developers who have been successful with our open-source and even some of our SaaS, they’ve taken a very automate first mindset and they’ve used tools like ours and others, but they’ve built them into workflows that just happen.
One of my advisory team members, he works at a very large company that’s invested a lot in automation for developer experience, and they’re world class at this. And what they did was they basically went on a hunt to strip out friction. If there was something that was being done sort of in that Shift Left yet another job to be done, they had a team that looked at that and said, “Hey, how do I automate that? How do I simplify that? How do I remove that?”
So it’s this sort of never ending quest to automate and code, I’ll say, to removing jobs that are repetitive and automatable. I think that’s a good lesson for anyone and just kind of continue to do that. For smaller teams, I think it’s important for them to triage deeply and I think adopt technologies that do the job for them.
I think there are bigger organizations, there’s 500 companies in the world maybe that can really invest a lot of money in doing these kinds of things and they do, but for everyone else, I think it is a combination of looking for best in breed technology, stacks, and SaaS solutions that fit in with what you’re doing. I think that’s another piece of good advice.
You don’t necessarily have to change your workflow, just continually improve your workflows to do that, and they can certainly come and hang out on our website and find some good ways to do that stuff and anybody who wants to talk, we’re glad to talk to them about how it could be done.
Mike: All right, cool. I think we’re onto something here. We could replace that whole Shift Left thing with a kill friction. Just give everybody –
John Amaral: That’s right.
Mike: – kill friction.
John Amaral: Well, Mike, that’s not – Every time we have a team meeting, at least once a week, we have our opening conversation with our whole team and we do three things. We have gratitude for each other for when we’ve helped each other out and we have a friction removal sort of shout out for anyone in the company who’s removed friction from some process, ’cause we’re trying to be that company that’s just insatiable friction removal engine. We actually call it out every week when we talk to each other on our team meetings.
Mike: Great. Hey John, thanks for being on the show.
John Amaral: Thanks a lot, Mike, appreciate the time.
Mike: All right. Back to you guys in the studio.
[End of Audio]