Enterprise Tech Adoption Challenges with Turja Chaudhuri
Hi, I'm Connie at Instruqt. We have a great talk planned for you today on developer experience with our guest, Turja Chaudhuri. Turja has more than ten years of experience working in IT, including more than five years in cloud technologies. Currently he serves as an assistant director for cloud platform and he has worked with multiple enterprises in their assisting their journey to the cloud and also help them establish best practices for architecture and governance in the cloud. So Turja, thank you so much for joining us today.
Thank you so much for inviting me. It's a pleasure. So actually, your article about Why Boring is Not Bad for Enterprises Always really caught my attention. And maybe let’s start by discussing like what prompted your interest in writing about, you know, adoption in enterprises. Yeah. So one of the reasons I have always been kind of interested in enterprises is basically when you go to the Internet, you see a lot of articles, right? But most of them are getting started and the scale is much less than what you typically expect from an enterprise customer.
And things start to break at scale. So issues which you will never have in, say, for example, a two member, three member five member team will start coming up when you have a distributed team which works across a big project or works across multiple products. That is why because I have always spent my life in enterprises starting from 2012 when I first joined Samsung Research. Then I went to PwC, then PwC UK, then Accenture, now I’m with EY. So because I have been with big firms, I have seen actually firsthand how things are very difficult to do unless and until you follow really strong patterns, good design patterns or processes at scale.
So things actually break at scale. I have seen that firsthand and so whenever I write, I always kind of try to give that perspective on not how to get started with stuff, but rather how to operate stuff at scale across an enterprise. Yeah. Excellent.
And from your experience, right, we all want, you know, innovation, right? In companies to be in the cutting edge, doing a lot of new things that, you know, benefits customers, the organization but at the same time. Right. Stability. Reliability is very important. So what is the best way to balance that from your experience, from what you have seen? Yeah. So this is typically a very difficult question. Very frankly, it's not a very simple thing.
There is not like a single answer or a very simple answer. Obviously, you have processes in place for stability, right? But at the same time you will see that some of these processes might actually hamper innovation also. So let's say, for example, you have an innovation team and they want, let's say, OpenAI. Let's take an example OpenAI. So there will be enterprises today, many people who are working well, who want to get started with OpenAI, maybe they have a use case. They just want to get started with OpenAI.
But at the same time, as an enterprise, if I think from an enterprise perspective, I don't want duplication, I don't want two teams creating the same chatbot on OpenAI, for example. That's why we have governance, that's why we have processes to avoid duplication, to ensure everything is regulated. So striking the trade balance, if you have such a strict process that from idea.
So let's take an idea from an idea to an actual product, it takes, say, two weeks, three weeks just to even get the request logged. Then the innovation angle will completely get lost. You create so many hurdles for a team to even innovate or rapidly prototype then it will not work.
But at the same time, when you go to production, there will be some added benefits. That's why when I visualize this, I always think of having a sandbox environment or a nonprod environment, or for example, a hypothesis environment where you can rapidly prototype with much, much less guardrails. You will have some high level principles there. For example, you will not allow client data. You will not allow PIA data on that sandbox. So you will have a few guardrails.
But if somebody follows or somebody is going to solution is constrained within those guardrails, they should be able to deploy very fast, very, very fast. It should be a sense of if you go next, next day you get a subscription with whatever you need, you do your prototyping. But the moment you are trying to move to prod and you are actually aligned to client data extensive use, then you should have processes like, say, security, infosec, privacy impact assessment, many of that.
So that's the balance. So you have innovation culture, you have a lot of innovation, rapid prototyping in the nonprod sandbox environments where people can rapidly prototype without a lot of hurdles, very easy approvals, nothing very fancy. Whereas when you go to prod, you obviously want to kind of prioritize stability a little bit more.
You don't want something to be just pushed and break everything. When you have, say, 50 life consumers on the platform. That is the kind of balance I would ask an enterprise team to strike.
I see. So after innovation right then, you know, you want to grow it out within the whole organization, right. Like thousands of developers will be using that. I think that's the next challenge, probably. Right. How do you get adoption within the organization? Yeah, so to be very fair, for example, when you have a new asset and you want to kind of educate people that, okay, we have this offering, let's say, for example, let's just take a very simple example. Say a company is promoting GitHub as the source code repository.
Okay. Maybe they were on something else maybe they were on Bitbucket or something I don't know. Now they are promoting it. So obviously, first of all, you need very good transition bot, but very good adoption bot, very good onboarding bot. So those things, so very good documentation, not a lot of manual approvals, very good automated flow, telling people the value proposition, everything very well-articulated. That is obviously one.
But then what you also need to do, you need champions who will champion you so for every portfolio you need to identify products which are big products, which other small products follow. So if you can get the big products to adopt your offering. Then automatically they become a very good success story. But the idea is continuous interaction. So you need to have a dedicated team so adoption obviously will happen organically, but that will happen at a slow, steady pace. When you want rapid adoption, when you want many people to kind of move on to your platform, then you need a dedicated team.
For example, a community focused team who has a Yammer channel or who has a Slack channel that they're publishing details. You want to conduct a lot of roadshows that, okay, this is available and then you want to create a deck, a very good collateral. Say for example, somebody can ask you, why are you coming up with this new source control repository versus what we had before? So you should have a very good value proposition that you can present. So across all of the journey so you should take basically you should have a PreSales team for that that component basically whose one objective is to help in adoption. Many times what I've seen people fail in is because the thing that the product team who is building the product will also help in adoption. Obviously, they will help in adoption to some extent, but their key priority is building a better product.
Always their focus will be that my this version of product version one, the new version version two needs to be better than version 1. so they will not always have a lot of focus on the actual adoption or the actual evangelizing of that. So you need a separate kind of a PreSales kind of a team who is more focused on helping people, educating people, helping them adopt understand the actual adoption challenges, articulating them, getting back to the product team that says guys your documentation is not up to date. This link does not work.
So basically overall, increasing the hygiene of the adoption cycle. To what extent does documentation play a big role in that? Huge. To be very fair, you cannot have in a huge company let's say for example, a company like EY with still like 50,000 people.
You cannot manually go and ask people and explain people. It's not possible. So you need very, very good documentation. For example, if you go to Microsoft and Amazon document, just look at the quality of the documentation, right? The documentation answers 95% of the questions. That’s why
you need to have very good documentation and you need to have guided paths if you see Microsoft learn the MS Learn thing that they have step by step guides on how to create the stuff. Then you need demos, labs, for example what Instruqt itself is a pioneer in. Like having demo environments that you can set stuff up. So basically you need a combination of all of this, you need good documentation, you need a good onboarding path, you need some sandbox where people can get access for free, maybe just try it out for 30 minutes.
So all of that kind of combines to give you that experience. So what we say here, for example, is if you see the developer productivity or the developer experience, that is how easy you have made life for your developers, right? So for example, if I take an example, Spotify, the company is very well-known company, Spotify. How do they measure developer productivity? One of the metrics they take is how long does it take a new developer to merge his 10th PR. That gives a very good idea of how your system is.
Is it easy for people to, for a new developer, for a new engineer to get onboarded to the system? How long does it take for them to actually start contributing real code on to the system? So say, for example, if you see that the time to 10th PR is 90 days, effectively your developer is not doing a lot of work for the first three months. If you can reduce it to say 15 days, then actually are doing a great work by 15 days your developer has all of the tools, tooling, everything they need to get, be productive and documentation, onboarding guides, demo labs. All of this play a pivotal role basically in helping people go to that stage quickly. Let's focus our discussion on enterprise adoption a little bit more on Kubernetes as we know, Kubernetes adoption is expanding. From working with enterprises, in your opinion like where most of the Fortune 500 enterprises are in their Kubernetes adoption cycle from what you have seen so far? See, from what I see is that Kubernetes in a sense, become the defect to compute nowadays.
So rather than putting something on a VM people are creating a Docker image and deploying it on Kubernetes, but at the same time that does not mean that it is getting any easier. Kubernetes in itself even with the managed service platforms like EKS, OpenShift still very difficult, to be very fair. It's a complicated thing. And that's where your platform teams can help.
In a big enterprise, you need a central Kubernetes center of excellence, for example, that creates usable offerings so that developer teams do not have to skill on everything. That is the advantage that you can give to a platform team as a platform team to your consumer teams, which are the actual business teams. So I see when I see that individually teams struggle to adopt Kubernetes. Even though the idea is correct, the process is not very simple. But now many companies, including EY, have platforms, internal platforms which help in adopting Kubernetes.
So you need to go to that stage where every single Kubernetes cluster in your enterprise needs to look the same. As simple as that. Everything needs to be automated. Everything needs to be linked to the same billing cycle. Every single contained image needs to be scanned with the same tooling. So there needs to be kind of like a standard set of practices across the entire Kubernetes lifecycle.
That is only when you will increase adoption. The problem with enterprises is standardization. Standardization is what you need. You'll need it in Kubernetes. You need it in every single other tooling that you offer and the moment you're offering standardization, it in a sense becomes a little opinionated. But that's okay.
You have your own opinion of how you want to do Kubernetes, which is the best opinion from your perspective. Some developer might say, No, I don't want to do Kubernetes that way, but that’s okay. That is where you kind of pivot and build an offering that most of your developers, at least 80% of your developers, can use. Mm hmm.
Okay. I see. And yeah, so I read about you mentioning about the Kubernetes Center of Excellence. Maybe can you elaborate a little bit more how that center of excellence can look like? So, I mean, see, it's like, for example, when I was in Accenture was part of the Cloud Center of excellence, right? So there can be different things. It's it's a very standard topic in enterprises. Most of the enterprises have this kind of center of excellence. This is subject matter experts who create and document patterns, best practices, standards, and guides so that everybody can follow them in a standard coherently.
Along with that, for example, you can even have platform offerings. So you have a standard automated way of deploying say a Kubernetes cluster. So all of that kind of was so basically it's like your product, your actual code offerings along with the services, which is wrappers around your offerings like best practices, guides how to do monitoring, how to do telemetry, how to do observability.
So every single cluster should do observability in the same way. Every single cluster should, for example, you can have a guiding principle that one application can only have one Kubernetes cluster for nonprod and prod. Meaning you cannot have one Kubernetes cluster having both prod and nonprod in the same cluster.
So that can be a guiding principle from your center of excellence. Then you have implementation patterns, you have automations scripts you might have a TerraForm script to do some stuff. So basically that is the high level idea. You have the product offerings and the services and both of them combine to kind of create a center of excellence. Hmm. Okay. I see. That's great.
And what's your view that to improve the adoption of Kubernetes, that an internal better internal training also help in terms of like mirroring, like real life, real world applications? See, again, as I said, you first have to tackle the big players in your enterprise. So if they're able to adopt Kubernetes, then the the small ones who kind of follows suit that is one approach. But at the same time, obviously you need good training. You need good training on the actual Kubernetes, you need good training on the Kubernetes platform offering that you might have developed. So say, for example, if the Enterprise has a platform offering on top of the native Kubernetes services, then you need to train your developers and engineers on that offering as well.
That is equally important and that is where you can have free labs, companies like say, Instruqt and then you can even set up your own lab environment where you can help people kind of play around with that lab easily on board. Then you need good documentation, guided paths, all of that. Basically everything that we have been speaking about, all of that kind of combines into that full fledged adoption kind of. So to be very fair, I mean, always when I think about training, there are two types of training.
One is the training on the actual asset or the technology. So in this case, it's Kubernetes, for example. I need to know what is a deployment, Then I need also training on what are the standard ways my enterprise wants me to adopt Kubernetes, which might be a little bit different from the generic way it's an abstraction on top of the generic way for example, we might want that okay all of the Kubernetes clusters I should have different type of node pulls for front, and so my frontend services should be deployed on one node pull. My backend services should be deployed on another node pull.
Something along those lines I might have. So basically that is the abstraction on top of the generic Kubernetes. So that training is also important because then everybody knows, okay, my enterprise wants me to deploy and use capabilities in this way. So both of this training is important, and your free labs and your guide documents and your learning guides and your training paths kind of help in that overall journey. Okay, cool. Well, my last question is on platform engineering.
Is it just another trendy term or in your opinion, is it going to have a real impact on the software engineering world? So I am personally part of the platform team. So I believe extremely strongly in platforms. And if you see even Martin Fowler, who is very well known, very respected in the industry, wrote a lot of books, he also has good documentation, good guides on platform. If you have read the book called Team Topologies, which is a very well known bestseller book. They have actually referenced the platform team as an enabler team.
So Platform is here to stay from what I see. Okay. I don't think it's something that is just a kind of a fad or anything. It's something that I think actually gives value. So your platform team ideally should be to reduce the overall cognitive load on your developers, because to be very clear, we are saying shift left, shift left, shift left. But the moment we are doing shift left, we are actually putting more and more pressure on our developers and engineers. Earlier a developer would just know Java and it's okay.
Now our developer needs to know Java, they need to know PostgreSQL and they need to know how to do graphQL They need to know how to write Terraform. They need to know how to debug a Kubernetes cluster. So, so much pressure is right now on a normal developer that the actual essence which is the only code, the code and the design that is not getting that much importance. The platform team is a way of offloading some of that cognitive load to the platform team so that your developer can actually focus on what he wants to do. So when a developer wants to create web applications, their shopping cart application, he should not have to think about, for example, how do I create my Kubernetes cluster, how do I deploy my services? He should have a very nice kind of a flow that okay, he has a repository. He's pushing code on the repository.
The code gets pushed into an artifactory kind of the stuff where the artifact will be stored and then deployed by another CICD pipeline. So those add ons that you give the that is again the developer experience. Right. And the platform is giving you by helping you the tools, the footings, the assets on which you build your application. The platform is effectively enabling you to reduce your cognitive load and just focus on what matters to you, which is the code, which is the business value that you get out of the code. Everything else which is different, different. To be very fair,
Cloud also came with the same promise cloud came with the promise that you don't have to focus. But when we actually started using Cloud we saw that even the cloud is much better than on prem you offload a lot of things to the cloud provider still, you have enough stuff you have to worry about. Okay, how do I deploy my code? How do I setup my infrastructure? How do I do monitoring? How do I do authentication? How do use logging? Now, the platform is an abstraction on top of the service provider, the cloud provider, and it's kind of taking care of all of these cross-cutting concerns so that as a developer and as engineer, you can rely on the platform team to do all of this common functionalities and you can just focus on your code. So again, I personally believe platforms are here to stay. Platform is the future and many companies, many big enterprises are investing a lot of money in platforms. For example,
I don't know you were aware of that initiative called PlatformCon. It's growing tremendously every year. I mean, I think last time they had a huge, huge participation. This year it might be even more so. Many people are interested in platforms and I think they are here to stay.
Yes. Thank you. Thank you for the explanation. I think if you want a developer productivity first, you know developer happiness, right. Make it easy for them.
That's really important. Exactly. Thank you so much for sharing your valuable insights today. We really appreciate that. Thank you, Turja. Thank you so much, guys. It's a pleasure.
2023-09-13 22:36
