Evolution of K8 Deployment and Management – Saad Malik, Spectro Cloud

This is texturong TV. Hey guys. Thanks for the throw.

We're here with son Malik who's CTO for spectrocloud and we're talking about kubernetes and where we are how we got here and where we're going inside. Welcome to the show. Thank you for hosting me.

I think we've been at this for a long time now and so those of us have been looking at kubernetes. We're like, whoa, it's more than half a decade but a lot of folks are still just getting started and when they do get started they're finding out that not only is it hard to manage one, but now they're trying to figure out how to manage many and fleets of clusters and a lot of them are maybe a little over well, so what's your sense of where are we with kubernetes in terms of making it more accessible from a management perspective? Yeah, I know.

Absolutely. I mean if you just look back six seven years ago kubernetes was there but at the same time there were many other container platforms. If you had things like Nomad or Rancher cattle and you had mazosphere within the last couple years.

Everyone was Consolidated on kubernetes primarily because of the Innovation and the speed it allows developers and it operations now because everyone has converging towards kubernetes what we're all so finding is that more and more clusters are being provision and for them to be able to now organizations to manage these at skills becomes challenging right? Because you want to be able to not only provide a cure brunettes, but all the different aspects along with it everything from authentication to authorization logging monitoring either responsibilities that more and more platform engineering and develop teams are now having to deliver on their own and either they're trying to do themselves or are looking towards platforms that can help them in enabling all these different operations. I think initially everybody thought that somehow or other we would have a bazillion people who had programming skills who could manage kubernetes and work their way through yaml files seems like we left the average it administrator behind who prefers graphical tools and now organizations are going we're never going to find enough of those devops folks.

So what is the right balance between it folks and giving them graphical tools and devops teams. They want to manage things through apis and see allies. Yeah, I think it depends definitely on the maturity of the organization and the type of applications being developed in some cases.

You have organizations that are building very specific platform tools that they want to provide to their customers. I think for the most part organizations like that. You don't want to abstract away too much of the kubernetes because they have to be in the weeds of understanding how deployments and see currents and all these different different pieces high together majority of organizations to are not building platform toolings.

Majority of companies are building either their own applications and user applications or simple services on top for those organizations. I don't think it makes sense to expose the complexities all the kubernetes later. Now, either you start providing them with some kind of IDP internal developer platform tooling that makes it easy to procure access to either our cluster or to our namespace or specific database services or what you also find is that you may also write them some level kubernetes accessed so that they can provision their own Services, you know a little bit here.

It seems like there is no standard management plan for kubernetes as of yet. What's your sense of how will that evolve as we go forward will the kubernetes community provide that or do you think that that's always going to be a space where vendors are going to compete with each other? Initially, the actual discussion was on the distribution.

Do you use a distribution whether it's eks gke or AKs and a public Cloud where they're using a distribution like cncf on-prem. What we're finding now is that kubernetes has become standardized all distributions are become commodity. The level now really is on the management aspect.

How do you manage these at scale? I don't think kubernetes itself an ecosystem will provide a simple management Solution on their own because there are many different requirements that different teams have some people care more about exposing to internal calculator is operates and runs versus other people are looking for providing application developer experiences on top there will definitely be a plethora different tools that very based on the requirements on different organizations that they have. It is subject to the whims of passion much like any other industry.

We have a lot of folks now who are building Cloud native microservices-based applications, but it's not always clear to me that they're fit for purpose for kubernetes. So do we need to take a closer? Look at what types of applications are deploying where because some things may run better somewhere else.

Absolutely. I mean, I think applications could be anything from database Services people are developing to Angie's or applications. That could be web pages.

For most applications. It does not actually matter whether the orchestration tool underneath is kubernetes is Amazo. Is there even a serverless function?

It doesn't matter for the most variety of applications and I think what we will find seeing more and more are that application teams are going to have access to a higher level abstraction that says here is my container you go and run it whether that runs on our kubernetes customer or not is not something that they're going to be ever even know that's gonna happen behind the scenes. So as you look into the rest of this year and probably into next year as well because things don't move all that quickly. How do you think kubernetes is going to evolve from where we are today?

Yeah, I think couple different areas. So one is on this developer front, you know as different development teams are not very responsible for understanding how their own code Works their Ides managing libraries and dependencies. They don't want to ever get involved in a kubernetes layer.

And so what we're going to find is that it teams and platform engineering teams are going to be providing more developer abstractions. So that these development teams don't have to get understand any of these aspects. I think what will happen is again, most of these organizations will have a mechanism of checking in a piece of code and their CI pipeline will automatically go ahead and build a code and deploy it onto one or more clusters completely abstracted away from the developers the other area that I see that will also happen for development teams is development applications always have dependencies these dependencies could be databases like no SQL databases or relational databases like Mara DB or message bosses, I think.

Ultimate teams will be given options in an IDP to very quickly secure access to one of these different services. On the platform engineering site because these teams are now going to be running kubernetes as the infrastructure for all their Dev teams. They're going to see a plethora of different clusters being deployed and these different clusters could be deployed on public clouds private clouds data centers Edge bare metal you name it for them to be able to consistently get visibility into the lifecycle and health of all of these different clusters and consistently being able to manage the lifecycle from a single-payer class.

I think that's what we're going to see more tooling to help both the development teams get the value they need out of kubernetes as well as for the infrastructure teams to get rain on being able to manage all these different infrastructures. Course everywhere you go these days in the land of devops. They're talking about observability.

How do I apply observability to kubernetes? And will that just converge with the management plan? Yeah, I think observability is two different facets for development teams.

One of course is getting observability into my own applications traditionally. If you look at how kubernetes first was started up it was a development teams who had to instrument their own application code to get the logging the monitoring to traceability aspects more and more the ci/cd platforms are now instrumenting. This code's automatically but the other aspect is not just for the development teams.

How does an infrastructure team that is managing hundreds maybe thousands of clusters at scale also get observability into the health of all applications across all the different environments that are running into we're gonna find that there's going to be higher level management platforms that do provide visibility and observability across all this different all the different areas. Speaking of other areas where they'll be convergent security is that always going to be managed separately from the management plan or is that too ultimately an extension of the management plan? I think as organizations have are now adopting kubernetes as critical business infrastructure where they operate and manage these at scale all the different security postures that organizations have whether these deal with Northside Communications or east west traffic and TLS.

These are all policies that are somewhat unique to each and every organization and what we'll see that these policies will become codified in terms of governance languages, like opa's and Rego where there'll be able to specify that. These are my security rules for in running an application or a cluster in our environment. These rules will be specified into the management plane itself, and there will be enforced down into every cluster regardless of where it's running public Cloud private or data centers.

How soon do you think? It might be before we see AI playing a larger role in the management of kubernetes. I especially these days what Chachi Pichi being everyone talking about it.

I do see that more and more that everything from placement logic of where the application workless are being deployed to how the infrastructure is performing being able to quickly and without much effort give actionable insights to the infrastructure teams on which cluster environments are under load or need additional capacity even up to the development teams of being able to make executive policies. These are all going to be driven by AI Ops at different levels. So what's your best advice to folks then as we kind of look at where we are.

Should I dive deep into kubernetes or can I kind of sit back and going you know what there's gonna be a layer of abstraction between me and all those exciting knobs and yeah, we'll files and all those other things that people look at and go. Oh my goodness. Yeah today in the cncf landscape.

There are over 2,000 different Technologies and Integrations everything from your different immutable operating systems to logging monitoring security and many many other layers, even for a devops cks person who's deep inside of it. It's very difficult for them to keep up with everything. I think for most organizations that are now either adopting your brunettes or looking to making a production kubernetes.

There are great landscape radar. There's a cncf radar landscape that provides you what are the upcoming technologies that people should be aware of today. And where is the actual future headed and there are actually tailored for if you're interested in logging or whatever ability looking for North communication traffic and security aspects.

Those are a great place for people to get started. I would never recommend had deep into your price first day obviously based on your requirements when you need to go deeper down you always are able to do so if needed All right folks when I was a child, my father would go to the store and replace those tubes in that television set and then Along Came the solid state television and that was the end of that. I think kubernetes will be the same one day.

We're gonna just be a higher level of abstraction and you can tell it what you want to have happened in some management plane will automatically take care of it for you, sad. Thanks being on the show. Thanks for having me Mike.

Appreciate it. And back to you in the student.