 From the SiliconANGLE Media Office in Boston, Massachusetts, it's theCUBE. Now, here's your host, Dave Vellante. Very often at SiliconANGLE Media, companies will come in and they'll present to us about a new product that they're announcing and we'll really have a deep detailed product discussion on speeds and feeds. But in this CUBE conversation, I really want to talk about the API economy. My name is Dave Vellante, I'm here with my friend, Steve Keniston. Steve, great to see you again. Thanks for coming into the studio. Thanks for having me on theCUBE, Dave. I love it here. So the API economy is something that you hear all the time. And as I was saying at the top, a lot of vendors will come in and say, hey, we got this big product that we're going to announce next week or next month. And we want to pick a thought leadership topic and we want to vector our product into that. And yeah, that's good, it's great to do that. It's trying to be relevant. But what I want to talk to you about is this notion of cloud and the API economy and how it's emerged in the network today. So I want to start with a developer perspective. And if you think about the way infrastructure has traditionally been deployed and what it means for a developer, can you help us understand that old view of the world and how it worked? Sure thing, Dave. And by the way, thanks for doing this, right? Having been on both sides of the table, the analyst side as well as the vendor side, you couldn't have hit the nail more on the head, right? Vendors like to come in and talk about product and talk to the analysts about how their product fits into what you guys are hearing in the market space. But I think what's happening more and more is this evolution of the conversation that needs to happen that sells to people who are trying to solve business problems, not solve speeds and feeds problems, right? So as you look at the API economy, right? And you think back to when infrastructure vendors were traditionally selling infrastructure, the conversation was always about, I wouldn't even say a DevOps style. I think that's fairly new. I think it was a test dev style, right? That was a developer developing some code, tossing it over the wall and some operations people trying to install it. And the minute that happened, right? Of course, that code set didn't fulfill all the requirements that were needed by the vendor or by the business, right? It wasn't secure enough. It wasn't, it didn't have all the right capabilities to fit into the infrastructure. Wasn't patched, integration. Didn't talk to the right systems. The punch list of stuff that operations guys have to go through. The developers. They didn't know. Didn't know, frankly, didn't care, right? Didn't understand how the database was laid out so it talks to it in a different way. So traditionally what would happen then is the implementation guys would say, okay, let me go fix this. And they'd do some fixing of it and they'd try to deploy it and it wouldn't work behaviorally the way the developer had designed it. And then there would be this conflict, right? You know, it's not working right, right? Well, it worked when I gave it to you. Yeah, hey, your application doesn't work. You just tell a guy, hey, your code doesn't work. That's the last thing an application developer wants to do. And that process. Well, it worked when I gave it to you, like you said. Exactly. But another point you made is it created a lot of tension. A lot of tension. And the process in and of itself became very, very inefficient, which then you saw the spinning up of. Well, wait, no, now the business guy. Now the business. Says, where's my app? Right. All right, and meanwhile, you have the application development team and the deployment teams sort of doing this back and forth, back and forth, back and forth. And, you know, they're trying to work together. But the line of business isn't getting the solution that they need to be, to drive a competitive business. So time to value was impacted substantially. Okay, so then actually, as you came out of the downturn, 2009, 2010, you saw shadow IT emerge. Right, so from your perspective, what did that bring to the table in this conversation? I think the biggest thing shadow IT brought to the conversation is the whole notion of cloud, right? Cloud was, yeah, it's there. We still see the number one reason why people use cloud as for data protection. I want to back it up. They think it's cheaper. It's not tapered. You get rid of a lot of that management capability. Or test dev too, right? Or test dev. But I think test dev, right, is slowly becoming even growing more and more because of this whole notion around shadow IT. It was, look, every time I toss this thing over the wall to the folks that need to implement the solution, I get a lot of pushback. And to your point, it creates a lot of this tension. I'm gonna go create my own way to develop this. And I'm gonna do all the development of that in the cloud. I'm not gonna wait for things to be provisioned for me. I'm not gonna wait for things to be tested and tell me I'm a bad developer, that sort of thing. I'm gonna go develop the code that I want and say, well, I'm done. It works, and then hand it off. And because it's in the cloud, hopefully the folks that need to deploy it can attach to the cloud and all of a sudden everything works the way it's supposed to, right? Still misses a lot of the things that the corporation needs from a protection security standpoint. Am I working with the right data set standpoint? Does the database look the same way it does here? Because when you develop a piece of code, you want it to run it and act against probably some components within your infrastructure. Is that happening, right? And there's still the big question mark. The epiphany from developers as a process of that shadow IT is, wow, I can essentially deploy infrastructure as code. Correct. And then when that hit, that's when you really started to hear the discussion of dev ops, the whole dev ops meme exploded. Although, I would observe, when we talked to a lot of people on theCUBE about this, is it dev ops or is it ops dev? What does that really mean? What it means is that most organizations, at least up until recently, I still say most organizations, don't have infrastructure as a code on-prem. If they want that, they got to go to one of the public cloud providers. And so, but they're looking for that public cloud experience on-prem. And so you had a lot of sort of ops dev, ops guys sort of learning the development piece that was relevant for deployment and the vendor community stepping up and delivering more of an API oriented experience. I think a big part of that too, Dave, to what you're just saying is, now all of a sudden the ops guys were learning things that was a little outside their comfort zone. And because of that, probably a lot of folks got frustrated. So the vendors, to your point, have made it a little bit easier to be able to deploy this through an API economy or through APIs. Why? Because they've started to automate a lot of the learning and the thinking because it's pretty simple. When you have infrastructure as code, there's a lot of things you can do programmatically. Now I can take that learning away and put the ops guys back in charge of ops. I don't need to go learn dev. I need to understand it so when they hand it to me, I know what I'm doing. But that whole API conversation is now moving away from education but more towards the true fulfillment and building out of these new applications that are making businesses more competitive. Okay, so when you think about the API economy, that term gets thrown around a lot. What does that mean to you? To me, the API economy, if you look at it, think of a great use case. I would think of a use case around manufacturing. If you think of a manufacturing company or a manufacturing organization, you have your suppliers, and we all know that just-in-time manufacturing is kind of the way to do business today. You have your manufacturing on the floor, and we know that a lot of systems are doing a lot of components within the manufacturing, and these systems are getting smarter and being able to learn and tell you when things are broken and not working. So you're actually getting real-time service to keep the floor running as fast as possible. Then all of a sudden, your inventory is now moving to some sort of inventory control system and those systems are talking. The vendors who are buying that inventory and then go sell to the public are working with APIs to be able to talk to that inventory and see what they need and when they need it. Then in turn, those vendors are selling to the consumer, and the consumer is using social media now. They're not picking up the phone and calling for customer service. They're saying, hey, this sweater is really nice, or hey, my iPod broke or whatever. So you need, as the original manufacturer, to be able to be tapped into these channels to get that information, and it's a circle, and that circle is really all held together with code. Okay, so that brings me to sort of the discussion of cloud and essentially what organizations, we talked about Dev Ops versus Ops Dev before. I would posit that the organizations, application development heads, CIOs, they want that cloud-like experience and they want it wherever their data is. They're not going to bring all their data into the cloud, too much data, governance, compliance, security, all that stuff. So they're going to bring the cloud operating model to their data, which means they're going to bring the API economy to their data, wherever that exists. It's in the cloud, on-prem, at the edge, someplace in between the cloud and the edge. And so I want to get your perspectives on how that's evolving in your view and where it needs to go. How that's evolving. Yeah, I mean, where are we today in terms of being able to programmatically across my infrastructure cloud, on-prem, edge, be able to control my infrastructure programmatically and get it to do what I want in the same way that I could do that in the cloud? I think that's a really good question and as I think about it, I think there are different organizations or there are different vendors who have been able to provide solutions to clients in a way such that... There are vendors who have provided solutions to clients that have done so in such a way that it's not holistic across your different infrastructure components, as you and I think about infrastructure, the storage servers, networking, et cetera. I think different vendors in different segments have done a better job. Think of Chef and Puppet. Chef and Puppet have gone a long way to the provisioning of servers and systems to be able to spin up systems that then in turn go build an operations around driving, building an application, testing an application, passing that testing process through a series of automated tests processes and then passing it back to development to go fix it. I don't know that you see the same type of the same level of automation that you see maybe at the server level, in the storage level, yet, yet, I say yet. All of that is coming. I see more and more that when you think of technologies coming down the pipe like a copy management functionality, right? The ability to reuse data. Now, that whole environment, it started a while ago, but you see it evolving more. The tools to then automate a lot of that process are now starting to come to fruition. They hadn't been there before, but they're starting to come networking, kind of the same thing. And that means when you talk about automation, you're just talking about programmatically invoking policy so that the system just does what I need it to do and I don't have to go manually reconfigure because the big vision here is distributed cloud, but managed with a single point of control. And when you think about these workloads that are going to require this new type of infrastructure, everybody talks about AI, machine learning, deep learning, it's requiring a different type of infrastructure and different type of mindset. Microservices are a big part of that. Functional programming across location. So edge, something in between edge and cloud called middle tier, right? And the cloud tier. So you've got processing happening at the edge, maybe real time, maybe aggregating data in the middle and then sending it back up to the cloud and then doing maybe more detailed modeling. That management of that distributed infrastructure cannot take place without the API economy. Do you agree and why and maybe help us think through how that will evolve? So I totally agree. I think the company or the business wants to be able to ensure, and I think you said it best, I'm not going to bring the data to you or am I going to bring the data to you or you're going to come to the data, right? The data has to. Yeah, the cloud model. The cloud model is the data, right? So I need to be able to have access in all those access points, right? That's very important to me because each one of those access points is going to give me the access and the capability to be able to tie in and talk to and touch customers in a different way, right? Or consumers of the data, right? And the customer in this case could be, and this is where the automation piece comes in, could be the developer, right? So the developer, right? Now, today is the person that we're selling to, right? We're not selling to the traditional infrastructure people. Although, of course they have accountability and responsibility for making sure the infrastructure is secure, stable, they've got enough storage, they've got enough horsepower to run the business. However, the person who needs to be able to access those capabilities or the data that actually lives on the disk, the developer doesn't care anymore what disk it is, they just need access to the data, right? So now I want to be able to come in every morning and I want the latest and greatest data set available to me so I can go build against an infrastructure that looks like reality, right? So that I know as I'm building my new application for consumers that I'm building it as fast as I can, as robust as I can, and as accurately as I can right away. And then I want to distribute that again quickly so that as many people who need to consume that application have the ability to do so. When we talk about things like, and I ask you sort of, we talk about things like containers and microservices. I worry sometimes you get, you know, maybe easy to manage dozens of containers and even hundreds but start managing hundreds of thousands and you know, same thing with microservices. Some of these microservices aren't so micro. They explode. Yeah, they explode. Macro services. Should we, is there a concern about API creep where I've got sort of this API economy blossoming but I've got all this now API complexity out there or do you see the industry being able to manage that? Is that, is API sort of a way to manage that? Will there be an abstraction layer there? How do you see that all evolving? Should we worry about API creep or should we even be embracing API creep? No, I think the jury's still out, right? I think that you hear a lot of the vendors talk about, oh yeah, we support, we have a RESTful API within our set and we can kind of write to anything. Is that really true? Can it write to anything? Because the more APIs that you see, right, the more little tricks, I mean we saw this when networking was going to be standardized, right? Are we going to standardize on an API eventually so that when you do say you write to anything, you can? I mean, hopefully, hopefully you can, right? But I don't know. Yeah, well, and the concern there would be just different quality and robustness and what you get from one vendor which might be rock solid, another one maybe not so much and is a weaker point in the link. I mean, all better than scripting, obviously, and a path toward automation. And it's not just quality, right? It's functionality, right? So you might be able to take advantage of certain things but you can't take advantage of others, right? Of course that becomes strategic selling for the vendor to say, hey, here's what I can offer, right? But at some point, again, when you're talking to that 23-year-old developer who just wants to sit down and be successful at building their application, they don't necessarily care or want to hear about that, right? Just like they don't care about what this gets on, they need certain functions to be able to work. It's the iPhone world now, right? When I push a button, I want it to work. I don't have the time or the cycles to try and go fix something. So the cloud operating model from an IT operations standpoint has been profound. One of the things we predicted at Wikibon is that over the next 10 years actually started probably two years ago. But from two years ago to sort of eight years on now, we predict $150 billion will come out of sort of undifferentiated IT labor costs, provisioning servers and loans and managing all that infrastructure, which doesn't add any value to the business, disappears or gets shifted to other activities. So it gets replaced by vendor R&D in the form of product that actually is cloud-like, public cloud services and the API economy. Shifting those resources into application development, design thinking, other value add- Analytics. Analytics for sure. All this AI buzz up the stack, if you will, that is going to allow people to differentiate with their digital business. Everybody talks about digital business. Digital businesses are those that differentiate with data. And that's what people want to spend their money. They don't want to spend their money on. That's why everybody complains about how we spend all our money on keeping the lights on. Big part of that is infrastructure management. Correct. Final thoughts. Caught me off guard. Okay. Well, I got some final thoughts. And then let me chat a little bit and then you can chime in. So I would say we're entering the next great phase of cloud. I mean a lot of this is driven by cloud and somewhat by open source. The first phase is going to kick the tires, what is the second phase was, wow, the economy is killing me. So I'm going to shift my CAPEX to OPEX. Actually, maybe the fourth phase. Third phase was shadow IT. I got to go fast. And I think the fourth phase was, wow, businesses and CEOs realizing that we can't just let shadow IT run away, run amok. We need to embrace the cloud model and bring the cloud model to our data. And as part of that, it's the API economy that we need to embrace and foster and invest in and shift the labor cost out of undifferentiated lifting to the things that add value. And I think the API economy is that vision. It does that. Yeah, so I would completely agree. So I haven't been in a sale in a customer call. I haven't been in a customer call yet this year where, for example, DevOps hasn't come up, right? And to me, that shows me that CIOs are thinking exactly what you're describing, right? I need to infiltrate some automation in here to get rid of the, oh, you're laughing. I'm not laughing. I like your shirt. So I haven't been in a sales meeting yet this year where we haven't had a conversation with the CIO or the executives at the table where we weren't talking about DevOps. And to me, DevOps instantly rings the API economy. Why? Because it injects a level of automation that really is what the CIO or the C-level is looking for, right? Because it does things like help take away some of that expense around the heating, cooling, whatever expense because you get to then offset pushing data into the cloud and leveraging the cloud in an OPEX-type model more. I think that the executives have been hearing a lot of, we have a cloud strategy, right? And you get to the people on the development floor or in the IT shop, right? And they say, yeah, well, we can't really do a lot of that. And I think the C-level is starting to see a lot more. If I can have the API economy help me, help them solve some of their problems, we can get to a cloud model a lot faster and meet the business requirements from a secure standpoint, from a data standpoint, a compliance standpoint that we need to be able to hit. And I think that's really important. Well, developers are driving the bus, hop on board. Steve, thanks for the chat. Thanks for having me, Dave. Appreciate your perspective, you're welcome, anytime. All right, thanks for watching everybody. This is theCUBE Conversations with Dave Vellante and Steve Kenneson. We'll see you next time.