On this episode of the Six Five Webcast, host Paul Nashawaty is joined by Dell Technologies’ Nivas Iyer, Sr. Principal Product Manager, for a conversation on overcoming data storage challenges in modern IT environments, transitioning from traditional VMs to Kubernetes.
Their discussion covers:
- The evolution of data storage from VMs to Kubernetes.
- Key challenges businesses face when managing data storage in Kubernetes environments.
- Best practices for implementing data storage solutions in Kubernetes.
- Dell Technologies’ approach to simplifying data storage for Kubernetes.
- Predictions for the future of data storage and Kubernetes.
Learn more at Dell Technologies. Also, discover more about Dell’s Kubernetes data storage software here and explore Dell’s free 90-day evaluation for Dell APEX Navigator here.
Watch the video below, and be sure to subscribe to our YouTube channel, so you never miss an episode.
Or listen to the audio here:
Disclaimer: The Six Five Webcast is for information and entertainment purposes only. Over the course of this webcast, we may talk about companies that are publicly traded and we may even reference that fact and their equity share price, but please do not take anything that we say as a recommendation about what you should do with your investment dollars. We are not investment advisors and we ask that you do not treat us as such.
Transcript:
Paul Nashawaty: Hello, and welcome to today’s session. We’re here to talk about VMs and to kubernetes and how to overcome the data storage challenges. My name is Paul Nashawaty, and I’m the Practice Lead at The Futurum Group. I cover the Application Development and Modernization Practice, and I’m joined today by Nivas from Dell. Nivas, would you like to introduce yourself?
Nivas Iyer: Hi. Nice to meet you, Paul. Hello, everyone. My name is Nivas Iyer. I’m the principal product manager here at Dell. I manage the kubernetes storage initiatives here. I’m really excited to be talking to you, Paul.
Paul Nashawaty: Yeah, same. This is an exciting time. I mean, cloud-native applications and orchestration around kubernetes is really popular and it’s really growing, but there’s a lot of challenges that go along with it. As organizations are looking and balancing VM and kubernetes requirements for these enterprise applications, they have to think about data storage challenges. Nivas, when we look at the overall landscape and the architecture for 2024, how are organizations viewing old and new ways of application building and VMs and kubernetes? What are they doing?
Nivas Iyer: Paul, I have been in this industry for over 10 or 12 years now, and I’ve seen a rapid change from bare metal to VMs, and I would say the first, the 2010 timeframe where people looking for server consolidations and looking for software-defined architectures. VMware helped in that era of the first age of cloud building, if you will. The next age, if you will, was beyond that to app modernization. That’s where kubernetes has come in as a layer that provides a platform for a pass platform as in a container basically slicing the operating system to make applications more easily consumable and more easily dynamic and fitting in with a more agile transformation with DevOps practices. Kubernetes fits right well into the application architecture changes, and of course VMware has led the change with the infrastructure changes, but we are also seeing some of those VMware components or the ideas coming flowing back into kubernetes a little bit.
Paul Nashawaty: That’s great. I agree with you. I mean, we see 88% of production workloads running in VMs today. We also see that in our research, we see 94% of organizations running on two or more clouds. This adoption across cloud-ready and cloud-native environments has really taken off really exciting, and it’s all about that modernization practice, and organizations that are driving towards this are really looking for seamless ways to do this. But heritage applications or legacy environments have some strict requirements. When we look at those applications and the data that goes along with those applications, we’ve seen a rise in adoption in databases like Redis and MySQL and Postgres and kubernetes environments. That’s a challenge for organizations. How is this changing the way enterprises are approaching stateful applications in their ecosystems?
Nivas Iyer: Kubernetes, it started out and nowadays like ubiquitous across the board as I mean for analytics to machine learning to GenAI, all the way, and it’s also finding its way back into transactional type applications and also on the systems of records and systems of engagement on the front end side, because it provides that agility, the modern flexibility to make sure that your applications are portable. Also, it’s truly multi-cloud in a way that you want applications to be available either on a particular cloud at one time, and you want to move that application to another cloud. Kubernetes provides that flexibility and availability to do that. So, initially, when kubernetes started, it was primarily focused on stateless application. That’s why you had concepts of load balancing with replica sets where you had stateless component that could be burst very quickly with the services front end, and then you could…
But then later on, as they added a database or stateful application that needed to maintain state, you had to make changes to it. Kubernetes introduced a concept of a stateful set, which basically provides a headless service, and then you can directly talking into the parts. Then now the resilience became a much important aspect as to how do I make sure that my components are more resilient in a stateful manner? The other aspect with kubernetes is how it consumes storage. Earlier when kubernetes introduced the concept of consuming storage, it had the concept of an inbox driver, or basically each storage vendor writes their own driver in the kubernetes community. Then it became really unwieldy because there were so many different types of volume types and the Codebase became unwieldy.
Kubernetes moved to a concept of a driver, of a CSI driver. Basically, it’s an interface that every storage vendor would then implement. Then kubernetes consumes that interface in a standardized fashion. Then consumes a storage and attaches it to an application, and they create other dynamism with the concept of percent volume claims, percent volumes, where you have applications can define, “Hey, I need this much amount of storage,” these other kind of, “I need read, write once, read, write many,” whatever. Then kubernetes just does it for you in a very declarative fashion, and the applications are, to a certain extent, totally decoupled from the storage implementation as 12 factor applications required.
Paul Nashawaty: What you’re saying is it’s a really super easy problem to solve, right?
Nivas Iyer: It is, but there are gaps. There are gaps with the CSI driver, because the challenges are with resilience, and the challenges are with making things like disaster recovery. With a lot of the customers that we deal with here at Dell, when they’re looking at modernization, when you look at especially transactional type applications where they are looking for, “Hey, I want this to be resilient to hardware failures.” Some of the CSI concepts are not there yet. At Dell, we worked on, okay, how about we can try to create a set of modules or application that could fix these things? These need to be fixed as to, okay, how can I make sure if there’s a node that failed, how can I make sure that those stateful applications are available in other healthier nodes? For example. Or things like, I have a particular data set here. I want to make sure that data is replicated to another site.
In case this site fails over because of storms, hurricanes, fires or whatever you name it, but the applications are still there, it automatically switches over to the other side and continues to deliver from the point where the data is not lost. All of those are typical, I would say, enterprise storage challenges that are solved in the traditional applications, but it’s done in a particular way, just like an Oracle databases where VMware has its certain ecosystem, but kubernetes doesn’t have some of these concepts. That’s where some of these concepts need to be filled in. There has been, I would say, innovation that was needed to fix that complexity to address these enterprise use cases.
Paul Nashawaty: That makes a lot of sense. I mean, when I think of these applications and how they’re being modernized, I have a maturity model that I usually talk to organizations about, which is starting from heritage applications that may be encapsulated into a VM, then from there, maybe in what I would call phase three, which is moving into more of a fat container. Then moving from that fat container to microservices than a fully elastic environment, there’s five stages for these applications, and everything you’re talking about aligns to those applications within those stages, because organizations need to be able to bridge the gap between the old and the new. These hurdles that are widespread with these kubernetes adoption that we see, as you were talking about, many of these databases are running and they need that persistent storage requirement. Can you talk a little bit more about the biggest challenges you’re seeing with customers and how Dell is helping address these challenges?
Nivas Iyer: Some of the key challenges that we see is the knowledge needed. Knowledge gaps are big. We have folks who are focused more on data governance and health and disaster recovery and making sure that the data is appropriately secure and things of that nature. Then you have folks who are more app-modernized, working in a DevOps fashion, and they’re very, very familiar with these kubernetes tool sets and things of that nature. Now these traditional IT workers, now they are supporting these newer applications, and sometimes they have a hard time learning these new tools and modernizing it. They would love to have certain tool sets that they are more familiar with and ease of use and scalability and things of that nature.
That is one area that I see is one of the big challenge that we need to do. The second thing, as you mentioned about this multi-cloud aspect, now we have seeing that so much kubernetes, we are seeing organizations saying, “I have like 30, 40, 50 clusters of kubernetes,” and all of them being, “Okay, I want to have a central data locality,” or, “I want to manage it in a centralized fashion when administrative standpoint.” Administration becomes very challenging when you are highly, highly distributed like that. Again, that’s another aspect of how do you manage the scale and complexity, and the fact that kubernetes is also a very, very evolving and a rapidly evolving. That’s actually a third challenge. We see a lot with organizations saying, “Hey, the kubernetes are moving at three releases a year.”
I mean, it’s very, very fast. Traditional IT generally doesn’t move that fast. Now they needed tools to say, “Okay, how can I make sure that I’m always compliant? I’m always refreshing my infrastructure. I’m always making sure that I can keep up with all the changes happening so rapidly.” These are some of two or three key challenges. Then of course the fourth challenge being, I have my traditional applications. They are very data governed and they have secure and all of that. Now I want to bring all that goodness to kubernetes but without impacting the application owners, how they write code and how they consume storage, we don’t want them to impact too much complexity on the application side. I want to take some of that complexity away from them and build it on the storage side and administer it seamlessly.
Those are the four major challenges that we see that we have looked to address in some of the product offerings. We recently announced the Apex Navigator for Kubernetes in May this year. That, again, takes some of our components that we built in the open source and through CSI and CSM, and then builds that layer of user experience that provides them that scale, reduces the complexity, provides them. Then as a journey, as a continuing evolving journey, we would be looking at lifecycle management, looking at simplicity in terms of how do you enforce some of these data capabilities from a simpler fashion for an organization?
Paul Nashawaty: I mean, it’s very interesting the perspective that you were sharing with regards to business continuity, data protection, data recovery, and how these organizations are taking that into consideration. We were talking about earlier, you and I were talking about on our briefing, our Futurum research showing that 20% of organizations found that it was critical that their applications were portable, and we found that 67% indicated that it was very important to their organization. That’s because of similar reasons that you’re talking about, which is the ability to move the application from core to edge to cloud and having the architecture and the infrastructure to support that. As you modernize, as you build these applications, whether it’s BCDR or if it’s workload burst capacity, or if it’s just the ability to move applications across, I mean, I was looking at my recent research the other day, and I was noticing that in the next three years, we were seeing that the edge locations are having 500 to 1,000 applications worldwide across these edge locations.
That means that those applications need to be able to be moving around and be it adjusted. If they’re built on-prem or in a public cloud, they have to move to the edge location, portability is key. Again, there’s a number of reasons to be that way. Then of course, everything that you mentioned with regards to the CSI driver and container storage, container storage modules, all aligned to that perfectly. As we get towards the end of the session here, I want to ask about one of the big challenges that we see with regards to the need to make kubernetes easy, especially for admins and DevOps teams that are looking at new technologies. For these organizations looking to manage multiple kubernetes clusters, as you know, that’s pretty complicated in some environments, what does the role of UI/UX design play in the storage management?
Nivas Iyer: When you look at kubernetes, I mean it was defined as a CLI-based tool. Of course, it requires, I would say, intricate knowledge of understanding things like YAML, the objects, the kind resources. When you write code, I mean you’re essentially writing a code, it’s infrastructure as code. You have to be fairly comfortable with coding to actually leverage kubernetes. A lot of our administrators that we see, they are not interested in coding as much. They’re interested in just performing their work as in just saying, “Hey, I have a disaster recovery scenario. I need to fail over to another site,” or, “I need to fail back,” or, “I need to set up a backup policy to make sure that all of my application components are getting backed up to provide that recovery, time objective, recovery point objective, how can I restore applications in case something goes wrong?” Or, “How do I enforce to make sure that we have appropriate quotas set?” Because the applications, they have certain quotas and they also want to make sure that there are resource constraints and things of that nature.
All of that so they’re doing their typical day-to-day administrative functions, and coding would be a huge leap for them to perform that. Especially, I have talked to one large energy company, and in fact the administrator was saying that 10 years ago they had 13 storage administrators and now they have only one person. This person, he was responsible for managing all the applications, including the SAPs, the Oracles, the VMware, the kubernetes, and all the modern applications, everything that requires. They have very strong storage data governance concepts to make sure that all the applications are backed up, they are replicated, they have DR, they have all of this. It is very, very hard for this individual to be able to work with 20 different tools. They wanted centralization to make sure, “Okay, I am familiar with certain things I want to automate. I want to use UX. I want to use ways in which I can scale myself to solve all these challenges rather than me having to learn like many different tools.”
Paul Nashawaty: Yeah, it makes sense. Actually, what I’m seeing in the research is that simplification of the interface is becoming more and more of a requirement for organizations. In fact, what we’re seeing is 67% of respondents in our recent research showed that they were hiring generalists over specialists and really focusing in on having generalists do the actual day-to-day and requiring from the vendors to simplify the solution to make it easier for the generalists to do the work. I think that what you’re talking about with regards to having the increased flexibility to go down to the command line and write lines of code or having a UI experience is definitely the interaction between where you’re meeting the organization where they need to be. That’s an important factor, because you can go as deep or as high level as you need to go, as the client need to go.
Nivas Iyer: The idea is to not have just one or the other, it has to have both. That’s where we focus on having both. We have focused a lot on the CLI aspects until now. I mean, before we had the Apex Navigator, we focused too much on DevOps community. We want to focus on automation operators, YAMLs and making them easier from that angle. But then we are now addressing the administrative angle saying that. Now we have both sides of the equation. We have an administrative function who’s looking at larger big picture scale and larger tasks, and we also have the DevOps personas who are looking at their own things. For example, you may have developers want to doing their own backups and restores and things like that, for various use cases. Those are the two personas and you have to address both.
Paul Nashawaty: Yeah, no, absolutely. Look, I want to thank you Nivas for your time today. This is really, really exciting, because the insights and perspective that you’ve shared, it’s really just the tip of the iceberg for what organizations need to know. This is a lot here for them to kind of go through and unpack. Where would you recommend the audience go to get started to just try this out?
Nivas Iyer: I would recommend we can go to dell.com/apexnavigator, where you can learn more about the Apex Navigator for kubernetes offer. You can sign up for a free 90-day evaluation. That way you can get started with this and there is no commitment required. You can sign off very quickly. It’s a SaaS offer. The other aspect I would recommend you can go developer.dell.com that has a lot of our developer relations and also some of our DevOps offers that include everything from CSI, CSM and also Ansible, Terraform, all the IEC components as well.
Paul Nashawaty: Nivas, thank you very much for your time today. This has been a great conversation. I am sure I enjoyed it. I know we just touched on a little bit here. I’m sure the audience enjoyed just the perspective of trying to figure things out, trying to figure out where they need to go next in their modernization journey and how they really want to take that VM to kubernetes approach and how they manage all their data with it. It’s a lot happening. I want to thank you for your time. I also want to thank the audience for attending our session today. There’s a lot here to unpack and I recommend going to the websites that Nivas mentioned. Also, if you want to learn more, feel free to go to thefutureroomgroup.com. Thank you very much.
Other Insights from The Futurum Group:
Application Development and Modernization
The Evolving Role of Developers in the AI Revolution
How Dell Supports Customers with AI – Six Five On the Road at Dell Technologies World
Author Information
At The Futurum Group, Paul Nashawaty, Practice Leader and Lead Principal Analyst, specializes in application modernization across build, release and operations. With a wealth of expertise in digital transformation initiatives spanning front-end and back-end systems, he also possesses comprehensive knowledge of the underlying infrastructure ecosystem crucial for supporting modernization endeavors. With over 25 years of experience, Paul has a proven track record in implementing effective go-to-market strategies, including the identification of new market channels, the growth and cultivation of partner ecosystems, and the successful execution of strategic plans resulting in positive business outcomes for his clients.
