(gentle music) >> Good morning from Las Vegas. It's theCUBE live at AWS Reinvent 2022 with tons of thousands of people today. Really kicks off the event. Big keynote that I think is probably just wrapping up. Lisa Martin here with Dave Vellante. Dave, this is going to be an action packed week on theCUBE no doubt. We talked with so many different companies. Every company's a software company these days but we're also seeing a lot of companies leaving software that can help them operate more efficiently in the background. >> Yeah, well some things haven't changed at Reinvent. A lot of people here, you know, back to 2019 highs and I think we exceeded those two hour keynotes. Peter DeSantis last night talking about new Graviton instances and then Adam Selipsky doing the typical two hour keynote. But what was different he was a lot more poetic than we used to hear from Andy Jassy, right? He was talking about the universe as an analogy for data. >> I loved that. >> Talked about ocean exploration as for the security piece and then exploring into the Antarctic for, you know, better chips, you know? So yeah, I think he did a good job there. I think a lot of people might not love it but I thought it was very well done. >> I thought so too. We're having kicking off a great day of live content for you all day today. We've got Eleanor Dorfman joining us, the sales leader at Retool. Eleanor, welcome to theCUBE. It's great to have you. >> Thank you so much for having me. >> So let's talk a little bit about Retool. I was looking on your LinkedIn page. I love the tagline, build custom internal tools best. >> Eleanor: Yep. >> Talk to us a little bit about the company you recently raised, series C two. Give us the backstory. >> Yeah, so the company was founded in 2017 by two co-founders who are best friends from college. They actually set out to build a FinTech company, a payments company. And as they were building that, they needed to build a ton of custom operations software that goes with that. If you're going to be managing people's money, you need to be able to do refunds. You need to be able to look up accounts, you need to be able to detect fraud, you need to do know your customer operations. And as they were building the sort of operations software that supports the business, they realized that there were patterns to all of it and that the same components were used at and again. And had the insight that that was actually probably a better direction to go in than recreating Venmo, which was I think the original idea. And that actually this is a problem every company has because every company needs operations engineering and operations software to run their business. And so they pivoted and started building Retool which is a platform for building custom operations software or internal tools. >> Dave: Good pivot. >> In hindsight, actually probably in the moment as well, was a good pivot. >> But you know, when you talk about some of those things, refunds, fraud, you know, KYC, you know, you think of operations software, you think of it as just internal, but all those things are customer facing. >> Eleanor: Yep. >> Right so, are we seeing as sort of this new era? Is that a trend that you guys, your founders saw that hey, these internal operations can be pointed at customers to support what, a better customer service, maybe even generate revenue, subscriptions? >> I think it's a direction we're actually heading now but we're just starting to scratch the surface of that. The focus for the last five years has very much been on this operations software and sort of changing the economics of developing it and making it easy and fast to productize workflows that were previously being done in spreadsheets or hacky workarounds and make it easier for companies to prioritize those so they can run their business more efficiently. >> And where are you having your customer conversations these days? Thinking of operations software in the background, but to Dave's point, it ends up being part of the customer experience. So where are you having your customer conversations, target audience, who's that persona? >> Mainly developers. So we're working almost exclusively with developer teams who have backlogs and backlogs of internal tools requests to build that sales teams are building manual forecasts. Support teams are in 19 different tools. Their supply chain teams are using seven different spreadsheets to do demand forecasting or freight forwarding or things like that. But they've never been able to be prioritized to the top of the list because customer facing software, revenue generating software, always takes prioritization. And in this economic environment, which is challenging for many companies right now, it's important to be able to do more with less and maximize the productivity especially of high value employees like engineers and developers. >> So what would you say the biggest business outcomes are? If the developer is really the focus, productivity is the- >> Productivity. It's for both, I would say. Developer productivity and being able to maximize your sort of R and D and maximize the productivity of your engineers and take away some of the very boring parts of the job. But, so I would say developer productivity, but then also the tools and the software that they're building are very powerful for end users. So I would say efficiency and productivity across your business. >> Across the business. >> I mean historically, you know, operations is where we focused IT and code. How much of the code out there is dedicated to sort of operations versus that customer facing? >> So I think it would actually be, it's kind of surprising. We have run a few surveys on this sort of, we call them the state of engineering time, and focusing on what developers are spending their time on. And a third of all code that is being written today is actually for this internal operations software. >> Interesting. And do you guys have news at the show? Are you announcing anything interesting or? >> Yeah, so our focus historically, you sort of gave away with one of your early questions, but our focus has always been on this operations, this building web applications on building UIs on top of databases and APIs and doing that incredibly fast and being able to do it all in one place and integrate with as any data source that you need. We abstract away access authentication deployment and you build applications for your internal teams. But recently, we've launched two new products. We're actually supporting more external use cases and more customer facing use cases as well as automating CRON jobs, ETL jobs alerting with the new retail workflows product. So we're expanding the scope of operations software from web applications to also internal operations like CRON jobs and ETL jobs. >> Explain that. Explain the scourge of CRON jobs to the audience. >> Yeah, so operations software businesses run on operations software. It's interesting, zooming out, it's actually something you said earlier as well. Every company has become a software company. So when you think about software, you tend to think about here. Very cool software that people are selling. And software that you use as a consumer. But Coca-Cola for example, has hundreds of software engineers that are building tools to make the business run for forecasting, for demand gen, for their warehouse distribution and monitoring inventory. And there's two types of that. There's the applications that they build and then the operations that have to run behind that. Maybe a workflow that is detecting how many bottles of Coca-Cola are in every warehouse and sending a notification to the right person when they're out or when they, a refill is very strong, but you know when you need a refill. So it does that, it takes those tasks, those jobs that run in the background and enables you to customize them and build them very rapidly in a code first way. >> So some of the notes that you guys provided say that there's over 500 million software apps that are going to be built in the next few years alone. That's tremendous. How much of that is operation software? >> I mean I think at least a third of that, if not more. To the point where every company is being forced to maximize their resources today and operational efficiency is the way to do that. And so it can become a competitive advantage when you can take the things that humans are doing in spreadsheets with 19 open tabs and automate that. That saves hours a day. That's a significant, significant driver of efficiency and productivity for a business >> It does, and there's direct correlation to the customer experience. The use experience. >> Almost certainly. When you think about building support tooling, I was web chat, chatting on the with Gogo wifi support on my flight over here and they asked for my order number and I sent it and they looked up my account and that's a custom piece of software they were using to look up the account, create a new account for me, and restore my second wifi purchase. And so when you think about it, you're actually, even just as a consumer, interacting with this custom software on the day time. And that's because that's what companies use to have a good customer experience and have an efficient business. >> And what's the relationship with AWS? You guys started, I think you said 2017, so you obviously started in the cloud, but I'm particularly interested in from a seller perspective, what that's like. Working with Amazon, how's that affected your business? >> Yeah, I mean so we're built on AWS, so we're customers and big fans. And obviously like from a selling perspective, we have a ton of integrations with AWS so we're able to integrate directly into all the different AWS products that people are using for databases, for data warehouses, for deployment configurations, for monitoring, for security, for observability, we can basically fit into your existing AWS stack in order to make it as seamless integration with your software so that building in Retool is just as seamless as building it on your own, just much, much faster. >> So in your world, I know you wanted to but, in your world is it more analytics? is it more transactional, sort of? Is it both? >> It's all of the above. And I think what's, over Thanksgiving, I was asked a lot to explain what Retool did with people who were like, we just got our first iPhone. And so I tried to explain with an example because I have yet to stumble on the perfect metaphor. But the example I typically use is DoorDash is a customer of ours. And for about three years, and three years ago, they had a problem. They had no way of turning off delivery in certain zip codes during storms. Which as someone who has had orders canceled during a storm, it's an incredibly frustrating experience. And the way it worked is that they had operation team members manually submitting requests to engineers to say there's a storm in this zip code and an engineer would run a manual task. This didn't scale with Doordash as they were opening in new countries all over the world that have very different weather patterns. And so they looked, they had one, they were sort of confronted with a choice. They could buy a piece of software out of the box. There is not a startup that does this yet. They could build it by hand, which would mean scoping the requirements designing a UI, building authentication, building access controls, putting it into a, putting it into a sprint, assigning an engineer. This would've taken months and months. And then it would take just as long to iterate on it or they could use Retool. So they used Retool, they built this app, it saved, I think they were saying up to two years of engineering time for this one application because of how quickly it was. And since then they've built, I think 50 or 60 more automating away other tasks like that that were one out of spreadsheets or in Jira or in Slack notifications or an email saying, "Hey, could you please do this thing? There's a storm." And so now they use us for dozens and dozens of operations like that. >> A lot of automation and of course a lot of customer delight on the other end of the spectrum as you were talking about. It is frustrating when you don't get that order but it's also the company needs to be able to have the the tools in place to automate to be able to react quickly. >> Eleanor: Exactly. >> Because the consumers are, as we know, quite demanding. I wanted to ask you, I mentioned the tagline in the beginning, build custom internal tools fast. You just gave us a great example of DoorDash. Huge business outcomes they're achieving but how fast are we talking? How fast can the average developer build these internal tools? >> Well, we've been doing a fun thing at our booth where we ask people what a problem is and build a tool for them while we're there. So for something lightweight, you can build it in 10 minutes. For something a little more complex, it can take up to a few weeks depending on what the requirements are. But we all have people who will be on a call with us introducing them to our software for the first time and they'll start telling us about their problems and in the background we'll be building it and then at the end we're like, is this what you meant? And they're like, we'd like to add that to our cart. And obviously, it's a platform so you can't do that. But we've been able to build applications on a call before while people are telling us what they need. >> So fast is fast. >> I would say very fast, yeah. >> Now how do you price? >> Right now, we have a couple different plans. We actually have a motion where you can sign up on our website and get started. So we have a free plan, we've got plans for startups, and then we've got plans all the way up to the enterprise. >> Right. And that's a subscription pricing kind of thing? >> Subscription model, yes. >> So I get a subscription to the platform and then what? Is there also a consumption component? >> Exactly. So there's a consumption component as well. So there's access to the platform and then you can build as many applications as you need. Or build as many workflows. >> When you're having customer conversations with prospects, what do you define as Retool's superpowers? You're the sales leader. What are some of those key superpowers that you think really differentiate Retool? >> I do think, well, the sales team first and foremost, but that's not a fair answer. I would say that people are a bit differentiator though. We have a lot of very talented people who are have a ton of domain expertise and care a ton about the customer outcomes, which I do actually think is a little more rare than it should be. But we're one of the only products out there that's built with a developer first mindset, a varied code first mindset, built to integrate with your software development life cycle but also built with the security and robustness that enterprise companies require. So it's able to take an enterprise grade software with a developer first approach while still having a ton of agility and nimbleness which is what people are really craving as the earth keeps moving around them. So I would say that's something that really sets us apart from the field. >> And then talk about some of the what developers are saying, some of the feedback, some of the responses, and maybe even, I know we're just on day one of the show, but any feedback from the booth so far? >> We've had a few people swing by our booth and show us their Retool apps, which is incredibly cool. That's my absolute favorite thing is encountering a Retool application in the wild which happens a lot more than I would've thought, which I shouldn't say, but is incredibly rewarding. But people love it. It's the reason I joined is I'd never heard someone have a product that customers talked about the way they talk about Retool because Retool enables them to do things. For some folks who use it, it enables them to do something they previously couldn't do. So it gives them super powers in their job and to triple their impact. And then for others, it just makes things so fast. And it's a very delightful experience. It's very much built by developers, for developers. And so it's built with a developer's first mindset. And so I think it's quite fun to build in Retool. Even I can build and Retool, though not well. And then it's extremely impactful and people are able to really impact their business and delight their coworkers which I think can be really meaningful. >> Absolutely. Delighting the coworkers directly relates to delighting the customers. >> Eleanor: Exactly. >> Those customer experience, employee experience, they're like this. >> Eleanor: Exactly. >> They go hand in hand and the employee experience has to be outstanding to be able to delight those customers, to reduce churn, to increase revenue- >> Eleanor: Exactly. >> And for brand reputation. >> And it also, I think there is something as someone who is customer facing, when my coworkers and developers I work with build tools that enable me to do my job better and feel better about my own performance and my ability to impact the customer experience, it's just this incredibly virtuous cycle. >> So Retool.com is where folks can go to learn more and also try that subscription that you said was free for up to five users. >> Yes, exactly. >> All right. I guess my last question, well couple questions for you. What are some of the things that excited you that you heard from Adam Selipsky this morning? Anything from the keynote that stood out in terms of- >> Dave: Did you listen to the keynote? >> I did not. I had customer calls this morning. >> Okay, so they're bringing- >> East coast time, east coast time. >> One of the things that will excite you I think is they're connecting, making it easier to connect their databases. >> Eleanor: That would very much exciting. >> Aurora and Redshift, right? Okay. And they're making it easier to share data. I dunno if it goes across regions, but they're doing better integration. >> Amazing. >> Right? And you guys are integrating with those tools, right? Those data platforms. So that to me was a big thing for you guys. >> It is also and what a big thing Retool does is you can build a UI layer for your application on top of every single data source. And you hear, it's funny, you hear people talk about the 360 degree review of the customer so much. This is another, it's not our primary value proposition, but it is certainly another way to get there is if you have data from their desk tickets from in Redshift, you have data from Stripe, from their payments, you have data from Twilio from their text messages, you have data from DataDog where they're having your observability where you can notice analytics issues. You can actually just use Retool to build an app that sits on top of that so that you can give your support team, your sales team, your account management team, customer service team, all of the data that they need on their customers. And then you can build workflows so that you can do automated customer engagement reports. I did a Slack every week that shows what our top customers are doing with the product and that's built using all of our automation software as well. >> The integration is so important, as you just articulated, because every, you know, we say every company's a software company these days. Every company's a data company. But also, the data democratization that needs to happen to be able for lines of business so that data moves out of certain locked in functions and enables lines of business to use it. To get that visibility that you were just talking about is really going to be a competitive advantage for those that survive and thrive and grow in this market. >> It's able to, I think it's first it's visibility, but then it's action. And I think that's what Retool does very uniquely as well is it can take and unite the data from all the places, takes it out of the black box, puts it in front of the teams, and then enables them to act on it safely and securely. So not only can you see who might be fraudulent, you can flag them as fraud. Not only can you see who's actually in danger, you can click a button and send them an email and set up a meeting. You can set up an approval workflow to bring in an exec for engagement. You can update a password for someone in one place where you can see that they're having issues and not have to go somewhere else to update the password. So I think that's the key is that Retool can unlock the data visibility and then the action that you need to serve your customers. >> That's a great point. It's all about the actions, the insights that those actions can be acted upon. Last question for you. If you had a billboard that you could put any message that you want on Retool, what would it say? What's the big aha? This is why Retool is so great. >> I mean, I think the big thing about Retool is it's changing the economics of software development. It takes something that previously would've been below the line and that wouldn't get prioritized because it wasn't customer facing and makes it possible. And so I would say one of two billboards if I could be a little bit greedy, one would be Retool changed the economics of software development and one would be build operations software at the speed of thought. >> I love that. You're granted two billboards. >> Eleanor: Thank you. >> Those are both outstanding. Eleanor, it's been such a pleasure having you on the program. Thank you for talking to us about Retool. >> Eleanor: Thank you. >> Operations software and the massive impact that automating it can make for developers, businesses alike, all the way to the top line. We appreciate your insights. >> Thank you so much. >> For our guests and Dave Vellante, I'm Lisa Martin. You're watching theCUBE, the leader in live, emerging, and enterprise tech coverage. (gentle music)

>>Hello, everyone. My name is Rick Pew. I'm a senior product manager at Mirant. This and I have been working on the Doctor Enterprise Container Cloud for the last eight months. Today we're gonna be talking about multi cloud kubernetes. So the first thing to kind of look at is, you know, is multi cloud rial. You know, the terms thrown around a lot and by the way, I should mention that in this presentation, we use the term multi cloud to mean both multi cloud, which you know in the technical sense, really means multiple public clouds and hybrid cloud means public clouds. And on Prem, uh, we use in this presentation will use the term multi cloud to refer to all different types of multiple clouds, whether it's all public cloud or a mixture of on Prem and Public Cloud or, for that matter, multiple on Prem clouds as doctor and price container. Cloud supports all of those scenarios. So it really well, let's look at some research that came out of flex era in their 2020 State of the cloud report. You'll notice that ah, 33% state that they've got multiple public and one private cloud. 53% say they've got multiple public and multiple private cloud. So if you have those two up, you get 86% of the people say that they're in multiple public clowns and at least one private cloud. So I think at this stage we could say that multi cloud is a reality. According to 4 51 research, you know, a number of CEO stated that the strong driver their desire was to optimize cost savings across their private and public clouds. Um, they also wanted to avoid vendor lock in by operating in multiple clouds and try to dissuade their teams from taking too much advantage of a given providers proprietary infrastructure. But they also indicated that there the complexity of using multiple clouds hindered the rate of adoption of doing it doesn't mean they're not doing it. It just means that they don't go assed fast as they would like to go in many cases because of the complexity. And here it Miranda's. We surveyed our customers as well, and they're telling us similar things, you know. Risk management, through the diversification of providers, is key on their list cost optimization and the democratization of allowing their development teams, uh, to create kubernetes clusters without having to file a nightie ticket. But to give them a self service, uh, cloud like environment, even if it's on prem or multi cloud to give them the ability to create their own clusters, resize their own clusters and delete their own clusters without needing to have I t. Or of their operations teams involved at all. But there are some challenges with this, with the different clouds you know require different automation. Thio provisioned the underlying infrastructure or deploy and operating system or deployed kubernetes, for that matter, in a given cloud. You could say that they're not that complicated. They all have, you know, very powerful consoles and a P I s to do that. But did you get across three or four or five different clouds? Then you have to learn three or four or five different AP ice and Web consoles in order to make that happen on in. That scenario is difficult to provide self service for developers across all the cloud options, which is what you want to really accelerate your application innovation. So what's in it for me? You know We've got a number of roles and their prizes developers, operators and business leaders, and they have somewhat different needs. So when the developer side the need is flexibility to meet their development schedules, Number one you know they're under constant pressure to produce, and in order to do that, they need flexibility and in this case, the flexibility to create kubernetes clusters and use them across multiple clouds. Now they also have C I C D tools, and they want them to be able to be normalized on automated across all of the the on prim and public clouds that they're using. You know, in many cases they'll have a test and deployment scenario where they'll want to create a cluster, deploy their software, run their test, score the tests and then delete that cluster because the only point of that cluster, perhaps, was to test ah pipeline of delivery. So they need that kind of flexibility. From the operator's perspective, you know, they always want to be able to customize the control of their infrastructure and deployment. Uh, they certainly have the desire to optimize their optics and Capex fans. They also want to support their develops teams who many times their their customers through a p I access for on Prem and public clouds burst. Scaling is something operators are interested in, and something public clouds can provide eso the ability to scale out into public clouds, perhaps from there on prem infrastructure in a seamless manner. And many times they need to support geographic distribution of applications either for compliance or performance reasons. So having you know, data centers all across the world and be able to specifically target a given region, uh, is high on their list. Business leaders want flexibility and confidence to know that you know, they're on prim and public cloud uh, deployments. Air fully supported. They want to be able, like the operator, optimize their cloud, spends business leaders, think about disaster recovery. So having the applications running and living in different data centers gives them the opportunity to have disaster recovery. And they really want the flexibility of keeping private data under their control. On on Prem In certain applications may access that on Prem. Other applications may be able to fully run in the cloud. So what should I look for in a container cloud? So you really want something that fully automates these cluster deployments for virtual machine or bare metal. The operating system, uh, and kubernetes eso It's not just deploying kubernetes. It's, you know, how do I create my underlying infrastructure of a VM or bare metal? How do I deploy the operating system? And then, on top of all that, I want to be able to deploy kubernetes. Uh, you also want one that gives a unified cluster lifecycle management across all the clouds. So these clusters air running software gets updated. Cooper Netease has a new release cycle. Uh, they come out with something new. It's available, you know, How do you get that across all of your clusters? That air running in multiple clouds. We also need a container cloud that can provide you the visibility through logging, monitoring and alerting again across all the clouds. You know, many offerings have these for a particular cloud, but getting that across multiple clouds, uh, becomes a little more difficult. The Doctor Enterprise Container cloud, you know, is a very strong solution and really meets many of these, uh, dimensions along the left or kind of the dimensions we went through in the last slide we've got on Prem and public clouds as of RG A Today we're supporting open stack and bare metal for the on Prem Solutions and AWS in the public cloud. We'll be adding VM ware very soon for another on Prem uh, solution as well as azure and G C P. So thank you very much. Uh, look forward, Thio answering any questions you might have and we'll call that a rap. Thank you. >>Hi, Rick. Thanks very much for that. For that talk, I I am John James. You've probably seen me in other sessions. I do marketing here in Miran Tous on. I wanted to to take this opportunity while we had Rick to ask some more questions about about multi cloud. It's ah, potentially a pretty big topic, isn't it, Rick? >>Yeah. I mean, you know, the devil's in the details and there's, uh, lots of details that we could go through if you'd like, be happy to answer any questions that you have. >>Well, we've been talking about hybrid cloud for literally years. Um, this is something that I think you know, several generations of folks in the in the I. A s space doing on premise. I s, for example, with open stack the way Miran Tous Uh does, um, found, um, you know, thought that that it had a lot of potential. A lot of enterprises believed that, but there were There were things stopping people from from making it. Really, In many cases, um, it required a very, ah, very high degree of willingness to create homogeneous platforms in the cloud and on the premise. Um, and that was often very challenging. Um, but it seems like with things like kubernetes and with the isolation provided by containers, that this is beginning to shift, that that people are actually looking for some degree of application portability between their own Prem and there and their cloud environments. And that this is opening up, Uh, you know, investment on interest in pursuing this stuff. Is that the right perception? >>Yeah. So let's let's break that down a little bit. So what's nice about kubernetes is through the a. P. I s are the same. Regardless of whether it's something that Google or or a W s is offering as a platform as a service or whether you've taken the upstream open source project and deploy it yourself on parameter in a public cloud or whatever the scenario might be or could be a competitor of Frances's product, the Kubernetes A. P I is the same, which is the thing that really gives you that application portability. So you know, the container itself is contained arising, obviously your application and minimizing any kind of dependency issues that you might have And then the ability to deploy that to any of the coup bernetti clusters you know, is the same regardless of where it's running, the complexity comes and how doe I actually spend up a cluster in AWS and open stack and D M Where and gp An azure. How do I build that infrastructure and and spin that up and then, you know, used the ubiquitous kubernetes a p I toe actually deploy my application and get it to run. So you know what we've done is we've we've unified and created A I use the word normalized. But a lot of times people think that normalization means that you're kind of going to a lowest common denominator, which really isn't the case and how we've attacked the the enabling of multi cloud. Uh, you know, what we've done is that we've looked at each one of the providers and are basically providing an AP that allows you to utilize. You know, whatever the best of you know, that particular breed of provider has and not, uh, you know, going to at least common denominator. But, you know, still giving you a ah single ap by which you can, you know, create the infrastructure and the infrastructure could be on Prem is a bare metal infrastructure. It could be on preeminent open stack or VM ware infrastructure. Any of the public clouds, you know, used to have a a napi I that works for all of them. And we've implemented that a p i as an extension to kubernetes itself. So all of the developers, Dev ops and operators that air already familiar operating within the, uh, within the aapi of kubernetes. It's very, very natural. Extension toe actually be able to spend up these clusters and deploy them >>Now that's interesting. Without giving away, obviously what? Maybe special sauce. Um, are you actually using operators to do this in the Cooper 90? Sense of the word? >>Yes. Yeah, we've extended it with with C R D s, uh, and and operators and controllers, you know in the way that it was meant to be extended. So Kubernetes has a recipe on how you extend their A P I on that. That's what we used as our model. >>That, at least to me, makes enormous sense. Nick Chase, My colleague and I were digging into operators a couple of weeks ago, and that's a very elegant technology. Obviously, it's a it's evolving very fast, but it's remarkably unintimidating once you start trying to write them. We were able toe to compose operators around Cron and other simple processes and just, >>you know, >>a couple of minutes on day worked, which I found pretty astonishing. >>Yeah, I mean, you know, Kubernetes does a lot of things and they spent a lot of effort, um, in being able, you know, knowing that their a p I was gonna be ubiquitous and knowing that people wanted to extend it, uh, they spent a lot of effort in the early development days of being able to define that a p I to find what an operator was, what a controller was, how they interact. How a third party who doesn't know anything about the internals of kubernetes could add whatever it is that they wanted, you know, and follow the model that makes it work. Exactly. Aziz, the native kubernetes ap CSTO >>What's also fascinating to me? And, you know, I've I've had a little perspective on this over the past, uh, several weeks or a month or so working with various stakeholders inside the company around sessions related to this event that the understanding of how things work is by no means evenly distributed, even in a company as sort of tightly knit as Moran Tous. Um, some people who shall remain nameless have represented to me that Dr Underprice Container Cloud basically works. Uh, if you handed some of the EMS, it will make things for you, you know, and this is clearly not what's going on that that what's going on is a lot more nuanced that you are using, um, optimal resource is from each provider to provide, uh, you know, really coherent architected solutions. Um, the load balancing the d. N s. The storage that this that that right? Um all of which would ultimately be. And, you know, you've probably tried this. I certainly have hard to script by yourself in answerable or cloud formation or whatever. Um, this is, you know, this is not easy work. I I wrote a about the middle of last year for my prior employer. I wrote a dip lawyer in no Js against the raw aws a piece for deployment and configuration of virtual networks and servers. Um, and that was not a trivial project. Um, it took a long time to get thio. Uh, you know, a dependable result. And to do it in parallel and do other things that you need to do in order to maintain speed. One of the things, in fact, that I've noticed in working with Dr Enterprise Container Cloud recently, is how much parallelism it's capable of within single platforms. It's It's pretty powerful. I mean, if you want to clusters to be deployed simultaneously, that's not hard for Doc. Aerated price container cloud to dio on. I found it pretty remarkable because I have sat in front of a single laptop trying to churn out of cluster under answerable, for example, and just on >>you get into that serial nature, your >>poor little devil, every you know, it's it's going out and it's ssh, Indian Terminals and it's pretending it's a person and it's doing all that stuff. This is much more magical. Um, so So that's all built into the system to, isn't it? >>Yeah. Interesting, Really Interesting point on that. Is that you know, the complexity isn't not necessarily and just creating a virtual machine because all of these companies have, you know, spend a lot of effort to try to make that as easy as possible. But when you get into networking, load balancing, routing, storage and hooking those up, you know, two containers automating that if you were to do that in terror form or answerable or something like that is many, many, many lines of code, you know, people have to experiment. Could you never get it right the first or second or the third time? Uh, you know, and then you have to maintain that. So one of the things that we've heard from customers that have looked a container cloud was that they just can't wait to throw away their answerable or their terror form that they've been maintaining for a couple of years. The kind of enables them to do this. It's very brittle. If if the clouds change something, you know on the network side, let's say that's really buried. And it's not something that's kind of top of mind. Uh, you know, your your thing fails or maybe worse, you think that it works. And it's not until you actually go to use it that you notice that you can't get any of your containers. So you know, it's really great the way that we've simplified that for the users and again democratizing it. So the developers and Dev ops people can create these clusters, you know, with ease and not worry about all the complexities of networking and storage. >>Another thing that amazed me as I was digging into my first, uh, Dr Price container Cloud Management cluster deployment was how, uh, I want I don't want to use the word nuanced again, but I can't think of a better word. Nuanced. The the security thinking is in how things air set up. How, um, really delicate the thinking about about how much credential power you give to the deploy. Er the to the seed server that deploys your management cluster as opposed thio Um uh or rather the how much how much administrative access you give to the to the administrator who owns the entire implementation around a given provider versus how much power the seed server gets because that gets its own user right? It gets a bootstrap user specifically created so that it's not your administrator, you know, more limited visibility and permissions. And this whole hierarchy of permissions is then extended down into the child clusters that this management cluster will ultimately create. So that Dev's who request clusters will get appropriate permissions granted within. Ah, you know, a corporate schema of permissions. But they don't get the keys to the kingdom. They don't have access to anything they don't you know they're not supposed to have access to, but within their own scope, they're safe. They could do anything they want, so it's like a It's a It's a really neat kind of elegant way of protecting organizations against, for example, resource over use. Um, you know, give people the power to deploy clusters, and basically you're giving them the power toe. Make sure that a big bill hits you know, your corporate accounting office at the end of the billing cycle, um so there have to be controls and those controls exist in this, you know, in this. >>Yeah, And there's kind of two flavors of that. One is kind of the day one that you're doing the deployment you mentioned the seed servers, you know, And then it creates a bastion server, and then it creates, you know, the management cluster and so forth, you know, and how all those permissions air handled. And then once the system is running, you know, then you have full access to going into key cloak, which is a very powerful open source identity management tool on you have dozens of, you know, granular permissions that you can give to an individual user that gives them permission to do certain things and not others within the context of kubernetes eso. It's really well thought out. And the defaults, you know, our 80% right. You know, there's very few people are gonna have to go in and sort of change those defaults. You mentioned the corporate directory. You know, hooks right upto l bap or active directory can suck everybody down. So there's no kind of work from a day. One perspective of having to go add. You know everybody that you can think of different teams and groupings of of people. Uh, you know, that's kind of all given from the three interface to the corporate directory. And so it just makes kind of managing the users and and controlling who can do what? Uh, really easy. And, you know, you know, day one day two it's really almost like our one hour to write because it's just all the defaults were really well thought out. You can deploy, you know, very powerful doctor and price container cloud, you know, within an hour, and then you could just start using it. And you know, you can create users if you want. You can use the default users. That air set up a time goes on, you can fine tune that, and it's a really, really nice model again for the whole frictionless democratization of giving developers the ability to go in and get it out of, you know, kind of their way and doing what they want to do. And I t is happy to do that because they don't like dozens of tickets and saying, you know, create a cluster for this team created cluster for that team. You know, here's the size of these guys. Want to resize when you know let's move all that into a self service model and really fulfill the prophecy of, you know, speeding up application development. >>It strikes me is extremely ironic that one of the things that public cloud providers bless them, uh, have always claimed, is that their products provide this democratization when in the experience, I think my own experience and the experience of most of the AWS developers, for example, not toe you know, name names, um, that I've encountered is that an initial experience of trying to start start a virtual machine and figuring out how to log into it? A. W s could take the better part of an afternoon. It's just it's not familiar once you have it in your fingers. Boom. Two seconds, right. But, wow, that learning curve is steep and precipitous, and you slip back and you make stupid mistakes your first couple 1000 times through the loop. Um, by letting people skip that and letting them skip it potentially on multiple providers, in a sense, I would think products like this are actually doing the public cloud industry is, you know, a real surface Hide as much of that as you can without without taking the power away. Because ultimately people want, you know, to control their destiny. They want choice for a reason. Um, and and they want access to the infinite services And, uh, and, uh, innovation that AWS and Azure and Google are all doing on their platforms. >>Yeah, you know, and they're solving, uh, very broad problems in the public clouds, you know, here were saying, you know, this is a world of containers, right? This is a world of orchestration of these containers. And why should I have to worry about the underlying infrastructure, whether it's a virtual machine or bare metal? You know, I shouldn't care if I'm an application developer developing some database application. You know, the last thing I wanna worry about is how do I go in and create a virtual machine? Oh, this is running. And Google. It's totally different than the one I was creating. An AWS I can't find. You know where I get the I P address in Google. It's not like it was an eight of us, you know, and you have to relearn the whole thing. And that's really not what your job is. Anyways, your job is to write data base coat, for example. And what you really want to do is just push a button, deploy a nor kiss traitor, get your app on it and start debugging it and getting it >>to work. Yep. Yeah, it's It's powerful. I've been really excited to work with the product the past week or so, and, uh, I hope that folks will look at the links at the bottoms of our thank you slides and, uh, and, uh, avail themselves of of free trial downloads of both Dr Enterprise Container, Cloud and Lens. Thank you very much for spending this extra time with me. Rick. I I think we've produced some added value here for for attendees. >>Well, thank you, John. I appreciate your help. >>Have a great rest of your session by bike. >>Okay, Thanks. Bye.

>> Narrator: From Hell's Kitchen in New York City, it's The Cube on the ground at Serverlessconf. Brought to you by SilliconANGLE Media. >> Hi, I'm Stu Miniman with The Cube, and we're here are Serverlessconf in Hell's Kitchen New York City, really happy to welcome to the program, another one of the keynote speakers. Ben Kehoe, who's the Cloud Robotics research scientist at iRobot. >> Yeah. >> Ben, great to see you. >> Great to see you too. >> All right, so tell us a little bit about how you got involved with Serverless. >> Yeah, I mean it all started, I was a grad student in robotics, and I started thinking about, you know, we have all these robotics algorithms. And as the cloud can enable robots to do more and better things, how do we help turn those robotics algorithms into web services. And I didn't get very far in that, right towards the end of my PHD, and then that was 2014, LAMBDA was released, and it was like hey, that looks like it does the kind of thing that I was thinking about that we needed. So then I joined iRobot, and we were developing a cloud solution, a cloud application for our connected robots and apps, and to help us scale that to stay lean. Serverless was the right choice, and we've been doing that since 2015. >> Yeah, so Ben, what is it about Serverless that made it a fit for this? You know, I think about, doesn't their responsiveness, performance, latency if I have to go >> Yeah. >> up to the cloud and back like that way. I think some of this needs to kind of live locally. And some that goes there, maybe you can just briefly tease through some of those dynamics for us. >> Yeah, when you're talking about robots, you definitely have to keep things local. You want a robot to be responsive to its environment. You want, that even if its cloud connection disappears, that it can still accomplish all of its tasks. So it's always a mix of keeping it as a timeless robot that is enabled to do better things through the cloud, in terms of additional computational power, or accessing libraries of information to help it understand its world better. And of course, when one robot learns something, all robots can benefit from that experience. >> Excellent, so this is the first step for Skynet is what you're saying, right? >> Could be. >> All right, bring us in a little bit. Your keynote, what were you looking to share? You know, some of the key points. >> Yeah, I think in the talks that I've given at Serverlessconf, they tend to be as much as I am enthusiastic about Serverless, fully bodying, I try and pull us back a little bit to say, "What are we still missing? "What's not here yet? "Where do we need to go?" And so I had some frowny face emoji in my talk about event driven programming, event driven Serverless, and Serverless without event driven programming. Now we're still, you know, we have areas to improve in each one of those. And then that transitioned really into, "How do we start bringing in people who "are just starting into Serverless?" Larger organizations, more traditional architectures, and people who are experienced with that, and understand traditional architectures well. How do we get them on board with Serverless? And so that starts with just the gateway drug, which is infrastructure automation at the edges of their application, taking scripts that they run from developer machines with Cron jobs, and moving those into a function that's triggered by some cloud event. And then from there, starting to bring them over in terms of you can reduce your costs by eliminating idle resources. You can start to simplify and strengthen by refactoring some of that. And then once you really get them thinking about, "Oh, this is really working for the things "that we're doing." New features will start to be developed. Serverless native or event driven native. And then sort of at the end of the talk, the key is that because Serverless architectures look different from traditional architectures, there's something called Conway's law that says, "The design of your application will follow "the communication patterns in your organization." >> Stu: Right. >> And so you have to sort of flip that around to say, "Well if our design is changing, then we have "to make our organization change as well." >> Right, does that mean we're going to have, micro-employees you know? Instead of micro services we have, you know, employees that we hire them, and then we fire them pretty quick when we don't need them, or? >> I hope not. >> Yeah. >> I hope not. >> (crosstalk) that that's the part time, the uber's >> Yes. >> nation of the workforce. >> Yes. That would be, I think an inefficient way of going about it. >> Yeah. >> But I think we do need to reset expectations around what we have control over, and what we don't, because when you're on a traditional architecture with servers, you can reach in and fix problems that you have. And recognizing that when you're running on functions as a service platform, and using managed services, that when the provider has some sort of incident, you're out of control of that. It's a very uncomfortable place to be of not being in control of your own destiny, even though when you look at the big picture, that's going to happen less often, then if you were doing it yourself. >> Stu: Yeah. >> And so that's making sure that the mindset inside the organization, and the way that people communicate, is appropriately tuned to that sort of new paradigm. >> Okay, yeah. Ben, some of those frowny faces, what are things that the community is working on that you're hopeful for? What are some of the areas that we need for the maturation of this space? >> Yeah, I think something that I talked about previously that's coming around, is monitoring. So there's much more tools out there to monitor the infrastructure to know what's going on inside these functions and these managed services. And there's now some security analysis tools that are coming out, that some of these people are present here. And that was a big aspect that I've harped on for a long time of... We have a lot of mature traditional tools, that will do network analysis of your servers. Well it's like, "I don't have any servers." And those vendors then say, "Well, we can't help you." And there's static code analysis vendors who say we look at your whole application, and the flows inside it. And we say, well most of my application exists outside of code that I've written. I just write little bits, that glue it together in the way that my business works. And they say, "Oh, well we can't help you." >> Yeah. It reminds me, I think you know for so many years, people were really excited about how they could build their infrastructure. >> Yeah. >> And now they look to environments, well I can get out of that. So it caught my eye. You know, you put out on twitter, said "Maybe we need to have, you know, my next talk will be, "Work dumber not harder." Maybe explain that a little bit. >> Yeah, so I think, >> Yeah. >> I've been thinking about, you know, with some of the talks here about how it's not building it yourself. That in some ways, there's not invented here syndrome. And we kind of want to go a little bit down the road of invented here syndrome, of if you're building something that is not business logic, you're probably ideally thinking, "Maybe I shouldn't be doing this." So turning it into, I don't want to have to be clever in setting up my architecture, because being clever and like writing, it's always interesting to do, right? When you're developing, you're solving a computer science problem. But often that mean you're not delivering business value. And so, in Paul Johnson's talk, he was talking about the kind of people he looks like. What the kind of people he looks for, look like. >> Yeah. >> And he was saying, you know, "It's people "who want to get stuff out the door. "And who think about good enough." And I think that's really the thing of, how do we, when the people you hire are people who just want to ship features, they're going to say, "I can pull together services to do that "without having to actually solve any hard problems." And that means that you're delivering value, and you're operating more in your business space then in a technology space." >> All right, Ben I want to give you the final word. >> Thank you. >> You know, only 460 people here, which is good growth for the show, but a lot of people out there that are still learning about Serverless, what tips do you give them? You know, first steps to get involved, get involved with the community, (mumbles) some early wins they can have? >> I think there's a couple of things. There is training out there, there's blogs. There's twitter. Ask questions. You know, ping me on twitter if you wonder about something. And there's a Serverless slack that's very active, and if you ask basically anybody, the link is floating around. >> All right, well Ben Kehoe, thanks so much. Great to meet you, and thanks for sharing in this community. >> Yeah, thanks for having me. >> And our community, I'm Stu Miniman and thanks for watching The Cube. (upbeat, exciting music bumper)

>> Announcer: Live from Midtown Manhattan its theCUBE. Covering BigData New York City 2017. Brought to you by SiliconANGLE Media and it's ecosystem sponsors. >> His name is Jim Kobielus. >> Jim: That right, John Furrier is actually how I pronounce his name for the record. But he is Basil Faruqui. >> Basil Faruqui who's the solutions marketing manager at BMC, welcome to theCUBE. >> Basil: Thank you, good to be back on theCUBE. >> So, first of all, I heard you guys had a tough time in Houston, so hope everything's getting better and best wishes. >> Basil: Definitely in recovery mode now. >> Hopefully that can get straightened out. What's going on BMC, give us a quick update and in context to BigData NYC what's happening, what is BMC doing in the the big data space now? The AI space now, the IoT space now, the cloud space? >> Like you said you know the data space, the IoT space. the AI space. There are four components of this entire picture that literally haven't changed since the beginning of computing. If you look at those four components of a data pipeline a suggestion, storage. processing and analytics. What keeps changing around it is the infrastructure, the types of data, the volume of data and the applications that surround it. The rate of change has picked up immensely over the last few years with Hadoop coming into the picture, public cloud providers pushing it. It's obviously created a number of challenges, but one of the biggest challenges that we are seeing in the market and we're helping customers address is the challenge of automating this. And obviously the benefit of automation is in scalability as well as reliability. So when you look at this rather simple data pipeline, which is now becoming more and more complex. How do you automate all of this from a single point of control? How do you continue to absorb new technologies and not re-architect your automation strategy every time. Whether it's Hadoop, whether it's bringing in machine learning from a cloud provider. And that is the the issue we've been solving for customers. >> All right, let me jump into it. So first of all you mention some things some things that never change, ingestion storage, and what was the third one? >> Ingestions, storage, processing and eventual analytics. >> So OK, so that's cool, totally buy that. Now if you move and say hey okay so you believe that's standard but now in the modern era that we live in, which is complex, you want breadth of data, and also you want the specialization when you get down the machine learning. That's highly bound, that's where the automation it is right now. We see the trend essentially making that automation more broader as it goes into the customer environments. >> Basil: Correct. >> How do you architect that? If I'm a CXO to I'm a CDO, what's in it for me? How do I architect this because that's really the number one thing is I know what the building blocks are but they've changed in their dynamics to the marketplace. >> So the way I look at it is that what defines success and failure, and particularly in big data projects, is your ability to scale. If you start a pilot and you spend, you know, three months on it and you deliver some results. But if you cannot roll it out worldwide, nationwide, whatever it is essentially the project has failed. The analogy often give is Walmart has been testing the pick up tower, I don't know if you seen, so this is basically a giant ATM for you to go pick up an order that you placed online. They're testing this at about hundred stores today. Now that's a success and Walmart wants to roll this out nationwide. How much time do you think their IT departments can have? Is this is a five year project, ten year project? No, the management's going to want this done six months, ten months. So essentially, this is where automation becomes extremely crucial because it is now allowing you to deliver speed to market and without automation you are not going to be able to get to an operational stage in a repeatable and reliable manner. >> You're describing a very complex automation scenario. How can you automate in a hurry without sacrificing you know, the details of what needs to be, In other words, you seem to call for re purposing or reusing prior automation scripts and rules and so forth. How how can the Walmart's of the world do that fast, but also do it well? >> So we do it we go about it in two ways. One is that out of the box we provide a lot of pre built integrations to some of the most commonly used systems in an enterprise. All the way up from the mainframes, Oracle's, SAP's Hadoop, Tableau's, of the world. They're all available out of the box for you to quickly reuse these objects and build an automated data pipeline. The other challenge we saw, and particularly when we entered the big data space four years ago, was that the automation was something that was considered close to the project becoming operational. And that's where a lot of rework happened because developers have been writing their own scripts, using point solutions. So we said all right, it's time to shift automation left and allow companies to build automation as an artifact very early in the development lifecycle. About a month ago we released what we call Control-M Workbench which is essentially a Community Edition of Control-M targeted towards developers. So that instead of writing their own scripts they can use a Control-M in a completely offline manner without having to connect to an enterprise system. As they build and test and iterate, they're using Control-M to do that. So as the application progresses the development lifecycle, and all of that work can then translate easily into an Enterprise Edition of Control-M. >> So quickly, just explain what shift-left means for the folks that might not know software methodologies, left political or left alt-right, this is software development so please take a minute explain what shift-left means, and the importance of it. >> Correct, so the if you if you think of software development and as a straight line continuum you can start with building some code, you will do some testing, then unit testing, than user acceptance testing. As it moves along this chain, there was a point right before production where all of the automation used to happen. You know, developers would come in and deliver the application to ops, and ops would say, well hang on a second all this CRON tab and all these other point solutions have been using for automation, that's not what we use in production. And we need you to now. >> To test early and often. >> Test early and often. The challenge was the developers, the tools they use, we're not the tools that were being used on the production end of the cycle. And there was good reason for it because developers don't need something really heavy and with all the bells and whistles early in the development lifecycle. Control-M Workbench is a very light version which is targeted at developers and focuses on the needs that they have when they're building and developing as the application progresses through its life cycle. >> How much are you seeing Waterfall and then people shifting-left becoming more prominent now. What percentage of your customers have moved to Agile and shifting-left percentage wise? >> So we survey our customers on a regular basis. In the last survey showed that 80% of the customers have either implemented a more continuous integration delivery type of framework, or are in the process of doing it. And that's the other. >> And getting upfront costs as possible, a tipping point is reached. >> What is driving all of that is the need from the business, you know, the days of the five year implementation timelines are gone. This is something that you need to deliver every week, two weeks, and iteration. And we have also innovated in that space and the approach we call Jobs-as-Code where you can build entire, complex data pipelines in code formats so that you can enable the automation in a continuous integration and delivery framework. >> I have one quick question, Jim, and then I'll let you take the floor and got to learn to get a word in soon. But I have one final question on this BMC methodology thing. You guys have a history obviously BMC goes way back. Remember Max Watson CEO, and then in Palm Beach back in 97 we used to chat with him. Dominated that landscape, but we're kind of going back to a systems mindset, so the question for you is how do you view the issue of the this holy grail, the promised land of AI and machine learning. Where, you know, end-to-end visibility is really the goal, right. At the same time, you want bounded experiences at root level so automation can kick in to enable more activity. So it's a trade off between going for the end-to-end visibility out of the gate, but also having bounded visibility and data to automate. How do you guys look at that market because customers want the end-to-end promise, but they don't want to try to get there too fast as a dis-economies of scale potentially. How do you talk about that? >> And that's exactly the approach we've taken with Control-M Workbench the Community Edition. Because early on you don't need capabilities like SLA management and forecasting and automated promotion between environments. Developers want to be able to quickly build, and test and show value, OK. And they don't need something that, as you know, with all the bells and whistles. We're allowing you to handle that piece in that manner, through Control-M Workbench. As things progress, and the application progresses, the needs change as well. Now I'm closer to delivering this to the business, I need to be able to manage this within an SLA. I need to be able to manage this end-to-end and connect this other systems of record and streaming data and click stream data, all of that. So that we believe that there it doesn't have to be a trade off. That you don't have to compromise speed and quality and visibility and enterprise grade automation. >> You mention trade-offs so the Control-M Workbench the developer can use it offline, so what amount of testing can they possibly do on a complex data pipeline automation, when it's when the tool is off line? I mean it simply seems like the more development they do off line, the greater the risk that it simply won't work when they go into production. Give us a sense for how they mitigate that risk. >> Sure, we spent a lot of time observing how developers work and very early in the development stage, all they're doing is working off of their Mac or their laptop and they're not really connecting to any. And that is where they end up writing a lot of scripts because whatever code, business logic, that they've written the way they're going to make it run is by writing scripts. And that essentially becomes a problem because then you have scripts managing more scripts and as the the application progresses, you have this complex web of scripts and CRON tabs and maybe some open source solutions. trying to make, simply make, all of this run. And by doing this I don't know offline manner that doesn't mean that they're losing all of the other controlling capabilities. Simply, as the application progresses whatever automation that they've built in Control-M can seamlessly now flow into the next stage. So when you are ready take an application into production there is essentially no rework required from an automation perspective. All of that that was built can now be translated into the enterprise grade Control-M and that's where operations can then go in and add the other artifacts such as SLA management forecasting and other things that are important from an operational perspective. >> I'd like to get both your perspectives because you're like an analyst here. So Jim, I want you guys to comment, my question to both of you would be you know, looking at this time in history, obviously on the BMC side, mention some of the history. You guys are transforming on a new journey and extending that capability in this world. Jim, you're covering state of the art AI machine learning. What's your take of the space now? Strata Data which is now Hadoop World, which is, Cloudera went public, Hortonworks is now public. Kind of the big, the Hadoop guys kind of grew up, but the world has changed around them. It's not just about Hadoop anymore. So I want to get your thoughts on this kind of perspective. We're seeing a much broader picture in BigData NYC versus the Strata Hadoop, which seems to be losing steam. But, I mean, in terms of the focus, the bigger focus is much broader horizontally scalable your thoughts on the ecosystem right now. >> Let Basil answer first unless Basil wants me to go first. >> I think the reason the focus is changing is because of where the projects are in their life cycle. You know now what we're seeing is most companies are grappling with how do I take this to the next level. How do I scale, how do I go from just proving out one or two use cases to making the entire organization data driven and really inject data driven decision making in all facets of decision making. So that is, I believe, what's driving the change that we're seeing, that you know now you've gone from Strata Hadoop to being Strata Data, and focus on that element. Like I said earlier, these difference between success and failure is your ability to scale and operationalize. Take machine learning for example. >> And really it's not a hype market. Show me the meat on the bone, show me scale, I got operational concerns of security and whatnot. >> And machine learning you know that's one of the hottest topics. A recent survey I read which polled a number of data scientists, it revealed that they spent about less than 3% of their time in training the data models and about 80% of their time in data manipulation, data transformation and enrichment. That is obviously not the best use of the data scientists time, and that is exactly one of the problems we're solving for our customers around the world. >> And it needs to be automated to the hilt to help them to be more productive delivering fast results. >> Ecosystem perspective, Jim whats you thoughts? >> Yes everything that Basil said, and I'll just point out that many of the core use cases for AI are automation of the data pipeline. You know it's driving machine learning driven predictions, classifications, you know abstractions and so forth, into the data pipeline, into the application pipeline to drive results in a way that is contextually and environmentally aware of what's going on. The path, the history historical data, what's going on in terms of current streaming data to drive optimal outcomes, you know, using predictive models and so forth, in line to applications. So really, fundamentally then, what's going on is that automation is an artifact that needs to be driven into your application architecture as a re-purposeful resource for a variety of jobs. >> How would you even know what to automate? I mean that's the question. >> You're automating human judgment, your automating effort. Like the judgments that a working data engineer makes to prepare data for modeling and whatever. More and more that need can be automated because those are patterned, structured activities that have been mastered by smart people over many years. >> I mean we just had a customer on his with a glass company, GSK, with that scale, and his attitude is we see the results from the users then we double down and pay for it and automate it. So the automation question, it's a rhetorical question but this begs the question, which is you know who's writing the algorithms as machines get smarter and start throwing off their own real time data. What are you looking at, how do you determine you're going to need you machine learning for machine learning? You're going to need AI for AI? Who writes the algorithms for the algorithms? >> Automated machine learning is a hot hot, not only research focus, but we're seeing it more and more solution providers like Microsoft and Google and others, are going deep down doubling down and investments in exactly that area. That's a productivity play for data scientists. >> I think the data markets going to change radically in my opinion, so you're starting to see some things with blockchain some other things that are interesting. Data sovereignty, data governance are huge issues. Basil, just give your final thoughts for this segment as we wrap this up. Final thoughts on data and BMC, what should people know about BMC right now, because people might have a historical view of BMC. What's the latest, what should they know, what's the new Instagram picture of BMC? What should they know about you guys? >> I think what I would say people should know about BMC is that you know all the work that we've done over the last 25 years, in virtually every platform that came before Hadoop, we have now innovated to take this into things like big data and cloud platforms. So when you are choosing Control-M as a platform for automation, you are choosing a very very mature solution. An example of which is Navistar and their CIO is actually speaking at the keynote tomorrow. They've had Control-M for 15, 20 years and have automated virtually every business function through Control-M. And when they started their predictive maintenance project where there ingesting data from about 300 thousand vehicles today, to figure out when this vehicle might break and do predictive maintenance on it. When they started their journey they said that they always knew that they were going to use Control-M for it because that was the enterprise standard. And they knew that they could simply now extend that capability into this area. And when they started about three four years ago there were ingesting data from about a hundred thousand vehicles, that has now scaled over 325 thousand vehicles and they have not had to re-architect their strategy as they grow and scale. So, I would say that is one of the key messages that we are are taking to market, is that we are bringing innovation that has spanned over 25 years and evolving it. >> Modernizing it. >> Modernizing it and bringing it to newer platforms. >> Congratulations, I wouldn't call that a pivot, I'd call it an extensibility issue, kind of modernizing the core things. >> Absolutely. >> Thanks for coming and sharing the BMC perspective inside theCUBE here. On BigData NYC this is theCUBE. I'm John Furrier, Jim Kobielus here in New York City, more live coverage the three days we will be here, today, tomorrow and Thursday at BigData NYC. More coverage after this short break.