Scale and Complexity [Cloud 2030 Summit 5/7]

Lowell Rob Hirschfeld CEO and co founder of RAC n. And this is the session about scale and complexity as part of the day on the cloud 2030 summit. You know, one of the things that we really have trouble comprehending as humans is just how big and interconnected everything gets. And that was the topic that we turn to at this point. Because really, as things get so big, it's going to become impossible for us to maintain it. That could mean Rise of the Machines, and AI is doing all our work. Or it could just

mean we build really fragile stuff. And that is what we took on it in this session. So enjoy it. As always, we want to hear your thoughts and feedback, the 2030 cloud to join in the conversations. And by the way, we're halfway through.

I think one thing that we're kind of touching on but not explicitly talking about is product management. As an industry, or I should say, as consumers to a certain extent Some of us have been involved in, in creating stuff. But fundamentally, I think most of this conversation is around us being consumers of products, that the product management skill set is now a requirement for any modern company that consumes it. And that's something that I don't think a lot of people fully understand. It used to be that you could just go to IBM or Ross pros company or any of the other companies that spun out afterwards. And you'd only have to have maybe

one or two vendors. And then funny thing happened about 1520 years ago, suddenly, that whole market just exploded with all kinds of options. And now there's all these different kinds of integrations that you can perform. And obviously operations becomes critical, then it's as a we were talking about earlier, but the skill set of being able to have your own in house product management of understanding. We're fundamentally building a

product internally, and we're supporting our customers who are our employees? How do we do that? How do we do that from quarter to quarter? How do we deploy new versions? When do we depreciate old stuff and get rid of it? Companies suck it that really bad right now, because they've I think, to a certain extent, as we did in OpenStack, initially, we were totally focused on the development. We didn't focus at all initially on the products supporting it long term. When do we say this old stuff needs to go away? JOHN, are you saying are you saying that as a consumer of technology, an IT organization for one of these end users of technology has to think of their operations, their IT infrastructure, as a product, their in house users, as their customers and therefore an internal form of product management, that being whatever is being delivered to the in house consumer, as opposed to a vendor? Is that is that the? Is that another way of saying what you've just pointed? Yes. Yep. Because it's that complicated. There is no one vendor, there's no IBM to save our bacon, there's no AWS to save us. It's really just, it's consumer. It's consumer

side product management. And yeah, I guess that's a way of putting it. Sure. And if you if we think about, again, cloud 2030, you know, I'm looking at, I still haven't did an inventory, but before AWS reinvent, AWS had 185 different services. That's an insane product catalog for a company that was the size of revenue of AWS, if I'm consuming, and I'm building products on this, I can't even get flash out of my environment, like, legit flash is gone. And

there's still applications that businesses depend on, because I can't move flash out, if I'm not looking at it in this product perspective. A lot of what's driving it is, is awareness and training of my customers internally. If I can't get them to the mold, they can consume my my services in the cloud like manner, that you know, office 365, whether I want it or not, I'm going to get a new version of it every week. If I can't train my organization, to do that, from a product perspective to how they consume it.

I'm going to just talk with flash and my environment until 2030. Yeah, and what your what your issue is here is one of persistence. This is actually where Rob started the conversation, or both Robin and Tim. I've got a you know, I've got a power PC that I'm still, you know, working on. If it persists because it's been there, it's been in house, I've had pretty much complete control of it. And I may have neglected to

upgraded over time. The the end product of a SaaS application or modularization, by which you create or compose applications is that your ability to count on persistence, if in fact you want it to persist in a particular form is really under, it's under assault, you don't always have the choice of Amazon of AWS continuing to support a release of something they did two years ago, you're, you're you're in the stream, and you're going to get washed down the stream with it. So there's a there's a persistence aspect to relying on somebody else to do this. You're there. Your other point here, though, is that the addition of a new approach to management to operations administration and management is, almost by definition, when a new when a, when the next Kubernetes comes along, you'll have the same kind of sense of, I've got this cloud of small insects tools that I have to use, and I have to pull together in order to manage this new infrastructure. It's aggravating, and I don't know that any of us here have, have really addressed what the what the driving force needs to be in 2030. In order to

prevent this from being a continuous rollercoaster on this, I'll take that. And it's a sense of responsibility to the, to your customers, whether they be internal customers, or external customers, or both, in some cases. So I'll give you an example. When I was at Yahoo, we built object stores before really anybody else even really had the concept. And

we had really good technology. Unfortunately, we had incredibly poor middle management. So nobody understood from a sense of a product, how we needed to manage the lifecycle of these objects, stores, cool technology as we deployed them. And they were getting used both by internal customers and also by our web properties. And so we ended up worldwide with many 10s of versions of objects store that we all had to manage individually. And operations teams had to manage. And they all

had very distinct ways that they had to be managed. And we, we should have had one version, the most release that you know, the supported version of the object store. But we were terrible at product management. And we didn't really care that much about our customers, fundamentally, we're just like, Well, you know, it does this suck. And that was essentially our attitude internally. And

we were very developer cutting edge focused and very not concerned about the pain that our customers had to go through, they just had to accept it. In You know, it fundamentally hamstrung the entire company, and so on. So people are seeing that talking to API management companies, and companies in general, are trying to reduce to how many API's they have. And their man they use, they

don't want to manage API's that, that they can't maintain, they want to have good API's that can be maintained. So basically keep up people kept on creating more and more API's in the last five years or so. And they aren't logged them aren't maintained, or well documented. So basically, there's lots of products that aren't actually being managed. So some of this is basically, let's make sure we, if you're going to create a product or service, you actually have enough people that can maintain it. So Mark, couple weeks ago,

you were talking about if you created a service, can you ever get rid of it? It's that type of thing. It's in terms of product management, same thing. So you have to be careful. How many technologies are gonna be

are you gonna use Are you gonna show there is a real concern about API sprawl. But you know, that is bundled in with the SAS applications that you bring on board it but you know, you're consuming an API versus you're building quote, unquote, managing an API. So you know, let's just tease those two apart. So when you say, you

know, enterprises don't they don't want to Maintain manage and API. Well, let's let's talk about what that really means. Right? Is it talking about API workflow, token ID, secrets management observability through the API stack, stitching it together, if you're using multiple applications, that is one aspect. Sure. But you know, if you're a buyer

of a SAS app, you're consuming API's, you just have to know how those API's stitch in with a workflow. That's, of course, you know that that is that is a challenging problem. Shawn, to talk about what you were talking about the object store, you it's a needle, you got a thread. So Yahoo's object store was, you know, perhaps not very product centric. We were building an object store. And this is at EMC, we were building the atmospheric object store. We were extremely product centric. We were extremely getting

all our use cases, what the features were the roadmaps as a disciplined organization, we are building an object store there. We got disrupted by AWS. So it's, you have to thread me and this is the same chat that's happening right now with Kubernetes. Right? If you're talking about compute orchestration, whether that was through v centers, VMs. Now you go into containers with Kubernetes. There is a needle to thread you know, how opinionated you want to be Rob was talking about earlier that he thinks Kubernetes is highly opinionated? Well, it's a spectrum. It's not

as opinionated as VMware, so as Cloud Foundry, right, so that was highly opinionated with tanzu, they're trying to do exactly the same thing. Rather than just orchestrating VMs. Now, it's containers. But it's where you are, where you are, what your consumers are actually buying. And again, you know, VMware is pretty damn smart. It is, you cannot be you cannot build a product, that's everything to everyone, they are looking at what is drawing in the most revenue, that's why they've bundled in with tanzu, Kubernetes and V center, they don't want to lose the innovation cycle. Next Gen companies that are consuming containers. And clearly, they don't

want to give up on VM orchestration, either. But they this might actually be an example for the one of the points I was I was trying to reason through for 2030 perspective. They're late. Maybe even late on purpose. If Kubernetes is a key technology for the next 10 years, which I think everybody's going to agree that it is whether it's for whatever reasons, then, then is it okay, that it's moving slower? Right, that we're going to count on opens to Kubernetes being a stable platform that we can build around? And what do you what do you mean, 10 year old cluster? So Rob, what do you mean by it's moving slower, what part of Kubernetes is moving slower? If what my point with this is that if we keep pushing the pace of edge, if our expectation is the pace of innovation on the technology side is going to keep increasing, then that the foundations that we build other technologies on top of are going to be so unstable, that we're gonna, we're gonna either have to completely transform how we think about building technologies, so that they're constantly able to shift, or things need to slow down so that I can say, you know, what, I'm expecting my Kubernetes application to have a five year longevity in this lifetime in this cluster. because, frankly, once I write the application, I don't want to deal with the fact that that Kubernetes changed an API, and now I need to migrate it. So

this, I've talked about it as a slant to VMware, which is that VMware moves at the speed of CIO, which is not particularly fast. We don't want this technology to move fast. But I do want the advantages of of the technologies brink. And I've struggled with this a lot. If you look at networking

technologies, and operability, of networking technologies, ideally, that's what I want in my cloud technologies. But it took a really long time to get to those standards. And they're very rigid, which, you know, can limit that on. And so there's a balance that

I think the question is, and this gets into kind of orchestration and management of the community and governance of the community and projects versus products, projects move a lot faster than products do. But then there's the instability as the enterprise I can't get flash out of my head. I'm gonna keep picking on flash. I can't get flash out of my environment. So I built these very static

point in time applications that I haven't matured my organization to be able to adopt technologies faster. So it's kind of a chicken and egg thing. If Yeah, if I can't, if I can't, if I can't wrap up my organization to adopt and change applications on the internet, the speed in which they're developed? Do I really want that innovation from the vendor side to move that fast? Yeah, Keith, sorry, I'm getting my brain cells warmed up here for this one. Um, the the thing I think about is, you know, the way we work in enterprise, it is somewhat lethargic, partly because of complexity, partly because of a number of other issues which have to be addressed, just not in this forum. But they do impact this, we have to become more nimble as an organization in terms of the products and services that we deliver. If we don't we run the risk of like

you said, the flash example, I'll use a more modern example. Look at Google and AWS. So Amazon has chosen to take the business path of we support everything, and we continue to support everything, including simple dB, which is one of their products from from the get go. Then you look at someone like Google who might deprecate a service and give you 30 to 60 days to get off of it is an enterprise I can't, I can't make those kinds of changes overnight, and have the structure in which to do so. Right. We see it with flash, you run the same risk with Google. I mean, this is probably one of the top reasons why when I talk to other enterprise organizations, other IT leaders, why they don't use Google, one of the top one or two issues is because of this deprecation issue, because they can't move that quickly. How do we start to help people along the way to make them more nimble or help them help themselves become more nimble? I don't think it's because the CIO moves slowly. I'm sorry, I don't buy that. I think

it actually is a combination of issues that are around culture, around the role of it and around technology that we can help influence to help change that dimension. But it has to be done in a very methodical way. Otherwise, people just kind of thumbing their nose at it and say, Okay, yeah, whatever, move on, you know, so we get on, we used to pick on Microsoft for being slow, and adopting technologies and moving fast, etc. What they've done with Office 365 is pretty impressive. So what lessons, if any, can we take from what they've done for product and bringing that to our own environments, users are not complaining that they're getting a new version? Well, unless you're on a Mac, I download the new version office every week.

But for the most part, it doesn't disrupt it normally no longer disrupts my workflow. To get a new version of Office every week, they've done a pretty good job of making it backwards compatible. It just works. Yeah, but Keith, it's, it's great when you get there. It's the getting there. That is

problematic. I mean, Case in point, 365. And I know, you know, this. I recently was trying to move from Google Apps to 365 over the break, had a horrific experience mail corruption, it was a handful of mailboxes had to back out of the whole thing. If I were

trying to do this for an enterprise, holy cow. What a nightmare. What an absolute nightmare. Now, for those mailboxes that are there, great things are happy, everybody's happy for those things that are in Google Apps, everybody's happy. But that transitionary process is enough to give me a moment of pause to say, You know what? So I've been involved in office 365 migrations, and that's pretty consistent experience because you're just, and that and that is the pain and this is why we don't do it is why we don't move from SAP. r three to to sa p Hana, because it's painful.

It's expensive, and it's risky. And so again, these are not technology reasons, though. Well, I mean, that's an interoperability problem that's been fundamental in the industry from day one, you know, how interoperable Do we want as a business practice and or from a just Well, from a business practice? I mean, Microsoft early on intentionally made their their applications very inoperable to thwart competition. I don't think that that's exactly their, their intention today. But that's fundamentally interoperability has been a problem from day one. But

I would say that did three things. 65 is probably a bad example of this. But if we take Keith's other example of SAP, or just upgrading in SAP and those of us that have been through that process, the challenge is ultimately it's not technologically driven. The problem is not because of technology. And the same thing actually holds true with Amazon, Google, Microsoft Alibaba, in terms of upgrades, if you want to switch if you want to switch to another provider, or make a change to another provider, or another version of an earpiece system. The problem is

because you allow the business processes to get so complicated that you essentially created your own snowflake of a footprint. And we're seeing the same thing in public cloud infrastructure to where people are building these these applications that are so complicated, and leveraging all of the different rich features and ecosystems of these major cloud providers, which is great. But if you ever wanted to change, God help you, because it's going to be incredibly problematic. That's not a technology problem. Yeah, so maybe that was my comment on the internet, is where where does the responsibility lie? For that interoperability? It does rely within the customer. Does it rely on the business? Does it rely on the standards? Is it government? I think probably it's a little bit of everything. Right now, today, I think

government is trying to put its toe in the water. As far as how it's going to enforce interoperability. I think that and I think that's a mistake. I

think it should sit squarely at the feet of the customer. The customer needs to take responsibility for how they use technology. I think the skill is essentially for many of the customers out there because technology's become so democratized, it's just not there. So what guardrails as a society do we put up to protect the average consumer of technology so that they don't end up buying the hype of K eight, and that I too, can run containers at home. You know, obviously, that's not reality. But you know, if you listen to the

hype, and you don't know any better, you're gonna think you're gonna believe it. Well, let's go very unhappy. Go back, go back to what I'm going to reiterate what Tim what Tim just said, then what size customer are you talking about? Because if it's an enterprise that's on them, right, you you've hired for that technology, an SMB, different story, right, where it's not their core business. But if you're running if you're running a full on it, shop that's on you. Hmm. Well, I think some people lobbying their legislators would disagree. Or, and

fundamentally, it is kind of the the problem. And I know I'm doing a little bit of far afield, but this is a topic that's that's going on right now. is get your your farfield. You shine out farfield. So keep going. Okay, so how much responsibility

does a company that makes products have to its customers? Where did it begin and end? So for example, when Adrian, when AWS goes down occasionally, which, like any system it does, or when Google goes down? Are they responsible? it? No, obviously, there's SLA is that they have contractual obligations to their customers, but fundamentally on a, on a, on a, on a jet in a generic sense. Do they have a responsibility to their customers to have their services available with certain capabilities at certain times? I'd say no, from an engineering perspective, but there's a lot of people that don't fundamentally understand how this stuff works. And they're going now to their congressman and, and, and Senator saying this, it's broken, go break up Facebook, because they did something bad to me. I think that's completely naive. But it

is the place that we're at, people fundamentally rely on some of these services to help them automate and make their businesses run. And you know, when Facebook tweaks our API, so that data flows out of it a little bit slowly for certain types of data fields. It impacts businesses are based on that. So he so you guys hear this, you guys are confirming my comment on cloud making people stupid, right? Yeah, but the you know, no net net neutrality is it? Is it the government's role to say that all bits should be treated equal, like from a consumer perspective, I love that I can buy my get my Verizon phone and get all this free content, but it's not competition because now the next HBO max doesn't have that agreement. So you get into some really

complicated me to do, I really want to be stuck with USBC for the next 30 years, that USB connector for the next 30 years as opposed to some other connector because the European Union union has said that everything should be USB Mini, which is I think the rule I have to either ship a dongle, whatever. So how much of the government getting involved with stifle innovation, which typically seems to be pace, versus customers demanding? I, I'm gonna be going back to lightning in the next round a second, because lightning is a key and a kite. I just raise money. So we are actually transitioning to what the next hot topic is sort of naturally, which I love, which is alright, how are we getting access to all this stuff? Right? How do we make sure that the people who are getting it have access and they understand what the consequences are? I mean, we just teased out this sort of question of people are all of a sudden dependent on these core technologies and don't even realize it. Who

are the haves and have nots in these cases? If you're if my if you do we have people who are locked out of technologies. I hope you enjoyed this session. It really got me thinking. And part of thinking about pace of innovation is who gets left behind in this rapid frantic pace we have and that is what we started talking about in the next session, social access, so please enjoy that session.

And think about how do we make sure that as we build technology for people, everybody gets access, so we don't just in a rush to get to the finish line, which there isn't that we leave people behind. It's important

2021-02-13 12:22

Other news