#017 – Kubernetes for Humans Podcast with Nilesh Gule (DBS Bank)

Itiel Shwartz: Kubernetes for Humans. Hello, everyone, and welcome back to another episode of the Kubernetes for Humans podcast. Today, with me on the show, we have Nilesh. Nilesh, do you want to introduce yourself?

Nilesh Gule: Hi, it’s a pleasure to be on the show. My name is Nilesh Gule. I was born and brought up in a small town called Goa in India, very close to Mumbai. If you happen to visit India, I highly recommend visiting this place. It’s known for its touristic beauty. It was a Portuguese colony, and you’ll find a lot of things that are quite different from the rest of India, which was a British colony. Our culture and food are quite different. I did my schooling in Goa, and then, when it was time to start my career, I moved to the Silicon Valley of India, Bangalore. I started my career as a .NET developer and worked in Bangalore for about seven and a half years before moving to Singapore. For the last 14 years, I’ve been living in Singapore. Over time, I moved from being a developer to a senior developer, taking on various roles across my decades-long career. I’ve done architecture roles, been a Scrum Master, and led a team that grew from three members to a 30- to 40-member team. In terms of technologies, I moved from .NET to Big Data and Java, and then when cloud came along, I was very interested in the scale and capabilities that cloud has to offer. I transitioned to cloud engineering as a Cloud Solution Architect and have been working on cloud-native applications, focusing on scalability, resilience, and making full use of cloud capabilities. Lately, I also headed a DevOps SRE team. That’s more or less what my career has been over the last two decades.

Itiel Shwartz: That sounds like a lot. Maybe I’ll ask you some questions about your history. First of all, I wonder—moving from India, not technology-related—how was it moving from India to Singapore? How is Singapore? Maybe share a bit about that on a personal level.

Nilesh Gule: Singapore has been quite good to me. I’ve spent almost 14 years in this country, and it’s been a significant part of my career progression. I have fond memories and a strong connection with Singapore. It’s one of the major technological hubs in Asia. India, as you know, is quite big, and there are a lot of opportunities there. In Singapore, what attracts people from India are the opportunities to work with leading banks, for example. The banking and financial services industries are quite strong here in Singapore, and in terms of innovation, Singapore is ahead of many other Asian countries. If you’re a technologist and like the challenge of being at the forefront of technology, Singapore has a lot to offer.

Itiel Shwartz: That’s cool. It looks like, you know, always in the movies, Singapore looks like a really beautiful city-state. It’s well-traveled and so organized.

Nilesh Gule: One thing you find when you come to Singapore is that everything just works.

Itiel Shwartz: Yeah, it sounds nice. Very different from Israel and, I guess, India as well, right? Not the most organized places. Let’s talk a bit about Kubernetes. When were you first introduced to Kubernetes? What was your role or position, and what did you do?

Nilesh Gule: I started with Kubernetes back in 2017. At that time, I was getting into the DevOps side of things, so I started learning Docker, which was an upcoming technology. Once you start learning Docker, you need a place to deploy your containers. I actually started with Docker Swarm, which was my first orchestrator. For some demos, I even used Mesos Marathon. There was a lot of competition between Docker Swarm and Kubernetes, but at one point, Kubernetes just took over. That was when I realized there was no point in spending time, effort, and energy on Docker Swarm, which even Docker themselves were almost giving up on. I started moving from Docker Swarm and other technologies to Kubernetes. Since then, I’ve been working with Kubernetes.

Itiel Shwartz: That’s cool. Was it official at your workplace, or was it more of a pet project? When were you introduced to Kubernetes in a production setting? Maybe share a bit about what the company was doing until then and how the migration happened. I know you’re currently in the financial sector, and for big companies, introducing new technology, especially one with a lot of caveats like Kubernetes, can be challenging. So, just share with us a bit about what happened and why.

Nilesh Gule: When I started, it was more for self-learning. It was a technology everyone was talking about at conferences and tech talks. That’s where my interest started. Initially, it was just about keeping myself updated. Then, around 2018, when I was leading a DevOps team, I worked with a production-grade Kubernetes cluster. Our company, an insurance company, was using Azure Kubernetes Service to deploy our applications, and I was heading the SRE engineering team. That’s where my experience with production-grade Kubernetes came in. In my current organization, a leading bank in Singapore, we have a mix of workloads running on both VPC and Kubernetes. We have a sort of multi-cloud, hybrid cloud environment where we use Kubernetes to a certain extent.

Itiel Shwartz: How did people get the hang of it? I know learning Kubernetes for the first time can be challenging. How did the implementation go? Did you migrate existing applications into Kubernetes, or was everything greenfield? I know that many in the insurance and financial sectors are only now migrating to Kubernetes. Think about yourself a few years ago—what are the most important things you wish you knew back then, things that were hard or very good?

Nilesh Gule: In my experience, when you start with Kubernetes, it’s easy to get going with “Hello World” applications. You can containerize your application using Docker or another container platform, create an OCI-compliant image, and then deploy it to Kubernetes. That’s the happy path. Developers find it easy at that stage. You expose the application using a service, then use Ingress—still good. But when you get into advanced use cases, like auto-scaling, stateful processing, working with custom resources, blue-green deployments, or scaling based on metrics, that’s when you need a change in mindset. 

For example, we were using Microsoft Azure as a cloud platform, and I remember an application lead saying, “Our SRE team can just spin up multiple replicas of our application, and everything will handle a large scale.” But if your application isn’t designed for it, just increasing the number of replicas won’t help. For instance, if you’re processing messages from a queue and your consumer picks all the messages in one batch, having four replicas just sitting there idle isn’t ideal. It’s not making efficient use of your resources.

It’s a change in mindset when building cloud-native applications. You have to think not just about how your application behaves but also about the surrounding aspects like high resiliency, doing things in small batches, and supporting patterns like the 12-factor app, where you scale out rather than up. Developers and operators need to understand that simply increasing replicas or servers won’t solve all your problems. 

Another key point is that when moving to cloud-native applications, it’s not always about 100% availability. You have to be prepared to handle failures gracefully. If you’re developing microservices, you need patterns like circuit breakers, retry mechanisms, and so on, to make your applications more resilient. These are the mindset changes required, which can be difficult when moving from monolithic applications to microservices or cloud-native applications.

Itiel Shwartz: What you’re saying makes a lot of sense, and I think not everyone fully understands that. But I wonder—how does a simple developer working in a bank or tech sector know they need to build their application differently because it’s cloud-native? How was the process of introducing this technology to other teams? Were there teams that already worked on Kubernetes, or did they need to change their applications to be more cloud-native? What do you suggest for companies migrating to Kubernetes? Should they take one team to be evangelists, or only write new things for Kubernetes? What’s your take?

Nilesh Gule: In my experience, when we started a cloud migration project, we first did a survey and built an inventory of which applications were using which technology stack. Then, we looked at which applications needed to be rehosted, refactored, or re-architected. As a first step, we conducted training for the teams that would be using these new technologies, making them aware of what’s coming and what changes they need to make. They have to understand it’s not just about lift and shift; there are going to be impacts that need to be understood.

When starting to migrate a project, I suggest choosing a small, low-risk application so everyone involved— from the infrastructure team to the application team, operators, and even DevOps or SRE teams—can understand the process. If you’re migrating an application, it might not have all the observability traits. That’s an opportunity to introduce observability and make your application more observable. Once the application is migrated, share the lessons learned with the rest of the teams. That way, you build a pathway for subsequent teams to adopt the new tools and technologies.

Itiel Shwartz: That makes complete sense. What would you say was the biggest challenge when you did the migration?

Nilesh Gule: I think the culture of the organization plays a key role. When we talk about DevOps, in many companies, DevOps is just a separate team. The application team builds the application, then hands it over to the DevOps team, who are expected to somehow push the application by building pipelines. The key challenge is collaboration and bringing in a culture change. If you want to implement DevOps the right way, you need both developers and operations working hand in hand. This is crucial when adopting DevOps, platform engineering, or automation.

Itiel Shwartz: That makes complete sense, but it can be hard to change the culture of an existing organization. Sometimes it takes time, but someone has to push it; otherwise, the organization will stay in its old ways. So, we’ve talked about the migration, but now let’s say you’ve migrated. What are your current challenges with Kubernetes? What are the biggest things, as we’re starting 2024, that aren’t working as expected or that you’d like to change or improve?

Nilesh Gule: The biggest challenge with Kubernetes right now is the ecosystem. There are so many options in the cloud-native landscape. Sometimes it’s challenging for decision-makers to identify the right tool for the right purpose. As architects or decision-makers, it’s important to understand how certain things work. For example, with service mesh, there are different providers—Istio, cloud provider offerings, etc. How do you choose the right one for your business, application, and organization? The pace at which new open-source projects and tools are being integrated into the Kubernetes ecosystem is a big challenge.

Itiel Shwartz: How do you solve that? You work in a big bank—how do you choose? What do you do in 2024? Are you implementing new tools or exploring new ones? I agree with you that Kubernetes is a chaotic environment, and even if you make the right decision today, it could be obsolete in a year. How do you cope with that? How do you prioritize and know what to focus on, like service mesh?

Nilesh Gule: We use the concept of a technology radar, not just for Kubernetes but for all technologies within the organization. This gives us a view of what is currently in use, what we should keep an eye on, what we should stop using, and what we should look forward to. We gauge industry trends, look at the progression of different projects, and try to keep things interoperable. We avoid using tools or technologies that are very vendor-specific so that if we need to switch to something better in the future, the effort is minimal. We try to use open technologies and open standards as much as possible. We review our tech radar periodically, like every six months, to see if what we said was good last year is still valid or if we need to change direction.

Itiel Shwartz: That’s a good answer. Now, people can’t see it because we’re on a podcast, but behind you, there are a lot of MVP awards. Maybe share a bit about what those MVPs stand for.

Nilesh Gule: The MVPs stand for Most Valuable Professional. It’s a recognition from Microsoft for people who are industry experts. We’re not Microsoft employees, but we evangelize different technologies, and Microsoft recognizes our community contributions. I’ve been lucky to receive this award since 2018, so six or seven times now, for Microsoft Azure. I do a lot of public speaking in and around Singapore at different conferences, usually about Kubernetes, service, and containerization. For those contributions, I’ve been awarded the MVP award.

Itiel Shwartz: Super cool.

Nilesh Gule: You can also see the Docker Captain badge, which is similar. Docker recognized my community contributions for containerization, and last year I was awarded Docker Captain.

Itiel Shwartz: That’s super cool. I love hearing about what people do and what they love. You talked about Microsoft—do you have anything planned, like a blog, book, or anything else you’d like to promote in the upcoming year? Are you speaking at KubeCon or Microsoft Days?

Nilesh Gule: I’ve spoken at Microsoft Days when it was happening in Singapore, and I’ve also spoken at API Days in Singapore and Australia. I haven’t had the opportunity to speak at KubeCon yet, but there was a recent Kube Day event where I had the opportunity to speak. Personally, I’m closely following platform engineering—the website, podcasts, and YouTube channel. There’s a lot of good content there, and platform engineering is picking up a lot recently. That’s what I’m currently interested in, and I might Embark on something related to platform engineering and GenAI.

Itiel Shwartz: That’s cool. Platform engineering is becoming the new DevOps—everyone is talking about it, and everyone wants to be there. To conclude our podcast, I always like to ask people, what does the future have in store? What do you think Kubernetes will be like in a few years? What will be the biggest trend, the biggest change? Your prediction for the future?

Nilesh Gule: The pace at which Kubernetes has evolved is rapid. When I started with Kubernetes, I didn’t think it would go so fast, and the ecosystem wasn’t that big. But now, almost all kinds of workloads are being run on Kubernetes. At some point, I wouldn’t be surprised if Kubernetes becomes part of our operating system, like many tools and utilities are nowadays. It could be that Kubernetes becomes just another part of our life. That’s the possibility I see in the next five to ten years.

Itiel Shwartz: That’s a cool prediction. I think that’s where the industry is going. It’s hard to know the future, but I see Kubernetes becoming like Linux—most of the time, I don’t think about Linux anymore; it’s just a base image in my Docker. I hope Kubernetes will reach that stage. I think we’ve wrapped up. Anything else you want to say to our audience?

Nilesh Gule: It was nice talking to you about my experiences and thoughts. I hope the listeners find it useful. It was a pleasure talking to you.

Itiel Shwartz: It was a pleasure for me as well. Super interesting journey and insights. Thanks a lot.

[Music]

Nilesh Gule is a Vice President at DBS Bank, where he leads the design and implementation of scalable and innovative solutions using hybrid cloud, big data, and emerging technologies. He has over 2 decades of experience as a software developer, architect, and leader in various domains such as BFSI, healthcare, and retail. He is a Microsoft MVP for Azure since 2018 and the first Docker Captain in Singapore for his excellent contributions to technical communities.

Nilesh is passionate about learning, adopting, and experimenting with new technologies, and sharing his knowledge and insights through blogging, speaking, and organizing events. He is a certified Azure Solutions Architect Expert, DevOps, and Data Engineer Associate, and a co-organizer of the Microsoft Azure Singapore user group. He lives by the motto of coding with passion and striving for excellence.

Itiel Shwartz is CTO and co-founder of Komodor, a company building the next-gen Kubernetes management platform for Engineers.

Worked at eBay, Forter, and Rookout as the first developer.

Backend & Infra developer turned ‘DevOps’, an avid public speaker who loves talking about infrastructure, Kubernetes, Python observability, and the evolution of R&D culture.  He is also the host of the Kubernetes for Humans Podcast. 

Please note: This transcript was generated using automatic transcription software. While we strive for accuracy, there may be slight discrepancies between the text and the audio. For the most precise understanding, we recommend listening to the podcast episode