>>The Cube presents UI Path Forward five. Brought to you by UI Path. >>Hi everybody. We're back at UI path forward to five. This is Dave Ante with Dave Nicholson. Derek Mu is here. He's automation product line lead for Merck. Thank you, by the way, for, you know, all you guys do, and thank you Dave for having in the, in the, in the vaccine area, saving our butts. And Bill Engel is back on the cube. He's the director at cgi. Guys, good to see you again. >>Good to see you. Thank >>You. So Merrick, Wow, it's been quite a few years for you guys. Take us through Derek, what's happening in sort of your world that's informing your automation strategy? >>Well, Dave, I mean as you know, we just came out of the pandemic. We actually have quite a few products like Gabriel Antiviral Pill. Obviously we worked, you know, continue to drive our products through a difficult time. But, you know, is during these can last few years that, you know, we've accelerated our journey in automation. We're about four years plus in our journey, you know, so just like the theme of this conference we're we're trying to move towards, you know, bigger automations, transformational change, continue to drive digital transformation in our company. >>Now Bill, you've been on before, but CGI tell people about the firm. It's not computer graphics imaging. >>Sure. No, it's, it's definitely not. So cgi, we're a global consultancy about 90,000 folks across the world. We're a, we're both a product company and a services company. So we have a lot of different, you know, software products that we deliver to our clients, such as CGI Advantage, which is a state local government EER P platform. And so outside of that, we, my team does automation and so we wrap automation around R IP and deliver that to our clients. >>So you guys are automation pros, implementation partners, right? So, so let's go back. Yep. Derek said four years I think. Yep. Right, You're in. So take us through what was the catalyst, how did you get started? Obviously it was pre pandemic, so it's interesting, a lot of companies pre pandemic gave lip service to digital transformation. Sounds like you guys already started your journey, but I'll come back to that. But take us back to the Catalyst four years ago. Why automation? We'll get into why UI path, >>Right. So I, I would say it started pretty niche in our company. Started first in our finance area. Of course, you know, we were looking in technology evaluating different companies, Blue Prism, ui P. Ultimately we chose UI p did it on-prem to start to use automation in sort of our invoice processing, sort of our financial processes, right? And then from there, after it was really when the pandemic hit, that's when sort of we all went to remote work. That's when the team, the COE continued to scale up, especially during pandemic. We were trying to automate more and more processes given the fact that more and more of our workers are remote, they reprocesses. How, how do you do events? You know, part of our livelihood is, is meeting with engaging with customers. Customers in this case is, are doctors and physicians, right? How do you engage with them digitally? How do you, you know, you know, a lot of the face to face contact now have to kind of shift to more digital, digital way. And so automation was a way to kind of help accelerate that, help facilitate that. >>You, you, I think you mentioned COE as in center of excellence. Yep. So, so describe your approach to implementing automation. It's, that sounds like when you say center, it sounds like something is centralized as, as opposed to a bunch of what we've been hearing a lot about citizen developers. What does that interaction >>Look like? We do have both. I would say in the beginning was more decentralized, but over time we, over the few years as, as we built more and more bots, we're now at maybe somewhere between four to 500 bots. We now have sort of internal to the company functional verticals, right? So there's an animal health, we have an animal health function. So there's, there's a team building engaging with the animal health business to build animal health box. There's human health, which is what I work on as well as hr, finance, manufacturing, research. And so internally there's engagement leads, one of the engagement leads that interact with the business. Then when there's an engineering squads that help build and design, develop and support and maintain those as well as sort of a DevOps team that supports the platform and maintains all the bot infrastructure. >>So you started in finance common story, right? I'm sure you hear this a lot Belt, How did you decide what to target? Was it, was it process driven decision? Was it, was it data oriented? Like some kind of combination? How did you decide, Do you remember? Or do you, could you take >>Us back to Oh yeah. So for, for cgi how we started to engage with MER is, you know, we, we do a lot of other business with Merck. We work on all their different business lines and we, we understand the business process. So we, we knew where there was potential for automation. So we brought those ideas to Merck and, and really kind of landed there and helped them realize the value from automation from that standpoint. And then from there the journey just continued to expand, you know, looking for those use cases that, that, you know, fit the mold for, for, for RPA to start. And now the evolution is to go to broader hyper automation. >>And, and was it CFO led into the finance department and then, or was it sort of more bottoms >>Up? Yeah, so, so I think it started in, in finance and, and, but we actually really started out in the business line. So out in regulatory clinical, that's, that's where we, we have the life science expertise that are embedded. And so I partnered with them to come up with, hey, here's a real solution we could do to help streamline, say submission archiving. So when, when submissions come back from the fda, they need to be archived into, you know, the, their system of record. So that's, those are the types of use cases that, that we helped automate. >>Okay. Cause you're saying a human had to sort physically archive that and you were able to sort of replicate that. Okay. And you started with software robots, obviously rpa and now you're expanding into, we we're hearing from UI this the platform message. How does that coincide Derek, with what you guys are doing? Are you sort of adding platform? What aspects of the platform are, are you adding? >>Yeah, no, I mean we are, we are on-premise, right? So we have the platform, but some of the cool things we just had, another colleague of mine presented earlier today. Some of the cool things we're, we're doing ephemeral infrastructure. So infrastructure as code, which essentially means instead of having all these dedicated bot machines, that that, you know, cuz these bots only in some cases run 10 minutes and they're done. So we're, we're soon of doing all on demand, you know, start up a server, run the bot when it's finished, you know, kill the server. So we only pay for the servers that we use, which allows us to save a whole >>Lot of money. Serverless bots. So you, but you're doing that OnPrem, so you >>No, >>No, but >>That's >>Cloud. We, >>We, we we're doing it OnPrem, but our, our bot machines that actually run the, let's say SAP process, right? We spin that machine up, it's on the cloud, it runs it finish, Let's say it's processed in one hour and then when it's done, we kill that machine. So we only play for that one hour usage of that bot machine. >>Okay. So you mentioned SAP earlier you mentioned Blue Prism when you probably looked at other competitors too. You pull the Gartner Magic quadrant, blah, blah, you know, with the way people, you know, evaluate technology, but SAP's got a product. Why UI path mean? Is it that a company like SAP two narrow for their only sap you wanted to apply it other ways? Maybe they weren't even in the business that back then four years ago they probably weren't. Right? But I'm curious as to how the decision was made for UiPath. >>Well, I think you hit it right on the nail. You know, SAP sort of came on a little later and they're specific to sort of their function, right? So UiPath for us is the most flexible tool can interact by UI to our sales and marketing systems, to, to workday, to service Now. It's, it cuts across every function that we have in the company as well as you're the most mature. I mean, you're the market leader, right? So Right. Definitely you, you continue to build upon those capabilities and we are exploring the new capabilities, especially being announced today. >>And what do you see Bill in the marketplace? Are you, are you kind of automation tool agnostic? Are you more sort of all in on? I >>Would say we are, we are agnostic as a company, but obviously as part of a, as an automation practice lead, you know, I want to deliver solutions to my clients that are gonna benefit them as a whole. So looking at UI path, you know, that this platform is, it covers the end to end spectrum of, of automation. So I can go really into any use case and be able to provide a solution that, that delivers value. And so that's, that's where I see the value in UI path and that's why CGI is, is a customer as well. We automate our internal processes. We actually have, we just launched probably SALT in the, in the market last week, expanded partnership with UiPath. We launched CGI, Excel 360. That's our fully managed service around automation. We host our clients whole UI path infrastructure and bots. It's completely hands off to them and they just get the value outta >>Automation. Nice, nice. Love >>It. Derek, you mentioned, you mentioned this ephemeral infrastructure. Yeah. Sounds like it's also ethereal possibility possibly you're saying, you, you're saying you have processes that are running on premises, right? But then you reach out to have an automation process run that's happening off pre and you're, and you're sort of, >>It's on the cloud, so, so yeah, so we have a in-house orchestrator, so we don't, we're not using your sort of on the cloud orchestrator. So, so we brought it in-house for security reasons. Okay. But we use, you know, so inside the vpn, you know, we have these cloud machines that run these automations. So, so that's, that's the ephemeral side of the, of the >>Infrastructure. But is there a financial angle to that in terms of when you're spinning these things up, are you, is it a, is it a pay by the drink or by the, by the CPU >>Hours, if you can imagine like we, you know, like I mentioned where somewhere between four to 500 bots and every bot has a time slot to run and takes a certain amount of time. And so that's hundreds and hundreds of bot machines that we in the old days have to have to buy and procure and, you know, staff and support and maintain. So in this new model, and we're just beginning to kind of move from pilot into implementation, we're moving all, all of bots this in ephemeral infrastructure, right? So these, okay, these machines, these bot machines are, you know, spun up. They run the, they, they run their automation and then they spin >>Down. But just to be clear, they're being spun up on physical infrastructure that is in your >>Purview and they spun up on aws. Yeah. Okay. And then they spin down. Okay, got >>It. Got it. Interesting. Four >>To 500 bots. You know, Daniel one point play out this vision of a bot chicken in every pot, I called it a bot for every employee. Is that where you're headed or is that kind of in this new ephemeral world, not necessary, it's like maybe every employee has access to an ephemeral bot. How, how are you thinking about that? >>That's a good question. So obviously the, the four to 500 is a mix of unattended bonds versus attended bonds, right? That, that we also have a citizen developer, sort of a group team. We support that as well from a coe. So, you know, we see the future as a mix. There's, there's a spectrum of, we are the professional development team. There's also, we support and nurture the personal automation and we provide the resources to help them build smaller scale automations that help, you know, reduce the, you know, the mundaneness and the hours of their own tasks. But you know, for us, we want to focus more and more on building bigger and bigger transfer transformational automations that really drive process efficiencies and, and savings. >>And what's the, what's the business impact been? You mentioned savings and maybe there's other sort of productivity. How do you measure the benefit, the ROI and, and >>Quantify that we, you know, I, I don't, I don't profess I don't think we have all the right answers, but yeah, simple metrics like number of hours saved or other sort of excitement sort of in like an nps, internal NPS between the different groups that we engage. But we definitely see automation demand coming from our, our functional teams going up, driving up. So it's, it's continued to be a hot area and hopefully we, we can, you know, like, like what the key message and theme of this, of this conference. Essentially we want to take and build upon the, the good work that we've done in terms of rpa and we want to drive it more towards digital transformation. >>So Bill, what are you seeing across the, your customer base in terms of, of, of roi? I'm not looking for percentages there. I'm sure they're off the charts, but in terms of, you know, you can optimize for fast payback, you know, maybe lower the denominator, you know, or you can optimize for, you know, net benefit over time, right? You know, what are you seeing? What are customers after they want fast payback and little quick hits? Or are they looking for sort of a bigger enterprise wide impact? >>Yeah, I think it's, it's the latter. It's that larger impact, right? Obviously they, you know, they want an roi and just depending upon the use case, that's gonna vary in terms of the, the benefits delivered. And a lot of our clients, depending on the industry, so in in life sciences it may be around, you know, compliance like GXP compliance is huge. And so that may may not be much of a time saver, but it ensures that they're, they're running their processes and they're being compliant with, you know, federal standards. So that's, that's one aspect to it. But you know, to, you know, a bank, they're looking to reduce their overall costs and and so on. But yeah, I think, I think the other, the other part of it is, you know, impacting broader business processes. So taking that top down approach versus kind of bottom up, you know, doing ta you know, the ones you choose the tasks is not as impactful as looking at broader across the entire business process and seeing how we can impact >>It. Now, Derek, when you guys support a citizen developer, how does that work? So, hey, I got this task I want to automate, I'm gonna go write a, you know, software robot. I'm gonna go do an automation. Do I just do it and then throw her to the defense? You guys, you guys send me a video on how to do it. Hold my hand. How's that work? >>Yeah, I mean, good question. So, so we obviously direct them to the UI path Academy, get some training. We also have some internal training materials to how to build a bot sort of internal inside Merck. We, we go through, we have writeups and SOPs on using the right framework for automations, using the right documentation, PDD kind of materials, and then ultimately how do we deploy bot inside the MER ecosystem. But I, I, maybe I'll just add, I think you asked the point about ROI before. Yeah. I'll also say because we're, we're a pharmaceutical company. I think one of the other key metrics is actually time saved, right? So if, if, if we have a bot that helps us get through the clinical process or even the getting a, a label approved faster, even if it's eight days saved, that's eight days of a product that can get out to the market faster to, to our patients and, and healthcare professionals. And that's, that, that's immeasurable benefit. >>Yeah, I bet if you compress that ELAP time of, of getting approval and so forth. All right guys, we've gotta go. Thanks so much. Congratulations on all the success and appreciate you sharing your story. Thank >>You so much. Appreciate it. You're welcome. >>Appreciate it. All right. Thank you for watching this Dave Ante for Dave Nicholson, The cubes coverage, two day coverage. We're here in day one, UI path forward, five. We'll be right back right after the short break. Awesome. >>Great.

>>From the Bellagio hotel in Las Vegas, it's the cube covering UI path forward for brought to you by UI path. >>Welcome back to Las Vegas. Lisa Martin, with Dave Vellante at UI path forward for, we have had it all today. Lots of great guests. We've had weather, we've had rain. We are outside and lots of great conversations going on. Next up, we're going to be talking about automation at healthcare giant. Merck. Joining us from merch is Dan Boyd automation leader, and from CGI partner of UI paths, bill angles, senior automation architect, guys, welcome to the program. >>Thanks for having us. >>So Dan, we'll go ahead and start with you. Let's talk about Merck and the implement and the adoption of automation, such a history company. >>Yeah. Thank you. Um, our journey started about two years ago and started with the small team and has evolved ever since we started just the handful of folks we've evolved, uh, from the size of our team, matured, operationally and expanded our capabilities along that journey to where we are today. And it continues to evolve as the technology changes. And it's been exciting to see the adoption at Merck over, you know, across the enterprise. Um, it's been an educational process, but it's been exciting just to see that understanding of the power that automation can deliver to them. And they see the value in making it real to them has been key. Um, then once it's real and they get excited and the word spreads and they appreciate the value right before their eyes and bill, are you, >>Uh, industry specialized or more automation specialist? >>Yeah. Yeah. So I'm more, uh, automation specialized, but uh, you know, CGI, we partner with our industry experts to identify use cases for automation and I help kind of, you know, solution the best approach to automation. Uh, and you know, so I actually started, you know, with, with Merck a little bit earlier before it was really formalized and, uh, just CGI is a large partner of merch and embedded within various areas of business. And, you know, I, I ended up educating, uh, CGI on automation and here's what to look for, you know, in a, in a, in a great use case for automation and, you know, really, we started to drum up some internal excitement and then came up with some actual real use cases within Merck, proved it out early. And then we began to partner with, uh, Dan and his team. >>Can you share a little bit about some of those use cases? Yes. >>So, you know, the ones that, uh, we've worked on are really specific within, uh, various areas, uh, within the division. So Dan, you want to talk about some of the >>You're working on yeah, I'll share one use case within a specific market of merch, and it's a commercial area where they were embarking on a revision in their customer engaged engagement approach in this market and where the, they had a problem. They, they needed to get the invoices out of SAP for customers. So that was on the one side of the process on the other was a customer portal where the customers needed access near real time to those invoices. So when they came to us, they had the invoices kind of set up to be emailed out of SAP. So they had that process set up. The problem is how do they get them over here into this customer portal? Say the backup plan was to have a temporary workers come on and do that manually handle the open emails with the invoices attachments and get them loaded. >>So we came in, uh, they called us in, in the 11th hour and we were able to, fortunately that the process was straightforward, uh, whereas invoices were coming through, uh, an email attachment and that was set up. So basically we automated the reading of the emails, the processing of the PDF attachments and saved them into a shared drive where there was another process to load them into SAP. So the volume was really large on a daily basis. Initially it was estimated at approximately 2,500 emails per day with these invoices. Um, so that would estimate it would take about 125 hours of people time to do that manually. Um, so that's what we automated. And in the end it was the averages it's over 3000 a day. So, um, the solution really came in and, and we were able to deliver that. And it's been a really, they were, they were static with what they could do, and then they saw the art of the possible with, with this automation. So it's a good success story. And, um, it's exciting to see, and they were thrilled >>And it's not an uncommon story, right. Where you're automating mundane tasks that was pushing a lot of paper, a lot of copy and pasting. Um, do you see how far away, and maybe we're there already? You think about mark it's it's uh, in a, in a unique industry, we've got, got highly skilled scientists too in serious R and D high risk trials. You got partners, you do some organic, some inorganic, you've got the manufacturing components. So a lot of different parts to the business. And when you think about saving time, as you think about some of the, the scientists that are working on various pipeline products, highly paid, if you can save more of their time, wow. That even drops more to the bottom line. Are we at that point yet? We heard the stats this morning. It was 2% or some single digit percentage of our processes are automated. How far away are we from attacking those types of automations? Are we there today? >>Uh, we do automations for all the, all the functions across Merck. Um, in some places adoption is farther along than others in their journey, but yeah, um, from the shop floor and the manufacturing sites, we found opportunities to, to introduce automation there. And even in the, in the labs in various capacities, see the use cases continue to grow and the adoption continue. We see that growing as well. >>Do you find that the, the highly skilled, uh, automations targeted at highly skilled folks are, are harder to sort of get your hands around, but they give you bigger ROI? Or is it not the case? Is it all sort of earn and burn? >>Yeah, from my perspective, I think it's, you know, use case by use case. Like if it's a, a complex use case, it requires, you know, more advanced capabilities, uh, you know, machine learning models, you know, leveraging, uh, you know, AI center within UI path, uh, you know, those they can, you know, provide, you know, fairly sizeable ROI, but I think is for those highly skilled workers, I'll give one example is, you know, out in, out in the labs, we, we helped, you know, automate some things that, you know, just made their life easier, right. Uh, you know, tests running overnight, if something failed, uh, with, with a test that was happening, then, you know, they, they wouldn't know about it and they lose critical data for, for these early tests that they're doing in, in the, in the preclinical cycle. So we actually put in a UI path robots to, to monitor and send alerts and provide recovery to make their lives a lot easier. Uh, so they don't have to worry about things, you know, failing in the middle of the night, you have a UI path robot, you know, supporting them in that map, that aspect, >>What's an automation, architecture look like we, where do we start architecting automation? >>Well, I think the journey, uh, so where do you start with an automation? Right. It's really understanding the use case. It comes down to what is the, the end to end process, and then where, where can we automate, uh, within that process and what is the right set of automation capabilities? So, you know, RPA is great for, you know, um, where we get, where we need to interact with user interfaces. But if we can, uh, you know, interact with API APIs, we would do that. You know, preferably over a UI is, is to keep, keep it more of a seamless integration. But I think it's about understanding the process, laying out the right solution, uh, if there's an opportunity to improve the process prior to automating it, you know, if there's, if there is that ability, then we'll look to do that. And we've done that. We may change that process, uh, up a little bit, just to make automation more efficient, more effective. Uh, and so, and then it just, we built it and we deploy it and they start to realize the value >>Hard. Is it dental prove the, on the versus just automating what's, what's known. In other words, you've got dependencies and there are complexities there w what's your experience in terms of how you approached it >>From my experience and what we found to be best practice and bill touched on it. But every use case is of course different than the, the corresponding process. Very, very varied, but really what's key, I think, is to right upfront, understand the end to end process. And a lot of cases, my team it's new to us, right. But the process owners, they live it every day. So understanding, partnering with them to really understand the end to end solution in the form of like a process map. So you can kind of echo back your understanding of their process and get that nod of the head from them and say, yes, you understand that this is an accurate representation. Then we can with the spirit of trying to get it right the first time. And, but it really, I think is incumbent upon us to really get that in-depth understanding upfront. And a lot of cases, if there's time sensitivity in the end, it's just more efficient and saves a lot of rework. So, >>So working backwards, sorry, at least working backwards from the known existing process and then implementing an automation is probably the best starting point, as opposed to trying to work backwards from some kind of the outcome that you envision. But, but I would think there's attractiveness in the, in the ladder. Right. So that you're not just repeating a process that may be outdated. >>Yeah. So your, uh, it comes down to a couple of things. So when you're initially looking at a process, you know, should we automate this or not? And how complex is it? You need to understand what is the potential benefit. So, you know, how much, uh, you know, how much time am I able to, uh, you know, have those workers reinvest into other areas of work, right. Or what other, what are some other benefits? Uh, you know, there, there may be some, uh, you know, compliance fines that were experienced through automation, we're able to, you know, to make sure we're meeting SLS and so on. Uh, so you is a lot to, you know, defining the benefits, the automation, putting a value to that. And then the process of going through the actual process, understand the complexity, right? And then you can come up with, you know, here's, here's what it's gonna take to build this thing. Here's the potential value. And then we have ways where we track, you know, what's, how has that ROI trending once it's in production? Uh, so we'll be, that gives us more insight. >>Dan, I've got a question for you. One of the conversations that Dave and I had earlier on the program was about automation as a boardroom topic. I'd love to get your perspectives. Merck is a history organization, been around for a long time. Cultural change is incredibly challenging, but I'd love to get your perspective on where is automation at Merck's board. Is that something that is really key to transformation? >>I'd say automation falls under our strategic initiative, just around digital digital transformation, right? So it's a sub pillar of that. So that is a strategic imperative and very important. And just being a more efficient and, and leveraging technology effectively, um, just to make merch more efficient and, and, and optimized and RPA and automation plays a part in that. I mean, >>That's what I suspected Lisa this morning when we have in that conversation, it seems to me that you wouldn't necessarily create an automation stove pipe at the board meeting. You might want to report on how these automations have affected, whether it's the income statement or the health of the company, et cetera. But it seems to me to be a fundamental part of the digital transformation, um, which involves a lot of different things, data and cloud and strategy and it et cetera. So is that pretty >>Common bill? Yeah, I, yes, it is. I mean, when, when an organization is looking to automate there's, you know, various angles are coming out, they're coming from the top-down approach where, you know, management saying, Hey, we need to, we need to automate what's, let's look across all the divisions and, and figure out where, where we should go. But then it's also, you know, bottom up where, you know, folks out in, out within the various lines of business know, they, they know the problems. They know, they know the business processes. So there's a couple of different angles where, you know, you you're able to discover new opportunities to automate. Uh, but those also those smaller ones opened the door to understanding, you know, much larger processes where we can look, you know, automate more of the upstream or downstream in that process. Are there variations of the process? So >>Was, was merch more bottom-up or top-down or middle out? I wouldn't say it's >>Started bottoms up. That's really out there. It came from the top-down. So as bill touched on, I think it's really key that we do have, uh, from, from this coming from the top, from our leadership is endorsing it and advocating it, but also we're on the, on the ground floor and educating. So the people with the hands-on doing the process, they understand it and the word is spreading. They see we've, we've made it real for them. Now it's real for them, and they can appreciate the value. And they're happy to be able to do more, to be freed up from the tedious tasks and do more interesting work. >>So we did start in the department, there was a champion with a budget who said, Hey, I'm going to try this and then look what I got. Yeah, >>Yeah. You definitely need the champion. So part of that is creating champions out in the different business lines to truly own the pipeline and understand the opportunities are out there and say, yeah, this is a good opportunity. This, this one let's look at it later. So you definitely have to have those folks out there that, that understand the technology, but also understand the business. >>How has that changed in the last 18 months with healthcare care undergoing such? I mean, my goodness, the things that have happened in a healthcare organization, how has that accelerated the need for things like automation, Christian, for both of you and for mark as well? Yeah. >>Yeah. So mark initiated, uh, like most companies that digital transformation, three, three plus years ago, and this just became an extension of that. And, and it's, it's a, it's a must, right? Just to stay up with the, the digital transformation and everything that's happening in this world. And, and obviously, uh, COVID accelerated, helped accelerate it in certain areas and made it real for a lot of people and appreciate the value and the need for it. >>Yeah. W within CGI, just across all of our clients, it's automation is really towards the top of the list of strategic priorities. So it's, so we've seen this massive just acceleration of, of needing to automate more and more and more, you know, which is, which is great. >>What's it like inside a merch these days, you guys must be really excited with all that. I mean, I know it's early days and nothing has been fully blessed yet, but I mean, you know, some of the big has got a lot of headlines and obviously, you know, we've been taking jabs, et cetera, but, but now here's Merck in the headlines. It's, it's gotta be an exciting time for you guys. >>Yeah. It's, it's great to be part of a company whose mission is to save and improve lives and right. It's um, with today, it's, it's really becoming real and more relevant, uh, of that mission and vision. So it's exciting. >>There were any gotchas when you go into this, I'm sure there are into this automation journey. What kinds of things would you advise people, Hey, make sure that you deal with these, whether it's an audit scope, consideration or things that you definitely don't want to do, or do you want to do? >>Yeah. It just comes down to the, you know, choosing the right use case to start with. Right. Making sure that you, if you're just starting out in your automation journey, you know, start with those use cases that you can quickly prove value for and then tackle the more complex ones. That's good >>For folks to know where to start, especially when there's still such a tumultuous environment that we're living in. Dan and bill. Thank you for joining Dave and Manet, talking about automation, the innovation that you're doing at Merck partnering with CGI really appreciate >>Your time. Thanks for having us >>For Dave Volante. I'm Lisa Martin, coming to you from windy, chilly Las Vegas. We are at UI path forward for stick around Dave and I will be right back with our next guest.

>>Hello, everyone. Welcome to this cube conversation. I'm here in Palo Alto, California. I'm John furrier, host of the cube, and we have a great guest here. Barack Shuster. Who's in Tel-Aviv senior director of chief architect at bridge crew, a part of Palo Alto networks. He was formerly the co-founder of the company, then sold to Palo Alto networks Brock. Thanks for coming on this cube conversation. >>Thanks John. Great to be here. >>So one of the things I love about open source, and you're seeing a lot more of the trend now that talking about, you know, people doing incubators all over the world, having open source and having a builder, people who are starting companies, it's coming more and more, you you're one of them. And you've been part of this security open source cloud infrastructure infrastructure as code going back a while, and you guys had a lot of success. Now, open source infrastructure as code has moved up to the stack, certainly lot going down at the network layer, but developers just want to build security from day one, right? They don't want to have to get into the, the, the waiting game of slowing down their pipelining of code in the CIC D they want to move faster. And this has been one of the core conversations this year is how to make developers more productive and not just a cliche, but actually more productive and not have to wait to implement cloud native. Right. So you're in the middle of it. And you've got you're in, tell us, tell us what you guys are dealing with that, >>Right? Yeah. So I hear these needles working fast, having a large velocity of releases from many of my friends, the SRAs, the DevOps, and the security practitioners in different companies. And the thing that we asked ourselves three years ago was how can we simplify the process and make the security teams an enabler instead of a gatekeeper that blocks the releases? And the thing that we've done, then we understood that we should do is not only doing runtime scanning of the cloud infrastructure and the cloud native clusters, but also shift left the findings and fixings the remediation of security issues to the level of the code. So we started doing infrastructure is good. We Terraform Kubernetes manifests cloud formation, server less, and the list goes on and we created an open source product around it, named checkup, which has an amazing community of hundreds of contributors. Not all of them are Palo Alto employees. Most of them are community users from various companies. And we tried to and succeeded to the democratic side is the creation of policy as code the ability to inspect your infrastructure as code and tell you, Hey, this is the best practice that you should use consider using it before applying a misconfigured S3 bucket into production, or before applying a misconfigured Kubernetes cluster into your production or dev environment. And the goal, >>The goal, >>The goal is to do that from the ID from the moment that you write code and also to inspect your configuration in CGI and CD and in runtime. And also understand that if there is any drift out there and the ability to fix that in the source code, in the blueprint itself. >>So what I hear you saying is really two problems you're solving. One is the organizational policies around how things were done in a environment before all the old way. You know, the security teams do a review, you send a ticket, things are waiting, stop, wait, hurry up and wait kind of thing. And then there's the technical piece of it, right? Is that there's two pieces to that. >>Yeah, I think that one thing is the change of the methodologies. We understood that we should just work differently than what we used to do. Tickets are slow. They have priorities. You have a bottleneck, which is a small team of security practitioners. And honestly, a lot of the work is repetitive and can be democratized into the engineering teams. They should be able to understand, Hey, I wrote the code piece that provision this instance, I am the most suitable person as a developer to fix that piece of code and reapply it to the runtime environment. >>And then it also sets the table for our automation. It sets the table for policies, things that make things more efficient scaling. Cause you mentioned SRS are a big part of this to dev ops and SRE. Those, those folks are, are trying to move as fast as possible at scale, huge scale challenge. How does that impact the scale piece become into here? >>So both themes Esri's and security teams are about a link to deploying application, but new application releases into the production environment. And the thing that you can do is you can inspect all kinds of best practices, not only security, best practices, but also make sure that you have provision concurrencies on your serverless functions or the amount of auto-scaling groups is what you expect it to be. And you can scan all of those things in the level of your code before applying it to production. >>That's awesome. So good, good benefits scales a security team. It sounds like too as well. You could get that policy out there. So great stuff. I want to really quickly ask you about the event. You're hosting code two cloud summit. What are we going to see there? I'm going to host a panel. Of course, I'm looking forward to that as well. You get a lot of experts coming in there. Why are you having this event and what topics will be covered? >>So we wanted to talk on all of the shifts, left movement and all of the changes that have happened in the cloud security market since inception till today. And we brought in great people and great practitioners from both the dev ops side, the chaos engineering and the security practitioners, and everybody are having their opinion on what's the current status state, how things should be implemented in a mature environment and what the future might hold for the code and cloud security markets. The thing that we're going to focus on is all of the supply chain from securing the CCD itself, making sure your actions are not vulnerable to a shut injection or making sure your version control system are configured correctly with single sign-on MFA and having branch protection rules, but also open source security like SCA software composition analysis infrastructure as code security. Obviously Ron thinks security drifts and Kubernetes security. So we're going to talk on all of those different aspects and how each and every team is mitigating. The different risks that come with. >>You know, one of the things that you bring up when you hear you talking is that's the range of, of infrastructure as code. How has infrastructure as code changed? Cause you're, you know, there's dev ops and SRS now application developers, you still have to have programmable infrastructure. I mean, if infrastructure code is real realize up and down the stack, all aspects need to be programmable, which means you got to have the data, you got to have the ability to automate. How would you summarize kind of the state of infrastructure as code? >>So a few years ago, we started with physical servers where you carried the infrastructure on our back. I, I mounted them on the rack myself a few years ago and connected all of the different cables then came the revolution of BMS. We didn't do that anymore. We had one beefy appliance and we had 60 virtual servers running on one appliance. So we didn't have to carry new servers every time into the data center then came the cloud and made everything API first. And they bill and enabled us to write the best scripts to provision those resources. But it was not enough because he wanted to have a reproducible environment. The is written either in declarative language like Terraform or CloudFormation or imperative like CDK or polluted, but having a consistent way to deploy your application to multiple environments. And the stage after that is having some kind of a service catalog that will allow application developer to get the new releases up and running. >>And the way that it has evolved mass adoption of infrastructure as code is already happening. But that introduces the ability for velocity in deployment, but also new kinds of risks that we haven't thought about before as security practitioners, for example, you should vet all of the open source Terraform modules that you're using because you might have a leakage. Our form has a lot of access to secrets in your environment. And the state really contains sensitive objects like passwords. The other thing that has changed is we today we rely a lot on cloud infrastructure and on the past year we've seen the law for shell attack, for example, and also cloud providers have disclosed that they were vulnerable to log for shell attack. So we understand today that when we talk about cloud security, it's not only about the infrastructure itself, but it's also about is the infrastructure that we're using is using an open source package that is vulnerable. Are we using an open source package that is vulnerable, is our development pipeline is configured and the list goes on. So it's really a new approach of analyzing the entire software bill of material also called Asbell and understanding the different risks there. >>You know, I think this is a really great point and great insight because new opera, new solutions for new problems are new opportunities, right? So open source growth has been phenomenal. And you mentioned some of those Terraform and one of the projects and you started one checkoff, they're all good, but there's some holes in there and it's open source, it's free, everyone's building on it. So, you know, you have, and that's what it's for. And I think now is open source goes to the next level again, another generational inflection point it's it's, there's more contributors there's companies are involved. People are using it more. It becomes a really strong integration opportunity. So, so it's all free and it's how you use it. So this is a new kind of extension of how open source is used. And if you can factor in some of the things like, like threat vectors, you have to know the code. >>So there's no way to know it all. So you guys are scanning it doing things, but it's also huge system. It's not just one piece of code. You talking about cloud is becoming an operating system. It's a distributed computing environment, so whole new area of problem space to solve. So I love that. Love that piece. Where are you guys at on this now? How do you feel in terms of where you are in the progress bar of the solution? Because the supply chain is usually a hardware concept. People can relate to, but when you bring in software, how you source software is like sourcing a chip or, or a piece of hardware, you got to watch where it came from and you gotta track track that. So, or scan it and validate it, right? So these are new, new things. Where are we with? >>So you're, you're you're right. We have a lot of moving parts. And really the supply chain terms of came from the automobile industry. You have a car, you have an engine engine might be created by a different vendor. You have the wheels, they might be created by a different vendor. So when you buy your next Chevy or Ford, you might have a wheels from continental or other than the first. And actually software is very similar. When we build software, we host it on a cloud provider like AWS, GCP, Azure, not on our own infrastructure anymore. And when we're building software, we're using open-source packages that are maintained in the other half of the war. And we don't always know in person, the people who've created that piece. And we do not have a vetting process, even a human vetting process on these, everything that we've created was really made by us or by a trusted source. >>And this is where we come in. We help you empower you, the engineer, we tools to analyze all of the dependency tree of your software, bill of materials. We will scan your infrastructure code, your application packages that you're using from package managers like NPM or PI. And we scan those open source dependencies. We would verify that your CIC is secure. Your version control system is secure. And the thing that we will always focus on is making a fixed accessible to you. So let's say that you're using a misconfigured backup. We have a bot that will fix the code for you. And let's say that you have a, a vulnerable open-source package and it was fixed in a later version. We will bump the version for you to make your code secure. And we will also have the same process on your run time environment. So we will understand that your environment is secure from code to cloud, or if there are any three out there that your engineering team should look at, >>That's a great service. And I think this is cutting edge from a technology perspective. What's what are some of the new cloud native technologies that you see in emerging fast, that's getting traction and ultimately having a product market fit in, in this area because I've seen Cooper. And you mentioned Kubernetes, that's one of the areas that have a lot more work to do or being worked on now that customers are paying attention to. >>Yeah, so definitely Kubernetes is, has started in growth companies and now it's existing every fortune 100 companies. So you can find anything, every large growler scale organization and also serverless functions are, are getting into a higher adoption rate. I think that the thing that we seeing the most massive adoption off is actually infrastructure as code during COVID. A lot of organization went through a digital transformation and in that process, they have started to work remotely and have agreed on migrating to a new infrastructure, not the data center, but the cloud provider. So at other teams that were not experienced with those clouds are now getting familiar with it and getting exposed to new capabilities. And with that also new risks. >>Well, great stuff. Great to chat with you. I want to ask you while you're here, you mentioned depth infrastructure as code for the folks that get it right. There's some significant benefits. We don't get it. Right. We know what that looks like. What are some of the benefits that can you share personally, or for the folks watching out there, if you get it for sure. Cause code, right? What does the future look like? What does success look like? What's that path look like when you get it right versus not doing it or getting it wrong? >>I think that every engineer dream is wanting to be impactful, to work fast and learn new things and not to get a PagerDuty on a Friday night. So if you get infrastructure ride, you have a process where everything is declarative and is peer reviewed both by you and automated frameworks like bridge and checkoff. And also you have the ability to understand that, Hey, once I re I read it once, and from that point forward, it's reproducible and it also have a status. So only changes will be applied and it will enable myself and my team to work faster and collaborate in a better way on the cloud infrastructure. Let's say that you'd done doing infrastructure as code. You have one resource change by one team member and another resource change by another team member. And the different dependencies between those resources are getting fragmented and broken. You cannot change your database without your application being aware of that. You cannot change your load Bonser without the obligation being aware of that. So infrastructure skullduggery enables you to do those changes in a, in a mature fashion that will foes Le less outages. >>Yeah. A lot of people getting PagerDuty's on Friday, Saturday, and Sunday, and on the old way, new way, new, you don't want to break up your Friday night after a nice dinner, either rock, do you know? Well, thanks for coming in all the way from Tel-Aviv really appreciate it. I wish you guys, everything the best over there in Delhi, we will see you at the event that's coming up. We're looking forward to the code to cloud summit and all the great insight you guys will have. Thanks for coming on and sharing the story. Looking forward to talking more with you Brock thanks for all the insight on security infrastructures code and all the cool things you're doing at bridge crew. >>Thank you, John. >>Okay. This is the cube conversation here at Palo Alto, California. I'm John furrier hosted the cube. Thanks for watching.

>>Oh, welcome back to the cubes coverage of coop con cloud native con 2021. I'm John is the Cuba, David Nicholson, our cloud host analyst, and it's exciting to be back in person in event. So we're back. It's been two years with the cube con and Linux foundation. So scrape, it was a hybrid event and we have a great guest here, Cuban London, Nick Dirk, and CT field CTO of harness and harness.io. The URL love the.io. Good to see you. >>Thank you guys for having me on. I genuinely appreciate >>It. Thanks for coming on. You were a part of our AWS startup showcase, which you guys were featured as a fast growing mature company, uh, as cloud scales, you guys have been doing extremely well. So congratulations. But now we're in reality now, right? So, okay. Cloud native has kind of like, okay, we don't have to sell it anymore. People buying into it. Um, and now operationalizing it with cloud operations, which means you're running stuff, applications and infrastructure is code and it costs money. Yeah. Martine Casada at Andreessen Horowitz. Oh, repatriated from the cloud. So there's a lot of, there's some cost conversations starting to happen. This is what you guys are in the middle of. >>Yeah, absolutely. What's interesting is when you think about it today, we want to shift left. When you want to empower all the engineers, we want to empower people. We're not giving them the data they need, right. They get a call from the CFO 30 days later, as opposed to actually being able to look at what change I did and how it actually affected. And this is what we're bringing in. Allowing people to have is now really empowering. So throughout the whole software delivery life cycle from CGI continuous integration, continuous delivery feature flagging, and even bringing cost modeling and in cloud cost management. And even then being able to shut down, shut down the services that you're not using, how much of that is waste. We talk about it. Every single cloud conference it's how much is waste. And so being able to actually turn those on, use those accordingly and then take advantage of even the cheapest instances when you should. That's really what >>It's so funny. People almost trip over dollars to pick up pennies in the cloud business because they're so focused on innovation that they think, okay, we've got to just innovate at all costs, but at some point you can make it productive for the developers in process in the pipeline to actually manage that. >>That's exactly it. I mean, if you think about it to me in order to breach state continuous delivery, we have to automate everything. Right. But that doesn't mean stop at just delivering, you know, to production. That means to customer, which means we've got to make them happy, but then ultimately all of those resources in dev and QA and staging and UAT, we've sticker those as well. And if we're not being mindful of it, the costs are astronomical, right. And we've seen it time and time again with every company you see, you've seen every article about how they've blown through all their budgets. So bring it to the people that can affect change. That's really the difference, making it visible, looking at it. In-depth not just at the cloud level and all the spend there, but also even at the, uh, thinking about it, the Kubernetes level down to the containers, the pods and understanding where are the resources even inside of the clusters and bringing that as an aggregate, not just for visibility and, and giving recommendations, but now more importantly, because part of a pipeline start taking action. That's where it's interesting. It's not just about being able to see it and understand it and hope, right? Hope is not a strategy acting upon it is what makes it valuable. And that's part of the automate everything. >>Yeah. We'll let that at the Dawn of the age of DevOps, uh, there was a huge incentive for a developer just to get their job done, to seize control of infrastructure, the idea of infrastructure as code, you know, and it's, it's, you know, w when it was being born, it's a fantastic, I've always wondered though, you know, be careful what you wish for. Do you really want all of that responsibility? So we've got responsibility from a compliance and security perspective and of course cost. So, so where do we, where do we go from here, I guess is the question. Yeah. So >>When we look at building this all together, I think when we think about software delivery, everybody wants to go fast. We start with velocity, right? Everybody says, that's where I want to go. And to your point with governance compliance, the next roadblock to hit is weight. In order to go fast, I have to do it appropriately. I've got governing bodies that tell me how this has to work. And that becomes a challenge. >>It slows it down too. It doesn't, I mean, basically people are getting pissed off, right? This is, this general sentiment is, is that developers are moving fast with their code. And then they have to stop. Compliance has to give the green light sometimes days, correct? Uh, it used to be weeks now. It's days, it's still unacceptable. So there's like this always been that tension to the security groups or say it, or finance was like slow down and they actually want to go faster. So that has to be policy-based something. Yep. This is the future. What is your take on that? >>Take on, this is pretty simple. When everybody talks about people, process and technology, it's kind of bogus, right? It's all about confidence. If you're confident that your developers can deploy appropriately and they're not going to do something wrong, you'll let them to play all the time. Well, that requires process. But if you have tooling that literally guarantees your governance, make sure that at no point in time, can any of your developers actually do something wrong. Now you have, >>That's the key. That's the key. That's the key because you're giving them a policy-based guardrails to execute in their programs >>And that's it. So now you can free up all those pieces. So all those bottlenecks, all those waiting all those time, and this is how all of our customers, they move from, you know, change advisory boards that approve deployments. >>Can you give us some, give us some, give us some, uh, customer anecdotal examples of this inaction and kind of the love letters you get, or, or the customer you take us through a use case of how it all. >>So this is one of my favorites. So NCR national cash register. If you slide a credit card at like a Chick-fil-A or a Safeway, right? Um, traditional technology. But what was interesting is they went from doing PCI audit, which would take seven days to go to a PCI audit right now with harness, because, >>And by the way, when you and the seventh, six day, the things that you did on day one change. >>Exactly, exactly. And so now, because of using harness and everything's audited, and all the changes are, are controlled to make sure that developers again, can only do what they're allowed. They only get to broadcast two per production. If they've met all their security requirements, all their compliance, permits, all their quality checks. Now, because of that, they literally gave a re read only view of harness to their auditor. And in three hours it was over. And it's because now we're that evidence file from code commit through to production. Yeah. It's there for point of sale compliant. >>So what is the benefits to them? What's the result saves them time, saves the money. What's the good, the free up more times. I'll see the chops it down. That's the key. >>Yeah. It's actually something we didn't build in like our ROI calculators, which was, we talked to their engineers and we gave them their nights and their weekends back, which I thought was amazing. But Thursday night, when we're doing that deploy, they don't have to be up. Harness is actually managing and understanding, using machine learning to understand what normal looks like. So they don't have to, they don't have to sit and look at the knock or sit in the war room and eat the free pizza. Yeah. Right. And then when those things break, same concept rates aren't as good. So >>I got to ask you, I got you here. You know, as the software development delivery lifecycle is radically being overhauled right now, which people generally agree that that's the case, the old models are, are different. How do you see your vision around AI and automation playing into this? Because you could say, okay, we're going to have different kinds of coding styles. This batch has got an AI block here. It's very Lego block. Like yep. Okay. Services and higher level services in the cloud. What's your reaction to how this impacts automation and >>Sure. So throughout our entire platform, we've designed our AI to take care of the worst parts of anyone's job as Guinea dev ops person. If they love babysitting deployments, they don't harness handles that for them, ask your engineers that they love sitting there waiting for their tests to run. Every time they build, they go get coffee, right. Because we're waiting for all of our tests to run. Y yeah. Right. The reality >>Is sometimes they have to wait days and >>That's it. But like, if I change the gas cap on, uh, on your car, would you expect me to check every light switch and every electronic piece? No. Well, why do we do that with code? And so our AI, our ML is designed to remove all the things that people hate. It's not to remove people's jobs. It's actually to make their jobs much better. >>How do you guys feed the data? What's the training algorithm for that? How does that work? Yeah, >>Actually, it's interesting. A lot of people think it's going to take a ton of time to figure this out. The good news is we start seeing this on the second deployment. On the second bill, we have to have a baseline of what good looks like, and that's where it starts. And it goes from there. And by the way, this isn't a lot of people say AI, and this AML, I teach a class on this because ML is not standard deviation. It's not some checks. So we use a massive amount of machine learning, but we have neural networks to think about things like engineers do. Like if we looked at a log and I saw the same log with two different user IDs, you and I would know, well, it's the same thing. It's just different users, but machine learning models. Don't so we've got to build neural networks to actually think like humans. So that, >>So that's the whole expectation maximization kind of concept of people talk about, >>Well, and that's it because at the end of the day, we're like I said, I'm not trying to take people's jobs. I want to meet. >>Yeah. You want to do the crap work out of the way. And I had to do other redundant, heavy lifting that they have to do every single time we use the cloud way. We've >>Built mechanical muscle in, in the early 19 hundreds. Right. And it made everyone's jobs easier, allowed them to do more with their time. That's exactly what we're doing here. >>I mean, we've seen the big old guys in the industry trying to evolve. You got the hot startups coming out. So you got, you know, adapt or die as classic thing. We've been saying for many years, David on the cube, you know that. So it's like, this is a moment of truth. We're going to see who comes out the other side. How do you, Nick, what would you be your, your kind of guess of when that other side is, when are we gonna know the winners and the losers truly in the sense of where we are now? >>So I think what I've found is that in this space specifically, there's a constant shift and this is something with software. And the problem is, is that we see them come in ebbs and flows, right. And very few times are there businesses that actually carry the model? And what you find is that when they focus on one specific problem, it solves it. Now, if I was working on VMs a few years ago, great, but now we're, we're here at coop con, right? And that's because it's eaten, uh, that side of the world. And so I think it's the companies that can actually grow the test of time and continue to expand to where the problems are. Right. And that's one of the things that I traditionally think about harness and we've done it. We cover our customers where they were, I think the old mainframes, if you had to, where they were, where they are at their traditional, their VM. >>I mean, if you think about it, Nick, it's one of those things where it's like, that's such a common sense way to look at it evolves with a problem. So I ride the right with tech ways. But if you think about the high order bit, here is just applications. We ended the day. Companies have applications that they want to write modern. The applications of their business is going to be codified so that you just work backwards from there. Then you say, okay, what is the infrastructure as code working for me? That's an ethos of dev ops. And that's where we're at. So that's why I think that the cloud need is kind of one already, but we still have the edge devices, more complexity. This is a huge next level conversation at one point is that we just put a hard and top on the complexity. When is that coming? Because the developers are clear. They want to go fast. They want to go shift left and have all that data, get the right analytics, the telemetry and the AI. But it's too complicated still. That is a big problem. >>It's too complicated. You ask for a full-stack developer to also know infrastructure, to also know edge computing. Like it's impossible, right? And this is where tooling helps, right? Because if you can actually parameterize that and make it to the engineers and have to care, they can do what they're best at. Hey, I'm great at turning code in artifact, let them do that and have tooling take care of the rest. This is where our goal is. Again, allow people >>We'll do what they love. And this is kind of the new roles that are changing. What SRE has done. Everyone talks about the SRE and some states just as he had dev ops guy, but it's not just that there's also, uh, different roles emerging. It's, it's an architectural game. At this point, we would say, >>I'd say a hundred percent. And this is where the decisions that you make on are architecturally. If you don't know how to then roll them out, this is what we've seen. Time and time again, you go to these large companies, I've got these great architectures on planning four years later, we haven't reached it because to that point process, >>The process killed them four >>Different new tools throughout the process. Well, yeah. >>So when do we hit peak Kubernetes peak >>Kubernetes? I think we have a bit to go in and I'm excited about the networking space and really what we're doing there and, and bringing that holistic portion of the network, like when Istio was originally released, I thought that was one of the most amazing things, uh, to truly come to it. And I think there's a vast space in networking. Um, and, and so I think in the next few years, we're going to see this, you know, turn into that a hundred percent utilized across the board. This will be that where everyone's workloads continue to exist. Um, somewhat like VMs we're in >>And, and, and no, no fear of developers as code in the very near future. You're talking about automating the mundane. Correct. Uh, there have been stories recently about the three-day workweek, you know, as a, as a fan of, um, utopian science fiction, myself, as opposed to dystopian. Absolutely. I think that, you know, technology does have the opportunity to lift all boats and, uh, and it's, it's not nothing to be afraid of. You know, the fact that I put my dishes in the dishwasher and they run by themselves for three hours. It's a good thing. It's a great thing. >>I don't need to deal with that. Yeah, I agree. No, I think that's, and that's what I said in the beginning. Right. That's really where we can start empowering people. So allow them to do what they're good at and do what they're best at. And if you look at why do people quit? We don't have to go so hard to find. Yeah. Why? Because they're secondary to babysit and implement and they're told everywhere they go, they're not going to have to >>That's the line. And that's all right. We got a break, but it's great insight to have you on the Q one final question for you. Um, I got to ask about the whole data as code something that I've been riffing on for a bunch of years now. And as infrastructures could we get that, but data is now the resource everyone needs, and everyone's trying to, okay, I have the control plane for this and that, but ultimately data cannot be siloed. This is a critical architectural element. How does that get resolved in the land of the competitive advantage and lock in and whatnot? What's your take on that? >>So data's an interesting one because it has, it has gravity and this is the problem. And as we move, as I think you guys know, as you move to the edge as remove, move it places there's insights to be taken at the edge there's insights to be taken as it moves through. And I think what you'll see honestly, going forward is you'll see compute done differently to your point. It needs to be aggregated. It needs to be able to be used together, but I think you'll see people computing it on its way through it. So now even in transport, you'll start seeing insights gained in real time before you can have the larger insights. And I see that happening more and more. Um, and I think ultimately we just want to empower that >>Nick, great to have you on CTO of field CTO of harness and harness.io is a URL. Check it out. Thanks for the insight. Thank you so much. Great comments. Appreciate it. Natural cube analysts right here, Nick, of course, we've got our, our analysts right here, David Nicholson. You're good on your own. I'm John for a, you know, we have the host. Thanks for watching. Stay with two more days of coverage. We'll be back after this short break.

>>Hey, welcome to the live panel. My name is Brett. I am your host, and indeed we are live. In fact, if you're curious about that, if you don't believe us, um, let's just show a little bit of the browser real quick to see. Yup. There you go. We're live. So, all right. So how this is going to work is I'm going to bring in some guests and, uh, in one second, and we're going to basically take your questions on the topic designer of the day, that continuous integration testing. Uh, thank you so much to my guests welcoming into the panel. I've got Carlos, Nico and Mandy. Hello everyone. >>Hello? All right, >>Let's go. Let's go around the room and all pretend we don't know each other and that the internet didn't read below the video who we are. Uh, hi, my name is Brett. I am a Docker captain, which means I'm supposed to know something about Docker. I'm coming from Virginia Beach. I'm streaming here from Virginia Beach, Virginia, and, uh, I make videos on the internet and courses on you to me, Carlos. Hey, >>Hey, what's up? I'm Carlos Nunez. I am a solutions architect, VMware. I do solution things with computers. It's fun. I live in Dallas when I'm moving to Houston in a month, which is where I'm currently streaming. I've been all over the Northeast this whole week. So, um, it's been fun and I'm excited to meet with all of you and talk about CIA and Docker. Sure. >>Yeah. Hey everyone. Uh, Nico, Khobar here. I'm a solution engineer at HashiCorp. Uh, I am streaming to you from, uh, the beautiful Austin, Texas. Uh, ignore, ignore the golden gate bridge here. This is from my old apartment in San Francisco. Uh, just, uh, you know, keeping that, to remember all the good days, um, that that lived at. But, uh, anyway, I work at Patrick Corp and I work on all things, automation, um, and cloud and dev ops. Um, and I'm excited to be here and Mandy, >>Hi. Yeah, Mandy Hubbard. I am streaming from Austin, Texas. I am, uh, currently a DX engineer at ship engine. Um, I've worked in QA and that's kind of where I got my, uh, my Docker experience and, um, uh, moving into DX to try and help developers better understand and use our products and be an advocate for them. >>Nice. Well, thank you all for joining me. Uh, I really appreciate you taking the time out of your busy schedule to be here. And so for those of you in chat, the reason we're doing this live, because it's always harder to do things live. The reason we're here is to answer a question. So we didn't come with a bunch of slides and demos or anything like that. We're here to talk amongst ourselves about ideas and really here for you. So we've, we obviously, this is about easy CII, so we're, we're going to try to keep the conversation around testing and continuous integration and all the things that that entails with containers. But we may, we may go down rabbit holes. We may go veer off and start talking about other things, and that's totally fine if it's in the realm of dev ops and containers and developer and ops workflows, like, Hey, it's, it's kinda game. >>And, uh, these people have a wide variety of expertise. They haven't done just testing, right? We, we live in a world where you all kind of have to wear many hats. So feel free to, um, ask what you think is on the top of your mind. And we'll do our best to answer. It may, might not be the best answer or the correct answer, but we're going to do our best. Um, well, let's get it start off. Uh, let's, let's get a couple of topics to start off with. Uh, th the, the easy CGI was my, one of my three ideas. Cause he's the, one of the things that I'm most excited about is the innovation we're seeing around easier testing, faster testing, automated testing, uh, because as much as we've all been doing this stuff for, you know, 15 years, since 20 years since the sort of Jenkins early days, um, it it's, it seems like it's still really hard and it's still a lot of work. >>So, um, let's go around the room real quick, and everybody can just kind of talk for a minute about like your experience with testing and maybe some of your pain points, like what you don't like about our testing world. Um, and we can talk about some pains, cause I think that will lead us to kind of talk about what, what are the things we're seeing now that might be better, uh, ideas about how to do this. I know for me, uh, testing, obviously there's the code part, but just getting it automated, but mostly getting it in the hands of developers so that they can control their own testing. And don't have to go talk to a person to run that test again, or the mysterious Jenkins platform somewhere. I keep mentioning Jenkins cause it's, it is still the dominant player out there. Um, so for me, I'm, I'm, I, I don't like it when I'm walking into a room and there's, there's only one or two people that know how the testing works or know how to make the new tests go into the testing platform and stuff like that. So I'm always trying to free those things so that any of the developers are enabled and empowered to do that stuff. So someone else, Carlos, anybody, um, >>Oh, I have a lot of opinions on that. Having been a QA engineer for most of my career. Um, the shift that we're saying is everyone is dev ops and everyone is QA. Th the issue I see is no one asked developers if they wanted to be QA. Um, and so being the former QA on the team, when there's a problem, even though I'm a developer and we're all running QA, they always tend to come to the one of the former QA engineers. And they're not really owning that responsibility and, um, and digging in. So that's kind of what I'm saying is that we're all expected to test now. And some people, well, some people don't know how it's, uh, for me it was kind of an intuitive skill. It just kind of fit with my personality, but not knowing what to look for, not knowing what to automate, not even understanding how your API end points are used by your front end to know what to test when a change is made. It's really overwhelming for developers. And, um, we're going to need to streamline that and, and hold their hands a little bit until they get their feet wet with also being QA. >>Right. Right. So, um, uh, Carlos, >>Yeah, uh, testing is like, Tesla is one of my favorite subjects to talk about when I'm baring with developers. And a lot of it is because of what Mandy said, right? Like a lot of developers now who used to write a test and say, Hey, QA, go. Um, I wrote my unit tests. Now write the rest of the test. Essentially. Now developers are expected to be able to understand how testing, uh, testing methodologies work, um, in their local environments, right? Like they're supposed to understand how to write an integration tasks federate into and tasks, a component test. And of course, how to write unit tests that aren't just, you know, assert true is true, right? Like more comprehensive, more comprehensive, um, more high touch unit tests, which include things like mocking and stubbing and spine and all that stuff. And, you know, it's not so much getting those tests. Well, I've had a lot of challenges with developers getting those tests to run in Docker because of usually because of dependency hell, but, um, getting developers to understand how to write tests that matter and mean something. Um, it's, it's, it can be difficult, but it's also where I find a lot of the enjoyment of my work comes into play. So yeah. I mean, that's the difficulty I've seen around testing. Um, big subject though. Lots to talk about there. >>Yeah. We've got, we've already got so many questions coming in. You already got an hour's worth of stuff. So, uh, Nico 81st thoughts on that? >>Yeah, I think I definitely agree with, with other folks here on the panel, I think from a, um, the shift from a skillset perspective that's needed to adopt the new technologies, but I think from even from, uh, aside from the organizational, um, and kind of key responsibilities that, that the new developers have to kinda adapt to and, and kind of inherit now, um, there's also from a technical perspective as there's, you know, um, more developers are owning the full stack, including the infrastructure piece. So that adds a lot more to the plate in Tim's oaf, also testing that component that they were not even, uh, responsible for before. Um, and, um, also the second challenge that, you know, I'm seeing is that on, you know, the long list of added, um, uh, tooling and, you know, there's new tool every other day. Um, and, um, that kind of requires more customization to the testing, uh, that each individual team, um, any individual developer Y by extension has to learn. Uh, so the customization, uh, as well as the, kind of the scope that had, uh, you know, now in conferences, the infrastructure piece, um, uh, both of act to the, to the challenges that we're seeing right now for, um, for CGI and overall testing, um, uh, the developers are saying, uh, in, in the market today. >>Yeah. We've got a lot of questions, um, about all the, all the different parts of this. So, uh, let me just go straight to them. Cause that's why we're here is for the people, uh, a lot of people asking about your favorite tools and in one of this is one of the challenges with integration, right? Is, um, there is no, there are dominant players, but there, there is such a variety. I mean, every one of my customers seems like they're using a different workflow and a different set of tools. So, and Hey, we're all here to just talk about what we're, what we're using, uh, you know, whether your favorite tools. So like a lot of the repeated questions are, what are your favorite tools? Like if you could create it from scratch, uh, what would you use? Pierre's asking, you know, GitHub actions sounds like they're a fan of GitHub actions, uh, w you know, mentioning, pushing the ECR and Docker hub and, uh, using vs code pipeline, I guess there may be talking about Azure pipelines. Um, what, what's your preferred way? So, does anyone have any, uh, thoughts on that anyone want to throw out there? Their preferred pipeline of tooling? >>Well, I have to throw out mine. I might as Jenkins, um, like kind of a honorary cloud be at this point, having spoken a couple of times there, um, all of the plugins just make the functionality. I don't love the UI, but I love that it's been around so long. It has so much community support, and there are so many plugins so that if you want to do something, you don't have to write the code it's already been tested. Um, unfortunately I haven't been able to use Jenkins in, uh, since I joined ship engine, we, most of our, um, our, our monolithic core application is, is team city. It's a dotnet application and TeamCity plays really well with.net. Um, didn't love it, uh, Ms. Jenkins. And I'm just, we're just starting some new initiatives that are using GitHub actions, and I'm really excited to learn, to learn those. I think they have a lot of the same functionality that you're looking for, but, um, much more simplified in is right there and get hubs. So, um, the integration is a lot more seamless, but I do have to go on record that my favorite CICT tools Jenkins. >>All right. You heard it here first people. All right. Anyone else? You're muted? I'm muted. Carlin says muted. Oh, Carla says, guest has muted themselves to Carlos. You got to unmute. >>Yes. I did mute myself because I was typing a lot, trying to, you know, try to answer stuff in the chat. And there's a lot of really dark stuff in there. That's okay. Two more times today. So yeah, it's fine. Yeah, no problem. So totally. And it's the best way to start a play more. So I'm just going to go ahead and light it up. Um, for enterprise environments, I actually am a huge fan of Jenkins. Um, it's a tool that people really understand. Um, it has stood the test of time, right? I mean, people were using Hudson, but 15 years ago, maybe longer. And, you know, the way it works, hasn't really changed very much. I mean, Jenkins X is a little different, but, um, the UI and the way it works internally is pretty familiar to a lot of enterprise environments, which is great. >>And also in me, the plugin ecosystem is amazing. There's so many plugins for everything, and you can make your own if you know, Java groovy. I'm sure there's a perfect Kotlin in there, but I haven't tried myself, but it's really great. It's also really easy to write, um, CIS code, which is something I'm a big fan of. So Jenkins files have been, have worked really well for me. I, I know that I can get a little bit more complex as you start to build your own models and such, but, you know, for enterprise enterprise CIO CD, if you want, especially if you want to roll your own or own it yourself, um, Jenkins is the bellwether and for very good reason now for my personal projects. And I see a lot on the chat here, I think y'all, y'all been agreed with me get hub actions 100%, my favorite tool right now. >>Um, I love GitHub actions. It's, it's customizable, it's modular. There's a lot of plugins already. I started using getting that back maybe a week after when GA and there was no documentation or anything. And I still, it was still my favorite CIA tool even then. Um, and you know, the API is really great. There's a lot to love about GitHub actions and, um, and I, and I use it as much as I can from my personal project. So I still have a soft spot for Travis CAI. Um, you know, they got acquired and they're a little different now trying to see, I, I can't, I can't let it go. I just love it. But, um, yeah, I mean, when it comes to Seattle, those are my tools. So light me up in the comments I will respond. Yeah. >>I mean, I, I feel with you on the Travis, the, I think, cause I think that was my first time experiencing, you know, early days get hub open source and like a free CIA tool that I could describe. I think it was the ammo back then. I don't actually remember, but yeah, it was kind of an exciting time from my experience. There was like, oh, this is, this is just there as a service. And I could just use it. It doesn't, it's like get hub it's free from my open source stuff. And so it does have a soft spot in my heart too. So yeah. >>All right. We've got questions around, um, cam, so I'm going to ask some questions. We don't have to have these answers because sometimes they're going to be specific, but I want to call them out because people in chat may have missed that question. And there's probably, you know, that we have smart people in chat too. So there's probably someone that knows the answer to these things. If, if it's not us, um, they're asking about building Docker images in Kubernetes, which to me is always a sore spot because it's Kubernetes does not build images by default. It's not meant for that out of the gate. And, uh, what is the best way to do this without having to use privileged containers, which privileged containers just implying that yeah, you, you, it probably has more privileges than by default as a container in Kubernetes. And that is a hard thing because, uh, I don't, I think Docker doesn't lie to do that out of the gate. So I don't know if anyone has an immediate answer to that. That's a pretty technical one, but if you, if you know the answer to that in chat, call it out. >>Um, >>I had done this, uh, but I'm pretty sure I had to use a privileged, um, container and install the Docker Damon on the Kubernetes cluster. And I CA I can't give you a better solution. Um, I've done the same. So, >>Yeah, uh, Chavonne asks, um, back to the Jenkins thing, what's the easiest way to integrate Docker into a Jenkins CICB pipeline. And that's one of the challenges I find with Jenkins because I don't claim to be the expert on Jenkins. Is there are so many plugins because of this, of this such a huge ecosystem. Um, when you go searching for Docker, there's a lot that comes back, right. So I, I don't actually have a preferred way because every team I find uses it differently. Um, I don't know, is there a, do you know if there's a Jenkins preferred, a default plugin? I don't even know for Docker. Oh, go ahead. Yeah. Sorry for Docker. And jacon sorry, Docker plugins for Jenkins. Uh, as someone's asking like the preferred or easy way to do that. Um, and I don't, I don't know the back into Jenkins that well, so, >>Well, th the new, the new way that they're doing, uh, Docker builds with the pipeline, which is more declarative versus the groovy. It's really simple, and their documentation is really good. They, um, they make it really easy to say, run this in this image. So you can pull down, you know, public images and add your own layers. Um, so I don't know the name of that plugin, uh, but I can certainly take a minute after this session and going and get that. Um, but if you really are overwhelmed by the plugins, you can just write your, you know, your shell command in Jenkins. You could just by, you know, doing everything in bash, calling the Docker, um, Damon directly, and then getting it working just to see that end to end, and then start browsing for plugins to see if you even want to use those. >>The plugins will allow more integration from end to end. Some of the things that you input might be available later on in the process for having to manage that yourself. But, you know, you don't have to use any of the plugins. You can literally just, you know, do a block where you write your shell command and get it working, and then decide if, for plugins for you. Um, I think it's always under important to understand what is going on under the hood before you, before you adopt the magic of a plugin, because, um, once you have a problem, if you're, if it's all a lockbox to you, it's going to be more difficult to troubleshoot. It's kind of like learning, get command line versus like get cracking or something. Once, once you get in a bind, if you don't understand the underlying steps, it's really hard to get yourself out of a bind, versus if you understand what the plugin or the app is doing, then, um, you can get out of situations a lot easier. That's a good place. That's, that's where I'd start. >>Yeah. Thank you. Um, Camden asks better to build test environment images, every commit in CII. So this is like one of those opinions of we're all gonna have some different, uh, or build on build images on every commit, leveraging the cash, or build them once outside the test pile pipeline. Um, what say you people? >>Uh, well, I I've seen both and generally speaking, my preference is, um, I guess the ant, the it's a consultant answer, right? I think it depends on what you're trying to do, right. So if you have a lot of small changes that are being made and you're creating images for each of those commits, you're going to have a lot of images in your, in your registry, right? And on top of that, if you're building those images, uh, through CAI frequently, if you're using Docker hub or something like that, you might run into rate limiting issues because of Docker's new rate, limiting, uh, rate limits that they put in place. Um, but that might be beneficial if the, if being able to roll back between those small changes while you're testing is important to you. Uh, however, if all you care about is being able to use Docker images, um, or being able to correlate versions to your Docker images, or if you're the type of team that doesn't even use him, uh, does he even use, uh, virgins in your image tags? Then I would think that that might be a little, much you might want to just have in your CIO. You might want to have a stage that builds your Docker images and Docker image and pushes it into your registry, being done first particular branches instead of having to be done on every commit regardless of branch. But again, it really depends on the team. It really depends on what you're building. It really depends on your workflow. It can depend on a number of things like a curse sometimes too. Yeah. Yeah. >>Once had two points here, you know, I've seen, you know, the pattern has been at every, with every, uh, uh, commit, assuming that you have the right set of tests that would kind of, uh, you would benefit from actually seeing, um, the, the, the, the testing workflow go through and can detect any issue within, within the build or whatever you're trying to test against. But if you're just a building without the appropriate set of tests, then you're just basically consuming almond, adding time, as well as all the, the image, uh, stories associated with it without treaty reaping the benefit of, of, of this pattern. Uh, and the second point is, again, I think if you're, if you're going to end up doing a per commit, uh, definitely recommend having some type of, uh, uh, image purging, um, uh, and, and, and garbage collection process to ensure that you're not just wasting, um, all the stories needed and also, um, uh, optimizing your, your bill process, because that will end up being the most time-consuming, um, um, you know, within, within your pipeline. So this is my 2 cents on this. >>Yeah, that's good stuff. I mean, those are both of those are conversations that could lead us into the rabbit hole for the rest of the day on storage management, uh, you know, CP CPU minutes for, uh, you know, your build stuff. I mean, if you're in any size team, more than one or two people, you immediately run into headaches with cost of CIA, because we have now the problem of tools, right? We have so many tools. We can have the CIS system burning CPU cycles all day, every day, if we really wanted to. And so you re very quickly, I think, especially if you're on every commit on every branch, like that gets you into a world of cost mitigation, and you probably are going to have to settle somewhere in the middle on, uh, between the budget, people that are saying you're spending way too much money on the CII platform, uh, because of all these CPU cycles, and then the developers who would love to have everything now, you know, as fast as possible and the biggest, biggest CPU's, and the biggest servers, and have the bills, because the bills can never go fast enough, right. >>There's no end to optimizing your build workflow. Um, we have another question on that. This is another topic that we'll all probably have different takes on is, uh, basically, uh, version tags, right? So on images, we, we have a very established workflow in get for how we make commits. We have commit shots. We have, uh, you know, we know get tags and there's all these things there. And then we go into images and it's just this whole new world that's opened up. Like there's no real consensus. Um, so what, what are your thoughts on the strategy for teams in their image tag? Again, another, another culture thing. Um, commander, >>I mean, I'm a fan of silver when we have no other option. Um, it's just clean and I like the timestamp, you know, exactly when it was built. Um, I don't really see any reason to use another, uh, there's just normal, incremental, um, you know, numbering, but I love the fact that you can pull any tag and know exactly when it was created. So I'm a big fan of bar, if you can make that work for your organization. >>Yep. People are mentioned that in chat, >>So I like as well. Uh, I'm a big fan of it. I think it's easy to be able to just be as easy to be able to signify what a major changes versus a minor change versus just a hot fix or, you know, some or some kind of a bad fix. The problem that I've found with having teams adopt San Bernardo becomes answering these questions and being able to really define what is a major change, what is a minor change? What is a patch, right? And this becomes a bit of an overhead or not so much of an overhead, but, uh, uh, uh, a large concern for teams who have never done versioning before, or they never been responsible for their own versioning. Um, in fact, you know, I'm running into that right now, uh, with, with a client that I'm working with, where a lot, I'm working with a lot of teams, helping them move their applications from a legacy production environment into a new one. >>And in doing so, uh, versioning comes up because Docker images, uh, have tags and usually the tax correlate to versions, but some teams over there, some teams that I'm working with are only maintaining a script and others are maintaining a fully fledged JAK, three tier application, you know, with lots of dependencies. So telling the script, telling the team that maintains a script, Hey, you know, you should use somber and you should start thinking about, you know, what's major, what's my number what's patch. That might be a lot for them. And for someone or a team like that, I might just suggest using commit shots as your versions until you figure that out, or maybe using, um, dates as your version, but for the more for the team, with the larger application, they probably already know the answers to those questions. In which case they're either already using Sember or they, um, or they may be using some other version of the strategy and might be in December, might suit them better. So, um, you're going to hear me say, it depends a lot, and I'm just going to say here, it depends. Cause it really does. Carlos. >>I think you hit on something interesting beyond just how to version, but, um, when to consider it a major release and who makes those decisions, and if you leave it to engineers to version, you're kind of pushing business decisions down the pipe. Um, I think when it's a minor or a major should be a business decision and someone else needs to make that call someone closer to the business should be making that call as to when we want to call it major. >>That's a really good point. And I add some, I actually agree. Um, I absolutely agree with that. And again, it really depends on the team that on the team and the scope of it, it depends on the scope that they're maintaining, right? And so it's a business application. Of course, you're going to have a product manager and you're going to have, you're going to have a product manager who's going to want to make that call because that version is going to be out in marketing. People are going to use it. They're going to refer to and support calls. They're going to need to make those decisions. Sember again, works really, really well for that. Um, but for a team that's maintaining the scripts, you know, I don't know, having them say, okay, you must tell me what a major version is. It's >>A lot, but >>If they want it to use some birds great too, which is why I think going back to what you originally said, Sember in the absence of other options. I think that's a good strategy. >>Yeah. There's a, there's a, um, catching up on chat. I'm not sure if I'm ever going to catch up, but there's a lot of people commenting on their favorite CII systems and it's, and it, it just goes to show for the, the testing and deployment community. Like how many tools there are out there, how many tools there are to support the tools that you're using. Like, uh, it can be a crazy wilderness. And I think that's, that's part of the art of it, uh, is that these things are allowing us to build our workflows to the team's culture. Um, and, uh, but I do think that, you know, getting into like maybe what we hope to be at what's next is I do hope that we get to, to try to figure out some of these harder problems of consistency. Uh, one of the things that led me to Docker at the beginning to begin with was the fact that it wa it created a consistent packaging solution for me to get my code, you know, off of, off of my site of my local system, really, and into the server. >>And that whole workflow would at least the thing that I was making at each step was going to be the same thing used. Right. And that, that was huge. Uh, it was also, it also took us a long time to get there. Right. We all had to, like Docker was one of those ones that decade kind of ideas of let's solidify the, enter, get the consensus of the community around this idea. And we, and it's not perfect. Uh, you know, the Docker Docker file is not the most perfect way to describe how to make your app, but it is there and we're all using it. And now I'm looking for that next piece, right. Then hopefully the next step in that, um, that where we can all arrive at a consensus so that once you hop teams, you know, okay. We all knew Docker. We now, now we're all starting to get to know the manifests, but then there's this big gap in the middle where it's like, it might be one of a dozen things. Um, you know, so >>Yeah, yeah. To that, to that, Brett, um, you know, uh, just maybe more of a shameless plug here and wanting to kind of talk about one of the things that I'm on. So excited, but I work, I work at Tasha Corp. I don't know anyone, or I don't know if many people have heard of, um, you know, we tend to focus a lot on workflows versus technologies, right. Because, you know, as you can see, even just looking at the chat, there's, you know, ton of opinions on the different tooling, right. And, uh, imagine having, you know, I'm working with clients that have 10,000 developers. So imagine taking the folks in the chat and being partnered with one organization or one company and having to make decisions on how to build software. Um, but there's no way you can conversion one or, or one way or one tool, uh, and that's where we're facing in the industry. >>So one of the things that, uh, I'm pretty excited about, and I don't know if it's getting as much traction as you know, we've been focused on it. This is way point, which is a project, an open source project. I believe we got at least, uh, last year, um, which is, it's more of, uh, it's, it is aim to address that really, uh, uh, Brad set on, you know, to come to tool to, uh, make it extremely easy and simple. And, you know, to describe how you want to build, uh, deploy or release your application, uh, in, in a consistent way, regardless of the tools. So similar to how you can think of Terraform and having that pluggability to say Terraform apply or plan against any cloud infrastructure, uh, without really having to know exactly the details of how to do it, uh, this is what wave one is doing. Um, and it can be applied with, you know, for the CIA, uh, framework. So, you know, task plugability into, uh, you know, circle CEI tests to Docker helm, uh, Kubernetes. So that's the, you know, it's, it's a hard problem to solve, but, um, I'm hopeful that that's the path that we're, you know, we'll, we'll eventually get to. So, um, hope, you know, you can, you can, uh, see some of the, you know, information, data on it, on, on HashiCorp site, but I mean, I'm personally excited about it. >>Yeah. Uh I'm to gonna have to check that out. And, um, I told you on my live show, man, we'll talk about it, but talk about it for a whole hour. Uh, so there's another question here around, uh, this, this is actually a little bit more detailed, but it is one that I think a lot of people deal with and I deal with a lot too, is essentially the question is from Cameron, uh, D essentially, do you use compose in your CIO or not Docker compose? Uh, because yes I do. Yeah. Cause it, it, it, it solves so many problems am and not every CGI can, I don't know, there's some problems with a CIO is trying to do it for me. So there are pros and cons and I feel like I'm still on the fence about it because I use it all the time, but also it's not perfect. It's not always meant for CIA. And CIA sometimes tries to do things for you, like starting things up before you start other parts and having that whole order, uh, ordering problem of things anyway. W thoughts and when have thoughts. >>Yes. I love compose. It's one of my favorite tools of all time. Um, and the reason why it's, because what I often find I'm working with teams trying to actually let me walk that back, because Jack on the chat asked a really interesting question about what, what, what the hardest thing about CIS for a lot of teams. And in my experience, the hardest thing is getting teams to build an app that is the same app as what's built in production. A lot of CGI does things that are totally different than what you would do in your local, in your local dev. And as a result of that, you get, you got this application that either doesn't work locally, or it does work, but it's a completely different animal than what you would get in production. Right? So what I've found in trying to get teams to bridge that gap by basically taking their CGI, shifting the CII left, I hate the shift left turn, but I'll use it. >>I'm shifting the CIO left to your local development is trying to say, okay, how do we build an app? How do we, how do we build mot dependencies of that app so that we can build so that we can test our app? How do we run tests, right? How do we build, how do we get test data? And what I found is that trying to get teams to do all this in Docker, which is normally a first for a lot of teams that I'm working with, trying to get them all to do all of this. And Docker means you're running Docker, build a lot running Docker, run a lot. You're running Docker, RM a lot. You ran a lot of Docker, disparate Docker commands. And then on top of that, trying to bridge all of those containers together into a single network can be challenging without compose. >>So I like using a, to be able to really easily categorize and compartmentalize a lot of the things that are going to be done in CII, like building a Docker image, running tests, which is you're, you're going to do it in CII anyway. So running tests, building the image, pushing it to the registry. Well, I wouldn't say pushing it to the registry, but doing all the things that you would do in local dev, but in the same network that you might have a mock database or a mock S3 instance or some of something else. Um, so it's just easy to take all those Docker compose commands and move them into your Yammel file using the hub actions or your dankest Bob using Jenkins, or what have you. Right. It's really, it's really portable that way, but it doesn't work for every team. You know, for example, if you're just a team that, you know, going back to my script example, if it's a really simple script that does one thing on a somewhat routine basis, then that might be a lot of overhead. Um, in that case, you know, you can get away with just Docker commands. It's not a big deal, but the way I looked at it is if I'm, if I'm building, if I build something that's similar to a make bile or rate file, or what have you, then I'm probably gonna want to use Docker compose. If I'm working with Docker, that's, that's a philosophy of values, right? >>So I'm also a fan of Docker compose. And, um, you know, to your point, Carlos, the whole, I mean, I'm also a fan of shifting CEI lift and testing lift, but if you put all that logic in your CTI, um, it changes the L the local development experience from the CGI experience. Versus if you put everything in a compose file so that what you build locally is the same as what you build in CGI. Um, you're going to have a better experience because you're going to be testing something more, that's closer to what you're going to be releasing. And it's also very easy to look at a compose file and kind of, um, understand what the dependencies are and what's happening is very readable. And once you move that stuff to CGI, I think a lot of developers, you know, they're going to be intimidated by the CGI, um, whatever the scripting language is, it's going to be something they're going to have to wrap their head around. >>Um, but they're not gonna be able to use it locally. You're going to have to have another local solution. So I love the idea of a composed file use locally, um, especially if he can Mount the local workspace so that they can do real time development and see their changes in the exact same way as it's going to be built and tested in CGI. It gives developers a high level of confidence. And then, you know, you're less likely to have issues because of discrepancies between how it was built in your local test environment versus how it's built in NCI. And so Docker compose really lets you do all of that in a way that makes your solution more portable, portable between local dev and CGI and reduces the number of CGI cycles to get, you know, the test, the test data that you need. So that's why I like it for really, for local dev. >>It'll be interesting. Um, I don't know if you all were able to see the keynote, but there was a, there was a little bit, not a whole lot, but a little bit talk of the Docker, compose V two, which has now built into the Docker command line. And so now we're shifting from the Python built compose, which was a separate package. You could that one of the challenges was getting it into your CA solution because if you don't have PIP and you got down on the binary and the binary wasn't available for every platform and, uh, it was a PI installer. It gets a little nerdy into how that works, but, uh, and the team is now getting, be able to get unified with it. Now that it's in Golang and it's, and it's plugged right into the Docker command line, it hopefully will be easier to distribute, easier to, to use. >>And you won't have to necessarily have dependencies inside of where you're running it because there'll be a statically compiled binary. Um, so I've been playing with that, uh, this year. And so like training myself to do Docker going from Docker dash compose to Docker space, compose. It is a thing I I'm almost to the point of having to write a shell replacement. Yeah. Alias that thing. Um, but, um, I'm excited to see what that's going, cause there's already new features in it. And it, these built kit by default, like there's all these things. And I, I love build kit. We could make a whole session on build kit. Um, in fact there's actually, um, maybe going on right now, or right around this time, there is a session on, uh, from Solomon hikes, the seat, uh, co-founder of Docker, former CTO, uh, on build kit using, uh, using some other tool on top of build kit or whatever. >>So that, that would be interesting for those of you that are not watching that one. Cause you're here, uh, to do a check that one out later. Um, all right. So another good question was caching. So another one, another area where there is no wrong answers probably, and everyone has a different story. So the question is, what are your thoughts on CII build caching? There's often a debate between security. This is from Quentin. Thank you for this great question. There's often a debate between security reproducibility and build speeds. I haven't found a good answer so far. I will just throw my hat in the ring and say that the more times you want to build, like if you're trying to build every commit or every commit, if you're building many times a day, the more caching you need. So like the more times you're building, the more caching you're gonna likely want. And in most cases caching doesn't bite you in the butt, but that could be, yeah, we, can we get the bit about that? So, yeah. Yeah. >>I'm going to quote Carlos again and say, it depends on, on, you know, how you're talking, you know, what you're trying to build and I'm quoting your colors. Um, yeah, it's, it's got, it's gonna depend because, you know, there are some instances where you definitely want to use, you know, depends on the frequency that you're building and how you're building. Um, it's you would want to actually take advantage of cashing functionalities, um, for the build, uh, itself. Um, but if, um, you know, as you mentioned, there could be some instances where you would want to disable, um, any caching because you actually want to either pull a new packages or, um, you know, there could be some security, um, uh, disadvantages related to security aspects that would, you know, you know, using a cache version of, uh, image layer, for example, could be a problem. And you, you know, if you have a fleet of build, uh, engines, you don't have a good grasp of where they're being cashed. We would have to, um, disable caching in that, in that, um, in those instances. So it, it would depend. >>Yeah, it's, it's funny you have that problem on both sides of cashing. Like there are things that, especially in Docker world, they will cash automatically. And, and then, and then you maybe don't realize that some of that caching could be bad. It's, it's actually using old, uh, old assets, old artifacts, and then there's times where you would expect it to cash, that it doesn't cash. And then you have to do something extra to enable that caching, especially when you're dealing with that cluster of, of CIS servers. Right. And the cloud, the whole clustering problem with caching is even more complex, but yeah, >>But that's, that's when, >>Uh, you know, ever since I asked you to start using build kits and able to build kit, you know, between it's it's it's reader of Boston in, in detecting word, you know, where in, in the bill process needs to cash, as well as, uh, the, the, um, you know, the process. I don't think I've seen any other, uh, approach there that comes close to how efficient, uh, that process can become how much time it can actually save. Uh, but again, I think, I think that's, for me that had been my default approach, unless I actually need something that I would intentionally to disable caching for that purpose, but the benefits, at least for me, the benefits of, um, how bill kit actually been processing my bills, um, from the builds as well as, you know, using the cash up until, you know, how it detects the, the difference in, in, in the assets within the Docker file had been, um, you know, uh, pretty, you know, outweigh the disadvantages that it brings in. So it, you know, take it each case by case. And based on that, determine if you want to use it, but definitely recommend those enabling >>In the absence of a reason not to, um, I definitely think that it's a good approach in terms of speed. Um, yeah, I say you cash until you have a good reason not to personally >>Catch by default. There you go. I think you catch by default. Yeah. Yeah. And, uh, the trick is, well, one, it's not always enabled by default, especially when you're talking about cross server. So that's a, that's a complexity for your SIS admins, or if you're on the cloud, you know, it's usually just an option. Um, I think it also is this, this veers into a little bit of, uh, the more you cash the in a lot of cases with Docker, like the, from like, if you're from images and checked every single time, if you're not pinning every single thing, if you're not painting your app version, you're at your MPN versions to the exact lock file definition. Like there's a lot of these things where I'm I get, I get sort of, I get very grouchy with teams that sort of let it, just let it all be like, yeah, we'll just build two images and they're totally going to have different dependencies because someone happened to update that thing and after whatever or MPM or, or, and so I get grouchy about that, cause I want to lock it all down, but I also know that that's going to create administrative burden. >>Like the team is now going to have to manage versions in a very much more granular way. Like, do we need to version two? Do we need to care about curl? You know, all that stuff. Um, so that's, that's kind of tricky, but when you get to, when you get to certain version problems, uh, sorry, uh, cashing problems, you, you, you don't want those set those caches to happen because it, if you're from image changes and you're not constantly checking for a new image, and if you're not pinning that V that version, then now you, you don't know whether you're getting the latest version of Davion or whatever. Um, so I think that there's, there's an art form to the more you pen, the less you have, the less, you have to be worried about things changing, but the more you pen, the, uh, all your versions of everything all the way down the stack, the more administrative stuff, because you're gonna have to manually change every one of those. >>So I think it's a balancing act for teams. And as you mature, I to find teams, they tend to pin more until they get to a point of being more comfortable with their testing. So the other side of this argument is if you trust your testing, then you, and you have better testing to me, the less likely to the subtle little differences in versions have to be penned because you can get away with those minor or patch level version changes. If you're thoroughly testing your app, because you're trusting your testing. And this gets us into a whole nother rant, but, uh, yeah, but talking >>About penny versions, if you've got a lot of dependencies isn't that when you would want to use the cash the most and not have to rebuild all those layers. Yeah. >>But if you're not, but if you're not painting to the exact patch version and you are caching, then you're not technically getting the latest versions because it's not checking for all the time. It's a weird, there's a lot of this subtle nuance that people don't realize until it's a problem. And that's part of the, the tricky part of allow this stuff, is it, sometimes the Docker can be almost so much magic out of the box that you, you, you get this all and it all works. And then day two happens and you built it a second time and you've got a new version of open SSL in there and suddenly it doesn't work. Um, so anyway, uh, that was a great question. I've done the question on this, on, uh, from heavy. What do you put, where do you put testing in your pipeline? Like, so testing the code cause there's lots of types of testing, uh, because this pipeline gets longer and longer and Docker building images as part of it. And so he says, um, before staging or after staging, but before production, where do you put it? >>Oh man. Okay. So, um, my, my main thought on this is, and of course this is kind of religious flame bait, so sure. You know, people are going to go into the compensation wrong. Carlos, the boy is how I like to think about it. So pretty much in every stage or every environment that you're going to be deploying your app into, or that your application is going to touch. My idea is that there should be a build of a Docker image that has all your applications coded in, along with its dependencies, there's testing that tests your application, and then there's a deployment that happens into whatever infrastructure there is. Right. So the testing, they can get tricky though. And the type of testing you do, I think depends on the environment that you're in. So if you're, let's say for example, your team and you have, you have a main branch and then you have feature branches that merged into the main branch. >>You don't have like a pre-production branch or anything like that. So in those feature branches, whenever I'm doing CGI that way, I know when I freak, when I cut my poll request, that I'm going to merge into main and everything's going to work in my feature branches, I'm going to want to probably just run unit tests and maybe some component tests, which really, which are just, you know, testing that your app can talk to another component or another part, another dependency, like maybe a database doing tests like that, that don't take a lot of time that are fascinating and right. A lot of would be done at the beach branch level and in my opinion, but when you're going to merge that beach branch into main, as part of a release in that activity, you're going to want to be able to do an integration tasks, to make sure that your app can actually talk to all the other dependencies that it talked to. >>You're going to want to do an end to end test or a smoke test, just to make sure that, you know, someone that actually touches the application, if it's like a website can actually use the website as intended and it meets the business cases and all that, and you might even have testing like performance testing, low performance load testing, or security testing, compliance testing that would want to happen in my opinion, when you're about to go into production with a release, because those are gonna take a long time. Those are very expensive. You're going to have to cut new infrastructure, run those tests, and it can become quite arduous. And you're not going to want to run those all the time. You'll have the resources, uh, builds will be slower. Uh, release will be slower. It will just become a mess. So I would want to save those for when I'm about to go into production. Instead of doing those every time I make a commit or every time I'm merging a feature ranch into a non main branch, that's the way I look at it, but everything does a different, um, there's other philosophies around it. Yeah. >>Well, I don't disagree with your build test deploy. I think if you're going to deploy the code, it needs to be tested. Um, at some level, I mean less the same. You've got, I hate the term smoke tests, cause it gives a false sense of security, but you have some mental minimum minimal amount of tests. And I would expect the developer on the feature branch to add new tests that tested that feature. And that would be part of the PR why those tests would need to pass before you can merge it, merge it to master. So I agree that there are tests that you, you want to run at different stages, but the earlier you can run the test before going to production. Um, the fewer issues you have, the easier it is to troubleshoot it. And I kind of agree with what you said, Carlos, about the longer running tests like performance tests and things like that, waiting to the end. >>The only problem is when you wait until the end to run those performance tests, you kind of end up deploying with whatever performance you have. It's, it's almost just an information gathering. So if you don't run your performance test early on, um, and I don't want to go down a rabbit hole, but performance tests can be really useless if you don't have a goal where it's just information gap, uh, this is, this is the performance. Well, what did you expect it to be? Is it good? Is it bad? They can get really nebulous. So if performance is really important, um, you you're gonna need to come up with some expectations, preferably, you know, set up the business level, like what our SLA is, what our response times and have something to shoot for. And then before you're getting to production. If you have targets, you can test before staging and you can tweak the code before staging and move that performance initiative. Sorry, Carlos, a little to the left. Um, but if you don't have a performance targets, then it's just a check box. So those are my thoughts. I like to test before every deployment. Right? >>Yeah. And you know what, I'm glad that you, I'm glad that you brought, I'm glad that you brought up Escalades and performance because, and you know, the definition of performance says to me, because one of the things that I've seen when I work with teams is that oftentimes another team runs a P and L tests and they ended, and the development team doesn't really have too much insight into what's going on there. And usually when I go to the performance team and say, Hey, how do you run your performance test? It's usually just a generic solution for every single application that they support, which may or may not be applicable to the application team that I'm working with specifically. So I think it's a good, I'm not going to dig into it. I'm not going to dig into the rabbit hole SRE, but it is a good bridge into SRE when you start trying to define what does reliability mean, right? >>Because the reason why you test performance, it's test reliability to make sure that when you cut that release, that customers would go to your site or use your application. Aren't going to see regressions in performance and are not going to either go to another website or, you know, lodge in SLA violation or something like that. Um, it does, it does bridge really well with defining reliability and what SRE means. And when you have, when you start talking about that, that's when you started talking about how often do I run? How often do I test my reliability, the reliability of my application, right? Like, do I have nightly tasks in CGI that ensure that my main branch or, you know, some important branch I does not mean is meeting SLA is meeting SLR. So service level objectives, um, or, you know, do I run tasks that ensure that my SLA is being met in production? >>Like whenever, like do I use, do I do things like game days where I test, Hey, if I turn something off or, you know, if I deploy this small broken code to production and like what happens to my performance? What happens to my security and compliance? Um, you can, that you can go really deep into and take creating, um, into creating really robust tests that cover a lot of different domains. But I liked just using build test deploy is the overall answer to that because I find that you're going to have to build your application first. You're going to have to test it out there and build it, and then you're going to want to deploy it after you test it. And that order generally ensures that you're releasing software. That works. >>Right. Right. Um, I was going to ask one last question. Um, it's going to have to be like a sentence answer though, for each one of you. Uh, this is, uh, do you lint? And if you lint, do you lent all the things, if you do, do you fail the linters during your testing? Yes or no? I think it's going to depend on the culture. I really do. Sorry about it. If we >>Have a, you know, a hook, uh, you know, on the get commit, then theoretically the developer can't get code there without running Melinta anyway, >>So, right, right. True. Anyone else? Anyone thoughts on that? Linting >>Nice. I saw an additional question online thing. And in the chat, if you would introduce it in a multi-stage build, um, you know, I was wondering also what others think about that, like typically I've seen, you know, with multi-stage it's the most common use case is just to produce the final, like to minimize the, the, the, the, the, the image size and produce a final, you know, thin, uh, layout or thin, uh, image. Uh, so if it's not for that, like, I, I don't, I haven't seen a lot of, you know, um, teams or individuals who are actually within a multi-stage build. There's nothing really against that, but they think the number one purpose of doing multi-stage had been just producing the minimalist image. Um, so just wanted to kind of combine those two answers in one, uh, for sure. >>Yeah, yeah, sure. Um, and with that, um, thank you all for the great questions. We are going to have to wrap this up and we could go for another hour if we all had the time. And if Dr. Khan was a 24 hour long event and it didn't sadly, it's not. So we've got to make room for the next live panel, which will be Peter coming on and talking about security with some developer ex security experts. And I wanted to thank again, thank you all three of you for being here real quick, go around the room. Um, uh, where can people reach out to you? I am, uh, at Bret Fisher on Twitter. You can find me there. Carlos. >>I'm at dev Mandy with a Y D E N D Y that's me, um, >>Easiest name ever on Twitter, Carlos and DFW on LinkedIn. And I also have a LinkedIn learning course. So if you check me out on my LinkedIn learning, >>Yeah. I'm at Nicola Quebec. Um, one word, I'll put it in the chat as well on, on LinkedIn, as well as, uh, uh, as well as Twitter. Thanks for having us, Brett. Yeah. Thanks for being here. >>Um, and, and you all stay around. So if you're in the room with us chatting, you're gonna, you're gonna, if you want to go to see the next live panel, I've got to go back to the beginning and do that whole thing, uh, and find the next, because this one will end, but we'll still be in chat for a few minutes. I think the chat keeps going. I don't actually know. I haven't tried it yet. So we'll find out here in a minute. Um, but thanks you all for being here, I will be back a little bit later, but, uh, coming up next on the live stuff is Peter Wood security. Ciao. Bye.

(uplifting music) >> Hello and welcome to this Cube Conversation. I'm John Furrier, host of theCube here in Palo Alto, California. We've got two great remote guests to talk about some big news hitting with Scality and Hewlett Packard Enterprise. Jerome Lecat CEO of Scality and Chris Tinker, Distinguished Technologist from HPE, Hewlett Packard Enterprise, Jerome, Chris, great to see you both Cube alumnis from an original gangster days as we'd say back then when we started almost 11 years ago. Great to see you both. >> It's great to be back. >> Good to see you John. >> So, really compelling news around kind of this next generation storage cloud native solution. Okay, it's really kind of an impact on the next gen, I call next gen, dev ops meets application, modern application world and something we've been covering heavily. There's some big news here around Scality and HPE offering a pretty amazing product. You guys introduced essentially the next gen piece of it, Artesca, we'll get into in a second, but this is a game-changing announcement you guys announced, this is an evolution continuing I think is more of a revolution, but I think, you know storage is kind of abstractionally of evolution to this app centric world. So talk about this environment we're in and we'll get to the announcement, which is object store for modern workloads, but this whole shift is happening Jerome. This is a game changer to storage and customers are going to be deploying workloads. >> Yeah, Scality really, I mean, I personally really started working on Scality more than 10 years ago, close to 15 now. And if we think about it I mean the cloud has really revolutionized IT. And within the cloud, we really see layers and layers of technology. I mean, it all start at around 2006 with Amazon and Google and Facebook finding ways to do initially what was consumer IT at very large scale, very low credible reliability and then slowly creeped into the enterprise. And at the very beginning, I would say that everyone was kind of wizards trying things and really coupling technologies together. And to some degree we were some of the first wizard doing this, but we, we're now close to 15 years later and there's a lot of knowledge and a lot of experience, a lot of tools. And this is really a new generation. I'll call it cloud native, or you can call it next gen whatever, but there is now enough experience in the world, both at the development level and at the infrastructure level to deliver truly distributed automated systems that run on industry standard servers. Obviously good quality server deliver a better service than others, but there is now enough knowledge for this to truly go at scale. And call this cloud or call this cloud native. Really the core concept here is to deliver scalable IT at very low cost, very high level of reliability, all based on software. And we've, we've been participated in this motion, but we feel that now the breadth of what's coming is at the new level, and it was time for us to think, develop and launch a new product that's specifically adapted to that. And Chris, I will let you comment on this because the customers or some of them, you can add a customer, you do that. >> Well, you know, you're right. You know, I've been in the, I've been like you I've been in this industry for a, well, along time. Give a long, 20 to 21 years in HPE in engineering. And look at the actual landscape has changed with how we're doing scale-out software-defined storage for particular workloads. And we're a catalyst has evolved here is an analytics normally what was only done in the three letter acronyms and massively scale-out parallel namespace file systems, parallel file systems. The application space has encroached into the enterprise world where the enterprise world needed a way to actually take a look at how to, how do I simplify the operations? How do I actually be able to bring about an application that can run in the public cloud or on premise or hybrid, be able to actually look at a workload optimized step that aligns the actual cost to the actual analytics that I'm going to be doing the workload that I'm going to be doing and be able to bridge those gaps and be able to spin this up and simplify operations. And you know, and if you, if you are familiar with these parallel processes which by the way we actually have on our truck, I, I do engineer those, but they are, they are, they are they have their own unique challenges, but in the world of enterprise where customers are looking to simplify operations, then take advantage of new application, analytic workloads whether it be smart, Mesa, whatever it might be, right. I mean, if I want to spin up a Mongo DB or maybe maybe a, you know, last a search capability how do I actually take those technologies, embrace a modern scale-out storage stack that without without breaking the bank, but also provide a simple operations. And that's, that's why we look for object storage capabilities because it brings us this massive parallelization. Back to you John. >> Well before we get into the product. I want to just touch on one thing Jerome you mentioned, and Chris, you, you brought up the DevOps piece next gen, next level, whatever term you use. It is cloud native, cloud native has proven that DevOps infrastructure is code is not only legit. It's being operationalized in all enterprises and add security in there, you have DevSecOps, this is the reality and hybrid cloud in particular has been pretty much the consensus is that standard. So our defacto center whatever you want to call it, that's happening. Multicloud are on the horizon. So these new workloads are have these new architectural changes, cloud on premises and edge. This is the number one story. And the number one challenge all enterprises are now working on. How do I build the architecture for the cloud on premises and edge? This is forcing the DevOps team to flex and build new apps. Can you guys talk about that particular trend? And is it, and is that relevant here? >> Yeah, I, I now talk about really storage anywhere and cloud anywhere and and really the key concept is edge to go to cloud. I mean, we all understand now that the edge will host a lot of that time and the edge is many different things. I mean, it's obviously a smartphone, whatever that is, but it's also factories, it's also production. It's also, you know, moving moving machinery, trains, planes, satellites that that's all the edge, cars obviously. And a lot of that I will be both produced and process there, but from the edge who will want to be able to send the data for analysis, for backup, for logging to a call, and that call could be regional, maybe not, you know, one call for the whole planet, but maybe one corporate region the state in the U.S. And then from there you will also want to push some of the data to public cloud. One of the thing that we see more and more is that the D.R that has centered the disaster recovery is not another physical data center. It's actually the cloud, and that's a very efficient infrastructure very cost efficient, especially. So really it, it, it's changing the paradigm on how you think about storage because you really need to integrate these three layers in a consistent approach especially around the topic of security because you want the data to be secure all along the way. And data is not just data, its data, and who can access the data, who can modify the data what are the conditions that allow modification all automatically erasure of the data? In some cases, it's super important that the data automatically erased after 10 years and all this needs to be transported from edge to core to cloud. So that that's one of the aspects. Another aspects that resonates for me with what you said is a word you didn't say, but it's actually crucial this whole revolution. It's Kubernetes I mean, Kubernetes is in now a mature technology, and it's, it's just, you know the next level of automatized operation for distributed system, which we didn't have 5 or 10 years ago. And that is so powerful that it's going to allow application developers to develop much faster system that can be distributed again edge to go to cloud, because it's going to be an underlying technology that spans the three layers. >> Chris, your thoughts hybrid cloud. I've been, I've been having questions with the HPE folks for God years and years on hybrid clouds, now here. >> Right (chuckles) >> Well, you know, and, and it's exciting in a layout right, so you look at like a, whether it be enterprise virtualization, that is a scale-out general purpose virtualization workloads whether it be analytic workloads, whether it be no data protection is a paramount to all of this, orchestration is paramount. If you look at that DevSecOps, absolutely. I mean, securing the actual data the digital last set is, is absolutely paramount. And if you look at how we do this look at the investments we're making, we're making enough and look at the collaborative platform development which goes to our partnership with Scality. It is, we're providing them an integral aspect of everything we do, whether we're bringing in Ezmeral which is our software we use for orchestration look at the veneer of its control plane, controlling Kubernetes. Being able to actually control the active clusters and the actual backing store for all the analytics that we just talked about. Whether it be a web-scale app that is traditionally using a politics namespace and now been modernized and take advantage of newer technologies running an NBME burst buffers or a hundred gig networks with Slingshot network of 200 and 400 gigabit looking at how do we actually get the actual analytics, the workload to the CPU and have it attached to the data at risk. Where's the data, how do we land the data? How do we actually align, essentially locality, locality of the actual asset to the computer. And this is where, you know, we can look leverage whether it be a Zair or Google or name your favorite hybrid, hyperscaler, leverage those technologies leveraging the actual persistent store. And this is where Scality is, with this object store capability has it been an industry trendsetter, setting the actual landscape of how provide an object store on premise and hybrid cloud run it in a public cloud, but being able to facilitate data mobility and tie it back to, and tie it back to an application. And this is where a lot of things have changed in the world of analytics, because the applications that you, the newer technologies that are coming on the market have taken advantage of this particular protocol as threes. So they can do web scale massively parallel concurrent workloads. >> You know what let's get into the announcement. I love cool and relevant products. And I think this hits the mark. Scality you guys have Artesca, which is just announced. And I think it, you know, we obviously we reported on it. You guys have a lightweight true enterprise grade object store software for Kubernetes. This is the announcement, Jerome, tell us about it. What's the big deal? Cool and relevant, come on, this is cool. Right, tell us. >> I'm super excited. I'm not sure, if you can see it as well on the screen, but I'm super, super excited. You know, we, we introduced the ring 11 years ago and they says our biggest announcements for the past 11 years. So yes, do pay attention. And, you know, after, after looking at, at all these trends and understanding where we see the future going. We decided that it was time to embark (indistinct) So there's not one line of code that's the same as our previous generation product. They will both exist, they both have a space in the market. And Artesca was specifically designed for this cloud native era. And what we see is that people want something that's lightweight especially because it had to go to the edge. They still want the enterprise grid that Scality is known for. And it has to be modern. What we really mean by modern is, we see object storage now being the primary storage for many application more and more applications. And so we have to be able to deliver the performance, that primary storage expects. This idea of a Scality of serving primary storage is actually not completely new. When we launched Scality 10 years ago, the first application that we were supporting was consumer email for which we were, and we are still today, the primary storage. So we have, we know what it is to be the primary store. We know what's the level of reliability you need to hit. We know what, what latency means and latency is different from throughput, you really need to optimize both. And I think that still today we're the only object storage company that protects data from both replication and original encoding Because we understand that replication is faster, but the original encoding is more better, and more, of file where fast internet latency doesn't matter so much. So we we've been being all that experience, but really rethinking of product for that new generation that really is here now. And so where we're truly excited, I guess people a bit more about the product. It's a software, Scality is a software company and that's why we love to partner with HPE who's producing amazing servers, you know for the record and the history. The very first deployment of Scality in 2010 was on the HP servers. So this is a long love story here. And so to come back to our desk is lightweight in the sense that it's easy to use. We can start small, we can start from just one server or one VM I mean, you would start really small, but he can grow infinitely. The fact that we start small, we didn't, you know limit the technology because of that. So you can start from one to many and it's cloud native in the sense that it's completely Kubernetes compatible it's Kubernetes office traded. It will deploy on many Kubernetes distributions. We're talking obviously with Ezmeral we're also talking with zoo and with the other all those of communities distribution it will also be able to be run in the cloud. Now, I'm not sure that there will be many true production deployment of Artesca going the cloud, because you already have really good object storage by the cloud providers but when you are developing something and you want to test that, you know just doing it in the cloud is very practical. So you'll be able to deploy our Kubernetes cloud distribution, and it's more than object storage in the sense that it's application centric. A lot of our work is actually validating that our storage is fit for this single purpose application. And making sure that we understand the requirement of these application, that we can guide our customers on how to deploy. And it's really designed to be the primary storage for these new workloads. >> The big part of the news is your relationship with Hewlett Packard Enterprise is some exclusivity here as part of this and as you mentioned the relationship goes back many, many years. We've covered the, your relationship in the past. Chris also, you know, we cover HP like a blanket. This is big news for HPE as well. >> This is very big news. >> What is the relationship, talk about this exclusivity Could you share about the partnership and the exclusivity piece? >> Well, there's the partnership expands into the pan HPE portfolio. we look, we made a massive investment in edge IOT device. So we actually have how did we align the cost to the demand. Our customers come to us, wanting to looking at think about what we're doing with Greenlake, like in consumption based modeling. They want to be able to be able to consume the asset without having to do a capital outlay out of the gate. Number two, look at, you know how do you deploy technology, really demand. It depends on the scale, right? So in a lot of your web skill, you know, scale out technologies, it putting them on a diet is challenging. Meaning how skinny can you get it. Getting it down into the 50 terabyte range and then the complexities of those technologies at as you take a day one implementation and scale it out over you know, you know, multiple iterations over quarters, the growth becomes a challenge so working with Scality we, we believe we've actually cracked this nut. We figured out how to a number one, how to start small, but not limit a customer's ability to scale it out incrementally or grotesquely. You can eat depending on the quarters, the month, whatever whatever the workload is, how do you actually align and be able to consume it? So now whether it be on our Edgeline products our DL products go right there, now what that Jerome was talking about earlier you know, we, we, we ship a server every few seconds. That won't be a problem. But then of course, into our density optimized compute with the Apollo products. And this where our two companies have worked in an exclusivity where they scale the software bonds on the HP ecosystem. And then we can, of course provide you, our customers the ability to consume that through our GreenLake financial models or through a CapEx partners. >> Awesome, so Jerome and, and Chris, who's the customer here obviously, there's an exclusive period. Talk about the target customer and how the customers get the product and how they get the software. And how does this exclusivity with HP fit into it? >> Yeah, so there there's really a three types of customers and we've really, we've worked a lot with a company called UseDesign to optimize the user interface for each the types of customers. So we really thought about each customer role and providing with each of them the best product. So the, the first type of customer are application owners who are deploying an application that requires an object storage in the backend, you typically want a simple object store for one application, they want it to be simple and work. Honestly they want no thrill, just want an object store that works. And they want to be able to start as small as they start with their application. Often it's, you know, the first deployment maybe a small deployment, you know applications like a backup like VML, Rubrik, or analytics like (indistinct), file system that now, now available as a software, you know like CGI does a really great departmental NAS that works very well that needs an object store in the backend. Or for high performance computing a wake-up house system is an amazing file system. We will also have vertical application like road peak, for example, who provides origin and the view of the software broadcasters. So all these are application, they request an object store in the backend and you just need a simple high-performance working well object store and I'll discuss perfect for that. Now, the second type of people that we think will be interested by Artesca are essentially developer who are currently developing some capabilities or cloud native application, your next gen. And as part of their development stack, it's getting better and better when you're developing a cloud native application to really target an object storage rather than NFS, as you're persistent. It just, you know, think about generations of technologies and NFS and filesystem were great 25 years ago. I mean, it's an amazing technology. Now, when you want to develop a distributed scalable application object storage is a better fit because it's the same generation. And so same thing, I mean, you know, they're developing something they need an object store that they can develop on. So they want it very lightweight, but they also want the product that their enterprise or their customers will be able to rely on for years and years on. And this guy's really great fit to do that. The third type of customer are more architects, I would say are the architects that are designing a system where they are going to have 50 factories, a thousand planes, a million cars, they are going to have some local storage which will they want to replicate to the core and possibly also to the cloud. And as the design is really new generation workloads that are incredibly distributed but with local storage Artesca are really great for that. >> And tell about the HPE exclusive Chris. What's the, how does that fit in? Do they buy through Scality? Can they get it for the HP? Are you guys working together on how customers can procure it? >> Both ways, yeah both ways they can procure it through Scality. They can secure it through HPE and it's, it's it's the software stack running on our density optimized compute platforms which you would choose and align those and to provide an enterprise quality. Cause if it comes back to it in all of these use cases is how do we align up into a true enterprise stack, bringing about multitenancy bringing about the, the, the fact that you know, if you look at like a local coding one of the things that they're bringing to it, so that we can get down into the DL325. So with the exclusivity, you actually get choice. And that choice comes into our entire portfolio whether it be the Edgeline platform the DL325 AMD processing stack or the Intel 380, or whether it be the Apollos or like I said, there's, there's, there's so many ample choices there that facilitate this, and it's this allows us to align those two strategies. >> Awesome, and I think the Kubernetes piece is really relevant because, you know, I've been interviewing folks practitioners and Kubernetes is very much maturing fast. It's definitely the centerpiece of the cloud native both below the, the line, if you will below under the hood for the, for the infrastructure and then for apps, they want a program on top of it that's critical. I mean, Jerome, this is like, this is the future. >> Yeah, and if you don't mind like to come back to the myth on the exclusivity with HP. So we did a six month exclusive and the very reason we could do this is because HP has such breadth of server portfolio. And so we can go from, you know, really simple, very cheap you know, DL380, machine that we tell us for a few dollars. I mean, it's really like simple system, 50 terabyte. We can have the DL325 that Chris mentioned that is really a powerhouse all NVME, clash over storage is NVME, very fast processors you know, dense, large, large system, like the APOE 4,500. So it's a very large graph of portfolio. We support the whole portfolio and we work together on this. So I want to say that you know, one of the reason I want to send kudos to HP for the breadth of their server line really. As mentioned, Artesca can be ordered from either company. In hand-in-hand together, so anyway, you'll see both of us and our field working incredibly well together. >> Well, just on that point, I think just for clarification was this co-design by Scality and HPE, because Chris you mentioned, you know, the, the configuration of your systems. Can you guys, Chris quickly talk about the design. >> From, from, from the code base the software is entirely designed and developed by Scality, from testing and performance, so this really was a joint work with HP providing both a hardware and manpower so that we could accelerate the testing phase. >> You know, Chris HPE has just been doing such a great job of really focused on this. I know I've been covering it for years before it was fashionable. The idea of apps working no matter where it lives, public cloud, data center, edge. And you mentioned edge line's been around for awhile, you know, app centric, developer friendly, cloud first, has been an HPE kind of guiding first principle for many, many years. >> Well, it has. And, you know, as our CEO here intended, by 2022 everything will be able to be consumed as a service in our portfolio. And then this stack allows us the simplicity and the consumability of the technology and the granulation of it allows us to simplify the installation. Simplify the actual deployment bringing into a cloud ecosystem, but more importantly for the end customer. They simply get an enterprise quality product running on an optimized stack that they can consume through a orchestrated simplistic interface. That customers that's what they're wanting for today's but they come to me and ask, hey how do I need a, I've got this new app, new project. And, you know, it goes back to who's actually coming. It's no longer the IT people who are actually coming to us. It's the lines of business. It's that entire dimension of business owners coming to us, going this is my challenge. And how can you, HPE help us? And we rely on our breadth of technology, but also our breadth of partners to come together in our, of course Scality is hand in hand and our collaborative business unit our collaborative storage product engineering group that actually brought, brought this to market. So we're very excited about this solution. >> Chris, thanks for that input and great insight. Jerome, congratulations on a great partnership with HPE obviously great joint customer base. Congratulations on the product release here. Big moving the ball down the field, as they say. New functionality, clouds, cloud native object store. Phenomenal, so wrap, wrap, wrap up the interview. Tell us your vision for Scality and the future of storage. >> Yeah, I think I started in, Scality is going to be an amazing leader, it is already. But yeah, so, you know I have three things that I think will govern how storage is going. And obviously Marc Andreessen said it software is everywhere and software is eating the world. So definitely that's going to be true in the data center in storage in particular, but the three trends that are more specific are first of all, I think that security performance and agility is now basic expectation. It's, it's not, you know it's not like an additional feature. It's just the basic tables, security performance and our job. The second thing is, and we've talked about it during this conversation is edge to go. You need to think your platform with edge, core and cloud. You know, you, you don't want to have separate systems separate design interface point for edge and then think about the core and then think about cloud, and then think about the diverse power. All this needs to be integrated in a design. And the third thing that I see as a major trend for the next 10 years is data sovereignty. More and more, you need to think about where is the data residing? What are the legal challenges? What is the level of protection, against who are you protected? What is your independence strategy? How do you keep as a company being independent from the people you need to be in the band? And I mean, I say companies, but this is also true for public services. So these, these for me are the three big trends. And I do believe that software defined distributed architecture are necessary for these trends but you also need to think about being truly enterprise grade. and that has been one of our focus with design of Artesca. How do we combine a lightweight product with all of the security requirements and data sovereignty requirements that we expect to have in the next thing? >> That's awesome. Congratulations on the news Scality, Artesca. The big release with HPE exclusive for six months, Chris Tinker, Distinguished Engineer at HPE. Great to see you Jerome Lecat CEO of Scality, great to see you as well. Congratulations on the big news. I'm John Furrier from theCube. Thanks for watching. (uplifting music)

>> Narrator: Live, from Las Vegas, it's theCUBE. Covering Dell EMC World 2017, brought to you by Dell, EMC. >> John: Okay, welcome back, everyone, this is theCUBE live in Las Vegas for Dell EMC World 2017, our 8th year covering EMC World. Now, the first year covering Dell EMC World, I'm John Furrier, my co-host this week, Paul Gillin, on the blue set, two CUBES, two shot guns, double barrel shot gun of content. Our next guest, who's been on theCUBE every single year we've been in existence, since 2010, the Chief Marketing Officer of Dell Technologies and Dell EMC, Jeremy Burton, formerly the CMO of EMC and again, 2010 was your first year with EMC, now. >> That's right. >> Look, I mean, welcome to theCUBE. >> Thanks, yeah the makeup takes a bit longer, I got to cover up more wrinkles, but you know. >> You're running the show, you're on stage, your son is doing some gigs up there. Where are you now mentally, I mean, 2010, when we started our journey with theCUBE was the first at EMC World in Boston, you just joined the company. Now, here, look where you're at. I mean, do you have the pinch me moments? How the hell did this happen? Look how big we are. What's, how do you feel? >> Yeah, it's great. I mean, I almost have this belief in tech, you can never plan more than a couple years. I mean, so I kind of laugh a little bit at the five year strategy or whatever. And I'm think even personally, if you're looking out maybe more than a couple years in your career as to what you want to do, its... it can all change. It's like the start of a race. You can have all the best plans in the world, but you don't know what's going to happen when you get around the first corner, right? So, yeah, I knew last year, when Michael asked me to take on the CMO role, that the marketing team could make a difference. I'm a big believer about story and making sure that people understand what we're trying to do. It was, for me at least, it was a challenge, and a real interesting role to take on. >> Certainly a big challenge, you got the merger going on, obviously bigger role, bigger company, more portfolio product. You also have a product background you usually were doing a lot of the product stuff. What's been the impact from a customer standpoint as you've been rolling out the brand of Dell Technologies which I know is a holistic brand. But you now have a lot of brands to deal with in your portfolio. >> Yeah, well the good news is we're bigger, we have more budget, we can do a bigger brand campaign and the real goal here is; most people, when they think of Dell, they think of a PC. When they think of EMC they think of a storage array. Dell Technologies, if you look at the breadth of the company now, it really is incredible what we can do in an organization. So the brand campaign is really about redefining the company. What is Dell Technologies stand for? Well, it's about transforming your business, Transforming IT, your workforce and security. If we can get across over the next couple of years, the impact that we can have on an organization that's really where the win is. Underneath that obviously, we want to say, hey look, if you're on a digital project, Pivotal's going to be lead. It if's a software-defined data center, it's VMWear. So first and foremost, it's getting the big story of Dell Technologies, and redefining how people perceive the company. >> Well, Jeremy, so what's the message? We've been trying to read the tea leaves here, about what's the theme coming out of the show. What is the single most important message you want customers to take away? >> Number one, first and foremost, it's about, look, if every company is going to become a digital company, if you want to become a digital company, trust Dell Technologies for your journey. >> Everybody's saying that, though. I mean, that's HP's pitch now, too. So why did you adopt digital transformation as a theme, when it has become such a buzzword in the industry? Are you trying to find a nuance there? >> No, because the thing is, is that's where the world is going. And we could make up something that's ours, but the problem with that, I've never been one for saying, oh, we're just going to make up a new category. The category, people are going to become digital companies without a doubt, and I think our differentiation, and this is in the ad campaign, and you see it around the show, here, it's about making it real. At some point, you got to realize that transformation. if you're going to go build a cloud native app with HP, good luck, they don't have any software. >> I think you said on theCUBE last year, or the year before, I forget which year it was. These eight years are blurring in, and... theCUBE's on it's eight year. I think you quote said, "never fight fashion," was a phrase you always say, so I do believe that digital transformation's a little bit boring, but it's a reality. >> Well and for us, I feel like our differentiation, whether it be EMC or Dell, is we're a very practical company. And if we can't make it real, nobody can. Which is why the ad campaign only focused on customers. It was, hey if you want to look at GE, if you're going to look at Colombia Sports Wear, Chitale Dairy, we got about ten different customers, cause I think, to your point, right, it is noisy. How do you make it believable? You have a real customer saying, "I bet on Dell Technologies and they transformed my business." >> So we were talking on the intro about the transformation I know there's a lot of herding cats with the new merged companies, and you got to get every thing they want on stage, limited time on stage, not a lot of customers on stage, so I got to ask you, look it, the business transformation is Isilon Onefs, so digital transformation really means the businesses. How do you evolve from speeds and feeds culture, to real business transformation? Cause that's kind of what I hear you saying. >> That is, if you look internally at how the company's got to transform, it's exactly that. We created around the time we brought the companies together a small group sales team called Dell Technologies Select and these are folks that actually don't... carry any one brand. They carry Dell Technologies, and they're working with fifty of our biggest most transformative customers. So obviously the goal here is over time, you want that fifty to be two hundred, to be a thousand. Really, you're going to grow the DNA within that group, because the difficulty is that, some companies are doing digital transformation, some people are not even doing IT transformation, some companies are still trying to figure out the last big issue that they had. The market doesn't, it's not an on-off switch, you've got early adopters, you've got 'luggards, and everything in between, so Dell Technologies Select, was really geared towards engaging with transformative customers in a different way, across the entire portfolio, instead of; a storage, a service, a virtualization. >> Can you dig a little deeper on the sales model? Because you had the merge of two great sales organizations, one enterprise focused, is account focused, another is channel focused, >> SMB >> And direct SMB. How are you getting them to work together, or trying to merge those cultures, or are you trying to use each for what it does best? >> It's a great question, cause I think this is where many companies fall down when they merge or acquire even, right? So think of the Dell Technologies Select at the very top of the pyramid, they're the biggest, most transformative projects we're engaged on, and have a set of folks who work across the portfolio. Beneath that, we have an enterprise sales team. That, is predominantly made up from the EMC sales team, prior to the merger; relationship selling, big accounts, you know there's three thousand accounts there. Bill Scannell runs that sales team. Beneath that, you've got the commercial sales team, and Marius Haas, who was from Dell. Marius runs that. And so we're trying to preserve the higher end relationship selling that Bill Scannell and his team did. And the transactional sales team that Dell had, and then even beneath that in Jeff Clarke's organization, you've got consumer and small business. So what we've tried to do is, not complicated things. Leave each area to do what they were good at. And then to the key point we made earlier, build this very broad digital capability. Kind of new DNA; start small and grow big. >> You know, EMC has always had good partner relations, they were storage and you had some swim lanes, some stuff to partner program, and all the different stuff you were involved in. The branding was phenomenal when you took over on that. But now my observation on this show, just from watching it over the years, is a whole lift in alliance and marketing partners. Intel Dan Bryan on stage, obviously Dell and Intel make a lot of sense together. That history is there. But the alliances in Microsoft, Cisco, now a whole new set of industry alliances now, at the disposal. Has that changed your thinking a bit? And how do you look at that? Because now that's not just like a merging, that's like pre-existing and exploding. >> No, you always need partners, right? I think both Dell and EMC never believed they do it all themselves, right? And I think here we are, together, we're a much bigger company, but we still need partners. I mean Intel, we're Intel's biggest customer, right? So that makes up more relevant to them, but whereas in the past, maybe we were always thought as on the EMC side as enemy of Microsoft because of the VMWare. Now, Microsoft's an alliance partner. And it's nice that folks like Satya, he's taken over the company, and he's made it very clear that he wants to build an ecosystem, or rebuild and ecosystem. The big companies like Intel and Microsoft, I mean Cisco, we still do two billion dollars of Vblock, right? And as much as I think... we do kind of jousting between vendors at times, ultimately the customer decides who partners, and who competes. We often partner because the customer wants us to partner. >> One of the things I always like about interviewing you, Jeremy, you have your toe in the water of the future. I heard you mention VR, virtual reality, and all kinds of reality on stage; AR, VR. AI is certainly the hottest thing in the world. Deep learning and machine learning... is getting integrated into some of the products. But as a brand marketer, how are you looking at these new trends? Cause they are great opportunities, you have a great show on stage, you had great entertainment, informative, colorful, but now, soon, as a marketer, you have to start integrating some of these awesome tools, into the marketing mix. >> It's incredible right now, because... one of the things I love about the coming together of Dell EMC, and maybe this is not intuitively obvious, but a lot of the client products, a lot of the VR and gaming business that Dell has built over the years, I mean all the guys who come here, are either gamers or have got kids who are gamers. And so getting access to the Alienware team, they've got relationships with the Minecraft team, working with the folks that work on the AR and VR headsets. To me it should make events like this much more engaging. I'm a big believer that over time, these events have got to become- >> And by the way, all those new startups, are going to be running Dell servers, potentially, so a lot of this stuff is going on, your hands in it. >> Yeah, we got to make this experiential for folks. And a lot of the client technology has got that, it grabs you, right? I'm looking forward to exploring- I mean particularly augmented reality. To me, that's a technology, which is going to be massive in future. I think the way we want to present the company, is not as consumer and business, or client and data center, I think we've got to show folks the end to end. If you're doing a service request as a field service worker, and you've got your augmented reality headset on, you're going to get data for the service request from a back office system, you're going to get your knowledge from an Isilon system but it's going to be rendered in real time in front of you, as you do your work. I think the customer wants to see the solution. >> We were talking with Peter Burris in the previous segment about... are we going back to the future? The old IBM, one throat to choke, IBM was in every market, they dominated almost every market. But they had the full range of products you could get from them, from one sales rep. Are we going back to that type of model now? >> Yes and no. If you want a good indication of the future, look at the past, right? And so, infrastructure clearly is consolidating, right? What we believe, as infrastructure consolidates, it can support fewer players. So, you got to be the big player. So, in infrastructure market, we have a consolidation play, and we're very open about that. We're going to be more efficient, more economic Even if that market's flat, we're going to take more- >> But it's still huge numbers, by the way. >> It's a huge number, and then look, there's the new cloud native world. We've got to play with Pivotal there. Look at the myriad of devices you're going to see in IRT. The IRT ecosystem is not a single, vertical integrated stack. You've got sprinklers, you've got things that attach to cows, you've got... sensors on cars. I think when on part of the tech industry starts to consolidate, and you get this, maybe fewer vendors, another area opens up, and you get this incredible ecosystem. I'd say, IoT, machine intelligence, cloud native apps, that's like the next frontier, and those ecosystems are thriving, as the prior ecosystem consolidates. >> Great, awesome comment there, I think you just encapsulated- well done, the consolidation, that's a huge number, by the way. That's massive. >> It's hundreds of billions of dollars. In fact, IDC would track it and say it's about three. >> A hyper conversion that's going on right now. I mean two years ago, that was a thriving ecosystem, now it's all consolidated- >> It's consolidating, because the macro category- >> It seems to happen faster. >> Yeah, you've got to, I think in infrastructure... It's interesting, we don't necessarily in our business need to be the first mover, like we weren't the first mover to hyperconverge. But we can't be asleep at the wheel, number one, and we have to bring our distribution scale to bear. Once something goes to mainstream, as we proved in our flash, and now we're proving in hyperconverge, we has zero revenue for VxRail a year ago, today it's the market leader. That's... we weren't first to market with the product, but we've got distribution scale. The reason why a lot of these small companies are struggling is because they spend all of their VC money, or their profits, it's all spent on building a distribution channel. And so that's where Wall Street doesn't value them anymore. >> Scales and new competitive advantage, we've said on theCUBE, we continue to say that, certainly Amazon web service has proven that. Scale is the new differentiator, it's the barred to entry, great point there. I got to ask you about a point we were discussing, with Peter Burris, and we were kind of riffing on this, kind of, meaning to joke at at some of the vendors out there. Everyone's claiming to be number one, at everything. It's like, we're number one at this! We're number one. Markel's number one, Dell's number one, HP's number one. So the question is, what is the scoreboard? So the answer in our little opening was; customers. That is the ultimate scoreboard. >> Yeah. >> How are you guys going to continue to push, because there's been some wins with the combination. That's ultimately going to be the scoreboard. Forget the market share from whatever research firm. How are you getting new customers, are you retaining them, are they valuing your products and services? Your thoughts. >> Yeah, I mean, there's a couple of things there. And I think the history of Dell is pretty interesting, because the data shows that the best way for us to get into a new customer, believe it or not, is with a PC. And, it's our, probably lowest priced product, it's our, maybe the most frictionless sale. And the nice thing now is once we get in there with the PC, and maybe a low end server, there's a whole lot more value we can bring in behind it. Which is why a lot of our focus, is not just on product; it's distribution channel as well, because if that's working effectively, we can get that cross-sale going. We've already seen in the early days of the merger, customers who've got our storage, sometimes a great tactic is to go, ask the customer; "hey, can we have your server business?" And it's been amazing how many folks have come back and said, "okay," because we've got relationships. And so, adding for the next couple of years, that cross sale becomes absolutely critical for us. Because we get a new customer, but then we want to keep that customer. How do we keep them? We got to solve more of the problem. And that's called cross-sale. >> Jeremy, great to have you on theCUBE. I know you're super busy, I know you got Gwen Stefani's the entertainment tonight. Great attendance here at the show. Congratulations on the CMO role, of the huge organization that's Dell Technologies. Big brand challenge, a great opportunity for you personally. So my final question, as always on theCUBE, What are your priories for next year? When we come back, and look back... what are you trying to do this year? You've got a lot going on, give us the plan. >> I mean, I'll leave the Dell Technologies thing to Michael, he's probably talked about that already. But marketing specifically, look, 70% of the content on the internet is going to be video by 2020. So, as a marketer, we've got to get really great at producing really high quality video content. It's the way that marketing's going to be done. So the nice thing, the exciting thing for the marketing team is, hey, if you're great at doing PowerPoint or writing a white paper, you're going to be a media star in the future. But I'm a huge believer in the fact that we've got to get great at doing unique content, at scale, and that's how you cut through the noise and get people's attention, because the world is going to become more noisy, not less. So that's one of the big priorities, obviously there's a little bit of bedding in of this new marketing model, we only closed the deal back in September. We got to get the team- >> You got to big budget, that's for sure. >> Yeah but video, and storytelling, is huge. Up there, that's the biggest trend. >> And don't forget the gaming. You brought up the gaming. CGI is coming around the corner, we're going to have VR, AR... >> You're going to see a lot of that. >> Jeremy Burton, Chief Marketing Officer of Dell Technologies. Dell EMC, here on theCUBE. Here at the first Dell EMC World 2017. I'm John Furrier, Peter Burris will be back with more live coverage, stay with us. (techno music)

>> Narrator: Live from Las Vegas. It's the CUBE. Covering NAB 2017, brought to you by HGST. >> Welcome back to the CUBE live in Las Vegas at the NAB show. We're having a great day so far. Very excited to introduce you to my next guest, Kevin Baillie, cofounder and VFX supervisor at Atomic Fiction and the CEO of Conductor Technologies. Never a boring day for you with those two titles, I can imagine. >> No, I like to joke that I like to make sure that I always have the most exciting job in the world so I had to pick three to make sure that I never have a down moment spoil that, that day >> Wow, I am impressed. So you just spoke at the virtual NAB conference last month on the visual effects in the cloud, power, and control. Something that I found very interesting was that six years ago, you were kind of on an island going "I have this hunch about cloud." Tell us about, what was that hunch, why did you have it, and what has it generated so far? >> Yeah, yeah, that's a great question. The hunch was less of like, "Hey cloud looks like a great opportunity." It was more of like knowing what wasn't working in the industry as it was at that time. There were all kinds of companies that were kind of like having financial troubles or having a hard time delivering projects, tons of bankruptcies and just really sad stories everywhere. And we looked at the market and said, "There's a ton of work here, this doesn't make sense." Some of the best entertainment is being made right now and it all relies on visual effects, what's wrong? And the further we broke down the problem, the more we realized that like fixed infrastructure within a market that naturally ebbs and flows, it just didn't, there wasn't a match there. So, through that problem, we looked for solutions and cloud was a very obvious one at that point. So we just made the jump. >> And tell us about Atomic Fiction versus Conductor Technologies. Chicken, egg, which one came first? And how are they collaborating together? >> Atomic Fiction came first. It was almost seven years ago at this point that we started Atomic. And we looked for any kind of a way to use cloud. We started using an AWS directly, we then used a tool called Zync. And as we grew, we found that the needs of the company were changing so radically that nothing that was out there could actually keep up with our pace of growth. We had all this customized pipeline that we couldn't find a way to like get it into the cloud. So we built our own and that was called Conductor. And after, I think we were working on like Game of Thrones and The Walk and had just started on Deadpool that we realized it was working so well that we decided to spin it off as it's own company and make a go for actually turning it into a product that could help everybody in the same way that the cloud had helped Atomic Fiction. >> Fantastic, one of my favorite movies is The Walk. I was looking at your website and you think as the viewer, "How did they film this?" You know, this day and age, so much is CGI. Talk to us about what realtime cloud rendering is. How does it enable a movie like The Walk or Deadpool to have that awe inspiring, jaw dropping reaction from the audience? >> Well I think a large portion of bringing that jaw dropping reaction to the audience and that level of realism is being able to run productions in the way that they want to be run. And what I mean by that is, let's take a movie like The Walk where you have to recreate 1974 New York and the Twin Towers, and all these different lighting scenarios. That means we have to build every building, every rain gutter, every hotdog stand in the street down to exacting detail, and that just takes a lot of time. So we spent a ton of time, probably the first three quarters of the schedule just building the city, building the city. And we couldn't render anything at that point And it wasn't only until the very end of the show that we were able to say, "alright, now we have New York is there, let's just put it on the screen." But that takes millions of hours of computing to get that done. The Walk for example, it used 9.1 million processor hours of rendering. That's over a thousand years on a single processor to get it done. So if we hadn't had the cloud, we would have had to been like, "Oh what can we render first "so we don't bottleneck at the end of the schedule?" And really kind of like trying to bend production into the box that we, of fixed infrastructure that we have. But with the cloud, we don't have to do that. We can say, we can go as big as we want to at the very end of the show and get it done if that's what makes sense for the show. Because that's what makes sense for the show, the creative just ends up being that much better. The same was true for Deadpool, the same is true for Star Trek. These movies, they just sort of, you want to craft love into the beginning part of it so the stuff you generate at the end is as beautiful as it can be. >> So is cloud really freeing production from being able to operate in the way that it needs to operate? >> Yeah, yeah, exactly. Because the traditional model is, a visual effects company builds a data center and stuffs it full of computers. In best case, with like three weeks lead time you can like rent a bunch of racks of computers and like shove them in a closet somewhere and get your project done. It ends up being expensive and painful. You need a big team to man all that stuff. Whereas with cloud, we can say, "Hey, I need a thousand computers three minutes from now." And boom, a thousand computers spin up out of nowhere. And the great thing that we've done with Conductor as well is we've gone and negotiated per minute software licensing with Autodesk and the Foundry and IsoTropic and Chaos Group. All these big software vendors in the industry. So not only can you get compute by the minute, you can also get all the software that you need by the minute, right. So you can have three thousand nodes running Autodesk to Arnold, and you, but you run it for 42 minutes and you only pay for 42 minutes of three thousand licenses of Arnold, right. So it's really transformative from a flexibility standpoint. >> And the cost model really flips it on it's head. >> And by the way, the artists get the result back faster. Because you can scale up so big and get the result back to them so quickly without any cost penalty, they see the fruits of their labor while the ideas are still fresh in their head, which is like a huge, like, intangible benefit which has real economic benefits. >> Absolutely, one of the things and themes that we've heard of today is that speed is key. Absolutely critical to whatever is going to happen or whether or not on a shoot, a vision changes direction. And without having the power of the cloud to facilitate something on a dime, there's delays, which all adds up to economic impact. >> Yeah, and you know, back on one of our earliest projects rendered in the cloud, Flight. The Robert Zemeckis movie with Denzel Washington. That exact thing happened, where it was like at the very end, he, Zemeckis realized that he needed this extra set of like a hundred visual effects shots. And if it hadn't have been for the cloud, we would have had to say, "No, sorry we can't do these." "We have to find somebody else to do them." But because the ability of the cloud to accommodate that last minute creative epiphany, we were able to actually do the work. So it really is truly transformative and allowed us to bring in, you know, hundreds of thousands of dollars of extra revenue that we wouldn't have been able to do otherwise. >> Absolutely. In terms of some of the public cloud providers, tell us who you're working with on that end. >> Yeah, so we're working with Google right now, using Google Compute Engine on the back end. And we're actually moving forward with Microsoft and Azure. Adding it as an option later in the year. So, hopefully at the end of the year, we'll be able to support all the large cloud providers. And be able to say, "Hey, Studio X. "We know you have an affinity for Google right now, "but on the next project maybe you need "a very specific GPU type." Or there's a company in China that needs to do some work and Google isn't there. Now Azure is your thing, right. So, I think that the world of cloud providers competing against one another is going to be really beneficial for everyone in our industry for sure. And we want to be there to facilitate a little bit of like, choose whoever's best, right. >> Right, giving you the ability to really be like agnostic on the back end. >> Yeah that's exactly right. >> So as we look at these massive resources that studios are generating, creating such interactive films, what are some of the precautions that you see and you can help them mitigate against leveraging the power of cloud. >> Well, one of the benefits of cloud is you only have to pay for what you use, just like electricity, right. One of the downsides of cloud is you have to pay for what you use, right. So, if you're not careful about the render you put in the cloud or the simulation you put in the cloud, or how long you keep data in the cloud, things can get really expensive really quickly. So, one of the things we did, and this is actually why we kind of spun Conductor off as it's own company. And we just raised our Series A round of funding back in December to build the team out, because a lot of this stuff is really complicated, is one of the big efforts, in kind of a post funding world for Conductor, is on analytics and being able to use data to help people drive production better. So you know, in the very beginning, we have cost limits where you can say, "On this shot, I don't want to spend "more than a thousand dollars." Or, "I never want this artist to be able to spend "more than fifteen hundred bucks a day." But in the future, I think that there is kind of like cloud buzz-wordy things that actually come into real play here where we can use machine learning to detect when things are taking too long and alert people. We can tell people how much a render is going to cost before they even submit it maybe. We can use computer vision to check for bad things happening in the middle of a render before a human ever has a chance to lay eyes on it. So there's all kinds of stuff we can do with data to help mitigate some of the downsides of cloud and hopefully only leave people with like great insights to help them run production better. >> That's fantastic. One of the things that really interests me is the machine learning and the artificial intelligence. To be able to look at whether it's a broadcast outlet or a film studio, to be able to take a look at and evaluate the value and additional revenue streams that can come. But also, in your case, maybe even leveraging AI and machine learning to make certain processes faster thereby lowering costs. >> Yeah, we can actually make proactive suggestions based on, like, you know, thousands or millions of data points and say like, "Hey if you tweak this value on your shading rate here, "you're going to end up with a great visual "and not spend any more time, or actually spend less." So things like that and then also working together with production management systems. Like the guys at Autodesk have a product called Shotgun that deals with schedules and artist assignments. And they can have all the schedule information. We have all the sort of infrastructure information. If we correlate those two data sets together, then we'll be able to actually proactively tell somebody when we think a shot is running behind schedule. Or a shot needs more optimization. And I mean, there's all kinds of things that we can use just purely using data and a trained machine learning model to actually help people run their entire business better, not just an individual shot. >> Right, well, six years ago, when you had this hunch, you said there were some skeptics around there. One, you must feel pretty validated by now, but are you kind of one of the go-to guys, go-to companies of this is how to do it properly? These are all of the advantages, economic advantages, etc, that we can provide? >> Yeah, I think that there were definitely people that told me I was absolutely crazy when I first got started. Some of them are actually using Conductor now, so that's kind of like good. >> That must feel good right? >> Yeah, it's a good validation point and they had a lot of reasons for thinking that we were insane, cause we kind of were. But we just sort of believed deep down that it was going to work. So, yeah, I mean now, I think we're in a great position to help people. And for me, and you know, this is always like a thing that I sometimes get a hard time for, but I'm so passionate about this industry moving into the cloud that I'm just as happy to talk to somebody about how to do it maybe on their own if they're trying to do it on a small scale. Or what our competitors might be doing. Really, through that, I've kind of, we've found a space where we don't really have any competitors yet and we're breaking new ground. Really servicing the sort of medium and enterprise scale customers, and that kind of flexibility and scale and security that they kind of need. So it's sort of interesting in this, in a way, this sort of like selfless, just being excited about cloud has helped us to find a market that we can really and truly add insane value to. >> Wow, that is fascinating. Well, your passion for it is evident. Thank you so much Kevin for joining us on the CUBE. >> Yeah, thank you so much. >> Have a great time at the rest of the show and we'll see you on the CUBE sometimes soon. >> I always do, thank you again. >> Excellent, we want to thank you for watching. Again, we are live at NAB Las Vegas. Stick around. We will be right back.

>> Announcer: Live from San Jose, California, it's the CUBE, covering Big Data Silicon Valley 2017. (upbeat synthesizer music) >> Live with the CUBE coverage of Big Data Silicon Valley or Big Data SV, #BigDataSV in conjunction with Strata + Hadoop. I'm John Furrier with the CUBE and my co-host George Gilbert, analyst at Wikibon. I'm excited to have our next guest, Yaron Haviv, who's the founder and CTO of iguazio, just wrote a post up on SiliconANGLE, check it out. Welcome to the CUBE. >> Thanks, John. >> Great to see you. You're in a guest blog this week on SiliconANGLE, and always great on Twitter, cause Dave Alante always liked to bring you into the contentious conversations. >> Yaron: I like the controversial ones, yes. (laughter) >> And you add a lot of good color on that. So let's just get right into it. So your company's doing some really innovative things. We were just talking before we came on camera here, about some of the amazing performance improvements you guys have on many different levels. But first take a step back, and let's talk about what this continuous analytics platform is, because it's unique, it's different, and it's got impact. Take a minute to explain. >> Sure, so first a few words on iguazio. We're developing a data platform which is unified, so basically it can ingest data through many different APIs, and it's more like a cloud service. It is for on-prem and edge locations and co-location, but it's managed more like a cloud platform so very similar experience to Amazon. >> John: It's software? >> It's software. We do integrate a lot with hardware in order to achieve our performance, which is really about 10 to 100 times faster than what exists today. We've talked to a lot of customers and what we really want to focus with customers in solving business problems, Because I think a lot of the Hadoop camp started with more solving IT problems. So IT is going kicking tires, and eventually failing based on your statistics and Gardner statistics. So what we really wanted to solve is big business problems. We figured out that this notion of pipeline architecture, where you ingest data, and then curate it, and fix it, et cetera, which was very good for the early days of Hadoop, if you think about how Hadoop started, was page ranking from Google. There was no time sensitivity. You could take days to calculate it and recalibrate your search engine. Based on new research, everyone is now looking for real time insights. So there is sensory data from (mumbles), there's stock data from exchanges, there is fraud data from banks, and you need to act very quickly. So this notion of and I can give you examples from customers, this notion of taking data, creating Parquet file and log files, and storing them in S3 and then taking Redshift and analyzing them, and then maybe a few hours later having an insight, this is not going to work. And what you need to fix is, you have to put some structure into the data. Because if you need to update a single record, you cannot just create a huge file of 10 gigabyte and then analyze it. So what we did is, basically, a mechanism where you ingest data. As you ingest the data, you can run multiple different processes on the same thing. And you can also serve the data immediately, okay? And two examples that we demonstrate here in the show, one is video surveillance, very nice movie-style example, that you, basically, ingest pictures for S3 API, for object API, you analyze the picture to detect faces, to detect scenery, to extract geolocation from pictures and all that, all those through different processes. TensorFlow doing one, serverless functions that we have, do other simpler tasks. And in the same time, you can have dashboards that just show everything. And you can have Spark, that basically does queries of where was this guys last seen? Or who was he with, you know, or think about the Boston Bomber example. You could just do it in real time. Because you don't need this notion of pipeline. And this solves very hard business problems for some of the customers we work with. >> So that's the key innovation, there's no pipe lining. And what's the secret sauce? >> So first, our system does about a couple of million of transactions per second. And we are a multi-modal database. So, basically, you can ingest data as a stream, exactly the same data could be read by Spark as a table. So you could, basically, issue a query on the same data. Give me everything that has a certain pattern or something, and could also be served immediately through RESTful APIs to a dashboard running AngularJS or something like that. So that's the secret sauce, is by having this integration, and this unique data model, it allows you all those things to work together. There are other aspects, like we have transactional semantics. One of the challenges is how do you make sure that a bunch of processes don't collide when they update the same data. So first you need a very low ground alert. 'cause each one may update to different field. Like this example that I gave with GeoData, the serverless function that does the GeoData extraction only updates the GeoData fields within the records. And maybe TensorFlow updates information about the image in a different location in the record or, potentially, a different record. So you have to have that, along with transaction safety, along with security. We have very tight security at the field level, identity level. So that's re-thinking the entire architecture. And I think what many of the companies you'll see at the show, they'll say, okay, Hadoop is given, let's build some sort of convenience tools around it, let's do some scripting, let's do automation. But serve the underlying thing, I won't use dirty words, but is not well-equipped to the new challenges of real time. We basically restructured everything, we took the notions of cloud-native architectures, we took the notions of Flash and latest Flash technologies, a lot of parallelism on CPUs. We didn't take anything for granted on the underlying architecture. >> So when you found the company, take a personal story here. What was the itch you were scratching, why did you get into this? Obviously, you have a huge tech advantage, which is, will double-down with the research piece and George will have some questions. What got you going with the company? You got a unique approach, people would love to do away with the pipeline, that sounds great. And the performance, you said about 100x. So how did you get here? (laughs) Tell the story. >> So if you know my background, I ran all the data center activities in Mellanox, and you know Mellanox, I know Kevin was here. And my role was to take Mellanox technology, which is 100 gig networking and silicon, and fit it into the different applications. So I worked with SAP HANA, I worked with Teradata, I worked on Oracle Exadata, I work with all the cloud service providers on building their own object storage and NoSQL and other solutions. I also owned all the open source activities around Hadoop and Saf and all those projects, and my role was to fix many of those. If a customer says I don't need 100 gig, it's too fast for me, how do I? And my role was to convince him that yes, I can open up all the bottleneck all the way up to your stack so you can leverage those new technologies. And for that we basically sowed inefficiencies in those stacks. >> So you had a good purview of the marketplace. >> Yaron: Yes. >> You had open source on one hand, and then all the-- >> All the storage players, >> vendors, network. >> all the database players and all the cloud service providers were my customers. So you're a very unique point where you see the trajectory of cloud. Doing things totally different, and sometimes I see the trajectory of enterprise storage, SAN, NAS, you know, all Flash, all that, legacy technologies where cloud providers are all about object, key value, NoSQL. And you're trying to convince those guys that maybe they were going the wrong way. But it's pretty hard. >> Are they going the wrong way? >> I think they are going the wrong way. Everyone, for example, is running to do NVMe over Fabric now that's the new fashion. Okay, I did the first implementation of NVMe over Fabric, in my team at Mellanox. And I really loved it, at that time, but databases cannot run on top of storage area networks. Because there are serialization problems. Okay, if you use a storage area network, that mean that every node in the cluster have to go and serialize an operation against the shared media. And that's not how Google and Amazon works. >> There's a lot more databases out there too, and a lot more data sources. You've got the Edge. >> Yeah, but all the new databases, all the modern databases, they basically shared the data across the different nodes so there are no serialization problems. So that's why Oracle doesn't scale, or scale to 10 nodes at best, with a lot of RDMA as a back plane, to allow that. And that's why Amazon can scale to a thousand nodes, or Google-- >> That's the horizontally-scalable piece that's happening. >> Yeah, because, basically, the distribution has to move into the higher layers of the data, and not the lower layers of the data. And that's really the trajectory where the traditional legacy storage and system vendors are going, and we sort of followed the way the cloud guys went, just with our knowledge of the infrastructure, we sort of did it better than what the cloud guys did. 'Cause the cloud guys focused more on the higher levels of the implementation, the algorithms, the Paxos, and all that. Their implementation is not that efficient. And we did both sides extremely efficient. >> How about the Edge? 'Cause Edge is now part of cloud, and you got cloud has got the compute, all the benefits, you were saying, and still they have their own consumption opportunities and challenges that everyone else does. But Edge is now exploding. The combination of those things coming together, at the intersection of that is deep learning, machine learning, which is powering the AI hype. So how is the Edge factoring into your plan and overall architectures for the cloud? >> Yeah, so I wrote a bunch of posts that are not published yet about the Edge, But my analysis along with your analysis and Pierre Levin's analysis, is that cloud have to start distribute more. Because if you're looking at the trends. Five gig, 5G Wi-Fi in wireless networking is going to be gigabit traffic. Gigabit to the homes, they're going to buy Google, 70 bucks a month. It's going to push a lot more bend with the Edge. On the same time, a cloud provider, is in order to lower costs and deal with energy problems they're going to rural areas. The traditional way we solve cloud problems was to put CDNs, so every time you download a picture or video, you got to a CDN. When you go to Netflix, you don't really go to Amazon, you got to a Netflix pop, one of 250 locations. The new work loads are different because they're no longer pictures that need to be cashed. First, there are a lot of data going up. Sensory data, upload files, et cetera. Data is becoming a lot more structured. Censored data is structured. All this car information will be structured. And you want to (mumbles) digest or summarize the data. So you need technologies like machine learning, NNI and all those things. You need something which is like CDNs. Just mini version of cloud that sits somewhere in between the Edge and the cloud. And this is our approach. And now because we can string grab the mini cloud, the mini Amazon in a way more dense approach, then this is a play that we're going to take. We have a very good partnership with Equinox. Which has 170 something locations with very good relations. >> So you're, essentially, going to disrupt the CDN. It's something that I've been writing about and tweeting about. CDNs were based on the old Yahoo days. Cashing images, you mentioned, give me 1999 back, please. That's old school, today's standards. So it's a whole new architecture because of how things are stored. >> You have to be a lot more distributive. >> What is the architecture? >> In our innovation, we have two layers of innovation. One is on the lower layers of, we, actually, have three main innovations. One is on the lower layers of what we discussed. The other one is the security layer, where we classify everything. Layer seven at 100 gig graphic rates. And the third one is all this notion of distributed system. We can, actually, run multiple systems in multiple locations and manage them as one logical entity through high level semantics, high level policies. >> Okay, so when we take the CUBE global, we're going to have you guys on every pop. This is a legit question. >> No it's going to take time for us. We're not going to do everything in one day and we're starting with the local problems. >> Yeah but this is digital transmissions. Stay with me for a second. Stay with this scenario. So video like Netflix is, pretty much, one dimension, it's video. They use CDNs now but when you start thinking in different content types. So, I'm going to have a video with, maybe, just CGI overlayed or social graph data coming in from tweets at the same time with Instagram pictures. I might be accessing multiple data everywhere to watch a movie or something. That would require beyond a CDN thinking. >> And you have to run continuous analytics because it can not afford batch. It can not afford a pipeline. Because you ingest picture data, you may need to add some subtext with the data and feed it, directly, to the consumer. So you have to move to those two elements of moving more stuff into the Edge and running into continuous analytics versus a batch on pipeline. >> So you think, based on that scenario I just said, that there's going to be an opportunity for somebody to take over the media landscape for sure? >> Yeah, I think if you're also looking at the statistics. I seen a nice article. I told George about it. That analyzing the Intel cheap distribution. What you see is that there is a 30% growth on Intel's cheap Intel Cloud which is faster than what most analysts anticipate in terms of cloud growth. That means, actually, that cloud is going to cannibalize Enterprise faster than what most think. Enterprise is shrinking about 7%. There is another place which is growing. It's Telcos. It's not growing like cloud but part of it is because of this move towards the Edge and the move of Telcos buying white boxes. >> And 5G and access over the top too. >> Yeah but that's server chips. >> Okay. >> There's going to be more and more computation in the different Telco locations. >> John: Oh you're talking about computer, okay. >> This is an opportunity that we can capitalize on if we run fast enough. >> It sounds as though because you've implemented these industry standard APIs that come from the, largely, the open source ecosystem, that you can propagate those to areas on the network that the vendors, who are behind those APIs can't, necessarily, do. Into the Telcos, towards the Edge. And, I assume, part of that is cause of the density and the simplicity. So, essentially, your footprint's smaller in terms of hardware and the operational simplicity is greater. Is that a fair assessment? >> Yes and also, we support a lot of Amazon compatible APIs which are RESTful, typically, HTTP based. Very convenient to work with in a cloud environment. Another thing is, because we're taking all the state on ourself, the different forms of states whether it's a message queue or a table or an object, et cetera, that makes the computation layer very simple. So one of the things that we are, also, demonstrating is the integration we have with Kubernetes that, basically, now simplifies Kubernetes. Cause you don't have to build all those different data services for cloud native infrastructure. You just run Kubernetes. We're the volume driver, we're the database, we're the message queues, we're everything underneath Kubernetes and then, you just run Spark or TensorFlow or a serverless function as a Kubernetes micro service. That allows you now, elastically, to increase the number of Spark jobs that you need or, maybe, you have another tenant. You just spun a Spark job. YARN has some of those attributes but YARN is very limited, very confined to the Hadoop Ecosystem. TensorFlow is not a Hadoop player and a bunch of those new tools are not in Hadoop players and everyone is now adopting a new way of doing streaming and they just call it serverless. serverless and streaming are very similar technologies. The advantage of serverless is all this pre-packaging and all this automation of the CICD. The continuous integration, the continuous development. So we're thinking, in order to simplify the developer in an operation aspects, we're trying to integrate more and more with cloud native approach around CICD and integration with Kubernetes and cloud native technologies. >> Would it be fair to say that from a developer or admin point of view, you're pushing out from the cloud towards the Edge faster than if the existing implementations say, the Apache Ecosystem or the AWS Ecosystem where AWS has something on the edge. I forgot whether it's Snowball or Green Grass or whatever. Where they at least get the lambda function. >> They're field by the way and it's interesting to see. One of the things they allowed lambda functions in their CDS which is going the direction I mentioned just for a minimal functionality. Another thing is they have those boxes where they have a single VM and they can run lambda function as well. But I think their ability to run computation is very limited and also, their focus is on shipping the boxes through mail and we want it to be always connected. >> Our final question for you, just to get your thoughts. Great save up, by the way. This is very informative. Maybe be should do a follow up on Skype in our studio for Silocon Friday show. Google Next was interesting. They're serious about the Enterprise but you can see that they're not yet there. What is the Enterprise readiness from your perspective? Cause Google has the tech and they try to flaunt the tech. We're great, we're Google, look at us, therefore, you should buy us. It's not that easy in the Enterprise. How would you size up the different players? Because they're all not like Amazon although Amazon is winning. You got Amazon, Azure and Google. Your thoughts on the cloud players. >> The way we attack Enterprise, we don't attack it from an Enterprise perspective or IT perspective, we take it from a business use case perspective. Especially, because we're small and we have to run fast. You need to identify a real critical business problem. We're working with stock exchanges and they have a lot of issues around monitoring the daily trade activities in real time. If you compare what we do with them on this continuous analytics notion to how they work with Excel's and Hadoops, it's totally different and now, they could do things which are way different. I think that one of the things that Hadook's customer, if Google wants to succeed against Amazon, they have to find the way of how to approach those business owners and say here's a problem Mr. Customer, here's a business challenge, here's what I'm going to solve. If they're just going to say, you know what? My VM's are cheaper than Amazon, it's not going to be a-- >> Also, they're doing the whole, they're calling lift and shift which is code word for rip and replace in the Enterprise. So that's, essentially, I guess, a good opportunity if you can get people to do that but not everyone's ripping and replacing and lifting and shifting. >> But a lot of Google advantages around areas of AI and things like that. So they should try and leverage, if you think about Amazon approach to AI, this fund the university to build a project and then set it's hours where Google created TensorFlow and created a lot of other IPs and Dataflow and all those solutions and consumered it to the community. I really love Google's approach of contributing Kubernetes, to contributing TensorFlow. And this way, they're planting the seeds so the new generation this is going to work with Kubernetes and TensorFlow who are going to say, "You know what?" "Why would I mess with this thing on (mumbles) just go and. >> Regular cloud, do multi-cloud. >> Right to the cloud. But I think a lot of criticism about Google is that they're too research oriented. They don't know how to monetize and approach the-- >> Enterprise is just a whole different drum beat and I think that's the only thing on my complaint with them, they got to get that knowledge and/or buy companies. Have a quick final point on Spanner or any analysis of Spanner that went from paper, pretty quickly, from paper to product. >> So before we started iguazio, I started Spanner quite a bit. All the publication was there and all the other things like Spanner. Spanner has the underlying layer called Colossus. And our data layer is very similar to how Colossus works. So we're very familiar. We took a lot of concepts from Spanner on our platform. >> And you like Spanner, it's legit? >> Yes, again. >> Cause you copied it. (laughs) >> Yaron: We haven't copied-- >> You borrowed some best practices. >> I think I cited about 300 research papers before we did the architecture. But we, basically, took the best of each one of them. Cause there's still a lot of issues. Most of those technologies, by the way, are designed for mechanical disks and we can talk about it in a different-- >> And you have Flash. Alright, Yaron, we have gone over here. Great segment. We're here, live in Silicon Valley, breakin it down, getting under the hood. Looking a 10X, 100X performance advantages. Keep an eye on iguazio, they're looking like they got some great products. Check them out. This is the CUBE. I'm John Furrier with George Gilbert. We'll be back with more after this short break. (upbeat synthesizer music)

>> Narrator: Live from Austin, Texas, it's The Cube covering South by Southwest 2017, brought to you by Intel. Now, here's John Furrier. >> Hey, welcome everyone back for day two of live coverage of South by Southwest. This is the cube, our flagship program from Silicon Angle. We go out to the events and extract the (mumbles). We're at the Intel AI Lounge, people are rolling in, it's an amazing vibe here, South by Southwest. The themes are AI, virtual reality, augmented reality, technology. They got great booths here, free beers, free drinks, and of course great sessions and great conversations here with the Cube. My first guest of the day here is Ben Parr, a friend of the Cube. He's been an entrepreneur, he's been a social media maven, he's been a journalist, all around great guy. Ben, thanks for joining us today. >> Thank you for having me again. >> So you're a veteran with South by Southwest, you know the social scene, you've seen the evolution from Web 2.0 all the way to today, had Scobel on yesterday, Brian Fanzo, really the vibe is all about that next level, of social to connecting and you got a startup you're working on that you founded, co-founded called AI? >> Ben: Octane AI. >> Octane AI, that's in the heart of this new social fabric that's developing. Where AI is starting to do stuff, keep learning, analytics but, ultimately, it's just a connection. Talk about your company. What is Octane AI? Tell us a little bit about the company. >> So Octane AI is a platform that lets you build an audience on Facebook Messenger and then through a bot. And so, what we do is allow you to create a presence on Messenger because if I told you there was a social app that had a billion users every month, bigger than Snapchat plus Twitter plus Instagram combined you'd want to figure out a strategy for how to engage with those people right? And that social app is Facebook Messenger. And yet no one ever thinks, oh could I build an audience on a messaging app? Could I build an audience on Messenger or WeChat or any of the others. But you can through a bot. And you can not just build an audience but you can create really engaging content through conversation. So what we've done is, we've made it really easy to make a bot on messenger but more importantly, a real reason for people to, actually, come to your bot and engage with it and make it really easy to create content for it. In the same way you create content for a blog or create content for YouTube Channel. Maroon 5, Aerosmith, KISS, Lindsay Lohan, 30 seconds to MARS, Jason Derulo and a whole bunch more use us to build an audience and engage their fans on Messenger. >> So let me get your thoughts on a couple of trends around this. Cause this is really kind of, to me, a key part that chat bots illustrate the big trends that are going on. Chat bots were the hype. People were talking about, oh chat bots. It's a good mental model for people to see AI but it also has been, kind of, I won't say a pest, if you will, for users. It's been like a notification. A notification of the economy we're living in. Now you're taking it to the next level. This is what we're seeing. The deep learnings and the analytics around turning notifications which can be noisy after a while, into real content and connections. >> Into something useful, absolutely. Like look, the last year of bots. The Facebook platform is not even a year old. We've been in that fart apps stage of bots. Remember the first year of mobile apps? You had the fart app and that made $50,000 a day and that was annoying as hell. We're at that stage now, the experimentation stage. And we've seen different companies going in different, really cool directions. Our direction is, how do you create compelling content so you're not spamming people but you have content that you can share, not just in your bot but as a link on your social media to your followers, to your fans, on Twitter, everywhere else and have a scalable conversation about whatever you want. Maroon 5 has conversations with their audience about their upcoming tours or they even released an exclusive preview of their new song, Cold, through our bots. You could do almost anything with our bots or with any bot. We're just learning right now, as an industry, what are the best practices. >> So where do bots go for the next level? Because you and I have known each other for almost over 10 years, we've seen the whole movement and now we're living in a fake news era. But social media is evolving where content now is super important that glues people together, communities together. In a way, you're taking AI or bots, if you will. Which is a first, I mean, .5 version of where AI is going. Where content, now, is being blended into notifications. How important is content in community? >> Content in community are essential to any product. And I feel like when you hear the word bot, you don't think community and that you could build a community with it because it's a bot, it's supposed to be automated. But you, actually, can if you do it in the right way and it can be a very, very powerful experience. We're building features that allow you to build more community in your bot and have people who are talking with your bot communicate with each other. There's a lot of that. What I feel like is, we're at the zero point one or zero point two of the long scale of AI. What we need to do right now is showcase all the use cases that really work for AI, bots, machine learning. Over time, we will be adding more other great technologies from Intel and others that will make all these technologies and everything we do better, more social and most of all, more personalized. I think that's one of the big benefits of AI. >> Do you see bot technology or what bots can turn into being embedded into things like autonomous vehicles, AR, is there a stack developing, if you will, around bots? What you're talking about is a progression of bots. What's your vision on where this goes down the road? >> I see a bunch of companies, now, building the technological stack for AI. I see a bunch of companies building the consumer interface, bots is one of those consumer interfaces. Not just chat bots but voice bots. And then I see another layer that's more enterprise that's helping make more efficient things like recruiting or all sorts of automation or driving. That are being built as well. But you need each of those stacks to work really well to make this all work. >> So are there bots here at South by Southwest? Is there a bot explosion, is there bots that tell you where the best parties are? What's the scene here at Southby? Where are the bots and if there were bots, what would they be doing to help people figure out what to do? >> The Southby bot is, actually, not a bad bot. They launched their bot just before South by Southwest. It has a good party recommendations and things. But it the standard bot. I feel like what we're seeing is the best use, there's a lot of good bot people. What I'm seeing right now is that people are still flushing out the best use cases for their bots. There's no bot yet that can predict all the parties you want to go to. We got to have our expectations set. That will happen but we're still a few years away from really deep AI bots. But there are clearly ones where you can communicate faster with your friends. There's clearly ones that help you connect with your favorite artist. There's clearly ones that help you build an audience and communicate at scale. And I feel like the next step is the usefulness. >> Talk about the user interface. Robert Scobel and I were talking yesterday, we have some guests coming on today that had user experience background. With AI, with virtual reality, with bots, with deep learning, all this collective intelligence going on, what's your vision of the user interface as it changes, as people's expectations? What are some of those things that you might see developing pretty quickly as deep learning, analytics, more data stats come online? What is the user interface? Cause bots will intersect with that as an assistant or a value add for the user. What's your vision on? >> I'll tell you what I see in the near term and then I'll tell you a really crazy idea of how I see the long term. In the near term, I think what you're going to see is bots have become more predictive. That, based on your conversations, are more personalized and maybe not a necessarily need as much input from you to be really intelligent. And so voice, text, standard interfaces that we're used to. I think the bigger, longer run is neurological. Is the ability to interface without having to speak. Is AI as a companion to help us in everything we do. I feel like, in 30 years, we won't even, it's, kind of like, do your remember the world when it had no internet? It's hard, it feels so much different. There will be a point in about 20 years we will not understand what the world was before AI. Before AI assistance where assisting us mentally, automatically and through every interface. And so good AI's, in the long run, don't just run on one bot or one thing, they follow you wherever you go. Right now it might be on your phone. When you get home, it may be on your home, it may be in your car but it should be the same sets of AI's that you use daily. >> Doctor Nevine Rou, yesterday, called the AI the bulldozer for data. What bulldozers where in the real world, AI's going to do that for data. Cause you want to service more data and make things more usable for users. >> Yes, the data really helps AI become more personalized and that's a really big benefit to the user to every individual. The more personalized the experience, the less you have to do. >> Alright, so what's the most amazing thing you've seen so far this year at Southby? What's going on out there that's pretty amazing? That's popping out of the wood work? In terms of either trend, content, product, demos, what are some of the cool things you're seeing. >> So, as it is only Saturday, I feel like the coolest thing will still come to me. But outside of AI, there have been some really cool mixed reality, augmented reality demos. I can't remember the name. There's a product with butterflies flying around me. All sorts of really breaking edge technologies that, really, create another new interface honestly where AI may interact with us through the augmented reality of our world. I mean, that's Robert Scogul's thing exactly. But there's a lot of really cool things that are being built on that front. I think those are the obvious, coolest ones. I'm curious to see which ones are going to be the big winners. >> Okay, so I want to ask you a personal question. So you were doing some venture investing around AI and some other things. What caused you to put that pause button on that mission to start the chat bot AI company? >> So I was an investor for a couple of years. I invested in ubean, the wireless electricity company and Shots with Justin Bieber which is always fun. And I love investing and I love working with companies. But I got into Silicone Valley and I got into startups because I wanted to build companies. I wanted to build ideas. This happened, in part, because of my co-founders. My co-founder Matt, who is the first head of product at Ustream and twice into the Forbes 30 under 30. One of the king makers of the bot industry. The opportunity to be a part of building the future of AI was irresistible to me. I needed to be a part of that. >> Okay, can you tell any stories about Justin Bieber for us, while we're here inside the Cube? (laughs) >> I wonder how many of those I can, actually, tell? Okay, so look. Justin Bieber is an investor in a company I'm an investor in called Shots. Which is now a super studio that represents everyone from Lele Pons to Mike Tyson on digital online and they're doing really, really well. One of Justin's best friends is the founder, John Shahidi. And so it's just really random. Sitting with John, who I invested in and just getting random FaceTime's. Be like, oh it's Justin Bieber, say hi to Justin. As if it was nothing. As if it was a normal, it's a normal day in his life. >> Could you just have him retweet one of my Tweets. He's got like a zillion followers. What's his follower count at now? >> You don't want that. He's done that to me before. When Justin retweets you or even John retweets you, thousands of not tens of thousands of Justin Bieber fans, bots and not bots, start messaging you, asking you to follow them, talking to you all the time. I still get the tweets all the time from all the Justin fans. >> Okay don't tweet me then. I'm nice and happy with 21,000 followers. Alright, so next level for you in terms of this venture. Obviously, they got some rock stars in there. What's the next step for you guys right now? Give us a little inside baseball in the venture status where you guys are at. What's the next step? >> We launched the company publicly in November, we started in May. We raised 1.6 million from general catalyst, from Sherpa Ventures, a couple of others. When we launched our new feature, Convos, which allows you to create shareable bots, shareable conversations with the way you share blog posts. And that came out with all those launch partners I mentioned before like Maroon 5. We're working on perfecting the experience and, mostly, trying to make a really, really compelling experience with the user with bots because if we can't do that, then there's no use to doing anything. >> So you provide the octane for the explosive conversations? (laughs) >> Yes, there you go, thank you, thank you. And we make it really easy. So we're just trying to make it easier to do this. This is a product that your mom could use, that an artist could use, any social media team could use. Writing a convo is like writing a blog post on media. >> Are moms really getting the chat bot scene? I, honestly, get the Hollywood. I'm going to go back to Hollywood in a second but being a general, middle America kind of tech/genre, what are they like? Are they grokking the whole bot thing? What's the feedback from middle America tech? >> But think of it this way. There are a billion people on Messenger and it's a, really, part of the question, they all use Facebook Messenger. And so, they may be communicating with a bot without knowing it. Or they might want to communicate with their fans. It's not about the technology as much as this is like connecting with who you really care about. If I really care about a Maroon 5 or Rachel Ray, I can now have that option. And it doesn't really matter what the technology is as much as it is that personal connection, that experience is good. >> John: Is it one-one-one or group? Cause it sounds like it's town hall, perfect for a town hall situation. >> It's one-on-one, it's scale. So you could have a conversation with a bot while each of the audience members is having a conversation one-on-one. When you can choose different options and it could be a different conversation for each person. >> Alright, so I got to ask about the Hollywood scene. You mentioned Justin Bieber. I wanted to go down that because Hollywood really has adopted social media pretty heavily because they can go direct to the audience. We're seeing that. Obviously, with the election, Trump was on Twitter. He bypasses all the press but Hollywood has done very well with social. How are they using the bots? They are a tell sign of where it's going. Can you share some antidotal stories or data around how Maroon 5, Justin, these guys are leveraging this and what's some of the impact? >> Sure, so about a month 1/2, 2 months before Maroon 5 launched their new song, new single, Cold. They came to us and wanted to build a distribution. They wanted to reach their audience in a more direct personal way. And so we helped them make a bot. It didn't take long. We helped them write convos. And so what they did was they wrote convos about things like exclusive behind the scenes photos from their recent tour or their top moments of 2016 or things that their fans really care about. And they shared em. They got a URL just like you would get, a blog poster URL. They shared it out with their 39 million Facebook fans, they shared it with their Twitter followers, they shared it across their social media. And 10's of thousand's of people started talking with their bot each time they did this. About 24 hours before the bot, before their new single release, they exclusively released a 10 second clip of Cold through their bot. And when they did that, within 24 hours, the size of their bot doubled because it went viral within the Maroon 5 community. There's a share function in our convos and people shared the convo with their friends and with their friends friends and it kept on spreading. We saw this viral graph happen. And the next day when they released the single, 1000's of people bought the song because of the bot alone. And now the bot is a core of their social strategy. They share a convo every single week and it's not just them but now Lohan and a whole bunch of others are doing the same thing. >> John: Lindsay Lohan. >> Lindsay Lohan is one of our most popular bots. Her fans are really dedicated. >> And so you can almost see it's, almost connecting with CGI, looking at what CGI's doing in film making. You could almost have a CGI component built-in. So it's all this stuff coming together. >> Ben: Multimedia matters. >> So what do you think about the Intel booth here? The AI experience? They got some Kinetic photo experience, amazing non-profit activities in deep loading (mumbles), missing children, what do you think? >> This is some of the best use cases for AI which is, people think of AI as just like the direct consumer interface which is what we do but AI is an underlying layer to everything we do. And if it can help even 1% or 1,000% identify and find missing children or increase the efficiency of our technology stacks so that we save energy. Or we figure out new ways to save energy. This is where AI can really make an impact. It is just a fundamental layer of everything. In the same way the internet is just a fundamental layer of everything. So I've seen some very cool things here. >> Alright, Ben Parr, great guest, in venture capitalist now founder of a great company Octane AI. High octane, explosive conversations looking forward to adopting. We're going to, definitely, take advantage of the chat bot and maybe we can get some back stage passes to Maroon 5. (laughs) >> (laughs) There will be some fun times in the future, I know it. >> Alright Ben Parr. >> Ben: Justin Bieber. >> Justin Bieber inside the Cube right here and Ben Parr. Thanks for watching. It's the Intel AI Lounge. A lot of great stuff. A lot of great people here. Thanks for joining us. Our next guest will be up after this short break. (lively music)

I[Announcer] Live from Silicon Valley, it's "The Cube." Covering Mobile World Congress 2017. Brought to you by Intel. >> 'Kay welcome back everyone, we are live in Palo Alto for "The Cube" special coverage of Mobile World Congress 2017. We're in our new 4,500 square foot studio, just moved in. We'll be expanding, you'll see a lot more in-studio coverage from "The Cube" as well as our normal going out to the events and extracting. Anyways I'm John Furrier Joining me is Jeff Frick. General manager of "The Cube." But a breakdown, all the action. As you know, we do a lot of data science. We've been watching the grid. We've been on the treadmill all weekend. All last week, digging into the Mobile World Congress. Sentiment, the vibe, the direction, and trying to synthesize all the action. And really kind of bring it all together for everyone here. And of course,we're doing it in Palo Alto. We're going to bring folks in from Silicon Valley that could not have made the trek to Barcelona. We're going to be talking to folks on the phone, who are in Barcelona. You heard from Lynn Comp from Intel. We have Floyd coming up next. CTO and SAP breaking down all the action from their new cloud. And big Apple news. SAP now has a general availability of the iOS native development kit. Which should change the game for SAP. There is tons of smart cities, smart stadiums, you know IOT, autonomous vehicles. So much going on at Mobile World Congress. We're going to break that down every day starting at 8AM. In-studio. And of course, I want to thank Intel for headlining our sponsorship and allowing us to create this great content. With some contributing support from SAP clouds I want to give a shout out, a bit shout out to Intel. Check out their booth. Check out their coverage. And check out their new SAP cloud, that's been renamed from HANA Cloud to SAP cloud. Without their support we wouldn't be able to bring this wall-to-wall great commentary. Jeff so with that aside. We got two days. We've got Laura Cooney coming in. Bob Stefanski managing this bridge between Detroit and Silicon Valley. And all that great stuff. Phones are ringing off the hook here in the studio. Go tweet us by the way at the cube or at ferrier We have Guy Churchwood coming in. We have great content all week. We have entrepreneurs. We have Tom Joyce, a Cube alumni. Who's an executive interviewing for a bunch of CEO positions. Really going to break down the changing aspect of Mobile World Congress. The iPhone's 10 years old. We're seeing now a new step function of disruption. Peter Burris said the most terrible in time. And I even compounded the words by saying and the phones are getting faster. So it's beyond the device. I mean what are you seeing on the grid? When you look at the data out there? >> John a bunch of things as we've been watching the stream of the data that came in and surprised me. First off just a lot of early announcements around Blackberry and Nokia. Who are often not really mentioned as the leaders in the handsets base. Not a place that we cover real extensively. But really kind of, these guys making a move and really taking advantage of the void that Samsung left with some of the Note issues. But what I thought was even more interesting is on our hashtag monitoring tools that IOT and 5G are actually above any of the handset manufacturers. So it really supports a hypothesis that we have that while handsets will be better and there'll be more data enabled by 5G, what 5G's really all about is as an IOT enabler. And really another huge step in the direction of connected devices, autonomous vehicles. We've talked about it. We cover IOT a lot. But I thought that was pretty interesting. >> Well Robo Car's also in there. That's a. >> Well everybody loves a car right. >> Well it's kind of a symbol of the future of the car. Which again ties it all together. >> Right right. The driverless race car, which is pretty interesting. >> Takes sports to a whole other level. >> I thought that was interesting. Another little thing as we watch these digital assistants and these voice assistants John, and I got a couple for Christmas just so I could try them out, is that Motorola announced that they're going to partner with Alexa. And use the Alexa voice system inside of their phones. You know I'm still waiting, I don't know why Siri doesn't have a stand-alone device and really when you use a Google Home versus an Amazon Alexa, very different devices, really different kind of target. So I thought that was an interesting announcement that also came out. But fundamentally it's fun to see the support of IOT and 5G, and really enable this next great wave of distribution, disruption, and opportunity. >> We're going to have Saar Gillia in the studio later today and tomorrow as a guest analyst for us on "The Cube." Of course folks may know Saar from being on "The Cube," he was recently senior vice reporting to Meg Whitman, and built out that teleco service provider, NFV business model for HP. And he's been to Mobile World Congress almost every year. He didn't make it this year, he'll be coming in the studio. And he told me prior to being, extremely vetting him for "The Cube" if you will, to use a Trump term, after extreme vetting of Saar Gillia he really wants to make the point of, and this is going to be critical analysis, kind of poking a hole into the hype, which is he doesn't think that the technology's ready for primetime. And specifically he's going to comment around he doesn't believe that the apps are ready for all this bandwidth. He doesn't think, he thinks that 5G is a solution looking for a problem. And I don't necessarily agree with him, so we'll have a nice commentary. Look for Saar today on "The Cube," at 11:30 he's coming on. It's going to be a little bit of a cage match there with Saar. >> I always go back to the which is the most underrepresented and most impactful law. Which is probably in the short term, in the hype cycle 5G's probably not going to deliver on their promise up to the level of the hype. As we find over and over with these funny things like Bluetooth. Who would ever think Bluetooth would be such an integral part of so many things that we do today? I think over the long term, the mid term, I think the opportunity's giant. >> I meant I think for people to understand 5G, at least the way I always describe it over the weekend, when I was at lacrosse games and soccer games over the weekend, for the folks that aren't in tech, 5G is the holy grail for IOT, mobile cars, and AI. Because what 5G does, it creates that mesh of rf, or rf radio frequency, at a whole other level. You look at the radios that Intel's announcing across their Telco partners, and what Intel's doing really is a game-changer. And we all know LTE, when the signal's low on the phone, everyone freaks out. We all know when WiFi doesn't work, the world kind of comes to a crawl. I mean just think 15 years ago wifi wasn't even around. So now think about the impact of just what we rely on with the digital plumbing called wireless. >> [Jeff] Right, right. >> When you think about the impact of going around the fiber to the home, and the cost it takes, to bring fiber to, Lynn Comp was commenting on that. So having this massively scalable bandwidth that's a radio frequency wireless is just a game-changing thing you can do. Low latency, 10 20 gig, that's all you need. Then you're going to start to see the phones change and the apps change. And as Peter Burris said a turbulent change of value propositions will emerge. >> It's funny at RSA a couple of weeks back the chatter was the people at RSA, they don't use wifi. You know, they rely on secure mobile networks. And so 5G is going to enable that even more, and as you said, if you can get that bandwidth to your phone in a safer, and secure, more trusted way, you know what is the impact on wifi and what we've come to expect on our devices and the responsiveness. And all that said, there will be new devices, there will be new capabilities. And I guess the other thing that's kind of funny is that of course the Oscar's made their way up to the, on the board. I thought that might wipe everything out after last night. But no IOT and 5G is still above Oscar's on the trending hashtag. >> Well I mean, Oscar's bring up... It's funny we all watch the Oscar's. There was some sort of ploy, but again, you bring up entertainment with the Oscar's. You look at what Hollywood's going through, and the Hollywood Reporter had an article talking about Reed Hastings with Netflix, he talked today really kind of higher end video so the entertainment business is shifting the court cutting is happening, we're seeing more and more what they call over the top. And this is the opportunity for the service providers but also for the entertainment industry. And with social media and with all these four form factors changing the role of media will be a packet data game. And how much can you fit in there? Whether it's e-sports to feature film making, the game is certainly changing. And again, I think Mobile World Congress is changing so radically. It's not just a device show anymore, it's not about the handset. It's about what the enablement is. I think that's why the 5G impact is interesting. And making it all work together, because a car talking to this device, it's complicated. So there's got to be the glue, all kind of new opportunities. So that's what I'm intrigued by. The Intel situation where you've got two chip guys battling it out for who's going to be that glue layer under the hood >> Right and if you look at some of the quotes coming out of the show a lot of the high-level you got to get away from the components and get into the systems and solutions, which we hear about over and over and over again. It's always about systems and solutions. I think they will find a problem to solve, with the 5G. I think it's out there. But it is... >> My philosophy Jeff is kill me with the bandwidth problem. Give me more bandwidth, I will consume more bandwidth. I mean look at compute pal as an example. People thought Morse law was going to cap out a decade ago. You look at the compute power in the chips with the cloud, with Amazon and the cloud providers it's almost infinite computes. So then the role of data comes in. So now you got data, now you got mobile, I think give us more bandwidth, I think the apps have no problem leveling up. >> [Jeff] Sucking it up. >> And that's going to be the debate with Saar. >> It's the old chip. The Intel Microsoft thing where you know, Intel would come out with a faster chip then the OS with eat more of it as part of the OS. And it kept going and going. We've talked through a lot of these John and if you're trying to predict the future and building for the future you really have to plan now for almost infinite bandwidth for free. Infinite storage for free, infinite compute for free. And while those curves are kind of asymptotically free they're not there yet. That is really the world in which we're heading. And how do you reshape the way you design apps, experiences, interphases without those constraints, which before were so so significant. >> I'm just doing a little crowd check here, you can go to crowdcheck.net/mwc if you want to leave news links or check in with the folks chatting. And I was just talking to SAP and SAP had the big Apple news. And one of the things that's interesting and Peter Burris talked about this on our opening this morning is that confluence between the consumer business and then the infrastructures happening. And that it was called devos but now you're starting to see the developers really focusing on the business value of technology. But yet it's not all developers even though people say the developers, the new king-makers, well I would say that. But the business models still is driven by the apps. And I think developers are certainly closer to the front lines. But I think you're going to start to see a much more tighter coupling between the c level folks in business and the developers. It's not just going to be a developer-led 100% direction. Whether it's entertainment, role of data, that's going to be pretty interesting Jeff. >> So Apple's just about finished building the new spaceship headquarters right. I think I opens up next month. I'm just curious to get your take John on Apple. Obviously the iPhone changed the game 10 years ago. What' the next big card that Apple's going to play? 'Cause they seemed to have settled down. They're not at the top of the headlines anymore. >> Well from my sources at Apple, there are many. Deep inside at the highest levels. What I'm hearing is the following. They're doing extremely well financially, look at the retail, look at the breadth of business. I think Tim Cook has done an amazing job. And to all my peers and pundits who are thrashing Apple they just really don't know what they're talking about. Apple's dominating at many levels. It's dominating firstly on the fiscal performance of the company. They're a digital presence in terms of their stickiness is second to none. However, Apple does have to stay in their game. Because all the phone guys they are in essence copying Apple. So I think Apple's going to be very very fine. I think where they could really double down and win on is what they did getting out of the car business. I think that was super smart. There was a post by Auto Blog this weekend saying Silicon Valley failed. I completely disagree with that statement. Although in the short term it looks like on the scoreboard they're kind of tapping out, although Tesla this year. As well as a bunch of other companies. But it's not about making the car anymore. It's all about the car's role in a better digital ecosystem. So to me I think Apple is poised beautifully to use their financial muscle, to either buy car companies or deal with the digital aspect of it and bring that lifestyle to the car, where the digital services for the personalization of the user will be the sticking point for the transportation. So I think Apple's poised beautifully for that. Do they have some issues? Certainly every company does. But compared to everyone else I just see no one even close to Apple. At the financial level, with the cash, and just what they're doing with the tax. From a digital perspective. Now Google's got a self-driving cars, Facebook's a threat, Amazon, so those are the big ones I see. >> The other thing that's happening this week is the game developer conference in San Francisco at Moscone. So you know again, huge consumers of bandwidth, huge consumers of compute power. Not so much storage. I haven't heard much of the confluence of the 5G movement with the game developer conference. But clearly that's going to have a huge impact 'cause most gaming is probably going to move to a more and more mobile platform, less desktop. >> Well the game developer conference, the one that's going on the GDC, is kind has a different vibe right now. It's losing, it's a little bit lackluster in my mind. It's classic conference. It's very monetized. It seems to be over-monetized. It's all about making money rather than promoting community. The community in gaming is shifting. So you can look at how that show is run, versus say e three and now you've got Twitch Con. And then Mobile World Congress, one of the big voids is there's no e-sports conversation. That certainly would be the big thing to me. To me, everything that's going digital, I think gaming is going to shift in a huge way from what we know as a console cult. It's going to go completely mainstream, in all aspects of the device. As 5G overlays on top of the networks with the software gaming will be the first pop. You're going to see e-sports go nuclear. Twitch Con, those kind of Twitch genre's going to expand. Certainly "The Cube" will have in the future a gaming cube. So there'll be a cube anchor desk for most the gaming culture. Certainly younger hosts are going to come one. But to me I think the gaming thing's going to be much more lifestyle. Less culty. I think the game developer conference's lost its edge. >> And one of the other things that comes, obviously Samsung made a huge push. They were advertising crazy last night on the Oscar's, with the Casey add about you know, people are creating movies. And they've had their VR product out for a while but there's a lot of social activity saying what is going to be the killer app that kind of breaks through VR? We know Oculus has had some issues. What do you read in between the tea leaves there John? >> Well it's interesting the Oscar's was awesome last night, I would love to watch the Hollywood spectacle but one of the things that I liked was that segway where they introduced the Oscar's and they kind of were tongue in cheek 'cause no one in Hollywood really has any clue. And they were pandering, well we need to know what they meant. It was really the alpha geeks who were pioneering what used to be the green screen technology now you go and CGI it's our world. I mean I want to see more of that because that is going to be the future of Hollywood. The tools and the technologies for filmmaking is going to have a Morse law-like impact. It's the same as e-sports, you're going to see all kinds of new creative you're going to see all kinds of new tech. They talked about these new cameras. I'm like do a whole show on that, I would love it. But what it's going to enable is you're going to see CGI come down to the price point where when we look at PowerPoints and Adobe Creative Suite and these tools. You're going to start to see some badass creative come down for CGI and this is when the artist aspect comes in. I think art design will be a killer field. I think that is going to be the future of filmmaking. You're going to see an indie market explode in terms of talent. The new voices are going to emerge, the whole diversity thing is going to go away. Because now you're going to have a complete disruption of Hollywood where Hollywood owns it all that's going to get flattened down. I think you're going to see a massive democratization of filmmaking. That's my take. >> And then of course we just continue to watch the big players right. The big players are in here. It's the start ups but I'm looking here at the Ford SAP announcement that came across the wire. We know Ford's coming in at scale as stuff with IBM as well So those people bring massive scale. And scale is what we know drives pricing and I think when people like to cap on Morse law they're so focused on the physical. I think the power of Morse law has nothing to do with the microprocessor per se. But really it's an attitude. Which we talked a little briefly about what does the world look like if you have infinite networking, infinite compute, and infinite storage. And basically free. And if you start to think that way that changes your perspective on everything. >> Alright Jeff well thanks for the commentary. Great segment really breaking down the impact of Mobile World Congress. Again this show is morphing from a device show phone show, to full on end-to-end network. Intel are leading the way and the entire ecosystem on industry partners, going to write software for this whole new app craze, and of course we'll be covering it here all day today Monday the 27th and all the day the 28th. Stay tuned stay watching. We've got more guests coming right back with more after the short break.