Deepak Goel, D2iQ | KubeCon + CloudNativeCon Europe 2023
What is “Instant Platform Engineering” and why is it important?
-Platform Engineering is a red-hot topic being touted as a remedy for DevOps difficulty and dysfunctionality, with pundits pronouncing DevOps “dead.”
-Platform engineering provides an internal development platform (IDP) that provides a “golden path” for developers.
-Platform engineering can solve the problem of multi-cloud and multi-cluster management by providing a centralized plane for unified fleet management across all environments.
-Platform engineering can simplify security by building strong security into the platform, making DevSecOps, zero trust, and air-gapped security easier to achieve.
-Platform engineering can provide a Kubernetes platform that is ideal for running AI workloads and edge/IoT deployments.
-A Kubernetes platform based on pure CNCF-conformant Kubernetes is important to avoid security, upgradeability, maintenance, and other problems, and to enable portability and the ability to easily accommodate open source community innovation.
-Instant Platform Engineering provides a production-ready, fully automated Kubernetes platform with top-to-bottom declarative APIs and GitOps workflow, ready to go out of the box.
-This relieves platform teams of the burden of engineering a Kubernetes platform by providing a feature-complete world-class Kubernetes platform, ready to deploy in minutes, enabling them to focus on higher-value work.
Transcript
This is texturing TV. Hello and welcome back to kubecon plus Cloud nativecon Europe. We're talking today with Deepak goals the CTO for d2iq and we're going to be talking about kubernetes.
And what's complex and what's not complex Deepak. Welcome the show. Nice looking nice meeting you may the perception today is that kubernetes is hard to manage and it's difficult.
But in reality is someone different there are there's the base platform which seems to have got maybe easier to manage but then there's all the stuff that sits on top of it these days. So what should people really be expecting about kubernetes in terms of its complexities these days, you know, how should they approach this? Yeah, you are right that kubernetes after being eight nine years into existence has become simpler and the aspect that has become simpler is it's Day Zero operation which is installation of the kubernetes.
So installation of the kubernetes has become a lot easier not is not difficult to install kubernetes. What is still very difficult is to manage the day to beyond the maintenance of kubernetes, and as people are adopting kubernetes for the production environment. There's also a complexity being added that vanilla kubernetes is just a platform to offer, but then they need.
Other applications to run to observe kubernetes health for example observability, for example, security authentication authorization policy management cncf does offer our plan tour of these applications, but that's at the complexity the more choices. You have the more you need to figure out which one of these choices make sense to you which one you should adopt which one you should integrate with. the other complexities all these projects they move independently with each other now who should make sure that how these different applications fit together to create a complete platform that can be run in production and not every organization has the skill set to Traverse or to navigate this cncf landscape or ecosystem of like 200 or 300 plus applications and to fit them together into a cluster and I strongly believe it's not their job either like if a banking system is there they just want to run their countries application on Cuba net is asking them to figure out rest of the Cuban it is I I don't think that's the right call the and I I try to explain the complexity of kubernetes with the car analogy.
So if you ask a driver to configure the engine first before driving the car, they'll say it's too complex. And that's what is happening with kubernetes. We have exposed the engine of cubanators to the developers and asking them to configure it before they can even deploy their application which is what devops is saying that the developer should also do the operation what's ending up happening is the operational aspect of devops has become so large and so big that they are getting less and less time on development because of the configurations that explosion that they are facing with kubernetes.
I think we need to build we need to move our Sac higher to upset kubernetes in a way that it gives like a steering breaks and accelerator to the developers so that they can just deploy their application and not having to worry. What is the engine? Yes, some people need to still worry about the engine but those would be the specialized mechanics who can take care of the kubernetes.
We hear about shift left all the time, but most of the developers. I know don't really want to know kubernetes. They just want to write code.
Yes. So have we overestimated what we want developers to do? Kind of I mean the devops was attractive.
It has some some benefits because then the developers can decide what's the right tooling to use but then again if the choices goes beyond a particular limit it becomes complexity like cicd is good till the deployment part is there but trouble shooting is bad tribute shooting is complex, right? How can we make how can we take this a notch further by not saying that you can easily deploy your applications, but maybe also easily troubleshoot your application which is what is happening. And which is what will happen is we are seeing a lot of progress happening in the field of airops, which is how can we use the smart make the system smart enough to tell what is going wrong in the system because ultimately these all our distributed systems and they are very complex to deal with and Frankly Speaking.
It's not should not be job of every developers to understand the entirety of the thing. They should be focused on the business application. What should happen is the system should be smart enough to automatically indicate and notify where the tension is needed instead of just watching the couple of dashboards and figuring out what's going on with the system.
Initially when we deployed kubernetes, we saw a lot of devops teams involved. But are we also starting to now see traditional it administrators get involved and they don't have programming skills per se but they can access some sort of graphical tool. I would imagine so as the whole thing becoming more accessible to a broader number of it operations people, right?
This is a trend that is has been repeated whenever big organizations like Global 2000 start adopting a newer technology. So what happens in the life of kubernetes is initially kubernetes was picked by developers in the newer startups and companies and they got very excited about the opportunities that this platform provides to them. But then the bigger organization was still evaluating whether this technology is here to stay now eight nine year down the line.
Yes. Everybody is acknowledged that cloud native and kubernetes is here to stay and now they are requesting the same Simplicity from the platform kubernetes that they have been requesting from other platforms as well. And so we are Meaning requirement that how can we make the management of kubernetes easier whether it is dependent on creating and provisioning a cluster to deploying an application.
They want Simplicity single click installation. And I think that's the right call because as I said not everybody needs to know the complex ecosystem under the hood but few people need to know and that's what the it Specialists are for. But the other developer Community Within These big organization can continue to Avail the Simplicity of the F section.
A lot of the organizations. I talked to were kind of all over the place in terms of versions that they're running of kubernetes somewhere as far back as one 12 and others are maybe relatively current what is the challenge with staying current with kubernetes? And why aren't more organizations on the latest and greatest version?
It does I'll answer that into two parts one is the traditional mindset with the upgrades upgrades in software Industries has always seen as challenging like people don't touch the system that is working because there's always an inner fear of like what if something goes bad, right? So there's there's a general hesitancy with upgrades. The second aspect is which ties to my first answer which is like installing kubernetes is simple Managing kubernetes from day two is not that simple and upgrade is one of those things and it's not just the kubernetes layer because you upgrading just vanilla kubernetes is still simple, but when kubernetes is running with other applications, you need to make sure that all these applications are running on the latest version of kubernetes, which is to make sure that the API that they're using is not duplicated and and knowing this means you need to know the engine that you are upgrading and that makes it complex.
What we need to do is we need to extend what makes kubernetes. So popular to upgrades for example, why kubernetes is so popular is it's declarative nature. It's yaml format.
It's API driven approach. However, if you see upgrade they are still not declarative. They're still not you can't just say, okay.
I need humanitis. From 124 to 125 and the system takes care of upgrading it declaratively. You still need to specify the steps.
You need to First upgrade the control plane node you then need to upgrade the node nodes. And that's a lot of complexity which again builds up this mindset of like why we need to upgrade if you don't have to upgrade. So we need to make the great simple and then approach the community say developers.
Don't worry this upgraded single click just do it and it will happen. All right, folks, you're heard it here. It is finally getting simpler.
It's been a long time in coming. But if you're just getting started, you're probably getting the benefit of all the work that's been going on for the last seven years Deepak. Thanks for coming by.
Thank you. Mike. Nice meeting you.
All right, and we'll be back in a minute.





