Hello, I'm Rob Hirschfeld CEO and co founder of RackN. And your host for the cloud 2030 podcast. This DevOps luncheon learn was a fascinating conversation talking about how we evolve technology in the future. And we centered it on networking, but in a very general way. Because what we kept finding was that the ability for a vendor to distribute technology and then connect things together and then build networks of that technology was a core component that we had to think about in building systems. And that led us into a very dark place where we really thought through who's going to own all of that infrastructure and what their motivations are, and how we can make sure that the people's needs and the systems and the vendors needs are well aligned, I think you'll find this very thought provoking. Enjoy.
Let's let's do that. Let's see if we can have a conversation about application of standards. I'll put it in there, and we'll see what happens.
Cool. Yep. I was gonna say that is a fabulous topic. Actually, Rob, because it's, you know, in terms of the areas that I'm focused on, that is the question is, Where's where's the rules there's can emerge from there's no organization is going to be able to stand up and say, Hey, these are the standards, everybody in here. That doesn't appear.
And part of part of my motivation for dovetailing with reinvent is that we're, but you know, there's a fundamental question, maybe I'll add it to the page is, is Amazon setting the standards? Right?
Well, no, because being one of the other major cloud providers that's implemented an AWS API for any of their services. Or finding very, they may be defining the core service set at some level, but I would argue that Google's done some innovative things there, as well. But no, these are standards within that ecosystem. Sure, absolutely. They own the standards within the AWS ecosystem, but across ecosystems, no way. In fact, the the fact that, that cloud cloud events is, you know, is being picked up by so many vendors and you know, being looked at so seriously is largely because Microsoft and Google participate in that as a part of CN CF. Right. And they're doing
it because Amazon isn't, isn't collaborating to set standards.
And Amazon has in the past, but the person who did that was, you know, has left the organization person was driving that has left the organization since but, but you still see them sort of poking around with it. And, you know, the idea of interoperability across clouds. I think what it comes down to is everybody in the cloud world is worried about data, gravity and keeping data on their platform. So anything that can get data into their platform, they're excited about anything that takes data out of their platform permanently, they they abhor, and so on. So what they're looking at now is they're beginning to realize that event interoperability is more on the positive side of that equation from their perspective than on the negative side that you get, you know, access to more data, yes, it may be replicated elsewhere, but that data in the context that you own, that your customers is, is positive.
Right, but the events, the events don't compromise data, that your data, gravity, right.
So so actually. So in some ways, actually, what you're saying is the way to make money in Cloud is data storage, and data.
Without a doubt. You know, ask yourself, why egress charges, but not ingress church, right? I mean, it is it is the fundamental business model. AWS was incredibly smart early on, they realize that data has gravity. And they said, so let's get as much data into our organization as possible, we can charge for the storage of that data. But in addition to that, it will bring across you know, we will do everything we can to bring across the applications and generate more data. And we'll do everything we can to bring across the services that make that data valuable. And that naturally makes those services valuable enough that organizations will want to, to transfer over to, you know, to use our cloud. And on top of that, it's a stick it's the only stickiness factor. In a lot of ways, it's not quite true because API's are also stickiness factor. But, um, but it's it is the major thing that makes the company go, we can only be Amazon because the cost would be exception.
And, and that's also why edge is so freakin important to everybody because that's where the data comes in and gets manipulated in the same space.
Yeah, I think I, my guess is at reinvent, although I've said this for three years in a row, but my guess is at reinvent something edgewise is going to shock us all. Because it is where there are a lot of organizations figuring out ways to keep data at the edge so that it never really leaves say, the branch or the the store or whatever it is. And so, right now, Amazon doesn't have a way to kind of get that initial data generation, they can get the aggregate data that might be sent back into the cloud, but they don't have a way to really be in the store or be in the branch. And I think I would not be shocked if some of the you know, the existing on prem Amazon stuff that that's out there, becomes officially packaged in a way that it becomes a great edge store. You know, yes, exactly. Anyways, it takes you off the networking topic a little bit, but not until it's
actually it is it is the pathway to the networking top Exactly.
It is it is what generates the networking business and the networking problems that we're going to see. So the next step, for sure is there's
data data gravity is right, just like you have you have positive and negative expressions, right? Data, gravity is an expression of networking. throughput, right, early birds of network,
David Aquarius, David McCurry, his latest equations on this, you know, latency. More so or actually, no bandwidth. And latency are both a factor and I think, but you know, really the, you know, the value of the data is the most important aspect. But the next most important aspect is, you know, that value has a time decay on it. And so the timeliness of getting access to that data is a really important factor due to gravity as well.
There's another component here that ties together with our modular modular cell phone, which I would actually describe as modular mobile device, that some of what we could actually start to see if you had real, real high performance, local networking, like what they described the 5g, you could decouple the screen from the compute, right? decouple the storage from the compute, and then all of a sudden, it's not a matter of, hey, my phone needs to have these sensors and these devices all crammed together, it's actually they could be, you know, disaggregated components, and you could have your goggles, and you could have your sensor, your cameras and all like all those things could be decoupled. Without what,
to the extent that you can, you can live with it, if it's not on the network, not you know, not being very functional. But I would argue that we're I don't know if you guys know that the sort of the was it the strangle pattern for converting applications from, you know, monoliths into micro services. But the idea is you kind of start with the data services, and you start picking apart and pulling out pieces and parts from the data on up to the user interface, in order to, to kind of generate that your set of micro services and that way your app can continue to the rest of the app and continue to run, it just begins to call out the services. And so in the same way, I would argue that's already happening with our mobile world and our mobile landscape, because you know, how much of your stuff depends on iCloud or Google or whatever it is that you use, on the back end. Now. I mean, you know, I tried to live without iCloud for, for quite a while. And in the end, the phone is just so much more valuable. If I just, you know, give up that data to that central processing piece. And I believe that they're sort of you know, there'll be more and more pieces where, you know, they'll they'll keep a usable app infrastructure on the front end. But more and more pieces will be actually running in the cloud over time,
but this, this is the dilemma that I faced with this in this in these discussions, because it's part of part of the reason, sorry, part of the reason that I think the networking is so fundamental here is that, the more the more moving everything Trump owning it to the cloud making iCloud, right. It's a hub for you to connect to a whole bunch of services. But I actually think it's standing in the way of us doing real analytics or real applications that involve multi sensor data or real real, you know, analytics or real time. systems because that that that thin straw going back to the cloud is actually the bottleneck from an application perspective that we need to break.
Well, let me ask you this, Rob. So you think there's a because in the in the way you would deal with this was to put in a process as you would apply theories of constraint, kind of constraint kind of activities, like value stream mapping, and things like that. So in the network, you think the industry does a good job of identifying the constraints in the relationship from a customer to, you know, to the valuable business and data that's behind the scenes? Do they? Does the network industry generally do a good job of identifying those constraints and eliminating them? Oh, no, no,
don't, I think I think the application developers do a really good job of working or working around the constraints.
Right, because, yeah, like days at Cisco, I do know, they spend a ton of money generating bigger and faster routers, right for kind of the core internet core systems. And so the internet core doesn't seem or feel like it's a constraint in any way, shape, or form. It does feel I don't, mile remains the biggest constraint.
But I think we've got a Jevons paradox issue. And this is so to me, every time we make, you know, bigger pipes, or you get somebody you know, you get you get people in fiber, and all of a sudden, everything's Yeah, I can, I can push more more and more bits. You know, we, as it becomes more more saturated in the environment, then we become better able to leverage that I actually have an expectation from an edge perspective that if we could actually solve edge networking, and it's not even a throughput perspective, it's an operational, I see this as an operational problem more than a networking tech problem, then we could see an explosion of data collection at the end, that would far outstrip our ability to ship, you would, you'd never ship all that data back. Which is why it's an operational problem, though.
So part of the operational problem, Rob, is that data, data creation collection, far outstrips network technology on the small. And back when I was doing mobile, we had some I consider him an asshole developer who came in and said, Well, gee, instead of using UDP to get this nice compact message packet through and only spend 250 kg of data to get a month to get tons of information, let's wrap everything in, in SSL. And even a single bit of data is a 1200 Bytes minimum to get through. And suddenly, our ability to do anything became much slower, because our straw became extremely constrained compared to our old straw. And so on the edge, a lot of what needs to happen is, we need to find secure ways that are that wrap securely, but our low footprint so that most of the information go across this data, and the data is extremely compact, still, because we're always going to have more and more data to do more and more complex things. And we're still not going to have the broadcast bandwidth to get them from remote devices to edge cloud or edge or whatever, there's always going to be that straw is going to be the limiting factor of how much we can actually be how intelligent we can be at whatever point we're at.
But I don't see it as as the total throughput of the system. This challenge to me would be if I'm adding in every sensor I add into a system as to connect back to the cloud. Right then definitely the bandwidth through my pipe matters. But I also have it adds a lot of cost and burden, right one to my to my internet connection but also to that device to be able to drop in you know sensor Right, what what would it look like with if Alexa, if you could say, alright, I have an Alexa in my house where I'm doing the processing. And I've been able to put this scares me, by the way, but I think this would improve the fidelity of the system. If I could put, you know, six or eight sensors microphones in every room. And, you know, the cost to add that sensor was all right, our to do would be small, or it was in plug, just a shim plug in every outlet. And the networking component overhead on that with the would be tiny, right? Oh, and the upper than the operational. So in doing that, I also have to do it has to be trivial to add each one of those sensors into the system. So low costs, but low user overhead. I'm sounding like, this is the way I played with protocols like this for home automation, where, you know, build a mesh and you add add sensors, the sensor cost is super cheap, and it builds a mesh and all sudden, now you have a home network.
And they're usually good clumps.
Usually the entry cost is higher, because you'll have to buy like a network bridge for anyway, depending on the technology, what they call it. On then the ETF each each additional sensor is relatively cheap, but there is the high buy in.
And this is where Beth calling comes in. And talks about the boxes that Verizon and other folks are building that sit there and are essentially the edge cloud for your home. And they're being the key is companies like Verizon and other folks are building at such quantity that those become commodity. And so it becomes a lot cheaper. As long as there's some sort of standardization.
I'm not even sure they need to be commodities, if they were really useful gateways write it, you know, I might look at if Alexa was a software product that stayed in my house and I controlled, what the egress was, I might be much more excited to have that type of an interface for my home than I am now when it's basically I lose control of the data that I don't have any because of this, you know, all that all that data gets out of my control.
So you might take, you might take a look at some of the stuff that the the home router systems are doing, because those are getting a hell of a lot more intelligent. And they might actually provide some of the stuff you're looking for, you just have to write the software around it. The problem is, is that it's going to be outdated in some number of years, and you're going to want more functionality and even less years. And it won't be backward compatible, the new one won't be backward compatible. That's the problem.
But I mean, you you're you get that happening these days, like look at first generation nest products and things like that those are essentially unsupported anymore. But that the other problem also is that even though there are home or other products that can act as a hub, ultimately, the vendors end up getting those through a web portal, right? Look at the home Wi Fi mesh systems. How many of those can you actually set up without having to go through their their web portal? Very few.
It got too bad even with my home router. i i no longer use the web interface on the router. I go through 18 t's web interface, right yeah, the access my own friggin router, which is in my house.
Yeah. Thermo smile thermostats as well. Um,
I've got a drop off folks. See ya.
It's a I mean, from from the vendor perspective, it, it makes sense because they can sell the product as a service. from the user perspective. It depends. If you are an entry level user, or not a power user, it is good enough for you. But ultimately, there is a ceiling store how much you can do with a product that you don't truly own. And arguably that sealing is fairly low.
Yep. Well, it's interesting how quickly we get tied back into right to repair and the operability of what You know, cuz as a as a vendor, it drives me nuts when when somebody's like turning a whole bunch of knobs and then asking for you to help them. You're like, Alright, how many knobs did you turn? Why did you turn those knobs? You know, and then trying to figure out enough to help them. And then that expertise is required to help somebody through that it's got to be insane, right. I was at&t, you know, having me go in and configure my router, it's opened up a portal or something would be having trouble.
Yeah. I mean, I also understand why vendors do this kind of thing like decentralization. For me, it's, it's cost effective. Instead of itself, producing self contained self contained devices, you provide them some devices that are smart enough to connect to your central control hub on there, you can do your updates there, you can do your QA, without having users complain about failed firmware upgrades and things like returning the devices because they don't work. For the most part, it does have a recurring revenue stream.
Yeah, well, this is the world we're in, right. It's all SAS managed, managed capabilities. And we're doing that some somewhat for a user benefit. But in a large part, it's an operational benefit. Because you're trying to, you know, as an operator, you don't want to have, you know, the less heterogeneity that you have in the system, the easier it is to manage.
Yeah. And the downside, of course, is what we've seen happening in the real world is much more susceptible to supply chain problems. Like in this case, like network connectivity, compute capacity. Like, ultimately, I worry about this building up to a point where something down infrastructure fails, that knowledge, thought could fail, and then everything comes crashing down. Now many people are how many people can continue their day to day life without their cell phone? A calendar is no longer acceptable, accessible if their email is not accessible?
Yeah, well, even even more things that I saw about with Google Maps is they intentionally make the names of roads smaller, so that people don't get, you know, used to using roads to navigate road names to navigate but instead use just rely more and more on the maps
I try seeing that as as a as a, you know, sinister, sinister thing I can see that be like yeah, just it's you know, the maps are accurate enough, we don't have to worry about it. But now we're very dependent on the tech Yep.
And that's why I think that the idea that it would all completely move off the phone is not realistic in part right because um, you know, in fact in quite the opposite I would expect the network to expand the cover more of the globe the 5g You know, whatever to expand to cover more of the globe through set through combination satellites and grounds things first. Because that of that reality, right, if I'm in the woods, in you know, in the mountains of Colorado, driving through some roads that I don't recognize where I am and I've been there before the last thing I want is for my map to stop working or for no more if I'm rushing around in subways trying to get to to a big meeting and the last thing I want is to miss the fact that the you know the location changed what the time changed or something because my email wasn't working.
Yeah, Mister Mister Mister stock, because the both those
both those things are important than network connectivity, super important, but at the same time, I will note though, that, you know, even the maps for relies on GPS, which is global coverage, and it is a form of networking.
It's funny that we say that the thing about not arriving on time because the meeting time or place changed up. We all grew up with dad. Like back in the 90s and earlier, cellphones were not ubiquitous. used to call someone today I had arranged for a day and time Or you'd
have to dial into a voicemail. So you'd arrive and find out something changed or whatever you have to dial into voicemail. Or
even done doesn't begin to listen until the turn of the century.
Yeah, yes. That's fairly Correct. Yeah, I mean, I got my first page are thrown on my desk in 97. So, you know, I spent a good, probably first six years, seven years of my career without even you know, without even internet dial up or anything. You know, it was a lot standalone laptop and cell phone. And then local networking, connect to local networking when I got, yeah, that's true. But, but at the same time, I guess. I would argue part of the reason that we are more independent as we are more distributed in the way we work, in terms of physical location. And so the question is, is that? Is that a bad thing? Right. I mean, there's pros and cons, there's people can work at home more easily. The idea that even even like I had a friend, two doors down our neighbor is a securities trader. So options trader, and he was they're able to do high speed decision making. You know, one of the first people in the FBI was one of the first people in the block to get fiber. And he's like, yeah, it's not quite as good as being in the office, but it's damn close. Yeah. So you know, it's I, I would argue that go, I would argue that the problem isn't so much that we're so dependent on our phones, the problem is that the value of the phone is not universally distributed yet.
Which I think in part is going to come back to the value of the network. Because
it's sending that statement is dependent on the network? Absolutely.
I would like one or two steps even further than what you're saying, because right, what you're describing to me is human efficiency. Right. And some of it, you know, now we're seeing leading to burnout as people never get away, like the idea that you would, didn't wait for the subway and read a book or a magazine, or just sit and think. And now, you know, it's easy to never get that time, you know, is translated to, hey, I'm actually not getting lost as much I don't spend as much time building travel buffer in or I don't know, spend an hour waiting for somebody to answer a question for me that when I just needed a quick answer, I can, you know, they can interact or it the whole, the whole system is becoming more efficient, efficient is not always a good thing. But I do think that, you know, looking at big societal problems, you know, improving health care, health access, improving energy utilization, that we can improve efficiency, right, all of that. The way that works is because we have these systems that interacts better collect more data are more responsive to sensors, right? They're operating at a higher state of utilization than they did before. And that's good. But then the only way we're going to get there is if we can have 100 times the sensor density, which means 100 times the network, you have to be able to get on the networks and connect things together. Like we have to have 100x improvement for that. Does that make like
I guess there's a the brace of a philosophical question for me is I guess I asked to do like how we benefited from the technology. It have we largely benefited and it are the privacy and control issues like the dark side of this technology, or has it largely been detrimental on his on our the benefits that we're seeing the silver line we
we are still at the beginning of the journey. But I agree with you the way we've built it. Are I actually you're not making a statement you're asking a question. I think that that we have seen just like in any technology wave that the first wave of that is driven by profit motive and, and the ability to disrupt things and the consequences. Thank you have consequences human terms aren't, aren't, are very hard to anticipate, but are also, you know, sort of a second thought in the first in the first wave of us. I would suspect that we're still in a area of human harm as a byproduct of innovation. And we're still having trouble quantifying it. Boy, that's a grim statement.
Do you think we'll get past that or you think it will be continued to be driven by profit motives, and will only get passionate in cases where it's profitable to do so?
I optimistic that we'll get we'll get past it. But it could be very ugly, before we get past it. Like, it's like, the technology waves in the past have been very ugly before they got they got better.
It's also societal change that it's driven by technology. But we're seeing bit the behavior of people as a whole change as well.
And that's, I mean, people change slower than the tech. Right. That's what what we ended up saying over and over again, with what of this.
I don't know if people change slower than a tech, I would say more that did change becomes in people becomes apparent, slower than the change in tech. That by time, we noticed that something or some societal change is detrimental. It in people, it tends to be already too late, that look at Facebook.
Definitely full circle.
It's
I'm thinking about like how evolution works, right? Where I'm not sure that this is the right analogy. But where were you people who fail. It's not people, organisms that can adapt to any circumstance, you benefit. And once they can disappear from the environment.
That statement makes me nervous.
Although I think, I think it isn't necessarily the ability to adapt, although those organisms that can adapt, have some advantages. It's the ability, it's having traits, or the ability to acquire traits that meet the new conditions. Right? So you could you could have an exist, you could, you know, you could have a change the environment that negatively affects a bunch of organisms in the ecosystem, but not others. And those others don't have to change. So So part of part of this is sort of luck of the draw. But anyway, but I think I, you know, I think all of this is all of this with evolution, it comes down to, if you have situational awareness, and you can adapt to the conditions you're seeing with that situational awareness, you have a distinct advantage, you start to have that OODA loop feedback loop that triggers that gives you some some advantage. If not, then you know, that you know, and that's the Red Queen, right? That's the whole Red Queen situation, we have to then everybody can adapt at a certain rate and so you have to adapt at least that rate in order to be able to survive. But there are those that kind of get lucky. Okay, look at this the draw, they land in a situation that's perfect to their their needs and allows them to at least stay steady if not grow and thrive.
And more often than not, chances are much more important than than adaptability or skill. Well, yeah, you're surely in the right place at the right time.
Yeah, because you make them may make an adaptability decision based on your situational awareness that turns out to be incorrect. Right and so adaptability isn't a panacea by any means luck by I agree totally like this is one of the things to set yourself up to be able to Take advantage of what luck you get. And being, you know, you know, there's so many organism organizations and leaders out there that hate the idea of being reactive to change. But to me, that's the advantage is knowing how you can react to different situations ahead of time. But not necessarily taking action until it's time to react to changes happen. And that's my spiel. That's huge. And that's the thing that I see so many organizations struggle with. And so in the networking world, it's kind of a similar thing, right? Not not changing everything about how you work your network. In anticipation of, of a, something that's going to happen, like, just take growth, for instance, like network usage growth, right, not necessarily installing everything you need for some dream target, load that you're going to have been setting yourselves up so that you can acquire equipment and upgrade the this the bandwidth and the performance of your network, as the need is clear. And as you have near term predicted prediction of what you're going to need in that short term. Right? Those companies have, I think, a distinct advantage over those that say, Okay, we're going to go in, and we're going to build, you know, this incredibly high speed network in anticipation of, you know, this new product having success or something,
like OpenStack. But, yeah, I mean,
it's I mean, but certainly the clouds give you that advantage, right? Like, if I'm using a public cloud, and I don't even worried about that equation, I'm, generally I'm like, okay, yeah, whatever network I need, I'm gonna get it when I don't need that network. Um, I'm not going to generally pay for it. Or I might reserve a chunk of stuff, but I can add to that chunk of stuff pretty easily. And so
but, you know, being adaptable, I definitely agree with that. Like, there's no amount of planning on contingency contingencies is going to protect you from from the future issues. And that there's a reason why the the saying goes, like, no plan survives contact with the entity. Right? Like, it's, you have to add, you can, you can have your methods for, for, for managing contingencies. But that, yeah, that there's, as you said, like that, there's always the chance there that that is something unforeseen and when you have to have the flexibility or male ability to deal with it.
Yeah, yeah,
that's a, that's a that's an interesting balance, because you can't have infinite flexibility and Chase, you can't, you can't always be chasing, you have to be, have to figure this figure it out.
You said, I think this, to me is what strategy is when it comes to technical technology planning. Strategy is setting yourselves up with the mechanisms by which you can react a number of different ways to a number of different situations. So that may mean acquiring the equipment ahead of time and having it ready. But, but it's about you know, having the strategy is to be able to have situational awareness and react to what you what you see, and be able to, with a little more effort or more cost, be able to change the tactics you're using reactiveness. As as you learn more and more information
is the difference between being opinionated and being stubborn.
Right. And that's the exactly I think that's a that's a great same number, we see that in software development and supply software supply chains all the time, right, which is people who are stubborn about the technologies that they're going to use about the processes that they use about the metrics that they measure themselves by having a heyday and then beginning to to be a problem for the organization in the longer term. Whereas organizations, the teams that are much more sort of like, Hey, we are constantly trying to learn very this, you know, this is all kind of old, but that we're constantly trying to learn. We're constantly trying to change our practices. As we learn. We're trying to be situationally aware of all the factors that chip that affect the way that we should behave and operate. Those organizations are surprising, right? Because they'll come in and I think one of the things that's happening right now it's really fascinating is this balance that's starting to happen between we can't build everything ourselves at each team can't build everything entirely from the ground up themselves, right, as an organization, that becomes a really costly thing in terms of both conflicts, in terms of operational conflicts, and in terms of costs. But at the same time, we can't lock everything down. So everybody does everything exactly the same way. And so finding that balance, finding a way to kind of provide economies of scale of common elements, and but allowing people to, you know, just say, sort of, you know, have an opinion within that context, individually, is sort of the the direction that everybody's trying to figure out. And, again, public cloud has some advantages. But if you have to run on multiple public clouds, the public clouds aren't working together in a way that that so you end up having different implemented clouds, which is where, you know, again, that's where VMware is strategy is basically to say, this isn't that's not going to work. For companies, they're going to need ways to kind of address this that are independent of those the clouds, even if they're mostly focused on
the blockchain. So supply chain and complexity.
Teach, but I see that's a later topic for later dates, we can go.
Wow, there are so many things and aspects to think about in how we build technology. And frankly, I can feel very powerless as we as we make all these pieces go. But it's important to think through what is going to happen in the future as we make these changes. And as we were saying, be ready for the change, but not following every change. And that is exactly the type of advice you can take to the bank because you build systems. Thanks. And please join us at the 23rd cloud. I would love to hear your opinions during these sessions, and see what you think and how you in shape and influence technology. Thank you for listening to the cloud 2030 podcast. It is sponsored by RAC in where we are really working to build a community of people who are using and thinking about infrastructure differently. Because that's what RackN does. We write software that helps put operators back in control of distributed infrastructure, really thinking about how things should be run, and building software that makes that possible. If this is interesting to you, please try out the software. We would love to get your opinion and hear how you think this could transform infrastructure more broadly, or just keep enjoying the podcast and coming to the discussions and laying out your thoughts and how you see the future unfolding. It's all part of building a better infrastructure operations community. Thank you
