(upbeat music) >> Hello everyone, welcome to this special Cube conversation. I'm John Furrier, host of theCube. We're here in Palo Alto. We've got some remote guests. Going to break down the Fortinet vulnerability, which was confirmed last week as a critical vulnerability that exposed a zero-day flaw for some of their key products, obviously, FortiOS and FortiProxy for remote attacks. So we're going to break this down. It's a real time vulnerability that happened is discovered in the industry. Horizon3.ai is one of the companies that was key in identifying this. And they have a product that helps companies detect and remediate and a bunch of other cool things you've heard on the cube here. We've got James Horseman, an exploit developer. Love the title. Got to got to say, I'm not going to lie. I like that one. And Zach Hanley, who's the chief attack engineer at Horizon3.ai. Gentlemen, first, thank you for joining the Cube conversation. >> Thank you. It's good to be here. >> Yeah, thank you so much for having us. >> So before we get into the whole Fortinet, this vulnerability that was exposed and how you guys are playing into this I just got to say I love the titles. Exploit developer, Chief Attack Engineers, you don't see that every day. Explain the titles Zach, let's start with you. Chief Attack Engineer, what do you do? >> Yeah, sure. So the gist of it is, is that there is a lot to do and the cybersecurity world. And we made up a new engineering title called Attack Engineer because there's so many different things an attacker will actually do over the course of attack. So we just named them an engineer. And I lead that team that helps develop the offensive capabilities for our product. >> Got it. James, you're the Exploit Developer, exploiting. What are you exploiting? What's going on there? >> So what I'll do in a day to day is we'll take N-days, which are vulnerabilities that have been disclosed to a vendor, but not yet publicly patched necessarily or a pocket exists for them. And I'll try to reverse engineer and find them, so we can integrate them into our product and our customers can use them to make sure that they're actually secure. And then if there's no interesting N-days to go after, we'll sometimes search for zero-days, which are vulnerabilities in products that the vendor doesn't yet know about. >> Yeah, and those are most critical. Those things can being really exploited and cause a lot of damage. Well James, thanks for coming on. We're here to talk about the vulnerability that happened with Fortinet and their products zero-day vulnerability. But first with the folks, for context, Horizon3.ai is a new startup rapidly growing. They've been on theCube. The CEOs, Snehal and team have described their product as an autonomous pen testing. But as part of that, they also have more of a different approach to testing environment. So they're constantly putting companies under pressure. Let's get into it. Let's get into this hack. So you guys are kind of like, I call it the early warning detection system. You're seeing things early because your product's constantly testing infrastructure. Okay? Over time, all the time always on. How did this come come about? How did you guys see this? What happened? Take us through. >> Yeah, sure. I'll start off. So on Friday, we saw on Twitter, which is actually a really good source of threat intelligence these days, We saw a person released details that 40 minutes sent advanced warning email that a critical vulnerability had been discovered and that an emergency patch was released. And the details that we saw, we saw that was an authentication bypass and we saw that it affected the 40 OS, 40 proxy and the 40 switch manager. And we knew right off the bat those are some of their most heavily used products. And for us to understand how this vulnerability worked and for us to actually help our clients and other people around the world understand it, we needed to get after it. So after that, James and I got on it, and then James can tell you what we did after we first heard. >> Yeah. Take us through play by play. >> Sure. So we saw it was a 9.8 CVSS, which means it's easy to exploit and low complexity and also kind of gives you the keys that take them. So we like to see those because they're easy to find, easy to go after. They're big wins. So as soon as we saw this come out we downloaded some firmware for 40 OS. And the first few hours were really about unpacking the firmware, seeing if we could even to get it run. We got it running a a VMware VMDK file. And then we started to unpack the firmware to see what we could find inside. And that was probably at least half of the time. There seemed to be maybe a little bit of obfuscation in the firmware. We were able to analyze the VDMK files and get them mounted and we saw that they were, their operating system was compressed. And when we went to decompress them we were getting some strange decompression errors, corruption errors. And we were kind of scratching our heads a little bit, like you know, "What's going on here?" "These look like they're legitimately compressed files." And after a while we noticed they had what seemed to be a different decompression tool than what we had on our systems also in that VMDK. And so we were able to get that running and decompress the firmware. And from there we were off to the races to dive deeper into the differences between the vulnerable firmware and the patch firmware. >> So the compressed files were hidden. They basically hid the compressed files. >> Yeah, we're not so sure if they were intentionally obfuscated or maybe it was just a really old version of that compression algorithm. It was the XZ compression tool. >> Got it. So what happens next? So take us through. So you discovered, you guys tested. What do you guys do next? How did this thing... I mean, I saw the news it hit heavily. You know, they updated, everyone updated their catalog for patching. So this kind of hangs out there. There's a time lag out there. What's the state of the security at that time? Say Friday, it breaks over the weekend, potentially a lot of attacks might have happened. >> Yeah, so they chose to release this emergency pre-warning on Friday, which is a terrible day because most people are probably already swamped with work or checking out for the weekend. And by Sunday, James and I had actually figured out the vulnerability. Well, to make the timeline a little shorter. But generally what we do between when we discover or hear news of the CV and when we actually pocket is there's a lot of what we call patch diffing. And that's when we take the patched version and the unpatched version and we run it through a tool that kind of shows us the differences. And those differences are really key insight into, "Hey, what was actually going on?" "How did this vulnerability happen?" So between Friday and Sunday, we were kind of scratching our heads and had some inspiration Sunday night and we actually figured it out. So Sunday night, we released news on Twitter that we had replicated the exploit. And the next day, Monday morning, finally, Fortinet actually released their PSIRT notice, where they actually announced to the world publicly that there was a vulnerability and here are the mitigation steps that you can take to mitigate the vulnerability if you cannot patch. And they also release some indicators of compromise but their indicators of compromise were very limited. And what we saw was a lot of people on social media, hey asking like, "These indicators of compromise aren't sufficient." "We can't tell if we've been compromised." "Can you please give us more information?" So because we already had the exploit, what we did was we exploited our test Fortinet devices in our lab and we collected our own indicators of compromise and we wrote those up and then released them on Tuesday, so that people would have a better indication to judge their environments if they've been already exploited in the wild by this issue. Which they also announced in their PSIRT that it was a zero-day being exploited in the wild It wasn't a security researcher that originally found the issue. >> So unpack the difference for the folks that don't know the difference between a zero-day versus a research note. >> Yeah, so a zero-day is essentially a vulnerability that is exploited and taken advantage of before it's made public. An N-day, where a security researcher may find something and report it, that and then once they announce the CVE, that's considered an N-day. So once it's known, it's an N-day and once if it's exploited before that, it's a zero-day. >> Yeah. And the difference is zero-day people can get in there and get into it. You guys saw it Friday on Twitter you move into action Fortinet goes public on Monday. The lag between those days is critical time. What was going on? Why are you guys doing this? Is this part of the autonomous pen testing product? Is this part of what you guys do? Why Horizon3.ai? Is this part of your business model? Or was this was one of those things where you guys just jumped on it? Take us through Friday to Monday. >> James, you want to take this one? >> Sure. So we want to hop on it because we want to be able to be the first to have a tool that we can use to exploit our customer system in a safe manner to prove that they're vulnerable, so then they can go and fix it. So the earlier that we have these tools to exploit the quicker our customers can patch and verify that they are no longer vulnerable. So that's the drive for us to go after these breaking exploits. So like I said, Friday we were able to get the firmware, get it decompressed. We actually got a test system up and running, familiarized ourself with the system a little bit. And we just started going through the patch. And one of the first things we noticed was in their API server, they had a a dip where they started including some extra HTTP headers when they proxied a connection to one of their backend servers. And there were, I believe, three headers. There was a HTTP forwarded header, a Vdom header, and a Cert header. And so we took those strings and we put them into our de-compiled version of the firmware to kind of start to pinpoint an area for us to look because this firmware is gigantic. There's tons of files to look at. And so having that patch is really critical to being able to quickly reverse engineer what they did to find the original exploit. So after we put those strings into our firmware, we found some interesting parts centered around authorization and authentication for these devices. And what we found was when you set a specific forwarded header, the system, for lack of better term, thought that you were on the inside. So a lot of these systems they'll have kind of, two methods of entry. One is through the front door, where if you come in you have to provide some credentials. They don't really trust you. You have to provide a cookie or some kind of session ID in order to be allowed to make requests. And the other side is kind of through the back door, where it looks like you are part of the system itself. So if you want to ask for a particular resource, if you look like you're part of the system they're not going to scrutinize you too much. They'll just let you do whatever you want to do. So really the nature of this exploit was we were able to manipulate some of those HTP headers to trick the system into thinking that we were coming in through the back door when we really coming in through the front. >> So take me through that that impact. That means remote execution. I can come in remotely and anonymous and act like I'm on the inside system. >> Yeah. >> And that's the case of the kingdom as you said earlier, right? >> Yeah. So the crux of the vulnerability is it allows you to make any kind of request you want to this system as if you were an administrator. So it lets you control the interfaces, set them up or down, lets you create packet captures, lets you add and remove users. And what we tried to do, which surprisingly the exploit didn't let us do was to create a new admin user. So there was some kind of extra code in there to stop somebody that did get that extra access to create an admin user. And so that kind of bummed us out. And so after we discovered the exploit we were kind of poking around to see what we could do with it, couldn't create an admin user. We were like, "Oh no, what are we going to do?" And eventually we came up with the idea to modify the existing administrator user. And that the exploit did allow us to do. So our initial POC, took some SSH keys adding them to an existing administrative user and then we were able to SSH in through the system. >> Awesome. Great, description. All right, so Zach, let's get to you for a second. So how does this happen? What does this... How did we get here? What was the motivation? If you're the chief attacker and you want to make this exploit happen, take me through what the other guy's thinking and what he did or she. >> Sure. So you mean from like the attacker's perspective, why are they doing this? >> Yeah. How'd this exploit happen? >> Yeah. >> And what was it motivated by? Was it a mistake? Was it intentional? >> Yeah, ultimately, like, I don't think any vendor purposefully creates vulnerabilities, but as you create a system and it builds and builds, it gets more complex and naturally logic bugs happen. And this was a logic bug. So there's no blame Fortinet for like, having this vulnerability and like, saying it's like, a back door. It just happens. You saw throughout this last year, F5 had a very similar vulnerability, VMware had a very similar vulnerability, all introducing authentication bypasses. So from the attacker's mindset, why they're actually going after this is a lot of these devices that Fortinet has, are on the edge of corporate networks and ransomware and whatever else. If you're a an APT, you want to get into organizations. You want to get from the outside to the inside. So these edge devices are super important and they're going to get a lot of eyes from attackers trying to figure out different ways to get into the system. And as you saw, this was in the wild exploited and that's how Fortinet became aware of it. So obviously there are some attackers out there doing this right now. >> Well, this highlights your guys' business model. I love what you guys do. I think it's a unique and needed approach. You take on the role of, I guess white hacker as... white hat hacker as a service. I don't know what to call it. You guys are constantly penetrating, testing, creating value for the customers to avoid in this case a product that's popular that just had the situation and needed to be resolved. And the hard part is how do you do it, right? So again, there's all these things are going on. This is the future of security where you need to have these, I won't say simulations, but constant kind of testing at scale. >> Yeah. >> I mean, you got the edge, it takes one little entry point to get into the network. It could be anywhere. >> Yeah, it definitely security, it has to be continuous these days. Because if you're only doing a pen test once a year or twice a year you have a year to six months of risk just building and building. And there's countless vulnerabilities and countless misconfigurations that can be introduced into a your network as the time goes on. >> Well, autonomous pen testing- >> Just because you're- >> ... is great. That's awesome stuff. I think it just frees up the talent in the organization to do other things and again, get on the real important stuff. >> Just because your network was secure yesterday doesn't mean it's going to be secure today. So in addition to your defense in depth and making sure that you have all the right configurations, you want to be continuously testing the security of your network to make sure that no new vulnerabilities have been introduced. >> And with the cloud native modern application environment we have now, hardware's got to keep up. More logic potential vulnerability could emerge. You just never know when that one N-vulnerability is going to be there. And so constantly looking out for is a really big deal. >> Definitely. Yeah, the switch to cloud and moving into hybrid cloud has introduced a lot more complexity in environments. And it's definitely another hole attackers going and after. >> All right. Well I got you guys here. I really appreciate the commentary on this vulnerability and this exploit opportunity that Fortinet had to move fast and you guys helped them and the customers. In general, as you guys see the security business now and the practitioners out there, there's a lot of pain points. What are the most powerful acute pain points that the security ops guys (laughing) are dealing with right now? Is it just the constant barrage of attacks? What's the real pain right now? >> I think it really matters on the organization. I think if you're looking at it from a in the news level, where you're constantly seeing all these security products being offered. The reality is, is that the majority of companies in the US actually don't have a security staff. They maybe have an IT guy, just one and he's not a security guy. So he's having to manage helping his company have the resources he needs, but also then he's overwhelmed with all the security things that are happening in the world. So I think really time and resources are the pain points right now. >> Awesome. James, any comment? >> Yeah, just to add to what Zach said, these IT guys they're put under pressure. These Fortinet devices, they could be used in a company that just recently transitioned to a lot of work from home because of COVID and whatnot. And they put these devices online and now they're under pressure to keep them up to date, keep them configured and keep them patched. But anytime you make a change to a system, there's a risk that it goes down. And if the employees can't VPN or log in from home anymore, then they can't work. The company can't make money. So it's really a balancing act for that IT guy to make sure that his environment is up to date, while also making sure it's not taken down for any reason. So it's a challenging position to be in and prioritizing what you need to fix and when is definitely a difficult problem. >> Well, this is a great example, this news article and this. Fortinet news highlights the Horizon3.ai advantage and what you guys do. I think this is going to be the table stakes for security in the industry as people have to build their own, I call it the militia. You got to have your own testing. (laughing) You got to have your own way to help protect yourself. And one of them is to know what's going on all the time every day, today and tomorrow. So congratulations and thanks for sharing the exploit here on this zero-day flaw that was exposed. Thanks for for coming on. >> Yeah, thanks for having us. >> Thank you. >> Okay. This is theCube here in Palo Alto, California. I'm John Furrier. You're watching security update, security news, breaking down the exploit, the zero-day flaw that was exploited at least one attack that was documented. Fortinet devices now identified and patched. This is theCube. Thanks for watching. (upbeat music)

(jazzy music) >> From our studios in the heart of Silicone Valley Palo Alto, California. This is a CUBE Conversation. >> Hello everyone, welcome to this special CUBE Conversation. I'm John Furrier with my cohost Abby Kearns, the Executive Director of The Cloud Foundry Foundation, my cohost. With Blair Hanley Frank, Principal Analyst at ISG Insights. Blair, great to see you, former journalist at Venturebeat. >> Great to see you again. >> Great to have you on theCUBE finally. Yes, likewise. It's good to be here. >> Thanks for coming on. So, I'd love to start to find out what you're working on. You've been covering the tech sector as a journalist now, as an analyst. You've always done good work, I always admired what you've done. I'm sure you're digging into some really good stuff. What are you researching? What are some of the things you're finding around cloud? What the, what's the data tell us? >> Yeah, awesome. So we have a forthcoming cloud study where we talked to 300 enterprise IT decision makers and we asked them what they're doing today what they're looking to do in the future and how they're doing it. And we're taking all of that information and we're putting that together with the information that we have from ISG's advisor and practitioner community. And building an understanding of where the market is and where it should be. And that's what we have going on today. One of the things that we think is really important, is when we look and the data and we look what's going on in the market, what we find really important is that enterprises today are starting to move to the cloud. They have some workloads in SaaS. They have some workloads in a public cloud, IaaS or PaaS. And then they have a lot of stuff that's still on premises. And that exists in a wide variety of workloads. Whether that's on bare metal, whether that's virtualized whether that's some sort of cloud native or containerized application that's still running on prem all the way up until the cloud and what we see is that those different modes of operation are actually going to continue to exist throughout the enterprise. Even as we see more workloads shift into the public cloud. Enterprises aren't realistically going to be able to retire all of their on premises investments for the foreseeable future. >> Nor should they. >> Right And so what they-- >> Amazon confirmed that with Outposts. You saw Azure Stack, I mean that's total. I mean, first the VMware deal, the RDS on premises, and then you've got the Outpost which still hasn't, we haven't heard anything about that. That's validation, Amazon essentially saying, "I'm going to put cloud on premise." >> Yeah. >> Cloud Operations. So certainly that's validated. The question I want to ask you and Abby, get your thoughts too if you want to chime in over the top. But I've always been critical of the cloud market share game, right? Like, I've always been vocal on theCUBE. Because it's always been infrastructure service, platform service and then SAS is the application. Now Amazon has some SAS but most of their SAS is their customers. Google's got G Suite, they've got their own SAS. Microsoft's got Office 365. So when you start bundling SAS revenues into cloud market share and revenue projections. You start to see, you know, sandbagging of the numbers. I mean you can talk to sales forces today in a work day, they have clouds. So what's a cloud? What is cloud technologies? And, you know, Azure as that develops all the sudden has this massive market share. And it didn't really exist a few years ago. Where'd that come from? Is that just a shift of some sandbagging on the revenue side? Or is that actually real cloud? Or is it, so this is the game that the customer has to squint through. Now we in the industry know that okay, a little bit of Office 365. Okay, is that really cloud? >> Yeah, I mean, when you think about financials with cloud vendors. Everybody is playing a slightly different shell game. And generally speaking, you're not really going to get real numbers from anybody. Except possibly Amazon. And the reason why Amazon is able to do that is because the financial results for AWS look great. But everybody else is going to be masking. >> But they don't have a lot of SaaS though. The think about there, their SaaS number is their customer base. So I mean-- >> Yeah, but I would argue cloud is nothing but infrastructure with a SaaS on top of it. I mean, we talk about cloud as if there's some magic kind of thing happening over here. But it's basically a different kind of data center with a different kind of SaaS on top of it. And I think if I'm, if it's me reporting my numbers out. Well, I'm going to make them look as good as I possibly can. >> CUBE Cloud is coming out with great numbers. (laughing) >> I mean, look. You're going to make it look as great as you can. I mean, infrastructure is infrastructure is infrastructure. But now like, when you talk about SAS on top of that. Well, what's cloud? What's not? And it's super, it's a very fungible definition. >> Alright, I'm not disagreeing on that point. I see how that makes sense. The question for people who are making quote, "decisions" on the buyers side. They tend to think of things like "cloud supplier"? Is that really a word? Like what does that mean? So if you're going to say cloud's part of a workload is that actually even relevant. A "cloud supplier", I mean, I guess they're supplying cloud to you. But, so when you start to get into the vendors versus the buyers and the consuming of the technology. We get in that old school game of trying to put things into like market share, revenue. I mean, I see Amazon just kicking ass ten ways from Sunday. And I think Azure's certainly doing some good things there. Google, we're going to see what's going on with Google. They've got great direction. But, it's like apples, oranges and pears. Right, like are they all the same or different? And then throw Salesforce in there. This is where it muddies the water. >> And Alibaba. >> Alibaba! So, I mean, so it's hard to like figure this out. So I'd love to get your thoughts on how you guys see that in the studies. Are customers confused? Do they have some visibility into what they want to do? What's out there in the data on this point. >> So, what I will say directionally speaking, SaaS is where the market is going. So when we asked our survey respondents for where are there applications today and where did they want to go? 90% of those people we surveyed, 90% of the 300 people we surveyed around the world said in 2019 we are primarily in a hybrid mode. Where our applications are on premises and in a public cloud. 5% of them said, the majority of our applications are in SaaS. Now when you look at 2021, 37% say that they expect to be in a hybrid mode. 61% expect that they are going to be majority SaaS for their workloads, in two years. >> So they're in build up mode, they're in shifting mode. >> They're shifting, and they're not just, they're planning to shift to SaaS. They're planning to, they want to get out of the business of running applications. And put some of that burden onto providers to say, "Okay, it's your job to run the application. We'll provide the data. We'll build our business processes but we don't want our job to be running those apps." And what we see is that when you look at total cost of ownership, our respondents found SaaS to be far more predictable in terms of TCO than IaaS and PaaS. And again, for those people who are are really paying attention. If you think about it, that doesn't. Like, that's not a surprise. But on the other hand, that's like, I think that's part of where the driver comes from. Is that when you're consuming a SaaS product, it's very understandable. It's very consumable. When you think about running application in an Iaas, PaaS environment. Maybe not so much. It's going to be, you're more in charge of that application. So-- >> And SaaS has got immediate gratification. >> Exactly. >> I mean, you see the benefits. >> Easy to consume. >> Is there revenue there, is it doing its objective? Why is the IAZ fuzzy? Just because it's a classic back office kind of mindset? Or is it more of maturity? It seems mature to me, I mean, I don't I think IAZ has been more mature than ever before right now. Now we kind of-- >> I think its been around awhile, I mean I'd love to hear your answer. I think it's, there's just, I feel it's a relic of the past. Whereas, it's not something we spend much time thinking about. Like, there's that old joke. You know, "Great job keeping the servers up" said no CEO ever. Right? (laughing) >> That's a good point. But now apart from the servers you've got SageMaker, you've seen what Amazon's moving with the Stack with SageMaker. Machine learning, all of this kind of SASification kind of platform creeping up to the top of the stack. It seems to be what everyone talks about. I'm sure Google next will hear all about AI and how Iot Edge or some focus around that piece. So, again I agree. It's the commoditization is just another distraction layer on top of it. >> Yeah. >> Sure. >> We've seen that movie before. >> We're moving up the stack, we're just moving up the stack at a faster pace than we have in the last two decades. >> So bottom line, Blair. What's the survey, what's the net net telling us? What's coming out of it? >> So the net net here is really that enterprises need to have a strategy and an operating model in place for the long haul. When they think about their cloud strategy overall, this is something where they're not going to be able to snap their fingers and get to cloud-native nirvana overnight. Because that requires technical change, it requires culture change, it requires process change. There's a lot of very heavy lifting that takes place and not all of the applications that exist in an enterprise today really need that heavy lift. And so when you think about what the future holds for enterprises. They really need to build a model for how they are going to make that transition as smooth as possible. Take advantage of the new capabilities that are entering the market as quickly as possible to help advance their business. While at the same time having the opportunity to work across all of those different modes of operation and do so with high reliability, high customer satisfaction, high performance. All of the things that you need to succeed as a business in 2019. >> So I totally agree. This is a heavy lift to go kill the old and bring in the new. And one of the things that I've seen as a trend, and I'd love to get your guys' thoughts on this, as a reaction. Because I've seen the Kubernetes trend really let a lot of air out of that tension. Because it allows people to get in with containers to get in around some workloads and bring kind of baby steps into transitioning stuff. And I've seen people saying, "You know what. I like the idea of going cloud but I got this app that I really don't want to shut it down and have to rebuild it. But I could put some containers around things, run it on some Vms, use Kubernetes to orchestrate it." So I think this has been, I'm not sure if it's actually been deployed in massive production. But I've heard people say that. Is that hype or is that reality? Is it becoming a crutch, is it a short term transitional? >> I got to drag out my soap box for this 'cause I have a soap box for this. >> Okay, let's go. >> I'm not a big believer in lift and shift. I think there are times where it may be opportunistic. When you're like end of life-ing hardware or something like that. But I'm not a big believer that a cloud is a goal. Because cloud should not be your goal. If I'm a business, my goal should not be cloud. My goal should be, how do I write more applications more quickly? And maybe, how do I use infrastructure in better and more efficient ways? But cloud is not my goal. If that's my goal, then I'm going to be really sad at the end of the day. Because that hasn't made my business better. So I think, I feel like we've all over rotated-- >> You're saying it's not the outcome. The outcome is the app that benefits from doing that. >> The outcome, if you're a bank and you tell me your goal is to be on the cloud. Well, then I'm like, you've got the wrong goal. Your goal should be, how am I writing more applications and getting them out into the hands of my customer and changing my business faster? If the cloud gets me to that, great! But that may not be the answer for all of your workloads and you need to really think about that before you say "my goal is cloud". My goal is to write more applications faster. Period. And if that's on the cloud or if that's on prim or if that's on bare metal, what have you. But I need to really think about what my outcome is. And I feel like we've really focused on the cloud as the solution and that's not the solution. And if you're check boxing, you know, I'm done for the year because I moved a bunch of stuff to the cloud. Well you're, the works not done. The work is the culture part and the team part and really figuring out the applications I need to create And how do I iterate on those applications? The cloud is just, it's a bi product of that. >> It should be enabling the outcome they want. >> Right. >> That's a great soap box. Your thoughts on the overall lift and shift soap box rant by my cohost Abby here? >> Yeah, I think that the, the big opportunity is to do what's right for the business. That's ultimately what should be driving any sort of transformation. I had a conversation with a start up once. They were very focused on taking their monolithic application and going to microservices. And they were like, "we're going to go to microservices. That's what we want to do because that's the future. That's what a modern application looks like." And they started decomposing their application what I would call radically decomposing their application. Getting down to the atomic, you know, moment of how small can we make every single piece of this application. What they figured out was that it was a massive headache. And so they actually then, took it and sort of re-composed the application into not microservices but what they called mega-services. Where they-- >> And then they ended up writing a book and being famous and doing a speaking tour. But they didn't achieve the objective. >> And so, and that's exactly it. That they all of the sudden created this host of technical problems by pursuing an ideal that wasn't-- >> And this is the danger, the dogma. Danger of having the dogma of a certain trend. I remember during the big data days when we were covering the Duke movement around 2010, 2011, 2012. I would hear this all the time in side cloud era. "Man, I just set up an 18 note cluster. I'm so pumped!" Well, what are you doing with it? "Well, I just collect data." I'm like well, I get it, I get. And then what happened was, that was their end game. We see a lot of that with clouds, your point where, it's not about, it's what you're using it for. And then they had to make up the term data lake after that. So again, they just kept adding on more but they actually missed the entire boat because it was about making data addressable for apps. >> It used to make things useful. >> So this is the danger of the tech world. >> And making it useful. Yeah, I feel like we follow the shiny penny. As opposed to saying, "Actually is that actually even relevant for me?" You know, when Docker came out in 2014 and every conversation started with, that was the answer for everything. Whatever you wanted. Do you want toast for lunch? Docker? And I feel like that was the answer for everything. And I feel like, why? Like, one, why do you care about a container? And two, like why? >> Containers were pretty cool though. >> Sure, they're cool. But containers have been around since 1969. >> Summer of love. The containers, ya know? >> It was, but I feel like, ya know everyone's like "that's my answer" and you're like "Well, what's the question you're asking?" And I feel like we continue, we went from Docker to the next thing and the next thing and the next thing. And I feel like we're not pausing to say "actually what are we hoping to gain?" You're point. >> So Kubernetes, what do you think is Kubernetes a shiny penny or shiny new toy? Or does that have any relevance in your mind in your soap box? Where does Kubernetes fit into your, your view. >> I mean I think Kubernetes is an amazing technology that has done a lot for the way think about scheduling and container orchestration. But it is also become victim of the shiny penny and that everyone is like "Kubernetes!" And you know, two years ago everyone is like "Kubernetes!" It's like how many people were using it two years ago? Not that many. And so I think about it in this like, and I often ask, "Why do you care so much about a container orchestrator?" >> FTO sold almost 650 million or whatever the number. >> 515, I know the Vmware. >> Is it 515 was the number? >> 515. >> That's half a billion dollars. That's Kubernetes' ca ching. >> I lived my two years, my last two years wrong. That's what I did. (laughing) But that's a different story about all of my mistakes. >> You could have been the Kubernetes foundation. >> But I think-- >> CNCF is doing pretty well, I mean, that community is rallying. It feels like an Amazon alternative. They feel cloud, it's very cloud native. So I think Kubernetes has been a good rallying cry, for sure. >> It is but I think you're also, you know, what you see even in CNCF which has so many amazing technologies. I do not want to take away from that but you also see the shiny penny effect happening within that community. You know, when I went to CUBECON in December you know, what was the hot topic? It wasn't Kubernetes it was Istio. You heard Istio everywhere. And I've never seen this many people so excited about service mesh in my life. I'm like "Great! This is awesome!" >> We love it on theCUBE, it's great content. Service mesh is great. Who wouldn't want policy staple applications? Come on! >> Well, ultimately the like-- >> Hold on. (inhaling) >> Exactly >> Have some of that staple, I'm saying. Fantasyland. >> I'm excited about it. >> No, stakes hard. >> Well, and this is what I end up telling clients is you want to adopt the parts of the stack that are necessary for you to solve the problems that you have. Right? If you are in the position where you need a service mesh, you know because you are having problems that only a service mesh can solve. And if you aren't in that position then you get to be like the 60% of respondents in our survey who said that they are currently experimenting with a service mesh. Or, the 33% who say that they plan to use it in the future. >> 60% are experimenting with it? >> Yeah, well, probably-- >> That numbers way high. >> Well, it's probably somebody has it running on some VM somewhere. >> It seems really high. >> Well if you look at the success at CUBECON one of the things that, Envoy is a great example, and you talk about some of the challenges-- >> Envoys great. >> The challenges that enterprises have. If you look at the success of all the open source projects, the ones that have been super successful. It's the folks that had to build it for themselves. Envoy had a lift. And I think this is a challenge that I see. I haven't really figured it out in the enterprise yet, how that's going to play out. It generally seems to be that the enterprises don't necessarily want to be like them. But they want the same kind of control. "I want to roll out my own cloud." But they don't want to have an open stack problem. Meaning, they don't want to have something that's not supported. So you have this kind of new changeover vibe going. I really haven't put my finger on it but it's, it has that same vibe. >> Well, enterprises are more in control. And what we've seen in our research is that enterprises actually feel comfortable now. They no longer feel like they're in the fog of war like "I don't know what's goin on!" They're more like "Oh, we actually understand and we're on it." And they're being more thoughtful about the technologies that they use. And they are experimenting more. And they're feeling really confident. But you know, my caution is always, use the technology when it makes sense, as it makes sense. But at the end of the day as a business owner, your fundamental question is, does this serve my outcomes? Does this serve my business outcomes? And if the answer is, I don't know. Then really think about what you're investing in in terms of technology. I mean, I love all of these technologies. But I'm never going to recommend all of them if that's not actually going to be in your best interest. >> That's great stuff. Well, thanks for coming on Blair. Appreciate it. You going to be at Google next? Cloud Foundry in Philly? In April, first week of April? >> Unfortunately, I won't make it to the Cloud Foundry Summit. >> Google Next, next month? >> Sure will. >> Alright, We'll see you there. >> Abby, thanks for co hosting this segment with me. >> Any time, John. >> Sharing the data here with my cohost Abby and John here. Co hosting the first ever CUBE, What we'd call it? Cloud? >> Cloud CUBE. >> Cloud CUBE. >> Rebrand. >> TheCUBE, thanks for watching. (jazzy music)

>> Hi, my name is Elaine Hanley, I lead the IBM DataOps Center of Excellence. We work with clients to help them to understand their data, understand how they can trust that data to get best value out of it, and use that data within the confines of the regulations that they need to adhere to. Over the last six months, we've been working with clients using our DataOps methodology. We want to come to you and show you and share with you some of the lessons that we've learnt with that. Join us on May 27th, where there'll executives from these companies and from IBM. I hope to see you then and share that with you. Thank you.

hi my name is Layne Hanley I lead the IBM bid ups center of excellence we work with clients to help them to understand their data understand how they can trust that they did get best value out of it and use that data within the confines and regulations that they need to adhere to over the last six months we've been working with clients using our bid ups methodology and we we want to come to you and show you and and share with you some of the lessons that we've learned with us so we'd love to join if you'd join us on May 27 where there'll be executives from these companies and from IBM and we'll talk about exactly what they adopts me means to them I hope to see you then and share that with you thank you