 Live from Washington D.C., it's Cube Conversations with John Furrier. Welcome back everyone here to a special Cube Conversation in Washington D.C. We're actually in Arlington, Virginia at Amazon Web Services Public Sector headquarters. We're here with Steve Vassaretti, who is with Rean Cloud, recently won some big award for $950 million for the Department of Defense contract, a partner of Amazon Web Services. We're really kind of changing the game in the cloud space with Amazon, among other partners. Thanks for joining me today. Thank you. So obviously we love cloud, I mean we're, we actually, we have all our stuff in Amazon, so we're kind of a little bit biased. But we're open minded to any cloud, we don't provision any infrastructure, right? So we love the idea of horizontally disrupting markets. And we're just kind of doing it on the media business. You're taking an approach with Rean Cloud that's different. What's different about what you guys are doing and why are you winning so much? Yeah, I mean I guess that is the keyword being disruption is I'm hearing more and more as this news spreads out about why we have disrupted, so we've proven the disruption. And when I mean disruption, I'll explain what the disruption we're creating in the service industry is. If you take a typical like a services company, they integrate products using people to integrate products to solve a problem. But in the cloud world, you can create those integrations with programmatic or APIs. So we can create turnkey solutions. And with that, what we are able to do is really sell outcome based and go to the customer and say it's not time and material, it's not fixed price, it's pure outcome based. So to give you an example, let's say if you went to a theme park and while you're on a ride, somebody just takes a picture. And then after you're done with the ride, they put a picture in front of you and say, do you want to buy this? And if you don't buy it, they throw it away. So we literally have the ability to create those outcomes on the fly like that. And that's the disruption because that kind of outcome based allows customers to meet their goals much quicker. So one of the secrets to do that, if I can get this right is you have to have a really software driven, data driven environment. Absolutely. So that's fundamental. So I want to get explore how you do that. And then what does it mean for the customers? Because what you're essentially doing is kind of giving a little predictive solution management to them saying you want to connect to this service. Is that microservices? Is this where it's kind of being wired? Take us through how that works because there's tech involved, I'm not saying you don't want to throw anything away, but if it's digital, what does it mean to turn it on or off? So is this what people are referring to in microservices and cloud? Yeah, so I'll get to the microservices part. The disruption, the way the innovation that we created is if you take 20 years ago, when you look at people transforming to the internet, so the first time they're going on the internet, at the time they were paying a HTML developer, they would develop a web page in hundreds of dollars an hour. And today, high school kids can create their own web pages. That's the outcome focus because the technology mature to a point where it order generates those HTML pages. So fast forward 20 years, today people are looking for DevOps engineer as a talent and whatever that DevOps engineer produces, we have figured out a way to outcome base, and you can drag and drop and create my architectures and we ought to produce that code. That's what makes us very unique. Now, coming to your question about microservices, when we are going to large customers, they're taking this phased approach. First they will do lift and shift based move to cloud, which actually doesn't even give them a lot of efficiency, doesn't give them better responsiveness, doesn't optimize for cloud and give the benefits. Say they put in the effort to apply DevOps to become very responsive to customers. So if I'm a bank, I have my checking business and savings business, and each line of business got very efficient by using cloud, but they have not disrupted an industry because they have not created a platform across lines of business, right? So what they really need to do is to take these services that are providing across lines of business and create a platform of microservices. So you basically provide an automation layer for things that are automated, but you allow glue to bring them together. Absolutely. That then kicks off microservices on top of it. Absolutely. So very innovative, so you essentially, it's DevOps in a box. That's it, and what not? Or in the cloud. Yeah, what normally takes three years, so most of our customers, when they tell this story, they tell us, oh, that's five years down the road. So we knock out three years off the mark, right? There are companies that, for example, DoD is one of our customers. There are some other companies that have been working with DoD for the last two, three years, and they have not been able to accomplish what we accomplished in three months. You can see a more holistic approach. I can imagine, just you basically break it down, automate it, put it in the library, use the overlaid, drag and drop. Exactly, plug and play. So question for you, so this makes sense in hardened environments, like DoD, probably locked and solid, pretty solid. But what about unknown new processes? How do you guys look at that? Do you take them as they come, use AI? So if you have unknown processes that couldn't morph out of this, how do you deal with that use case? So yeah, those, unfortunately, so what, there's this notion of co-creation. So there's unknown processes where we put our best engineers, is what drives to this commoditization or LEGOs that we should use. So you're always feeding the system with new, if you will, recipes, I hate to use that word, it's more of a chef thing, but more modules, if you will, a bit automated way, so it's really push-button cloud. Absolutely, so no integration of the hire coders to do anything, and at best hit a REST API or initiate a microservice. So what, I mean, the company started with Amazon.com, I'm sorry, Amazon Web Services as our first customer, and they retained us for software companies like Microsoft, SAP, and they went to Amazon and said we want to create a turnkey solution, like email as a solution, for example, for Microsoft. Exchange is software, email as a solution is spam filters plus four or five other things, that we have to click button and launch, and Amazon, then we were servicing Amazon to create these turnkey solutions. Talk about the DoD deal, because now this is interesting, because I can see how they could like this. What does it mean for your customer, in this case, the DoD, as you won this new contract, I was announced a couple days ago? How'd that go down? Yeah, so I think we are super happy. Actually, again, 2010. Your friends calling them, hey, that $950 million, check clear yet, that doesn't work that way. It doesn't quite work that way. But although, just some history, 10 years ago, I had to choose between joining as a lead cloud architect for DISA versus first architect for Amazon Web Services. And I made the choice to go to Amazon Web Services, although I really loved servicing DoD, because I think DoD is very mature in what you're calling microservices. Back in the day, they had to be on the forefront of net-centric enterprise services, modern-day microservices, because the Information Sharing Act required them to create so many services across the department. But there wasn't a technology like Amazon Web Services to make them so successful. So we are coming back now, and we are able to do this. And I was with a company called MITRE at the time. And I was the lead on the first infrastructure of the service BPA. If I compare to what that infrastructure of the service BPA was, the blanket purchase agreement, to what this OTA, I think it's a night and day difference, OTA stands for Other Transaction Agreements, which is a contract thing. It's a contract thing. It's outside of Federal Acquisition Regulation, which is beautiful, by the way, because unlike, if you're doing such a deal, $950 million deal, probably companies that spend millions of dollars to write paper to win the deal, OTAs are a little different. DIUX, who has the charter for the OTA, they need to find a real customer and a real problem to bring commercial entities and the commercial innovation to solve a DOE problem. And then we have to prove ourselves that about, I'm told 29 companies competed and we won the first phase, but there are two consequent phases where we have to provide our services, our platform, to the customer satisfaction, and the OTA can only be the services we already provide. So it's a very proven technology. And as I see some of these social media responses, I look at those responses, people are talking about, oh, small companies winning these big deals and somebody was responding like, okay, we spent hundreds of millions on large companies, did nothing, and the small company already did a lot with $6 million. Well, that's the flattening of the world we're living in. You're dealing with DevOps, you've automated away a lot of their inefficiencies. Absolutely. And this is really what cloud's about. That's the promise that you're getting to the DOD. So the question for you is, okay, now as you go into the same, they could have added another $50 million, just to get a nice billion dollar, maybe a unicorn feature in there. But congratulations, you got to go in and automate. How do you roll this out? How big is the company? What are your plans? What do you go from here? Our company today is about 300 plus people, but we're not ruling this out on a people basis, obviously. Usually we have at least 10x more productivity than a normal company because, especially servicing someone like DOD is very interesting because they do follow standards set by DISA. So what that means is if I'm building applications or microservices, which is a collection of instances, I have DISA as something called STIGD, it's security guidelines. So everybody is using these STIGD components. Now we create this drag and drop package of those components and at that point it's variations of those components that you drag and drop and create, right? And the best thing is you get very consistent, quality, secure deployment. I mean, you and I are on the same page on this whole DevOps valuation, and certainly Mark Andreessen wrote that seminal comment about the 10x engineer. This is really the scale we're talking about here. So for the folks that don't get this, how do you explain to them like what Oracle and IBM and the other guys are trying to do, they're old processes are like, they got stacks of binders of paper, they have their strategies to go win the deals and then they scratch on that saying, why didn't we win? What are they missing? What are the competitors that failed in the bid? What are they missing with cloud in your opinion? Is it the architecture? Is it the automation? Is it the microservices? Or are they just missing the boat on the sales motion? Yeah, I think the biggest thing that people need to know is being on their toes. When Annie talks about being on their toes, when companies like Amazon at scale being on their toes, which means gone are those days where you can have roadmaps that you plan year from now and you do it, you're aware from the customer by then. But if you're constantly focusing on the customer and innovating every day, we have a vision and a backlog, we don't have a roadmap. What we work on is what our next customer needs. And you're constantly servicing customers and you have stories to tell about customers being successful. What's your backlog look like? Backlog could be a zillion things. What really matters? Yeah, exactly. Feature requests or just whatever the customer might need? Feature requests, user stories, really understanding the why part of it. We try to emphasize the why of, you know, why you're doing and whose pain are you solving type of things. But the important thing is, you know, are we focusing on what matters to the customer next? How hard is multicloud to do? Because you take DevOps and you have this abstraction layer that you're providing on top of elastic resources like say Amazon Web Services. When you start thinking multicloud, isn't that just an API call? Or does it kind of change? You have Amazon, it's got S3 and EC2 and a variety of other services. Azure and Google have their own file system. How hard is it code-based-wise to do what you're doing across multiple clouds? It's not at all difficult. Because every cloud has their infrastructure as code, languages like I talked about, you know, HTML to be generated to get a webpage. We use a technology called Terraform. That is inherently multicloud. So when we generate that code, I could change the provider and make it, you know, another cloud. Just a whole other language conversion. One other language, yes, exactly. Do you have to do that heavy lifting up front? And again, we don't. And so happened that if you look at our platform that automates all these, the Amazon part of it grew so much because of what I just said. The customer demand, even the enterprise customers that do have a multicloud strategy, you know, they end up using more of what is good, right? So we end up building more of what is good. So the lesson is, besides being your toes, which I would agree with Andy on that one, is to be DevOps, automate, connect via APIs. Yeah. Anything else you would add to that? And DevOps is a, it's a principle of being very agile, experimenting in small batches, being very responsive to customers. It's just all principles that, you know, that you embody and just call it DevOps. It's a culture, right? Managing partner, Rean Cloud C. Thanks so much for coming in. Congratulations on your 950 million, this close to a billion, almost congratulated, and congratulations to success. Infrastructure is code DevOps, going to the next level is all about automation and really making things connect and easily driven by software and data. It's the queue bringing you the data here in Washington DC, here in Arlington, Virginia. AWS is public sector world headquarters. I'm John Furrier. Thanks for watching.