Abstraction on Abstractions with Martez Reed

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

Hey, you're listening to the CTO advisor podcast. We're continuing our series of looking back at the CTO advisor virtual conference back in 2020, April. This week, we have Martez Reed, director of technical marketing at Morpheus Data. That's his day job. We're not going to talk a lot about Morpheus, but we are going to talk about one of the core problems that Martez has been trying to solve basically his whole career, which is abstractions, which in practice, normally pretty good thing, you say, Martez?

Yeah. I mean, at its core, it's definitely a great idea where I'm trying to take away some of the complexity or at least not expose some of the complexity of the underlying system. And what it also allows technology vendors and organizations to do is hopefully simplify consumption of network storage, compute, whatever it ends up being. Yeah. And I think when we look at abstractions, if we get into this conversation specifically talking about storage extraction on Kubernetes on Twitter, but when we look at abstractions, we look at the ultimate abstraction, which is AWS.

We can do incredible things with abstractions and AWS. I can deploy an application that has redundant storage, redundant networking, terabytes or terabits of bandwidth. I can replicate from site to site with simply some clicks of the button. So powerful abstractions. And we want to bring those abstractions on premises because both of us believe in hybrid infrastructure. We have, you know, the Lambda instances, serverless instances sitting right next to our Oracle stack and the two interacting. And what I've seen in practice is that when we bring the public cloud concepts on premises or hybrid, stuff breaks.

And the question is, how does it break, where does it break, and how do we fix it? So let's, let's, let's tear apart like this, this abstraction we looked at on Twitter, which was, it was a company Portworx owned by, well, a solution Portworx owned by Pure Storage now, which abstracts away persistent storage in Kubernetes. Pretty good concept. You're closer to the cloud native stuff than I am. Neither one of us are making the claim to be cloud native people, but you're closer to it than I am.

Can you kind of explain the concept? Yeah, at its core, the idea is, let's say, as a developer, you want to be able to deploy a stateful workload, stateful being something that has persistent data, such as a database, something where I need data to stay and not be ephemeral as the container comes and goes. The challenge is, as part of the integration for the Kubernetes cluster to talk to the underlying storage, well, it becomes, what's that, what's that touch point of how it interfaces and interacts with the underlying storage?

And so in the case of Kubernetes, you have persistent volumes and persistent volume claims. Persistent volumes being the declaration or the instantiation of the class or object of storage that I want. So I might say for my database, I want a 20 gigs of storage. And in the case of, let's say, storage classes, I want it to be highly performant. The question then becomes, how does Kubernetes then map that to an underlying block device on the backend? And so you get into the case of, well, the developer doesn't know about whether it's running on Pure, whether it's running on HPE, whether it's running on, insert your storage vendor of choice.

The idea would be, I should abstract that away. And the developer doesn't have to concern themselves with the nuances of the underlying storage. For me, the challenge becomes, you start to have a sort of delineation that is no longer there from a traditional IT management perspective, where it's often traditionally been, well, the storage administrator carves out some storage. You start to see some of this when you talk about virtualization with vSphere, where the storage has been presented up to your ESXi host.

And then from a VM perspective, you've abstracted away some of the low-level nuances. What's now happening is we're starting to have another abstraction, so to speak. Where we're then exposing the low-level storage into the Kubernetes cluster, but it's not exposed in the same way that we've traditionally seen with, let's say, direct to the host. It's similar to the VMware ESXi level, but it's a little bit different in the idea that now we're expecting a further removal of, I would say, continuity from an IT operations perspective.

Typically, the virtualization administrator is a little bit closer to the storage admin. So now we've moved to the consumer of that more native storage access up to the developer. And so there starts to become some challenge there, I think, in my opinion. So I think let's dive into what some of those challenges are, and we'll use historical perspective. You're absolutely right. The VM admin is closer to the storage admin. As a matter of fact, the industry has spent the past, I'd say, seven or eight years giving the VM admin tools to help troubleshoot that level of abstraction.

Give you an example. I can do snapshots in a storage array. I can do snapshots in VMware vSphere. VMware vSphere allows the ability to do a snapshot from a software level. Super efficient, but not as good as the implementation on the storage vendor side. Like the storage vendor side knows storage much better than VMware. So what VMware has done in the past, or what they worked with storage vendors for, is when you initiate a snapshot, instead of it being a software snapshot, it is a snapshot.

It makes a call to the Dell EMC, or the Pure, or the HPE storage array to do the native function that makes the snapshot. So when I go to replicate, reinitiate, hydrate the snapshot, it is all native. When it breaks, I'm using the storage solution's native tools to fix the snapshot, or the or corruption in the data pieces. That's just one example. There's examples across the board because of the history between VMware and the storage industry. Matter of fact, VMware VMworld is sometimes called the biggest storage conference of the year because most storage vendors are selling into the VM admin piece.

Portworx is now, I don't want to call it a shim, but it's something on top of that. So one of the features that I like to pick with when it comes to Portworx is replication. It does replication in software. So it allows the OpenShift administrator, the person that's consuming EKS, to basically not have underlying rights to the storage APIs. And they can do replication at the application level and not at the storage platform level. Okay. Sounds really great feature.

What you talked about, which is you're pushing it closer to the consumer. The question happens, what the question appears. And we have this question in all abstractions, especially in AWS. What happens when replication breaks? Like who fixes that? And Portworx, I don't know enough about Portworx to know about what tools. I do know enough about Dell EMC, Pure Storage, HPE, NetApp, et cetera, to know how to fix that. My operation teams know enough about that to fix that.

Don't know enough about Portworx. It's yet another tool or abstraction in my environment to manage. Yeah. And that's literally the challenge. And the argument or the counterpoint is often going to be, well, as an administrator of Kubernetes or IT organization, you're going to have to lean further into Kubernetes. But that's yet another thing when we start talking about the ecosystem that IT organizations now have to deal with. So it's you leaning into Kubernetes, you leaning into AWS, you leaning into GCP, you leaning into Azure as part of your organization's multi-cloud digital transformation strategy.

And when we actually think about it as human beings, there's really only so much bandwidth we really have. We think we can learn all the things and go fully in depth with everything, but it's actually not the case. And so the challenge becomes, yes, that application level replication is great when it works, but when it breaks, it becomes the nuance of, well, now I need to understand both how specifically the Portworx is facilitating the replication, but also hopefully understand some of the nuance of the application deployment in Kubernetes and how Kubernetes is handling some of the native interfaces with that, let's say that storage driver from a Portworx perspective.

And so we come in a situation where we have abstractions being great and simplifying the complexity, but on the flip side, it's hiding the complexity and the nuances of what we're actually going to have to deal with potentially at some point. Now, a counter to this is that abstractions is a part of computer science. Like I don't, I don't go into, I don't go, I don't implement a DOS memory manager anymore in my Windows Server 2020 deployment. That I don't worry as much, unless I'm a SQL guy, I don't worry too much about memory management.

The OS does that. And I count on the OS to do that. When there's times to troubleshoot it, I have the tooling in Windows to troubleshoot. I have to have the knowledge to know what I'm looking at, but I'm not too worried about memory management abstractions in modern OSs fix that for us. I think my challenge is as I'm looking at how fast the cloud native movement, and not just the cloud native movement is moving, but abstractions moving, there's not enough time for the industry to react.

So, but from a customer perspective, I'm supporting again, AIX, HPUS, older versions of the Linux kernel, modern Linux kernels, serverless Windows Server from 2003 all the way to 2021 or whatever the latest version is, my landscape continues to grow faster than I can learn and absorb this stuff. So I look towards vendors somewhat like, and this is where Morpheus I think comes in and we look towards the vendors to manage and help us with that abstractions. The question is, are vendors the right place to look at for help?

Because I can't do it all. Where do I look to kind of help me get the insights that I need while being able to still leverage abstractions to get work done quickly? Yeah, that's a really good question. And traditionally vendors haven't really been that path because obviously vendors have a vespid interest in you choosing whatever their technology or their solution is. In some cases, yes, you have had similar to Morpheus had essentially overlays or platforms that focus on how to stitch things together, how to integrate components.

But just the broad challenge becomes the sheer amount of technology that IT organizations are now faced with becomes in a lot of ways inundating to try and figure out how to stitch things together, how to tie things together. And even from a cloud native perspective, we're starting to see some things that would lean towards that where you talk about, I have multiple, let's say, versions of Kubernetes or distributions of Kubernetes, let's say with an Azure Arc. I'm going to manage in my environment some AKS and EKS and some OpenShift.

And ideally I would have a platform to help facilitate that management. Just the challenge that I think as an industry, we're going to have is, as you mentioned, just the sprawl of what's next. And even as organizations adopt Kubernetes at this point, it's somewhat strange. And some would argue that it's never going to happen or it's not going to happen anytime soon. But the next thing that comes after Kubernetes, many of us in the industry may think that, well, it'll just be abstractions on top of Kubernetes.

And that's where the industry seems to be going. But I think in a lot of ways, let's say, what is it, eight, 10 years ago, I don't think many of us could have foreseen Kubernetes being what it is. And as you mentioned, things like OpenStack have sort of come and seemingly gone as a novel idea in a lot of ways, but still definitely valuable for organizations. And so it's how do I continue to manage that sprawl of technologies and really not so much technologies, but very wildly different management paradigms.

Yeah, I remember when DevOps was a thing, and it's still a thing, but when it was a thing that I would create a DevOps group, we were kind of confused as to what the operating model meant to the impact of enterprise IT. And I still hear people struggling with this is what do I do with my SAP basis DBA, the DBA function that taught this subject Joe Hall about, you know, the future of the DBA and where they fit in the org structure, even from a job perspective.

But what's happening, I'm seeing a bifurcation of enterprise IT in a very difficult concept, like we've heard the bimodal construct from Gartner. What I'm seeing is that IT executives are trying to figure out how to divvy up the DBA. Like, I don't care if you're cloud native, if you're a monolithic application, if you're something in between, you need a DBA. You need DBA capabilities. You need that knowledge of data, data structures, et cetera. Across all your application stacks, you have one DBA with multiple heads.

And I think that is where the ball is moving. Companies like Morpheus are going to help us figure out that abstraction and managing and troubleshooting that abstraction layer. I think where executives need to focus their energies at is governance and helping to determine how are they going to divide this functional capability across multiple operating models, because you do and you're going to have multiple operating models, but you only have limited resources. Tim Crawford of Avoya likes to say that, and I agree with him, that the CIO's biggest challenge is talent and recruiting and retaining talent.

And if I'm having trouble doing it in one discipline, I'm going to have trouble across the board. So I think that's the focus of the conversation and what I would like my listeners to take away. Martez, it would have been great to do this in person. Both of us are local here in the Chicagoland area. I don't know why I didn't think about just popping over to a Starbucks and us joining and doing it. I guess it's too much of a CTO advisor road trip hangover.

Yeah, maybe the next time. Maybe the next time. For people who want to connect with you, how do they do that? I'm on LinkedIn. I'm on Twitter, at GreenReadTech, G-R-E-E-N-R-E-E-D. G-R-E-E-N-R-E-E-D-T-E-C-H. Love talking tech and will share whatever knowledge I have if it's helpful. And I'll link it. Little known fact. I met Martez virtually about six, seven years ago. com to kind of anybody who wants to use the platform. Actually, I still get more views on Virtualized Geek, and I haven't blogged on there in well over a year.

And I put out a call for anybody who wanted to be new to blogging to put out a blog post. Martez was the only one to answer that. And I only have two blog posts, I think, on that entire platform that I didn't write. And one of them is his. I'll put a link to that. I've got to read what it's all for. It's actually still pretty relevant. It was talking about the IT skills gap, which is still a challenge, even as you mentioned talent acquisition and retention.

That's that's actually really funny. So I'll I'll I'll I'll link to that. com. You want to learn more about me or you want to engage with me? DMs are open on Twitter at CTO Advisor. Talk to you next. CTO Advisor podcast.