Evolution of Modern App Development with Mirantis’s Alexander Freedland

This is Textron tv. Hey guys, thanks for the throw. We're here with Alexander Friedland, newly appointed CEO for Martis, and we're talking about where he hopes to take the company in 2024.

Alexander, welcome to the show. Michael, it's wonderful to be here. Thank you for having me on.

Hey, Alexander. Good to see you. What brought you back to Martis?

Well, what brought me to Mirantis is that I actually founded this company, God knows how many years ago. Nobody remembers, but, uh, I was the one who originally incorporated, and I was on Mirantis board and the CEO and, you know, chairman and, you know, CEO again, and chairman again, and then whatever for the duration of the company. So this is my third stint as a CEO.

And, uh, since I started it, I just wanna continue. That's the reason. One of the challenges you're hearing from customers, what are they struggling with these days?

It seems like sometimes they wanna be involved in application development and run a lot of infrastructure. Other times they don't and they wanna consume it as a managed service. Um, where are we on this journey?

Well, it's, it's a vibrant market out there and it's, you know, it takes all kinds, there are all kinds of customers. There are some that are old school and they want to run their own infrastructure. Some wanna just have it all in public clouds.

Some wanna be in software development business and know nothing about infrastructure. Some wanna be in combinations of this, and it's a vibrant and mature industry. So I think we hear in, well, We see a lot of different kinds of applications these days.

There's monolithic applications that might be running on something like OpenStack. We have cloud native applications running on Kubernetes, and we also have serverless computing frameworks and all kinds of fun stuff coming down the pike in the future, is it getting more complex to build applications? I mean, have we reached some level of complexity that's just unsustainable?

I don't think so. I think the application development, um, never truly changes, right? It's, it's as good or as complex as a human mind is able to capture it.

So I think there was a, a huge revolution that happened with Agile, where distributed teams became capable of building very complex applications through the processes. And I think that's where kind of the human endeavor is. And then humans are managing the same level of complexity that they're capable of, is just the tools and the domains are changing, but the complexity at the human level stays the same.

Plus, you know, multiplied by automation and productivity tooling, whether it's, you know, environments or processes or code generators or ai. This is just, you know, additional, uh, productivity things. But humans are solving the same complexity problems, and I think it's gonna remain that way.

Everybody and his brother is talking about AI these days. What impact do you think AI will have on the way we think about application development? I think AI is probably one of the largest revolutions happening in front of our eyes.

And, um, it's probably bigger than, you know, anything we've seen in it, uh, because it's ubiquitous and it is just a part of it. Um, ultimately it's again, a huge automation and, um, a way to do things more efficiently and, uh, it's gonna touch every single part of our lives. Um, but ultimately, again, it'll just allow people to leverage their talents more and the tools will change and the stacks will change.

And I think we're very, very early. I mean, we're probably more early than, you know, AWS was in 2000, whatever, six when they started, right? Or thousand three.

It's just a very, very beginning of this. And in the next next decade we'll see a tremendous change. First in infrastructure and then on the ways the types of applications that could be built.

And then it's gonna go into application and it's gonna just thrive. So it's all it goes infrastructure and then apps. So this is a whole new stack.

There's a lot of talk these days about developer productivity, and I think we've been having this conversation on and off for a while now. But what is your sense of what is the fundamental issue here? What's the challenge?

Because from my perspective, we seem to be talking about everything in the world about how to build things faster, but it's still an art. So how do we balance art and science? I think there are two components to that, right?

One is at what, at what level of abstraction developers are allowed to work to actually build things that customers care, right? And those companies that, and, and those developers who really live in the agile world, and I I've been seeing it in, in the other companies I've been involved with. You know, the, the, the company that I just came back from is, um, the company that my co-founder Boris, started the Mira co-founder of Boris Star Co Freedom Phi.

And that now is part of a Helio ecosystem, which is the one of the largest, it's called deep in now, distributed, um, a decentralized physical infrastructure. The speed with which these people operate is astounding, and they just deal with a changing environment. And the, you know, small teams move very, very fast and all the infrastructure is outsourced.

And that's just an example of how innovative teams are capable of doing. And then on the other side, there are much larger organizations that are trying to do that, but then they're inhibited by processes and compliance and infrastructure and multiple environments all over the world, including regulatory and all that. And suddenly they have to do it, you know, with these constraints in mind.

And then many of them have to deal with infrastructure and funding and financing and availability, and that slows them down. So I think as far as engineers are concerned, if you give 'em the tools they want and stay out of their way, they can be very fast. But unfortunately, the infrastructure and the processes of larger organizations sometimes stand in the way in finding the exactly right optimal balance for each organization is where the art is.

And I think it's gonna continue that way for a while On the back end. We hear a lot of people talking about platform engineering these days, which appears to be a methodology for managing DevOps workflows at scale. What is your sense of what are the challenges in kind of adopting platform engineering?

Is this the right answer or are we grasping at yet another straw? It's, it, again, it's a natural progression of any, uh, industry right in, in it, it starts with infrastructure, then you start going on top. And once the physical infrastructure is understood, you start to build application infrastructure.

And these application infrastructure layers, it always been the case, you know, the, the olden days three years ago, that's how Oracles were born and all those other things, right? So you automate the layers of the application and then when you are in a multi-cloud environment and regulatory and all that, you need to make sure that you develop it once and then it runs everywhere where you need to do that. And for that, you need to have abstractions that will again, enable developers to, to build things that you can build on your laptop, and then magically they will run everywhere.

And then if it becomes complex, you have to automate it using the latest productivity tools, be it AI or GitHub, so what have you. And today that's where the puck is. This is where the action is, and the physical part is sort of understood.

And now it's the application infrastructure where the community is now doing the most innovation. So this is, this is, this is a normal progression of, of an industry. Do you think developers will embrace that concept?

'cause sometimes I feel like they wanna have their cake and eat it too. They're like, well, I don't want to deal with all this cognitive load, but I don't want you to tell me what tools to use either. So how do we kind of figure out a way to keep those guys on board?

It's a very good question. And I think, um, this is where art of every company, of every vendor, um, you know, becomes important. If you allow I developers to have whatever they have and give them flexibility, they will actually out-innovate everybody.

But then it's very difficult to keep as a chaos instill, especially if you're a large organization. If you go to the other side and you force a process on them, the best developers will not agree. And those who will stay will still be hampered because they will probably prefer different tools and everything else.

And so you have to find a way where on the one hand, you enable developers, and on the other hand, you make sure that you have control and, um, auditability and all this other things that large organizations need. One of the ways to do this is through using the tool sets that today, your smart tool sets that allow you to create smart customizations of tooling and environments on standardized platforms like Kubernetes, and then manage that through tooling. Like for example, you know, Kubernetes operators that will allow you to very quickly build blueprints that will enable developers and enable partners to come in and do things correctly.

And these blueprints then can become tools that organizations can manage for their compliance, and yet give flexibility to developers to work in those environments that will make 'em the most productive. And I think, you know, if you, if you remember what TIS has done in the Lens platform, which is actually the control plane for Kubernetes work, and the blueprints that, um, we are, we're talking about could be plugins into Lens, and this is one of the environments where we're doing a lot of innovation in the community to solve exactly this problem that you just described. Are we having something of a chicken and an egg problem when it comes to Kubernetes that feel like, uh, the platform's complex and a lot of developers are intimidated by it, and as a result, we don't have enough apps to justify the deployment of the clusters.

So how do we kind of break that log in? I don't see this happening actually. And, uh, I think developers are very comfortable developing on top of Kubernetes.

They don't really care, right? They just put stuff in the container and, you know, they, they press a button and everything just happens. And the idea of building applications with containers and Kubernetes as a environment has become a standard thing.

Now, managing complex Kubernetes environments, doing this work, being aware of Kubernetes, if you have to deal with this at the DevOps layer, yes, that can be a challenge. And there are some amazing people who would just, you know, put things in CLI and manage it themselves, but most developers don't wanna know about that. So you create abstractions and tools like Lens, there's a million people using Lens who don't want to deal with CLI and Cube configs and all those other things, right?

And just want to interact with it simply. Um, and the more abstraction we create from the infrastructure, it's no different from we have to deal with OpenStack or VMware developers don't wanna deal with that stuff. It just needs to happen automatically.

And, um, that complexity will need to be abstracted. And there are two ways to abstract that complexity. One traditional is what traditional, entrenched vendors have been doing is creating stacks, vertical stacks where they curate things, put them together in the way that they just work, and enable organizations to digest that stack.

And that's where everybody works. The other one is a horizontal approach where you allow people to build, you know, the optimal solutions for what works, but then they become complex and they manages through a managed service. We call it zero ops and others call it managed service with automation.

But ultimately, if you provide a service on top of it, that abstracts complexity, it solves that. So meranti has always been an open platform that would abstract complexity through a managed, through a managed approach as a service. You have a million developers using Lens, and the Docker folks would say they have somewhere between 10 and 15 million developers.

And not sure what percentage of those are already in Kubernetes, but let's say there's a lot, but it seems like there's 50 million enterprise developers. So how do we bring the rest of these folks along? Well, many of those developers don't really need Kubernetes, right?

They, um, they build abstractions in, in, in their world of their application domain, right? And they put code, put it in the container, and they push it, and then whatever happens and Kubernetes happens. So, um, ultimately it's just like the average of 30 years ago when Microsoft came in with integrated development environment and kind of created the revolution.

It's the same thing. We need to make sure that all the components that developers and needing to develop their applications, they are abstracted and the tools are available. And if you need to go deeper into this, you have visibility and ability to do this, right?

And so Lens is a good place to start when you go bottoms up. So for the DevOps people and all that, you have simple things. You, you simplify Kubernetes, but then you just expand this to other use cases, right?

If you're talking about GitHubs, for example, and you wanna be part of that, you know, you build that interface and you want security components, you build this interface and you expand it, Docker is doing it their way, and they have a very, very loyal constituency. Um, we're coming from a different angle. We're having a constituency of our own.

They will all work together. And ultimately it's about, you know, offering the, the tool that's most convenient to people. You know, developers will always choose things that they like.

There is no other way. So what's your best advice to IT leaders that are trying to recruit and retain these developers? 'cause a lot of them can vote with their feed anytime they want.

Well, again, it's, it's always a challenge, right? So if you are an IT organization, you have to decide what business you are truly in, right? And public clouds were born out of the fact that many application owners did not wanna be in the IT business, right?

So the shadow IT would, would what got Amazon started. And today there are certain types of applications and developers and application owners and all that that don't want to be in the IT business. And to them, infrastructure is relevant.

For some it's actually not. It's actually very relevant because how it's optimized, how it's structured has tremendous importance on what the application workload is. And what you have to do as an IT leader is to understand what business you don't need to be in.

And you let that go to a managed service provider, you know, whether it's public or private, it doesn't matter, or to a public cloud. And, and those where you must be because infrastructure is actually a differentiator. And if it is differentiator at scale, I don't think these companies that run that have problems attracting talent, but those who don't have that and they're trying to do this, this where the talent will walk.

And there you go to companies like tis or others who can actually help you not to be in this business by providing you a service that will give you the right economics and yet enable your developers in your organization to actually move very fast, but you know, in a compliant and uh, um, auditable way. All right folks, you heard it here. It's kind of all about right sizing the experience to the developer based on what they need and going from there.

'cause if you treat 'em all the same, well, and chances are they're probably not gonna be happy. Hey Alexander, thanks for being on the show, Michael, thank you very much. Take care.

And back to you guys in the studio.