Hybrid Cloud? Multi-Cloud? Cloud Native? Whether you're already there or planning to migrate, it's critical to understand the networking implications that can have a big impact on your happiness. In this episode, Jim talks to networking expert Aniket Daptari who shares key architectural considerations and best practices to help minimize the bumps you may encounter in your cloud journey.
Listen to other Navigating the Cloud Journey episodes here.
Cloud Networking: Considerations & Best Practices
Jim: Hey everybody, Jim Mandelbaum back for another adventure of navigating the cloud journey podcast. Today, I'm joined by Aniket Diptari with Nutanix. He is Director of Product Management with an emphasis on networking. So I love the fact that we're going to get into a conversation around cloud and networking in the cloud. Welcome.
Jim: Let me get started with this. And I love this question because it it's a different answer for everybody. And especially because you're coming from Nutanix. I'd love you to help me understand from your frame of reference, what is the difference between public cloud and private cloud?
Aniket: Sure, first of all thanks for having me here. It's a privilege and allowing me to air my thoughts and what I've gathered from over the years from my experience. So, to get to your question what's the difference between private and public cloud. Before that let's quickly address what cloud really is. And what I wanted to say from what I have learned and read and from all the experience I've gathered, cloud is really an operating model. It's not a location. It's not a destination we need to get to. It's an operating model. And it has certain operating principles. These principles can be applied either in the private or the public data centers. And these principles are self service provisioning, a high degree of automation, and on demand consumption of infrastructure of services. So that's what cloud is.
Now to your question. What's the difference between private and public? It's as simple as infrastructure that's either owned, operated, and managed by an entity is considered private and infrastructure that's owned, operated, and managed either by an Amazon at a Google or an Oracle or another third party that you don't own, but you go and rent from is basically public cloud. So as long as the infrastructure is adhering to the cloud principles I spoke about self-service, provisioning, automation on demand, self-service consumption, that's the cloud. This cloud can be owned or rented. If it is owned, it's private. If it's rented from it's a public cloud, right?
Jim: I like that. If you own it, it's private. If you rent it as public. That's a really good little blurb. But since you're a networking guy, let's kind of talk about some architectural implications of owning it versus renting it. Maybe you can dive into that a little bit.
Aniket: There's one quick point I want to make about cloud, and then I quickly get to networking whether on premise or the public cloud. And when I say on-premise, I do mean private cloud, I will tend to use the terms interchangeably. So, what we are increasingly seeing is that there is a macro shift from an all or nothing public cloud mindset to a cloud smart mindset that entails, matching the workload to the best infrastructure you have, whether it be private or public based on numerous considerations, different considerations, whether it be cost or performance, security, compliance, business continuity, so on and so forth.
So, what we are seeing is that increasingly customers are shifting towards a multicloud, a hybrid cloud mindset. And this has been backed by some surveys that that are available surveys conducted by Gartner, by other analyst firms like Vanson Bourne, et cetera. And they validate this mindset shift that we are observing. So, while this is happening, while we have cloud both private and public and the customer's mindset is shifting towards multicloud, networking has a very key role to play in all of this in the customer's journey, whether it was on premise or evolving to public and multi public clouds. So, what is that role? That's essentially your question. Fundamentally networking has two parts to it, connectivity and then security. Right?
So, the first role obviously is to connect workloads. And connecting not just workloads themselves have different components. So, connecting interconnecting workloads are distributed or scaled, and there are multiple copies running. So, providing that fabric of connectivity, this connectivity needs to be ubiquitous. This connectivity needs to be uniformly, low latency, high bandwidth, or the user experience to be consistent across the board. And there is also the connectivity aspect to the consumer, to the user who's trying to consume these workloads. So, there's a connectivity aspect to it and then there is a security aspect to it, which also happens in the network- a portion of the security, of securing both workloads and the access to workloads. A portion of that securing also happens in the network. And this networking becomes particularly important because it needs to adhere to the cloud operating principles we spoke about earlier in the conversation. So that's sort of what role the networking has to play.
And this role by the way, does not change. Whether it's on-premise whether it's your private cloud or the public cloud, this role remains the same.
Jim: Okay. So, we already know from talking to everybody that on-prem, isn't going away anytime soon, we know that. And we also know that companies that tried the lift and shift, it was a failure because it just, you know, you can't just lift it and expect it to operate the same and we can't expect the return on investment. So, we know that folks are gonna run on-prem and they're going to start shifting workloads to the cloud, but it starts creating a problem.
Jim: And maybe you can talk to me about it from a networking perspective. If I have processes that are running on prem, and I need to start shifting some of those processes to the cloud, how do I ensure that they are in essence, virtually connected, both on-prem and in the cloud, not only... you brought up two points, we've got the connectivity problem of them, but I've also got the security problem. How do I address that?
Aniket: Right. So, the point of take into consideration here is that the role networking is playing is the connectivity needs to be ubiquitous because when you have a private and a public cloud or multiple public clouds, workloads themselves, applications themselves or components of applications, will get distributed.
And so that connectivity piece needs to be ubiquitous, but it also needs to be consistent. And why this is important? I go back to I'm an author I really like to read from his name is his name is Avi. Friedman is currently the CEO of this company called Kentik. But what I like about something he wrote is an article called Three infrastructure mistakes your company ought not to make. In that article, he says, and by the way, these thoughts also got validated or resonated by Martin Casado in a separate article that Martin wrote. But the crux of Avi's article is that the mistakes companies are making as they embark on their cloud journeys is that they end up landing themselves in cloud jails.
They get sucked in by tools and they don't design for monitorability. Some of the thoughts that Avi made in that article got resonated in another article written by Martin Casado a little more recently. And there, the crux of Martin Casado's article is that why cloud delivers big benefits in terms of on demand, agility and elasticity, the pressure it ends up putting on the margins can start to outweigh the benefits as the company scales and grows. And that's exactly along the lines of what Avi also says.
Aniket: And so what's the, what's the implication of, of this, of what Harvey said of what Martin Casado is saying is that these companies who are embarking on cloud journeys need to insure themselves from cloud lock-in. Now look at your on-premise worlds. Multi-vendor strategy is a very commonly applied strategy for several on-premise deployments. Are we doing that adequately in the public cloud world? So that's the one thing that we ought to do.
And the other thing we ought to do is to use networking as that insurance to abstract yourself from the underlying substrate.
Jim: Okay, wait, I want to stop you on this because you hit on, you hit on two things that I want to kind of dive in real quick on. One which was cloud lock-in right? So, you talk about cloud lock-in. And there's a lot of people that are again, they're making the journey. So they're just starting or they're already along the journey. And they hear cloud lock-in and they go, well, wait a minute. What does that mean? Let's step back from a big picture. What does it mean? And then dive into what you were really going after is just from an infrastructure networking point of view. What does that mean? So can we address that from both perspectives?
Aniket: Sure, see the idea of cloud lock-in is each public cloud provides you a plethora of services, a plethora of functionality. And every cloud provider provides you that. The problem though, is the features and functionalities that they provide you are not the same. Each one has a slightly different menu of products or functionalities or services they offer. And even those that are consistent or similar, or the same across different cloud providers, they aren't exposed to you via the same set of interfaces, via the same set of APIs.
What this means is if you are shifting your workloads to a particular cloud, you have to write your application to that cloud ecosystem, to that particular clouds' ecosystem. Now to make these journeys simpler, each of these cloud providers have their product offerings, whether it's Google's Anthos or AWS Outposts, or Azure Stack from Microsoft. What they do is they try and diminish the differences between on-premise and that cloud; not multicloud right? So, that's really the idea of cloud lock-in.
Today, the way the clouds are providing or exposing, or you know, making their features and functionalities available are not consistent. What that means, what that translates to, is you as a customer of the cloud, having to write your applications to that substrate. Right? So that's really the problem that, that sort of results in locking yourselves in that ecosystem.
Jim: So, we know that when we start writing to APIs are you promoting the concept of writing to maybe open source type architecture in the cloud versus a cloud vendor specific type architecture? Or is that even an option?
Aniket: So, what I'm describing is the problem, and there could be number of different approaches to address that problem. Essentially what should a solution to this problem look like? The solution to this problem should try and abstract you from the vagaries of the different substrates that your applications will eventually need to run on or in. There is an underlying premise that there are existing applications on premise in a majority of enterprises. Right? Of course, those that are starting up may have chosen to start in the public cloud. But if you, for just the next few seconds, keep that aside. The majority of applications existing in on-premise land.
And so. We should find a way to abstract the differences, the vagaries between on-premise land and all the different clouds that you have. Harmonize, have a level playing field, and write your applications to that level playing field so that you can leverage the best of each of the clouds, whether on premise or any of the public clouds, because they also a lot of goodness. They offer elasticity and agility. You use them for that elasticity and agility and worldwide global presence and so on, so forth, but insuring yourselves by having a substrate that abstracts the underlying substrate to insure yourself from cloud lock-in..
Jim: Thank you.
Jim: So, one of the things that on prem, we kind of focus on software defined networking, and we really do push in software defined networking. And I'm kind of curious from your take on that. How does that apply as I go into this hybrid environment? We're used to it when we can control the infrastructure, but the minute I moved to this, I love your rental service. Now that I'm renting my services, how do I even deal with the concept once I go into that world?
Aniket: Okay. So, while you use the term software defined networking, another way I like to explain the idea of software defined networking is by calling it network virtualization. And I go back to something we started this discussion with which is the cloud operating principles that you need a certain velocity, that you need a certain on demand, self service consumption. Now with networking, while in the last several years, there was a huge emphasis on speeds and feeds, and we were rapidly advancing with the help of silicon and hardware. We were rapidly advancing from 1 meg to 10 meg to 1 gig to 10 gig, to a hundred gig. And while the raw wire speed was going, you know, shifting, taking giant leaps, the real velocity of consumption of network infrastructure was not keeping pace with the rest of the ecosystem.
You had "compute or "server" virtualization, you had storage virtualization, but you didn't quite have adequate or sufficient network virtualization. And that was impeding the velocity of consumption. While you had raw wire speed that was really fast, the consumption velocity of infrastructure on the networking front was not adhering to the cloud principles.
Jim: Okay. Wait, so I want to stop you on that for a second, cause I want to dive in on that one real quick. So, if I have a virtual environment on prem and I have upgraded my physical layer one cabling to be 10 gig, a hundred gig, doesn't that automatically mean that the virtual environments I'm running on those are now taking advantage of that speed?
Aniket: While that may be the case, the point I'm making is that the consumption of networking is still not self-service. Why? Because networks are operated and managed by specialized individuals called Network Administrators. And to get anything done on the network, or in the network, you have to go through let's say an it ticket, go to change management approvals, maintenance windows, and then that Network Administrator has to then go ahead and make that change in the physical network. That happens or that's a consequence of the lack of network virtualization or adequate network virtualization.
Jim: And that's an important differentiation. And that's, what's great about that is it's because if I have a resource that needs more bandwidth, now we have the ability to allocate it more bandwidth than just saying you get what you get.
Aniket: True, yes. And this network virtualization, what it does is, is it abstracts the underlying physical network. So first let's talk about in the confines of the on-premise data center or what we are calling the private cloud, right? Because there is a human Network Administrator that I had to go and knock the doors or disturb him or her and have them provision what are the changes I want in the physical network, that was slowing or impeding my velocity of consumption. So I said, I will abstract that underlying physical network, and I did that by creating a layer of network, a virtual network in software on top of the underlying physical network.
So you still need the physical network. The physical network provides that ubiquitous low latency, high bandwidth connectivity. It is managed operated by the specialized Network Administrators, they are not going away. But anything that a tenant of the cloud needs is going to have to be self-service. He's going to have to be on demand. And that is satisfied by having the network be virtualized in software and have it run on top of the physical network. And this is very akin to what we are doing, whether with compute or with storage. Creating virtual machines on top of physical machines. Enabling the available compute capacity to be pulled together and used more efficiently, more optimally with the self-service on demand aspect to it. So we are doing the same thing with networking. Now, this is what you do on premise. But it sort of extends seamlessly because the problem statement applies even to public clouds. Because you want to abstract the differences, the vagaries between public and private cloud, and between one public cloud and the other public cloud, you want networking to serve as that substrate, that levels the playing field, equalizes harmonizes at playing field.
Jim: First of all, I want to make sure everybody knows that the Avi Friedman article I've read it. I agree with you. It's really great because it talks about mistakes that we're all making. We'll make sure that we link to that in this. But one of the things that I've heard come up is the concept of multi-home to multicloud, what do we mean when we talk about that?
Aniket: Exactly. So each cloud provides distinct benefits, right? Each cloud is good for something different from the other cloud. And therefore, there are benefits that customers stand to gain from not being "single homed" and instead being multihomed. And there are different considerations for multi cloud, right? The considerations can be cost, or performance, or geographical proximity to your customer, or security compliance business continuity. There are a number of different considerations that govern the mindset shifts that is happening from going all in on one cloud substrate, evolving from that all in on one cloud substrate to a multi-cloud or cloud smart approach. That entails matching each workload to the best cloud, whether private or public, based on the considerations we just discussed.
Jim: Yeah. And another thing that's that I don't think a lot of people know is, is that even within the same cloud provider, public cloud provider in the region you choose, there may be services that aren't available in that region that are available in other regions. So I think there's a little understanding that people have that if they use this provider that they have a service and they go and look and say, it's not there because it's not available in that region. So that's always something to take in consideration.
Jim: So, I'm going to ask you to pull out your crystal ball and tell me what's going to happen with this traditional on-prem legacy world that we're living in. Where do you see that going in the next three to five years?
Aniket: Yeah. What I think is no matter how beautiful and wonderful the lure of the public cloud is, no matter how attractive it appears. What one must not forget is that renting appears to be cost effective in the early days, but soon the cost benefit ratio starts not to remain as compelling with the passage of time, with more workloads and with more data moving to the public clouds, the cost benefits of the public cloud soon starts outweighing having your own infrastructure. And for this I'll point all our listeners to the article written by Sarah Wang and Marquis Casado from Andreessen Horowitz. And I'll share the link to that article. And it says the cost of cloud, The Trillion Dollar Paradox, that's the article. And I I'd probably, I'd probably shared a little while earlier, but the crux of that argument is that while cloud delivers on the benefits, the pressure it puts on the margins can start to outweigh the benefits as the company scales and grows and the company's growth starts to slow down, right? And because of this, to sort of now come to your crystal ball question, I don't see on-premise disappearing. But based on different surveys we've seen, we are gathering information that the nature of the workload and the nature of the infrastructure for sure is going to evolve.
The cloud principles will permeate. So, on-premise will translate from legacy data centers to being more cloud data centers on premise private clouds, and the nature of workloads is also seemed to be evolving from being virtual machine centric, from being virtualized, to being containerized.
Jim: Yeah, I think microservices is absolutely going to become something and that, and I apologize for stepping on you there, but you touched on something I didn't ask you about earlier.
And I'd like to, which is microservices. I think we're gonna see containers. I think we're going to see more modular applications developed. And I think that to your point, I think we're going to see a lot of services that are set up and such. It really won't matter whether it's on prem, I own the infrastructure, or I rent in the infrastructure.
So I think that we're going to see it really won't matter where you apply it. And to your point. Re-evaluating on a regular basis, going back and looking at your costs and saying, and please tell me if you disagree with me, but I think having a quarterly, every six, or annual review of what you're consuming and what services you're consuming, and then doing an assessment, does, where does this make sense to run?
Aniket: It's an absolute must that diligent vigilance of your infrastructure and workloads and workload placement is an absolute must. To avoid things getting out of hand that diligent vigilance is an absolute must. I completely agree with what you said.
Jim: Okay. Well, is there anything that you wanted to talk about that we haven't covered for folks that either in the networking side of the security side, in the cloud, that we haven't covered?
Aniket: What I'd say is that while you asked me that crystal ball question, we spoke about applications, evolving from being virtualized to containerized and you made a very pertinent point about the relevance of microservices. Because what is happening is that the advent of containerization is leading to this to this evolution to the microservices framework of writing and deploying applications.
The consequence of that on networking is that the number of end points you had, virtual machines were fewer in number, but with microservices that one virtual machine is decomposing into a number of constituent components that run inside containers or pods. And so the number of endpoints are far greater and these containers are more ephemeral.
So that's something that networking has to reconcile with. And when I say networking, I mean, both on the connectivity and on the security side. And the other relevant point here is that this evolution from virtualization to containerization, to containerized microservices, is not happening overnight. It's going to be a long, painful transition. And what's really critical is that networking playing the role of a level playing field applies here in the evolution of the nature of the workload just as much as it does in a multi-cloud scenario. Building virtualized and their containerized counterparts, or portions of an application that are virtualized and other portions that are containerized, and providing that seamless connectivity in a consistent manner, exposing the same primitives that were available to you in the virtualized world and in the containerized world, that's the relevance of networking on the connectivity and the security front to, sort of, bring back the role of networking in that crystal ball scenario as well.
Jim: That's great. All right. Well, I want to thank you very much for being my guest. And folks, if you have any questions, please reach out. Either one of us will be glad to answer any questions. Of course, he's the smarter one of the two, so we'll direct them towards him. So, I want to thank you very much for being my guest and everybody have a wonderful day.
Aniket: Thank you again.