>> Narrator: theCUBE's live coverage is made possible by funding from Dell Technologies. Creating technologies that drive human progress. (upbeat music) >> Welcome back to Barcelona, Spain, everyone. It's theCUBE live at MWC '23, day three of four days of CUBE coverage. It's like a cannon of CUBE content coming right at you. I'm Lisa Martin with Dave Nicholson. We've got Dell and VMware here. Going to be talking about the ecosystem partnerships and what they're doing to further organizations in the telco industry. Please welcome Jared Woodrey, Director of Partner Engineering Open Telecom Ecosystem Lab, OTEL. Odded Solomon is here as well, Director of Product Management, VMware Service Provider and Edge Business Unit at VMware. Guys, great to have you on the program. >> Thank you for having me. >> Welcome to theCUBE. So Jared, first question for you. Talk about OTEL. I know there's a big announcement this week, but give the audience context and understanding of what OTEL is and how it works. >> Sure. So the Open Telecom Ecosystem Lab is physically located at Round Rock, Texas, it's the heart and soul of it. But this week we also just announced opening up the Cork, Ireland extension of OTEL. The reason for our existence is to to try and make it as easy as possible for both partners and customers to come together and to re-aggregate this disaggregated ecosystem. So that comes with a number of automation tools and basically just giving a known good testing environment so that tests that happen in our lab are as close to real world as they possibly can be and make it as transparent and open as possible for both partners like VMware as well as customers. >> Odded, talk about what you're doing with Dell and OTEL and give us a customer example of maybe one that you're working with or even even mentioning it by a high level descriptor if you have to. >> Yeah. So we provide a telco cloud platform, which is essentially a vertical in VMware. The telco cloud platform is serving network function vendors, such as Ericsson, Nokia, Mavenir, and so on. What we do with Dell as part of this partnership is essentially complementing the platform with some additional functionality that is not coming out of the box. We used to have a data protection in the past, but this is no longer our main business focus. So we do provide APIs that we can expose and work together with Dell PPDM solution so customer can benefit from this and leverage the partnership and have overall solution that is not coming out of the box from VMware. >> I'm curious, from a VMware perspective. VMware is associated often with the V in VMware, virtualization, and we've seen a transition over time between sort of flavors of virtualization and what is the mix currently today in the telecom space between environments that are leveraging what we would think of as more traditional virtualization with full blown Linux, Windows operating systems in a VM versus the world of containerized microservices? What does that mix look like today? Where do you see it going? >> Yeah, so the VMware telco cloud platform exists for about eight years. And the V started around that time. You might heard about open stack in addition to VMware. So this has definitely helped the network equipment providers with virtualizing their network functions. Those are typically VNF, virtualized network functions, inside the VMs. Essentially we have 4G applications, so core applications, EPC, we have IMS. Those are typically, I would say maybe 80 or 90% of the ecosystem right now. 5G is associated with cloud native network functions. So 5G is getting started now, getting deployed. There is an exponential growth on the core side. Now, when we expand towards the edge of the network we see more potential growth. This is 5G ran, we see the vRAN, we see the open RAN, we see early POCs, we see field trials that are starting. We obviously has production customer now. You just spoke to one. So this is really starting, cloud native is really starting I would say about 10 to 20% of the network functions these days are cloud native. >> Jared, question for you. You mentioned data protection, a huge topic there obviously from a security perspective. Data protection used to be the responsibility of the CSPs. You guys are changing that. Can you talk a little bit about how you're doing that and what Dell's play there is? >> Yeah, so PowerProtect Data Management is a product, but it's produced by Dell. So what this does is it enables data protection over virtual cloud as well as the physical infrastructure of specifically in this case of a telecoms ecosystem. So what this does is enables an ability to rapidly redeploy and back up existing configurations all the way up to the TCP and TCA that pulls the basis of our work here with VMware. >> So you've offloaded that responsibility from the CSPs. You freed them from that. >> So the work that we did, honestly was to make sure that we have a very clear and concise and accurate procedures for how to conduct this as well. And to put this through a realistic and real world as if it was in a telecoms own production network, what did that would actually look like, and what it would take to bring it back up as well. So our responsibility is to make sure that when we when we provide these products to the customers that not only do they work exactly as their intended to, but there is also documentation to help support them and to enable them to have their exact specifications met by as well. >> Got it. So talk about a little bit about OTEL expansion into Cork. What you guys are doing together to enable CSPs here in EMEA? >> Yeah, so the reason why we opened up a facility in Cork Island was to give, for an EMEA audience, for an EMEA CSPs and ability to look and feel and touch some of the products that we're working on. It also just facilitates and ease especially for European-based partners to have a chance to very easily come to a lab environment. The difference though, honestly, is the between Round Rock, Texas and Cork Island is that it's virtually an extension of the same thing. Like the physical locations can make it easier to provide access and obviously to showcase the products that we've developed with partners. But the reality is that it's more than just the physical location. It's more about the ability and ease by which customers and partners can access the labs. >> So we should be expecting a lot of Tito's vodka to be consumed in Cork at some point. Might change the national beverage. >> We do need to have some international exchange. >> Yeah, no, that's good to know. Odded, on the VMware side of things. There's a large group of folks who have VMware skillsets. >> Odded: Correct. >> The telecom industry is moving into this world of the kind of agility that those folks are familiar with. How do people come out of the traditional VMware virtualization world and move into that world of cloud native applications and serve the telecom space? What would your recommendation be? If you were speaking at a VMUG, a VMware Users Group meeting with all of your telecom background, what would you share with them that's critical to understand about how telecom is different, or how telecom's spot in its evolution might be different than the traditional IT space? >> So we're talking about the people with the knowledge and the background of. >> Yeah, I'm a V expert, let's say. And I'm looking into the future and I hear that there are 80,000 people in Barcelona at this event, and I hear that Dell is building optimized infrastructure specifically for telecom, and that VMware is involved. And I'm an expert in VMware and I want to be involved. What do I need to do? I know it's a little bit outside of the box question, but especially against the backdrop of economic headwinds globally, there are a lot of people facing transitions. What are your thoughts there? >> So, first of all, we understand the telco requirements, we understand the telco needs, and we make sure that what we learn from the customers, what we learn from the partners is being built into the VMware products. And simplicity is number one thing that is important for us. We want the customer experience, we want the user experience to be the same as they know even though we are transitioning into cloud native networks that require more frequent upgrades and they have more complexity to be honest. And what we do in our vertical inside VMware we are focusing on automation, telco cloud automation, telco cloud service assurance. Think of it as a wrapper around the SDDC stack that we have from VMware that really simplifies the operations for the telcos because it's really a challenge about skillset. You need to be a DevOps, SRE in order to operate these networks. And things are becoming really complex. We simplify it for them with the same VMware experience. We have a very good ability to do that. We sell products in VMware. Unlike our competition that is mostly selling professional services and support, we try to focus more on the products and delivering the value. Of course, we have services offering because telcos requires some customizations, but we do focus on automation simplicity throughout our staff. >> So just follow up. So in other words the investment in education in this VMware ecosystem absolutely can be extended and applied into the telecom world. I think it's an important thing. >> I was going to add to that. Our engagement in OTEL was also something that we created a solutions brief whether we released from Mobile World Congress this week. But in conjunction with that, we also have a white paper coming out that has a much more expansive explanation and documentation of what it was that we accomplished in the work that we've done together. And that's not something that is going to be a one-off thing. This is something that will stay evergreen that we'll continue to expand both the testing scope as well as the documentation for what this solution looks like and how it can be used as well as documentation on for the V experts for how they can then leverage and realize the the potential for what we're creating together. >> Jared, does Dell look at OTEL as having the potential to facilitate the continued evolution of the actual telco industry? And if so, how? >> Well, I mean, it would be a horrible answer if I were to say no to that. >> Right. >> I think, I honestly believe that one of the most difficult things about this idea of having desired ecosystem is not just trying to put it back together, but then also how to give yourself choice. So each time that you build one of those solution sets like that exists as an island out of all the other possibilities that comes with it. And OTEL seeks to not just be able to facilitate building that first solution set. Like that's what solutions engineering can do. And that's generally done relatively protected and internally. The Open Telecom Ecosystem seeks to build that then to also provide the ability to very easily change specific components of that whether that's a hardware component, a NIC, whether a security pass just came out or a change in either TCP or TCA or we talked a little bit about for this specific engagement that it was done on TCP 2.5. >> Odded: Correct. >> Obviously there's already a 2.7 and 3.0 is coming out. It's not like we're going to sit around and write our coattails of what 2.7 has happened. So this isn't intended to be a one and done thing. So when we talk about trying to make that easier and simpler and de-risk all of the risk that comes from trying to put all these things together, it's not just the the one single solution that you built in the lab. It's what's the next one? And how do I optimize this? And I have specific requirements as a CSP, how can I take something you built that doesn't quite match it, but how do I make that adjustment? So that's what we see to do and make it as easy and as painless as possible. >> What's the engagement model with CSPs? Is it led by Dell only, VMware partner? How does that work? >> Yeah, I can take that. So that depends on the customer, but typically customers they want to choose the cloud vendor. So they come to VMware, we want VMware. Typically, they come from the IT side. They said, "Oh, we want to manage the network side of the house the same way as we manage the IT. We don't want to have special skill sets, special teams." So they move from the IT to the network side and they want VMware there. And then obviously they have an RSP process and they have hardware choices. They can go with Dell, they can go with others. We leverage vSphere, other compatibility. So we can be flexible with the customer choice. And then depending on which customer, how large they are, they select the network equipment provider that the runs on top. We position our platform as multi-vendor. So many of them choose multiple network functions providers. So we work with Dell. So assuming that the customer is choosing Dell. We work very closely with them, offering the best solution for the customer. We work with them sometimes to even design the boxes to make sure that it fits their use cases and to make sure that it works properly. So we have a partnership validation certification end-to-end from the applications all the way down to the hardware. >> It's a fascinating place in history to be right now with 5G. Something that a lot of consumers sort of assume. It's like, "Oh, hey, yeah, we're already there. What's the 6G thing going to look like?" Well, wait a minute, we're just at the beginning stages. And so you talk about disaggregation, re-aggregation, or reintegration, the importance of that. Folks like Dell have experience in that space. Folks at VMware have a lot of experience in the virtualization space, but I heard that VMware is being acquired by Broadcom, if it all goes through, of course. You don't need to comment on it. But you mentioned something, SDDC, software-defined data center. That stack is sometimes misunderstood by the public at large and maybe the folks in the EU, I will editorialize for a moment here. It is eliminating capture in a way by larger hyperscale cloud providers. It absolutely introduces more competition into the market space. So it's interesting to hear Broadcom acknowledging that this is part of the future of VMware, no matter what else happens. These capabilities that spill into the telecom space are something that they say they're going to embrace and extend. I think that's important for anyone who's evaluating this if they're concern. Well, wait a minute. Yeah, when I reintegrate, do I want VMware as part of this mix? Is that an unknown? It's pretty clear that that's something that is part of the future of VMware moving forward. That's my personal opinion based on analysis. But you brought up SDDC, so I wanted to mention that. Again, I'm not going to ask you to get into trouble on that at all. What should we be, from a broad perspective, are there any services, outcomes that are going to come out of all of this work? The agility that's being built by you folks and folks in the open world. Are there any specific things that you personally are excited about? Or when we think about consumer devices, getting data, what are the other kinds of things that this facilitates? Anything cool, either one of you. >> So specific use cases? >> Yeah, anything. It's got to be cool though. If it's not cool we're going to ask you to leave. >> All right. I'll take that challenge. (laughs) I think one of the things that is interesting for something like OTEL as an exist, as being an Open Telecom Ecosystem, there are going to be some CSPs that it's very difficult for them to have this optionality existing for themselves. Especially when you start talking about tailoring it for specific CSPs and their needs. One of the things that becomes much more available to some of the smaller CSPs is the ability to leverage OTEL and basically act as one of their pre-production labs. So this would be something that would be very specific to a customer and we would obviously make sure that it's completely isolated but the intention there would be that it would open up the ability for what would normally take a much longer time period for them to receive some of the benefits of some of the changes that are happening within the industry. But they would have immediate benefit by leveraging specifically looking OTEL to provide them some of their solutions. And I know that you were also looking for specific use cases out of it, but like that's a huge deal for a lot of CSPs around the world that don't have the ability to lay out all the different permutations that they are most interested in and start to put each one of those through a test cycle. A specific use cases for what this looks like is honestly the most exciting that I've seen for right now is on the private 5G networks. Specifically within mining industry, we have a, sorry for the audience, but we have a demo at our booth that starts to lay out exactly how it was deployed and kind of the AB of what this looked like before the world of private 5G for this mining company and what it looks like afterwards. And the ability for both safety, as well as operational costs, as well as their ability to obviously do their job better is night and day. It completely opened up a very analog system and opened up to a very digitalized system. And I would be remiss, I didn't also mention OpenBrew, which is also an example in our booth. >> We saw it last night in action. >> We saw it. >> I hope you did. So OpenBrew is small brewery in Northeast America and we basically took a very manual process of checking temperature and pressure on multiple different tanks along the entire brewing process and digitized everything for them. All of that was enabled by a private 5G deployment that's built on Dell hardware. >> You asked for cool. I think we got it. >> Yeah, it's cool. >> Jared: I think beer. >> Cool brew, yes. >> Root beer, I think is trump card there. >> At least for folks from North America, we like our brew cool. >> Exactly. Guys, thank you so much for joining Dave and me talking about what Dell, OTEL, and VMware are doing together, what you're enabling CSPs to do and achieve. We appreciate your time and your insights. >> Absolutely. >> Thank you. >> All right, our pleasure. For our guests and for Dave Nicholson, I'm Lisa Martin. You watching theCUBE live from MWC '23. Day three of our coverage continues right after a short break. (upbeat music)

>>From San Francisco. It's the cube covering PagerDuty summit 2019 brought to you by PagerDuty. >>Hey, welcome back everybody. Jeff Frick here with the Q. We're a PagerDuty summit. It's the fourth year of the show. He's been here for three years. It's amazing to watch it grow. I think it's finally outgrown the Western Saint Francis here in lovely downtown San Francisco and we're really excited to be joined by our next guest. He's Alex Solomon, the co founder, co founder and CTO PagerDuty. Been at this over 10 years. Alex, first off, congratulations. And what a fantastic event. Thank you very much and thank you for having me on your show. So things have changed a lot since we had you on a year ago, this little thing called an IPO. So I'm just curious, you know, we have a lot of entrepreneurs. I watch a show as a founder and kind of go through this whole journey. What was that like? What are some of the things you'd like to share from that whole experience? >>Yeah, it was, it was incredible. I I, the word I like to use is surreal. Like just kind of going through it, not believing that it's real in a way. And adjoining by my, my lovely wife who came, came along for this festivities and just being able to celebrate that moment. I know it is just a moment in time and it's not, it's not the end of the journey certainly, but it is a big milestone for us and uh, being able to celebrate. We invited a lot of our customers, our early customers have been with us for years to join us in that, a celebration. Our investors who have believed in us from back in 2010. Right, right. We were just getting going and we just, we just had a great time. I love it. I love 10 year overnight success. 10 years in the making. >>One of my favorite expressions, and it was actually interesting when Jenn pulled up some of the statistics around kind of what the internet was, what the volume of traffic was, what the complexity in the systems are. And it's really changed a lot since you guys began this journey 10 years ago. Oh, it has. I mean back then, like the most popular monitoring tool is Nagios and new Relic was around but just barely. And now it's like Datadog has kind of taken over the world and the world has changed. We're talking about not just a microservices by containers and serverless and the cloud basically. Right. That's the kind of recurring theme that's changed over the last 10 years. But you guys made some early bets. You made bets on cloud. He made bets on dev ops. He made bets on automation. Yeah, those were pretty good. >>Uh, those, those turn out to be pretty good places to put your chips. Oh yeah. Right place, right time and um, you know, some, some experiential stuff and some just some raw luck. Right. All right, well let's get into it. On top of some of the product announcements that are happening today, what are some of the things you're excited to finally get to showcase to the world? Yeah, so one of the big ones is, uh, related to our event intelligence release. Uh, we launched the product last year, um, a few months before summit and this year we're making a big upgrade and we're announcing a big upgrade to the product where we have, uh, related incidents. So if you're debugging a problem and you have an incident that you're looking at, the question you're gonna ask is, uh, is it just my service or is there a bigger widespread problem happening at the same time? >>So we'll show you that very quickly. We'll show you are there other teams, uh, impacted by the same issue and we'll, we, we actually leveraged machine learning to draw those relationships between ongoing incidents. Right. I want to unpack a little bit kind of how you play with all these other tools. We, you know, we're just at Sumo logic a week or so ago. They're going to be on later their partner and people T I think it's confusing. There's like all these different types of tools. And do you guys partner with them all? I mean, the integration lists that you guys have built. Um, I wrote it down in service now. It's Splunk, it's Zendesk, it goes on and on. And on. Yeah. So explain to folks, how does the PagerDuty piece work within all these other systems? Sure. So, um, I would say we're really strong in terms of integrating with monitoring tools. >>So any sort of tool that's monitoring something and we'll admit an alert, uh, when something goes down or over an event when something's changed, we integrate and we have a very wide set of coverage with all, all of those tools. I think your like Datadog, uh, app dynamics, new Relic, even old school Nagios. Right. Um, and then we've also built a suite of integrations around all the ticketing systems out there. So service now a JIRA, JIRA service desk, um, a remedy as well. Uh, we also now have built a suite of integrations around the customer support side of things. So there'll be Zendesk and Salesforce. That's interesting. Jen. Megan had a good example in the keynote and kind of in this multi system world, you know, where's the system of record? Cause he used to be, you want it, everybody wanted it to be that system of record. >>They wanted to be the single player in the class. But it turns out that's not really the answer. There's different places for different solutions to add value within the journey within those other applications. Yeah, absolutely. I, I think the single pane of glass vision is something that a lot of companies have been chasing, but it's, it's, it's really hard to do because like for example, NewRelic, they started an APM and they got really good at that and that's kind of their specialty. Datadog's really good at metrics and they're all trying to converge and do everything and become the one monitoring solution to the Rooney rule them all right. But they're still the strongest in one area. Like Splunk for logs, new Relic and AppDynamics for APM and Datadog for metrics. And, um, I don't know where the world's going to take us. Like, are they, is there going to be one single monitoring tool or are, are you going to use four or five different tools? >>Right. My best guess is your, we're going to live in a world where you're still gonna use multiple tools. They each can do something really well, but it's about the integration. It's about building, bringing all that data together, right? That's from early days. We've called pager duty, the Switzerland monitoring, cause we're friends with everyone when we're partners with everyone and we sit on top right a work with all of these different roles. I thought her example, she gave him the keynote was pretty, it's kind of illustrative to me. She's talking about, you know, say your cables down and you know, you call Comcast and it's a Zendesk ticket. But >>you know then that integrates potentially with the PagerDuty piece that says, Hey we're, you know, we're working on a problem, you know, a backhoe clipped the cable down your street. And so to take kind of that triage and fix information and still pump that through to the Zen desk person who's engaging with the customer to actually give them a lot more information. So the two are different tracks, but they're really complimentary. >>Absolutely. And that's part of the incident life cycle is, is letting your customers know and helping them through customer support so that the support reps understand what's going on with the systems and can have an intelligent conversation with the customer. So that they're not surprised like a customer calls and says you're down. Oh, good to know. No, you want to know about that urge, which I think most people find out. Oh yeah. Another thing >>that struck me was this, this study that you guys have put together about unplanned work, the human impact of always on world. And you know, we talk a lot in tech about unplanned maintenance and unplanned downtime of machines, whether it's a, a computer or a military jet, you know, unplanned maintenance as a really destructive thing. I don't think I've ever heard anyone frame it for people and really to think about kind of the unplanned work that gets caused by an alert and notification that is so disruptive. And I thought that was a really interesting way to frame the problem and thinking of it from an employee centric point of view to, to reduce the nastiness of unplanned work. >>Absolutely. And that's, that V is very related to that journey of going from being reactive and just reacting to these situations to becoming proactive and being able to predict and, and, uh, address things before they impact the customer. Uh, I would say it's anywhere between 20 to 40 or even higher percent of your time. Maybe looking at software engineers is spent on the some plant work. So what you want to do is you want to minimize that. You want to make sure that, uh, there's a lot of automation in the process that you know what's going on, that you have visibility and that the easy things, the, the repetitive things are easy to automate and the system could just do it for you so that you, you focus on innovating and not on fixing fires. Right? Or if you did to fix the fire, you at least >>to get the fire to the right person who's got the right tone to fix the type. So why don't we just, you know, we see that all the time in incidents, especially at early days for triage. You know, what's happening? Who did it, you know, who's the right people to work on this problem. And you guys are putting a lot of the effort into AI and modeling and your 10 years of data history to get ahead of the curve in assigning that alerted that triage when it comes across the, the, uh, the trans though. >>Yeah, absolutely. And that's, that's another issues. Uh, not having the right ownership, get it, getting people, um, notified when they don't own it and there's nothing they can do about it. Like the old ways of, of uh, sending the alert to everyone and having a hundred people on a call bridge that just doesn't work anymore because they're just sitting there and they're not going to be productive the next day I work cause they're sitting there all night just kind of waiting for, for something to happen. And uh, that's kinda the, the old way of lack of ownership just blasted out to everyone and we have to be a lot more target and understand who owns what and what's, what, which systems are being impacted and they only let getting the right people on the auto call as quickly as possible. The other thing that came up, which I thought, you know, probably a lot of people are thinking of, they only think of the fixing guy that has to wear the pager. >>Sure. But there's a whole lot of other people that might need to be informed, be informed. We talked about in the Comcast example that people interacting with the customer, ABC senior executives need to be in for maybe people that are, you know, on the hook for the SLA on some of the softer things. So the assembly that team goes in need, who needs to know what goes well beyond just the two or three people that are the fixing people? Right. And that's, that's actually tied to one of our announcements, uh, at summit a business, our business response product. So it's all about, um, yes, we notify the people who are on call and are responsible for fixing the problem. You know, the hands on keyboard folks, the technical folks. But we've expanded our workflow solution to also Lupin stakeholders. So think like executives, business owners, people who, um, maybe they run a division but they're not going to go on call to fix the problem themselves, but they need to know what's going on. >>They need to know what the impact is. They need to know is there a revenue impact? Is there a customer impact? Is there a reputational brand impact to, to the business they're running. Which is another thing you guys have brought up, which is so important. It's not just about fixing, fixing the stuck server, it's, it is what is the brand impact, what is the business impact is a much broader conversation, which is interesting to pull it out of just the, just the poor guy in the pager waiting for it to buzz versus now the whole company really being engaged to what's going on. Absolutely. Like connecting the technical, what's happening with the technical services and, and uh, infrastructure to what is the, the impact on the business if something goes wrong. And how much, like are you actually losing revenue? There's certain businesses like e-commerce where you could actually measure your revenue loss on a per minute or per five minute basis. >>Right. And pretty important. Yeah. All right Alex. So you talked about the IPO is a milestone. It's, it's fading, it's fading in the rear view mirror. Now you're on the 90 day shot clock. So right. You gotta keep moving forward. So as you look forward now for your CTO role, what are some of your priorities over the next year or so that you kind of want to drive this shit? Absolutely. So, um, I think just focusing on making the system smarter and make it, uh, so that you can get to that predictive Holy grail where we can know that you're going to have a big incident before it impacts our customers. So you can actually prevent it and get ahead of it based on the leading indicators. So if we've seen this pattern before and last time it causes like an hour of downtime, let's try to catch it early this time and so that you can address it before it impacts for customers. >>So that's one big area of investment for us. And the other one I would say is more on the, uh, the realtime work outside of managing software systems. So, uh, security, customer support. There's all of these other use cases where people need to know, like, signals are, are being generated by machines. People need to know what's going on with those signals. And you want to be proactive and preventative around there. Like think a, a factory with lots and lots of sensors. You don't want to be surprised by something breaking. You want to like get proactive about the maintenance of those systems. If they don't have that, uh, you know, like say a multi-day outage in a factory, it can cost maybe millions of dollars. Right. >>All right, well, Alex, thanks a lot. Again, congratulations on the journey. We, uh, we're enjoying watching it and we'll continue to watch it evolve. So thank you for coming on. Alright, he's Alex. I'm Jeff. You're watching the cube. We're at PagerDuty summit 2019 in downtown San Francisco. Thanks for watching. We'll see you next time.

>> From Union Square in downtown San Francisco, it's theCUBE, covering Pager Duty Summit '18. Now, here's Jeff Frick. >> Hey welcome back here everybody, Jeff Frick here with theCUBE. We're at Pager Duty Summit 2018, at the Weston St. Francis, Union Square in San Francisco. It's a beautiful day outside, a really historic building, and we're happy to be here for our second Pager Duty Summit, and our next guest, super excited to have him, we didn't have him last year. He's Alex Solomon, the Co-Founder and CTO of Pager Duty, Alex, great to see you. >> Yeah, thanks for having me. >> Absolutely, so we were just talking a little bit. Before we turned the cameras on, you started this little adventure in '09, so it's been nine years. So what, I'd just love to get your perspective, as you come to something like this, and look at all these people that are here, to see what started as just a germ of an idea, back in your head nine years ago. >> Yeah, it's exciting to see such an amazing conference. We have over 800 people here today, and it's definitely buzzing. I could feel the excitement in the air. >> Right, well Ray Kurzweil is the Keynote, that's getting right up there. >> Exactly. >> Really an amazing story. One of the things that was, that was key to Ray's topic was the accelerating technology curve, in terms of power and performance, and it's not linear, it accelerates, and you guys have seen a huge growth in your business, and your throughput and all the incidents that you're reporting, and now we're talking about BI, and using Machine Learning and Artificial Intelligence to make some sense and to help filter through all this phenomenal amount of throughput. So how are you, how do you see that opportunity, how are you guys grasping the opportunity? What are you going to do with that Machine Learning? >> Sure, so about three months ago, we launched our new Event Intelligence product, which is all about capturing the, all the signals coming out of all of your different tools, things like monitoring tools. Things like ticketing systems, collaboration tools like Slack, and processing all those signals, mostly events and alerts and filtering out the noise. So a lot of alerts and events are not necessarily relevant for someone to get paged about in the middle of the night. Maybe it's a false alert, maybe it's something that has gone up, and will fix itself. >> Right. >> So it's about filtering out all the noise in there, and it's also about automatically clustering, and correlating related events. So we take those events in, and then we group them together into incidents, and we determine the surface area of the problem, which systems are affected, and we page those people, and only those people, so that they can respond to the incident. >> Right. So do you leverage the total learning of the Pager Duty System, in kind of an anonymized way, so you can leverage the multi-billions of dollars worth of incidents to get that type of learning, that was one of Ray's key themes, it helps if you have a billion of something, if you want to start applying some of these Machine Learning techniques. >> Exactly, so the more data you have when you're applying AI and ML, the better the results will be. We have over nine years of data that we've accumulated since founding the company, and we leveraged that for (mumbles) conditions, so for, I'll give you an example. If you're looking at an incident, you just got paged for something, or multiple people got paged, and you're looking at an evolving situation, our algorithms will automatically look in the past, and see has this type of problem happened before? Have you seen this type of incident before? Have you seen these events come in before, that are similar to this and, if so, what happened last time? >> Right. >> Who solved it, what was the resolution, so you can apply that knowledge, to the problem, and resolve it much faster. >> Right. So is it? So you do it both within the existing company, and their ecosystem so yeah, Joe solved it last time, Suzie solved it the time before, as well as to get more of an aggregate, of kind of an anonymized of we see this pattern over and over and over, this might be what you're looking at. >> Yeah, and we haven't done the aggregate picture yet, but it's something that we're very excited about, because we have the potential to become kind of like the Internet weather, where we can tell, based on the number of customers that we have, problems with the Internet, such as, let's say one of the Public Cloud providers is having an issue. Well, they have lots of customers that are Pager Duty customers, and they can now see oh, we have, we're seeing all of this additional incident activity, in this part of the Internet. >> Right. So there's something going on. >> Right. >> And we can start, this is an opportunity that we're very excited about, start telling, being able to tell, oh there's a problem with one of the Cloud providers, there's a problem with one of the main, big infrastructure providers that is commonly used by a lot of different companies. >> Right, because so many of these systems now, are so interdependent. You've got all these APIs, from all these different applications, all these different Cloud providers, and the whole thing stitched together so, trying to figure out where that little, the glitch is, is not necessarily as easy as when you kind of controlled everything. >> Exactly. >> It's funny too, because Jen had a line from her Keynote, which you just triggered. She said, "You know, we're the ones that want to be up, "when the rest of the world seems down." >> Yeah, exactly. >> So, let me expand on that a little bit. So you were the Founder. Jennifer came in a couple years ago, if I recall. I'm sure everyone who loves the classic entrepreneur tale, who liked to watch the show. You founded it, you got it to a certain point, and at some point you decided, you're going to bring in a new CEO. Wonder if you can talk a little bit about how that process went down. Kind of your thoughts as a Founder, of making that transition to see your company go, from this stage to that stage. >> Sure, sure, so yeah, I was the Founding CEO. I built, well me, not just by myself, but with my two Co-founders, and with the great team that we hired, we built the company from zero to over fifty million in annual recurring revenue. The company, when we decided to make that transition, I got into about 200 people or so. So a pretty good scale starting from nothing. >> Yeah, and to a fifty million run right, that's good. >> Yeah, and I'm a first-time entrepreneur, so I haven't done this before, and at that point we had a lot of work to do on the product side of things, like a lot of exciting new things, such as Event Intelligence that we just launched earlier this year, and other products are on Analytics and Visibility, that we're announcing here today. But I found myself spending a lot of my time, inside the building hiring and managing, and I didn't get enough of an opportunity to talk to customers and think about product, and think about the vision, what should we be building next? >> Right, right. >> So I wanted to go and focus more of my time in that direction. I initially started by thinking, maybe I can hire a CEOO, like a Chief Operating Officer to run Sales/Marketing and I can focus on Product and Engineering. Did a lot of due diligence, and talking to other CEOs who had been there, and done that, and realized that while that may solve some problems, it introduces new ones, and that the best bet is to find a World Class CEO. Like the best people out there in the world, are going to command that title, and they're going to want that role. >> Right. >> And I could still get to focus on product, and on talking to customers, and on vision, by replacing myself and taking on a CTO role, so that's what I ultimately decided to do. Had lots of help from the Board, who was very supportive in this decision, and they helped a lot with the interview process for, and the screening process for finding Jennifer. >> Well, you did good. We've known Jennifer for a long time, so I think that was one of your better hires. >> Absolutely. >> In the long history of the company. >> My best hire. Your best hire, very good. Well, and again, congratulations, it's funny you know, you see it over and over right? Overnight successes that are 10 years in the making. You know clearly, your last round of funding was a huge validation on your guy's strategy, and where you're taking the company, and then I just want to call out too, you guys were chosen for the Ernst & Young Co-founder, wait, hold on, the Entrepreneur of the Year Award 2018. Which is funny because you always think of that as maybe a little company just getting started right, or a really early entrepreneur. But you guys have been at this for nine years. Again, really good validation as to where you are in the market, and people realizing the value that you guys are delivering, so congratulations on that. >> Thank you very much. >> Alright Alex, well thanks for taking a few minutes from I'm sure, a very busy couple of days, and it was great to meet you. >> Absolutely, thanks for having me on the show. >> Alright, he's Alex, I'm Jeff. We're at Pager Duty Summit 2018, thanks for watching. (bright music)

>> Voiceover: Live from Austin, Texas. It's the Cube, covering DockerCon 2017, brought to you by Docker and support from its Ecosystem partners. >> Hi, I'm Stu Miniman and joining me, my co-host, for the second day of theCube's program, Jim Kobielus. Really excited to have, not only the founder of Docker, Solomon Hykes, he's also the CTO, Chief Product Officer, did some keynotes here, all over the place. So, Solomon, thank you so much, thanks for havin' us. Congratulations on all the progress and welcome back to theCUBE. >> Thanks a lot! It's a lot of fun! >> So many things to talk about, but let's start with you. How ya doin'? I'm sure there's so much that went into this week. What are you most proud of? What are you most excited about these days? >> Where to start? The cool thing, for me, about DockerCon is I focus on the keynote. We just package up the nice story, try to explain what we're doing, where we're going, and that's a pretty massive team effort. I think it's 30 of us for months preparing, deciding what we want to talk about, working on demos, pulling all-nighters. It's just really fun to see a keynote go from nothing to a really nice, fun story. Then I get to show up and discover all the other cool stuff. I'm like everyone else. I just marvel at the organization, the crowd, the energy. I'm a happy camper right now. >> It's interesting some of the dynamics in the industry. Okay, what's the important part? Who contributes to what? What fits where? Two years ago we had the hugging out as to the runtime and had the Open Source Foundation step in. Big thing at the keynote yesterday, two big things: it was Moby project and Linux Kit. Can you, maybe, unpack for our audience a little bit? What is Docker, the company? What's the Open Source? Who are some of the main players? It was the whole keynote, so we don't have time to get into it. What's real, and what was there? >> You're right, that was the big announcement, the Moby Project. Basically, in a nutshell, we launched Docker and we made it a product and an open source project, all rolled into one. We just kind of adopted this hybrid model, building a product that would just help people be more efficient, developers and ops, and at the same time, we would develop that in the open. That really helped us. It participated in the appearance of this huge Ecosystem. It was a big decision for us. Over time, both grew. Docker grew as a product, and it grew as an open source project. So over time we had to adapt to that growth. On the open source side that meant gradually spitting out smaller projects out of the main one. Now we have dozens of projects, literally. We got containerd. We got SwarmKit. We got InfraKit. We got all these components, and each of those is a project. Then we integrate them. What we're doing now, is we're completing that transformation and making sure there's a place for open source collaboration, free-for-all, openness, modularity, try new things, move fast, break things maybe. Then there's the product that integrates, takes the best parts, integrates them together, makes sure they're tested, they're solid, and then ships that to developers and customers. Basically we're saying, Moby is for open source collaboration. It's our project and all of it. And Docker is the product that integrates that open project into something that people can consume that's simple. It's two complementary parts to our platform. >> Could you talk a little bit about, there's kind of that composable nature of what you're building there. There's what Docker will build from it, and I think you've got a couple of examples of some of your partners. What's going to happen in the Cloud? What's going to happen with some of these others? Walk us through one of those. >> Everything about Docker's modular. So really, if you installed Docker for your favorite platform, whether it's the Mac, Windows, your favorite Cloud provider, Linux server, etc., you're actually installing a product that's an assembly of lots of components. Like I said, these components are developed in the open and then they're assembled. Now with the Moby Project, there's a place to assemble in the open, start the assembly in the open, so that other companies, the broader Ecosystem, can collaborate in the assembly, kind of experiment with how things fit together. The really cool thing about that is it makes it way easier to ports the platform, to expand it and customize it. So if you're a Cloud provider and you see all the pieces and you think "Well, I could optimize that. "I could add a little bit of magic "to make it work even better in my Cloud or in my hardware." Then you can do that in the open. You can do that with a community. Then you can partner with Docker to test it, and certify it, and distribute it as an easy-to-use product. Everything can go faster. >> You mentioned open a lot there. Does that mean that Docker is now closed? There's certain people that are very dogmatic when it comes to open source, so maybe you can parse that for us. >> I think it's the same people that were complaining before that we were confusing our product and an open project. We think of ourselves as having a lot to learn, and there's an Ecosystem that's made of a lot of people and companies and projects that have had a lot of experience with openness in the past. We spend most of our time listening, figuring out what the next step should be, and then taking that next step. People told us, "Clarify the relative place, "open source collaboration and your product." That's what we did. Now, I'm sure someone's going to say, "I preferred it before." Well, we just have to, at some point, chose. The key thing to remember is, Docker does everything in the open, and then integrates it into a product that you can use. If you don't like the product, if you want an alternative, then you still have all the pieces in the open right now. I would say, no. Not only is Docker not going closed, we're actually accelerating the rate at which we're opening up stuff. >> Personally, I felt it was a nice maturation of what you've done before, which was batteries are included but swappable. But we've taken the next step. It reminds me of those cool little science kits my kids get. Where it's like, oh okay, I could free build it or I can do it or I could do some other things. >> We use that tagline. It used to be, Docker has batteries included, but swappable. You can make other batteries and we'll swap them in to the product. We'll decide what's in there. Now everyone can do the swapping. It's a big free-for-all. Honestly, it's fun to watch. >> Is there any piece of Docker, the project, outside of core Docker, that Docker the company will refrain from building, will rely on ISVs to build? Or will Docker the company get involved, or reserve for itself the latitude to get involved in development of more peripheral pieces of the overall project going forward? >> We spent a lot of time thinking about that. Honestly, there's so many different constraints, we just decided we're going to follow the users, follow the customers. We just want a platform that works and solves people's problems. That's the starting point. From there, we work out the implementation details, what technology to use, the order in which to build things. Also, what makes more sense in the core platform and what makes more sense as an add-on. It's kind of on a case-by-case basis. >> Is there a grand vision document or functional service layered architecture that all of these components of the project are implementing or enabling? In other words, will Docker, as a project ever be complete or will it always be open-ended, will it constantly evolve and possibly broaden in scope continuously, indefinitely? >> If you look at the Moby Project on the one side, with experimentations and all the building blocks, I think that's going to just continuously expand. Really, openness is all about scale. There's only so much one company can build on their own, but if you really show the Ecosystem you're serious about really welcoming everybody and allowing for different opinions and approaches, then, honestly, I think there's no limit to how large that project can scale. I think Moby can go into tens of thousands of contributors as open source becomes easier and more accessible, which we're really working on, I think it can go into hundreds of thousands. That's going to take a while. That will, I think, never end growing. I think Docker, the product, the company, the reason we've been so successful is that we've been, well at least we've worked really hard to focus and be disciplined in what problems we want to solve, so it's a more iterative approach. We would rather solve less problems, but solve them really, really well, so that if you're using Docker for developing or going to production, you're really delighted Just every detail kind of fits together. There's a roadmap, of course. We're going to do more and more. But we don't want to rush trying to do everything. >> Solomon, great progress on all of these pieces. I've got the tough one for you. In the last year or so, Kubernetes has really exploded out there. Lots of your Ecosystem is heavily using it. Is it that Docker Swarm and Kubernetes will just be options out there? I look at Microsoft Dasher and they're very supportive of both initiatives. Many of your partners are there. How do you guys look at that dynamic and how would you like people to think of that going forward? >> It's a great case study of why we're transitioning to this open project model with Moby. The whole point is that at any given time, Docker, the product, will not be using all of the building blocks out there. It's just not possible. There's too many permutations. So we have to chose. One of these building blocks is orchestration. A year ago when we decided to build an orchestration, we had really specific opinions on what it should look like, as product builders. We looked around and we decided it needs to be a new kind of a building block. So we built Swarm Kits for our own use and we integrated it. Now that there's an open project for elaboration, we're throwing Swarm Kit in there so that everyone can modify it, extend it, and also replace it with something else. I think the big change, now, is that if you look at something like Kubernetes or Rocket as a container on time. Honestly, I could make a super long list of all the components out there that are really cool and we don't use in Docker. Now you can combine them all in Moby in custom assemblies. And we actually demoed that on stage yesterday. We showed taking some pieces from Docker and taking Kubernetes as a piece and plugging it together and saying "Look, there you go! "Weekend project." I think we're going to see a lot of conversions and reuse of ideas and codes, especially in the orchestration piece. I think over time, the differences between Kubernetes, Swarm Kit, and others will really diminish. We'll just integrate the bits and pieces that make the most sense. I don't really think of Kubernetes as a competitor or a problem. I think of it as another cool component in the Moby Ecosystem. Yeah, I think it's a lot of cool stuff. >> I tell ya, the Kubernetes community is just so thrilled that containerd is now open source. It really solves that issue and really it hasn't been something I've heard a lot, coming into the show. It's one of the themes we wanted to look at, and it hasn't been something that is like, Oh boy! Fight, war, anything like that. Hey! Congrats on that! I want to turn back to your root there. I think about dotCloud to Docker. It's a lot about the application modernization. Fast forward to today, Ben's up on stage talking of the journey. How do we take your legacy applications and wrap them in? What do you think about that kind of progression? We like that spectrum out there to help customers, at least partially, and be able to make changes. But I can't imagine that's when you started Docker that that was one of the use cases that you really thought you'd use. What surprised you? What's changed how you built things? What do you see from customers? >> Actually, you'll find this surprising, but this actually was a use case that we had in mind from the very beginning. I think that was lost in the noise for the first few years in the life of Docker because it became this exciting, new thing. >> Come on, Cloud native, Cloud native! >> Yeah, exactly! Docker has a huge developer community now. We spent a lot of time making it great for devs. The truth is, I used to be sysadmin. I used to be on call. I'm an ops guy first and we learned how to help developers. Developers are the customer. The Docker came out of our ops roots and then it evolved to help the developers. That's something that's now lost in the noise of history. It's a really pragmatic tool. It's built to solve real problems. One design opinion we baked in from the beginning is that it has to allow you to do things incrementally. If Docker forces you to throw away what you have, just to get the benefits, then we screwed up. The whole point is that Docker can adapt to what you're doing. For example, you'll see a lot of details in how Docker's designed to allow for stateful applications to run in there, to allow for your own network model to fit. Before Docker, all the containers solutions, all the paths, required you to change your app. Even things like port discovery. You had to change the source code. Docker did not require that. It gives you extra things you can do if you want to go further. But the starting point is incremental. Honestly, I'm really glad that now that's resonating, that we're reaching that point in the community where there's a lot of people using Docker interested in that, because for a few years I was worried that that would be missed in the noise of early adopters that don't mind rewriting everything. From the beginning, Docker was not just for Cloud-Native, microservices, Twelve-Factor, etc. I'm, personally, as a designer of products, as a pragmatist, I'm just happy that we're there. >> How do you see Docker evolving to support more complex orchestrations for data? For hybrid data cloud, environments private and public? You got the likes of Microsoft, Oracle, and IBM as partners and so forth. They have these complex scenarios now, their customers or petabytes scale and so forth. Where do you see that going, the data, the persistence of storage side of the containerization under Docker going? >> I think there's a lot of work to do. I think over time we're going to see specialized solutions for different uses of data. Data has such a big word. It's like computing. Just like computing now is no longer considered one category but it's specialized, I think data will be the same. I think it's a great fit for this modular Lego approach to the Docker Ecosystem. We're going to see different approaches to different data models, and I think we're going to see a lot modularization and a lot of different assemblies. Again, I think a lot of that will happen in Moby and we'll see a lot of cool, open stuff. We, ourselves, are facing a lot of data related questions, in request for customers. There's stuff in there already. You've got data volumes. And I think you're going to see a lot more on the data topic in the next year. >> Like containerization of artificial intelligence and deep learning and all that. Clearly, that's very incognito so far because, yeah. >> We're seeing a lot of really cool machine learning use cases using Docker already. OpenAI is all on Docker. We watch what they're doing with great interest. >> Are you a member of that consortium? >> Let's say friends and family (laughs). So OpenAI came out of the Y Combinator Ecosystem and Docker is a Y Combinator company. We spend a lot of time with them. I think AI on Docker is a really cool use case. I'm a big fan of that. >> Jim: Cool! Us too! >> Solomon, unfortunately, we're runnin' low on time. Last question I have for you is, there is so many things we can do with Docker now. Here's a bunch of the use cases like, "Oh, I can run lots of applications." Everything from Oracles in the store now, things like that. What is the quick win when you're talking to customers and let's get started? What's the thing that gets them the most excited that impacts their business the fastest? >> Ya know, it's-- >> And it never comes down to one thing, but, ya know. >> Honestly, we keep talking about Lego. I think it's like asking, what's your favorite Lego toy? I think we're maturing in the model. I think Lego is just the perfect analogy because it's a lot of building blocks. There's more and more, but there's also the sets. I think we're consolidating around a few different sets. There's maybe a dozen main use cases. We're seeing people identify with one, and then we're helping them see a starting point there. Here's a starter set for your problem, and then it clicks. >> Yeah, I hear that, and I can't help but think back. You're the big green platform that all my Legos build on. I can have my space stuff. I can have my farm set. Maybe the Duplos don't quite fit on it. It's the platform helping me to modernize a lot of what we're doing. Solomon Hykes, always a pleasure to catch up. >> Likewise! Congratulations on all the progress here, and we look forward to catching up with you the next time! We'll be back. Jim and I will be back with lots more coverage here from DockerCon 2017. You're watching theCUBE. (electronic music)

>>Hi everybody. This is Dave Volante. Welcome to this cube conversation where we're going to go back in time a little bit and explore the early days of Kubernetes. Talk about how it formed the improbable events, perhaps that led to it. And maybe how customers are taking advantage of containers and container orchestration today, and maybe where the industry is going. Matt Provo is here. He's the founder and CEO of storm forge and Chandler Huntington hoes. Hoisington is the general manager of EKS edge and hybrid AWS guys. Thanks for coming on. Good to see you. Thanks for having me. Thanks. So, Jenny, you were the vice president of engineering at miso sphere. Is that, is that correct? >>Well, uh, vice-president engineering basis, fear and then I ran product and engineering for DTQ masons. >>Yeah. Okay. Okay. So you were there in the early days of, of container orchestration and Matt, you, you were working at a S a S a Docker swarm shop, right? Yep. Okay. So I mean, a lot of people were, you know, using your platform was pretty novel at the time. Uh, it was, it was more sophisticated than what was happening with, with Kubernetes. Take us back. What was it like then? Did you guys, I mean, everybody was coming out. I remember there was, I think there was one Docker con and everybody was coming, the Kubernetes was announced, and then you guys were there, doc Docker swarm was, was announced and there were probably three or four other startups doing kind of container orchestration. And what, what were those days like? Yeah. >>Yeah. I wasn't actually atmosphere for those days, but I know them well, I know the story as well. Um, uh, I came right as we started to pivot towards Kubernetes there, but, um, it's a really interesting story. I mean, obviously they did a documentary on it and, uh, you know, people can watch that. It's pretty good. But, um, I think that, from my perspective, it was, it was really interesting how this happened. You had basically, uh, con you had this advent of containers coming out, right? So, so there's new novel technology and Solomon, and these folks started saying, Hey, you know, wait a second, wait if I put a UX around these couple of Linux features that got launched a couple of years ago, what does that look like? Oh, this is pretty cool. Um, so you have containers starting to crop up. And at the same time you had folks like ThoughtWorks and other kind of thought leaders in the space, uh, starting to talk about microservices and saying, Hey, monoliths are bad and you should break up these monoliths into smaller pieces. >>And any Greenfield application should be broken up into individuals, scalable units that a team can can own by themselves, and they can scale independent of each other. And you can write tests against them independently of other components. And you should break up these big, big mandalas. And now we are kind of going back to model this, but that's for another day. Um, so, so you had microservices coming out and then you also had containers coming out, same time. So there was like, oh, we need to put these microservices in something perfect. We'll put them in containers. And so at that point, you don't really, before that moment, you didn't really need container orchestration. You could just run a workload in a container and be done with it, right? You didn't need, you don't need Kubernetes to run Docker. Um, but all of a sudden you had tons and tons of containers and you had to manage these in some way. >>And so that's where container orchestration came, came from. And, and Ben Heineman, the founder of Mesa was actually helping schedule spark at the time at Berkeley. Um, and that was one of the first workloads with spark for Macy's. And then his friends at Twitter said, Hey, come over, can you help us do this with containers at Twitter? He said, okay. So when it helped them do it with containers at Twitter, and that's kinda how that branch of the container wars was started. And, um, you know, it was really, really great technology and it actually is still in production in a lot of shops today. Um, uh, more and more people are moving towards Kubernetes and Mesa sphere saw that trend. And at the end of the day, Mesa sphere was less concerned about, even though they named the company Mesa sphere, they were less concerned about helping customers with Mesa specifically. They really want to help customers with these distributed problems. And so it didn't make sense to, to just do Mesa. So they would took on Kubernetes as well. And I hope >>I don't do that. I remember, uh, my, my co-founder John furrier introduced me to Jerry Chen way back when Jerry is his first, uh, uh, VC investment with Greylock was Docker. And we were talking in these very, obviously very excited about it. And, and his Chandler was just saying, it said Solomon and the team simplified, you know, containers, you know, simple and brilliant. All right. So you guys saw the opportunity where you were Docker swarm shop. Why? Because you needed, you know, more sophisticated capabilities. Yeah. But then you, you switched why the switch, what was happening? What was the mindset back then? We ran >>And into some scale challenges in kind of operationalize or, or productizing our kind of our core machine learning. And, you know, we, we, we saw kind of the, the challenges, luckily a bit ahead of our time. And, um, we happen to have someone on the team that was also kind of moonlighting, uh, as one of the, the original core contributors to Kubernetes. And so as this sort of shift was taking place, um, we, we S we saw the flexibility, uh, of what was becoming Kubernetes. Um, and, uh, I'll never forget. I left on a Friday and came back on a Monday and we had lifted and shifted, uh, to Kubernetes. Uh, the challenge was, um, you know, you, at that time, you, you didn't have what you have today through EKS. And, uh, those kinds of services were, um, just getting that first cluster up and running was, was super, super difficult, even in a small environment. >>And so I remember we, you know, we, we finally got it up and running and it was like, nobody touch it, don't do anything. Uh, but obviously that doesn't, that doesn't scale either. And so that's really, you know, being kind of a data science focused shop at storm forge from the very beginning. And that's where our core IP is. Uh, our, our team looked at that problem. And then we looked at, okay, there are a bunch of parameters and ways that I can tune this application. And, uh, why are the configurations set the way that they are? And, you know, uh, is there room to explore? And that's really where, unfortunately, >>Because Mesa said much greater enterprise capabilities as the Docker swarm, at least they were heading in that direction, but you still saw that Kubernetes was, was attractive because even though it didn't have all the security features and enterprise features, because it was just so simple. I remember Jen Goldberg who was at Google at the time saying, no, we were focused on keeping it simple and we're going from mass adoption, but does that kind of what you said? >>Yeah. And we made a bet, honestly. Uh, we saw that the, uh, you know, the growing community was really starting to, you know, we had a little bit of an inside view because we had, we had someone that was very much in the, in the original part, but you also saw the, the tool chain itself start to, uh, start to come into place right. A little bit. And it's still hardening now, but, um, yeah, we, as any, uh, as any startup does, we, we made a pivot and we made a bet and, uh, this, this one paid off >>Well, it's interesting because, you know, we said at the time, I mean, you had, obviously Amazon invented the modern cloud. You know, Microsoft has the advantage of has got this huge software stays, Hey, just now run it into the cloud. Okay, great. So they had their entry point. Google didn't have an entry point. This is kind of a hail Mary against Amazon. And, and I, I wrote a piece, you know, the improbable, Verizon, who Kubernetes to become the O S you know, the cloud, but, but I asked, did it make sense for Google to do that? And it never made any money off of it, but I would argue they, they were kind of, they'd be irrelevant if they didn't have, they hadn't done that yet, but it didn't really hurt. It certainly didn't hurt Amazon EKS. And you do containers and your customers you've embraced it. Right. I mean, I, I don't know what it was like early days. I remember I've have talked to Amazon people about this. It's like, okay, we saw it and then talk to customers, what are they doing? Right. That's kind of what the mindset is, right? Yeah. >>That's, I, I, you know, I've, I've been at Amazon a couple of years now, and you hear the stories of all we're customer obsessed. We listened to our customers like, okay, okay. We have our company values, too. You get told them. And when you're, uh, when you get first hired in the first day, and you never really think about them again, but Amazon, that really is preached every day. It really is. Um, uh, and that we really do listen to our customers. So when customers start asking for communities, we said, okay, when we built it for them. So, I mean, it's, it's really that simple. Um, and, and we also, it's not as simple as just building them a Kubernetes service. Amazon has a big commitment now to start, you know, getting involved more in the community and working with folks like storm forage and, and really listening to customers and what they want. And they want us working with folks like storm florigen and that, and that's why we're doing things like this. So, well, >>It's interesting, because of course, everybody looks at the ecosystem, says, oh, Amazon's going to kill the ecosystem. And then we saw an article the other day in, um, I think it was CRN, did an article, great job by Amazon PR, but talk about snowflake and Amazon's relationship. And I've said many times snowflake probably drives more than any other ISV out there. And so, yeah, maybe the Redshift guys might not love snowflake, but Amazon in general, you know, they're doing great three things. And I remember Andy Jassy said to me, one time, look, we love the ecosystem. We need the ecosystem. They have to innovate too. If they don't, you know, keep pace, you know, they're going to be in trouble. So that's actually a healthy kind of a dynamic, I mean, as an ecosystem partner, how do you, >>Well, I'll go back to one thing without the work that Google did to open source Kubernetes, a storm forge wouldn't exist, but without the effort that AWS and, and EKS in particular, um, provides and opens up for, for developers to, to innovate and to continue, continue kind of operationalizing the shift to Kubernetes, um, you know, we wouldn't have nearly the opportunity that we do to actually listen to them as well, listen to the users and be able to say, w w w what do you want, right. Our entire reason for existence comes from asking users, like, how painful is this process? Uh, like how much confidence do you have in the, you know, out of the box, defaults that ship with your, you know, with your database or whatever it is. And, uh, and, and how much do you love, uh, manually tuning your application? >>And, and, uh, obviously nobody's said, I love that. And so I think as that ecosystem comes together and continues expanding, um, it's just, it opens up a huge opportunity, uh, not only for existing, you know, EKS and, uh, AWS users to continue innovating, but for companies like storm forge, to be able to provide that opportunity for them as well. And, and that's pretty powerful. So I think without a lot of the moves they've made, um, you know, th the door wouldn't be nearly as open for companies like, who are, you know, growing quickly, but are smaller to be able to, you know, to exist. >>Well, and I was saying earlier that, that you've, you're in, I wrote about this, you're going to get better capabilities. You're clearly seeing that cluster management we've talked about better, better automation, security, the whole shift left movement. Um, so obviously there's a lot of momentum right now for Kubernetes. When you think about bare metal servers and storage, and then you had VM virtualization, VMware really, and then containers, and then Kubernetes as another abstraction, I would expect we're not at the end of the road here. Uh, what's next? Is there another abstraction layer that you would think is coming? Yeah, >>I mean, w for awhile, it looked like, and I remember even with our like board members and some of our investors said, well, you know, well, what about serverless? And, you know, what's the next Kubernetes and nothing, we, as much as I love Kubernetes, um, which I do, and we do, um, nothing about what we particularly do. We are purpose built for Kubernetes, but from a core kind of machine learning and problem solving standpoint, um, we could apply this elsewhere, uh, if we went that direction and so time will tell what will be next, then there will be something, uh, you know, that will end up, you know, expanding beyond Kubernetes at some point. Um, but, you know, I think, um, without knowing what that is, you know, our job is to, to, to serve our, you know, to serve our customers and serve our users in the way that they are asking for that. >>Well, serverless obviously is exploding when you look again, and we tucked the ETR survey data, when you look at, at the services within Amazon and other cloud providers, you know, the functions off, off the charts. Uh, so that's kind of an interesting and notable now, of course, you've got Chandler, you've got edge in your title. You've got hybrid in, in your title. So, you know, this notion of the cloud expanding, it's not just a set of remote services, just only in the public cloud. Now it's, it's coming to on premises. You actually got Andy, Jesse, my head space. He said, one time we just look at it. The data centers is another edge location. Right. Okay. That's a way to look at it and then you've got edge. Um, so that cloud is expanding, isn't it? The definition of cloud is, is, is evolving. >>Yeah, that's right. I mean, customers one-on-one run workloads in lots of places. Um, and that's why we have things like, you know, local zones and wavelengths and outposts and EKS anywhere, um, EKS, distro, and obviously probably lots more things to come. And there's, I always think of like, Amazon's Kubernetes strategy on a manageability scale. We're on one far end of the spectrum, you have EKS distro, which is just a collection of the core Kubernetes packages. And you could, you could take those and stand them up yourself in a broom closet, in a, in a retail shop. And then on the other far in the spectrum, you have EKS far gate where you can just give us your container and we'll handle everything for you. Um, and then we kind of tried to solve everything in between for your data center and for the cloud. And so you can, you can really ask Amazon, I want you to manage my control plane. I want you to manage this much of my worker nodes, et cetera. And oh, I actually want help on prem. And so we're just trying to listen to customers and solve their problems where they're asking us to solve them. Cut, >>Go ahead. No, I would just add that in a more vertically focused, uh, kind of orientation for us. Like we, we believe that op you know, optimization capabilities should transcend the location itself. And, and, and so whether that's part public part, private cloud, you know, that's what I love part of what I love about EKS anywhere. Uh, it, you know, you shouldn't, you should still be able to achieve optimal results that connect to your business objectives, uh, wherever those workloads, uh, are, are living >>Well, don't wince. So John and I coined this term called Supercloud and people laugh about it, but it's different. It's, it's, you know, people talk about multi-cloud, but that was just really kind of vendor diversity. Right? I got to running here, I'm running their money anywhere. Uh, but, but individually, and so Supercloud is this concept of this abstraction layer that floats wherever you are, whether it's on prem, across clouds, and you're taking advantage of those native primitives, um, and then hiding that underlying complexity. And that's what, w re-invent the ecosystem was so excited and they didn't call it super cloud. We, we, we called it that, but they're clearly thinking differently about the value that they can add on top of Goldman Sachs. Right. That to me is an example of a Supercloud they're taking their on-prem data and their, their, their software tooling connecting it to AWS. They're running it on AWS, but they're, they're abstracting that complexity. And I think you're going to see a lot, a lot more of that. >>Yeah. So Kubernetes itself, in many cases is being abstracted away. Yeah. There's a disability of a disappearing act for Kubernetes. And I don't mean that in a, you know, in an, a, from an adoption standpoint, but, uh, you know, Kubernetes itself is increasingly being abstracted away, which I think is, is actually super interesting. Yeah. >>Um, communities doesn't really do anything for a company. Like we run Kubernetes, like, how does that help your bottom line? That at the end of the day, like companies don't care that they're running Kubernetes, they're trying to solve a problem, which is the, I need to be able to deploy my applications. I need to be able to scale them easily. I need to be able to update them easily. And those are the things they're trying to solve. So if you can give them some other way to do that, I'm sure you know, that that's what they want. It's not like, uh, you know, uh, a big bank is making more money because they're running Kubernetes. That's not, that's not the current, >>It gets subsumed. It's just become invisible. Right. Exactly. You guys back to the office yet. What's, uh, what's the situation, >>You know, I, I work for my house and I, you know, we go into the office a couple of times a week, so it's, it's, uh, yeah, it's, it's, it's a crazy time. It's a crazy time to be managing and hiring. And, um, you know, it's, it's, it's, it's definitely a challenge, but there's a lot of benefits of working home. I got two young kids, so I get to see them, uh, grow up a little bit more working, working out of my house. So it's >>Nice also. >>So we're in, even as a smaller startup, we're in 26, 27 states, uh, Canada, Germany, we've got a little bit of presence in Japan, so we're very much distributed. Um, we, uh, have not gone back and I'm not sure we will >>Permanently remote potentially. >>Yeah. I mean, w we made a, uh, pretty like for us, the timing of our series B funding, which was where we started hiring a lot, uh, was just before COVID started really picking up. So we, you know, thankfully made a, a pretty good strategic decision to say, we're going to go where the talent is. And yeah, it was harder to find for sure, especially in w we're competing, it's incredibly competitive. Uh, but yeah, we've, it was a good decision for us. Um, we are very about, you know, getting the teams together in person, you know, as often as possible and in the safest way possible, obviously. Um, but you know, it's been a, it's been a pretty interesting, uh, journey for us and something that I'm, I'm not sure I would, I would change to be honest with you. Yeah. >>Well, Frank Slootman, snowflakes HQ to Montana, and then can folks like Michael Dell saying, Hey, same thing as you, wherever they want to work, bring yourself and wherever you are as cool. And do you think that the hybrid mode for your team is kind of the, the, the operating mode for the, for the foreseeable future is a couple of, >>No, I think, I think there's a lot of benefits in both working from the office. I don't think you can deny like the face-to-face interactions. It feels good just doing this interview face to face. Right. And I can see your mouth move. So it's like, there's a lot of benefits to that, um, over a chime call or a zoom call or whatever, you know, that, that also has advantages, right. I mean, you can be more focused at home. And I think some version of hybrid is probably in the industry's future. I don't know what Amazon's exact plans are. That's above my pay grade, but, um, I know that like in general, the industry is definitely moving to some kind of hybrid model. And like Matt said, getting people I'm a big fan at Mesa sphere, we ran a very diverse, like remote workforce. We had a big office in Germany, but we'd get everybody together a couple of times a year for engineering week or, or something like this. And you'd get a hundred people, you know, just dedicated to spending time together at a hotel and, you know, Vegas or Hamburg or wherever. And it's a really good time. And I think that's a good model. >>Yeah. And I think just more ETR data, the current thinking now is that, uh, the hybrid is the number one sort of model, uh, 36% that the CIO is believe 36% of the workforce are going to be hybrid permanently is kind of their, their call a couple of days in a couple of days out. Um, and the, the percentage that is remote is significantly higher. It probably, you know, high twenties, whereas historically it's probably 15%. Yeah. So permanent changes. And that, that changes the infrastructure. You need to support it, the security models and everything, you know, how you communicate. So >>When COVID, you know, really started hitting and in 2020, um, the big banks for example, had to, I mean, you would want to talk about innovation and ability to, to shift quickly. Two of the bigger banks that have in, uh, in fact, adopted Kubernetes, uh, were able to shift pretty quickly, you know, systems and things that were, you know, historically, you know, it was in the office all the time. And some of that's obviously shifted back to a certain degree, but that ability, it was pretty remarkable actually to see that, uh, take place for some of the larger banks and others that are operating in super regulated environments. I mean, we saw that in government agencies and stuff as well. >>Well, without the cloud, no, this never would've happened. Yeah. >>And I think it's funny. I remember some of the more old school manager thing people are, aren't gonna work less when they're working from home, they're gonna be distracted. I think you're seeing the opposite where people are too much, they get burned out because you're just running your computer all day. And so I think that we're learning, I think everyone, the whole industry is learning. Like, what does it mean to work from home really? And, uh, it's, it's a fascinating thing is as a case study, we're all a part of right now. >>I was talking to my wife last night about this, and she's very thoughtful. And she w when she was in the workforce, she was at a PR firm and a guy came in a guest speaker and it might even be in the CEO of the company asking, you know, what, on average, what time who stays at the office until, you know, who leaves by five o'clock, you know, a few hands up, or who stays until like eight o'clock, you know, and enhancement. And then, so he, and he asked those people, like, why, why can't you get your work done in a, in an eight hour Workday? I go home. Why don't you go in? And I sit there. Well, that's interesting, you know, cause he's always looking at me like, why can't you do, you know, get it done? And I'm saying the world has changed. Yeah. It really has where people are just on all the time. I'm not sure it's sustainable, quite frankly. I mean, I think that we have to, you know, as organizations think about, and I see companies doing it, you guys probably do as well, you know, take a four day, you know, a week weekend, um, just for your head. Um, but it's, there's no playbook. >>Yeah. Like I said, we're a part of a case study. It's also hard because people are distributed now. So you have your meetings on the east coast, you can wake up at seven four, and then you have meetings on the west coast. You stay until seven o'clock therefore, so your day just stretches out. So you've got to manage this. And I think we're, I think we'll figure it out. I mean, we're good at figuring this stuff. >>There's a rise in asynchronous communication. So with things like slack and other tools, as, as helpful as they are in many cases, it's a, it, isn't always on mentality. And like, people look for that little green dot and you know, if you're on the you're online. So my kids, uh, you know, we have a term now for me, cause my office at home is upstairs and I'll come down. And if it's, if it's during the day, they'll say, oh dad, you're going for a walk and talk, you know, which is like, it was my way of getting away from the desk, getting away from zoom. And like, you know, even in Boston, uh, you know, getting outside, trying to at least, you know, get a little exercise or walk and get, you know, get my head away from the computer screen. Um, but even then it's often like, oh, I'll get a slack notification on my phone or someone will call me even if it's not a scheduled walk and talk. Um, uh, and so it is an interesting, >>A lot of ways to get in touch or productivity is presumably going to go through the roof. But now, all right, guys, I'll let you go. Thanks so much for coming to the cube. Really appreciate it. And thank you for watching this cube conversation. This is Dave Alante and we'll see you next time.

>> From theCUBE studios in Palo Alto, in Boston, bringing you data driven insights from theCUBE and ETR. This is Breaking Analysis with Dave Vollante. >> The rise of Kubernetes came about through a combination of forces that were, in hindsight, quite a long shot. Amazon's dominance created momentum for Cloud native application development, and the need for newer and simpler experiences, beyond just easily spinning up computer as a service. This wave crashed into innovations from a startup named Docker, and a reluctant competitor in Google, that needed a way to change the game on Amazon and the Cloud. Now, add in the effort of Red Hat, which needed a new path beyond Enterprise Linux, and oh, by the way, it was just about to commit to a path of a Kubernetes alternative for OpenShift and figure out a governance structure to hurt all the cats and the ecosystem and you get the remarkable ascendancy of Kubernetes. Hello and welcome to this week's Wikibon CUBE Insights powered by ETR. In this breaking analysis, we tapped the back stories of a new documentary that explains the improbable events that led to the creation of Kubernetes. We'll share some new survey data from ETR and commentary from the many early the innovators who came on theCUBE during the exciting period since the founding of Docker in 2013, which marked a new era in computing, because we're talking about Kubernetes and developers today, the hoodie is on. And there's a new two part documentary that I just referenced, it's out and it was produced by Honeypot on Kubernetes, part one and part two, tells a story of how Kubernetes came to prominence and many of the players that made it happen. Now, a lot of these players, including Tim Hawkin Kelsey Hightower, Craig McLuckie, Joe Beda, Brian Grant Solomon Hykes, Jerry Chen and others came on theCUBE during formative years of containers going mainstream and the rise of Kubernetes. John Furrier and Stu Miniman were at the many shows we covered back then and they unpacked what was happening at the time. We'll share the commentary from the guests that they interviewed and try to add some context. Now let's start with the concept of developer defined structure, DDI. Jerry Chen was at VMware and he could see the trends that were evolving. He left VMware to become a venture capitalist at Greylock. Docker was his first investment. And he saw the future this way. >> What happens is when you define infrastructure software you can program it. You make it portable. And that the beauty of this cloud wave what I call DDI's. Now, to your point is every piece of infrastructure from storage, networking, to compute has an API, right? And, and AWS there was an early trend where S3, EBS, EC2 had API. >> As building blocks too. >> As building blocks, exactly. >> Not monolithic. >> Monolithic building blocks every little building bone block has it own API and just like Docker really is the API for this unit of the cloud enables developers to define how they want to build their applications, how to network them know as Wills talked about, and how you want to secure them and how you want to store them. And so the beauty of this generation is now developers are determining how apps are built, not just at the, you know, end user, you know, iPhone app layer the data layer, the storage layer, the networking layer. So every single level is being disrupted by this concept of a DDI and where, how you build use and actually purchase IT has changed. And you're seeing the incumbent vendors like Oracle, VMware Microsoft try to react but you're seeing a whole new generation startup. >> Now what Jerry was explaining is that this new abstraction layer that was being built here's some ETR data that quantifies that and shows where we are today. The chart shows net score or spending momentum on the vertical axis and market share which represents the pervasiveness in the survey set. So as Jerry and the innovators who created Docker saw the cloud was becoming prominent and you can see it still has spending velocity that's elevated above that 40% red line which is kind of a magic mark of momentum. And of course, it's very prominent on the X axis as well. And you see the low level infrastructure virtualization and that even floats above servers and storage and networking right. Back in 2013 the conversation with VMware. And by the way, I remember having this conversation deeply at the time with Chad Sakac was we're going to make this low level infrastructure invisible, and we intend to make virtualization invisible, IE simplified. And so, you see above the two arrows there related to containers, container orchestration and container platforms, which are abstraction layers and services above the underlying VMs and hardware. And you can see the momentum that they have right there with the cloud and AI and RPA. So you had these forces that Jerry described that were taking shape, and this picture kind of summarizes how they came together to form Kubernetes. And the upper left, Of course you see AWS and we inserted a picture from a post we did, right after the first reinvent in 2012, it was obvious to us at the time that the cloud gorilla was AWS and had all this momentum. Now, Solomon Hykes, the founder of Docker, you see there in the upper right. He saw the need to simplify the packaging of applications for cloud developers. Here's how he described it. Back in 2014 in theCUBE with John Furrier >> Container is a unit of deployment, right? It's the format in which you package your application all the files, all the executables libraries all the dependencies in one thing that you can move to any server and deploy in a repeatable way. So it's similar to how you would run an iOS app on an iPhone, for example. >> A Docker at the time was a 30% company and it just changed its name from .cloud. And back to the diagram you have Google with a red question mark. So why would you need more than what Docker had created. Craig McLuckie, who was a product manager at Google back then explains the need for yet another abstraction. >> We created the strong separation between infrastructure operations and application operations. And so, Docker has created a portable framework to take it, basically a binary and run it anywhere which is an amazing capability, but that's not enough. You also need to be able to manage that with a framework that can run anywhere. And so, the union of Docker and Kubernetes provides this framework where you're completely abstracted from the underlying infrastructure. You could use VMware, you could use Red Hat open stack deployment. You could run on another major cloud provider like rec. >> Now Google had this huge cloud infrastructure but no commercial cloud business compete with AWS. At least not one that was taken seriously at the time. So it needed a way to change the game. And it had this thing called Google Borg, which is a container management system and scheduler and Google looked at what was happening with virtualization and said, you know, we obviously could do better Joe Beda, who was with Google at the time explains their mindset going back to the beginning. >> Craig and I started up Google compute engine VM as a service. And the odd thing to recognize is that, nobody who had been in Google for a long time thought that there was anything to this VM stuff, right? Cause Google had been on containers for so long. That was their mindset board was the way that stuff was actually deployed. So, you know, my boss at the time, who's now at Cloudera booted up a VM for the first time, and anybody in the outside world be like, Hey, that's really cool. And his response was like, well now what? Right. You're sitting at a prompt. Like that's not super interesting. How do I run my app? Right. Which is, that's what everybody's been struggling with, with cloud is not how do I get a VM up? How do I actually run my code? >> Okay. So Google never really did virtualization. They were looking at the market and said, okay what can we do to make Google relevant in cloud. Here's Eric Brewer from Google. Talking on theCUBE about Google's thought process at the time. >> One interest things about Google is it essentially makes no use of virtual machines internally. And that's because Google started in 1998 which is the same year that VMware started was kind of brought the modern virtual machine to bear. And so Google infrastructure tends to be built really on kind of classic Unix processes and communication. And so scaling that up, you get a system that works a lot with just processes and containers. So kind of when I saw containers come along with Docker, we said, well, that's a good model for us. And we can take what we know internally which was called Borg a big scheduler. And we can turn that into Kubernetes and we'll open source it. And suddenly we have kind of a cloud version of Google that works the way we would like it to work. >> Now, Eric Brewer gave us the bumper sticker version of the story there. What he reveals in the documentary that I referenced earlier is that initially Google was like, why would we open source our secret sauce to help competitors? So folks like Tim Hockin and Brian Grant who were on the original Kubernetes team, went to management and pressed hard to convince them to bless open sourcing Kubernetes. Here's Hockin's explanation. >> When Docker landed, we saw the community building and building and building. I mean, that was a snowball of its own, right? And as it caught on we realized we know what this is going to we know once you embrace the Docker mindset that you very quickly need something to manage all of your Docker nodes, once you get beyond two or three of them, and we know how to build that, right? We got a ton of experience here. Like we went to our leadership and said, you know, please this is going to happen with us or without us. And I think it, the world would be better if we helped. >> So the open source strategy became more compelling as they studied the problem because it gave Google a way to neutralize AWS's advantage because with containers you could develop on AWS for example, and then run the application anywhere like Google's cloud. So it not only gave developers a path off of AWS. If Google could develop a strong service on GCP they could monetize that play. Now, focus your attention back to the diagram which shows this smiling, Alex Polvi from Core OS which was acquired by Red Hat in 2018. And he saw the need to bring Linux into the cloud. I mean, after all Linux was powering the internet it was the OS for enterprise apps. And he saw the need to extend its path into the cloud. Now here's how he described it at an OpenStack event in 2015. >> Similar to what happened with Linux. Like yes, there is still need for Linux and Windows and other OSs out there. But by and large on production, web infrastructure it's all Linux now. And you were able to get onto one stack. And how were you able to do that? It was, it was by having a truly open consistent API and a commitment into not breaking APIs and, so on. That allowed Linux to really become ubiquitous in the data center. Yes, there are other OSs, but Linux buy in large for production infrastructure, what is being used. And I think you'll see a similar phenomenon happen for this next level up cause we're treating the whole data center as a computer instead of trading one in visual instance is just the computer. And that's the stuff that Kubernetes to me and someone is doing. And I think there will be one that shakes out over time and we believe that'll be Kubernetes. >> So Alex saw the need for a dominant container orchestration platform. And you heard him, they made the right bet. It would be Kubernetes. Now Red Hat, Red Hat is been around since 1993. So it has a lot of on-prem. So it needed a future path to the cloud. So they rang up Google and said, hey. What do you guys have going on in this space? So Google, was kind of non-committal, but it did expose that they were thinking about doing something that was you know, pre Kubernetes. It was before it was called Kubernetes. But hey, we have this thing and we're thinking about open sourcing it, but Google's internal debates, and you know, some of the arm twisting from the engine engineers, it was taking too long. So Red Hat said, well, screw it. We got to move forward with OpenShift. So we'll do what Apple and Airbnb and Heroku are doing and we'll build on an alternative. And so they were ready to go with Mesos which was very much more sophisticated than Kubernetes at the time and much more mature, but then Google the last minute said, hey, let's do this. So Clayton Coleman with Red Hat, he was an architect. And he leaned in right away. He was one of the first outside committers outside of Google. But you still led these competing forces in the market. And internally there were debates. Do we go with simplicity or do we go with system scale? And Hen Goldberg from Google explains why they focus first on simplicity in getting that right. >> We had to defend of why we are only supporting 100 nodes in the first release of Kubernetes. And they explained that they know how to build for scale. They've done that. They know how to do it, but realistically most of users don't need large clusters. So why create this complexity? >> So Goldberg explains that rather than competing right away with say Mesos or Docker swarm, which were far more baked they made the bet to keep it simple and go for adoption and ubiquity, which obviously turned out to be the right choice. But the last piece of the puzzle was governance. Now Google promised to open source Kubernetes but when it started to open up to contributors outside of Google, the code was still controlled by Google and developers had to sign Google paper that said Google could still do whatever it wanted. It could sub license, et cetera. So Google had to pass the Baton to an independent entity and that's how CNCF was started. Kubernetes was its first project. And let's listen to Chris Aniszczyk of the CNCF explain >> CNCF is all about providing a neutral home for cloud native technology. And, you know, it's been about almost two years since our first board meeting. And the idea was, you know there's a certain set of technology out there, you know that are essentially microservice based that like live in containers that are essentially orchestrated by some process, right? That's essentially what we mean when we say cloud native right. And CNCF was seated with Kubernetes as its first project. And you know, as, as we've seen over the last couple years Kubernetes has grown, you know, quite well they have a large community a diverse con you know, contributor base and have done, you know, kind of extremely well. They're one of actually the fastest, you know highest velocity, open source projects out there, maybe. >> Okay. So this is how we got to where we are today. This ETR data shows container orchestration offerings. It's the same X Y graph that we showed earlier. And you can see where Kubernetes lands not we're standing that Kubernetes not a company but respondents, you know, they doing Kubernetes. They maybe don't know, you know, whose platform and it's hard with the ETR taxon economy as a fuzzy and survey data because Kubernetes is increasingly becoming embedded into cloud platforms. And IT pros, they may not even know which one specifically. And so the reason we've linked these two platforms Kubernetes and Red Hat OpenShift is because OpenShift right now is a dominant revenue player in the space and is increasingly popular PaaS layer. Yeah. You could download Kubernetes and do what you want with it. But if you're really building enterprise apps you're going to need support. And that's where OpenShift comes in. And there's not much data on this but we did find this chart from AMDA which show was the container software market, whatever that really is. And Red Hat has got 50% of it. This is revenue. And, you know, we know the muscle of IBM is behind OpenShift. So there's really not hard to believe. Now we've got some other data points that show how Kubernetes is becoming less visible and more embedded under of the hood. If you will, as this chart shows this is data from CNCF's annual survey they had 1800 respondents here, and the data showed that 79% of respondents use certified Kubernetes hosted platforms. Amazon elastic container service for Kubernetes was the most prominent 39% followed by Azure Kubernetes service at 23% in Azure AKS engine at 17%. With Google's GKE, Google Kubernetes engine behind those three. Now. You have to ask, okay, Google. Google's management Initially they had concerns. You know, why are we open sourcing such a key technology? And the premise was, it would level the playing field. And for sure it has, but you have to ask has it driven the monetization Google was after? And I would've to say no, it probably didn't. But think about where Google would've been. If it hadn't open source Kubernetes how relevant would it be in the cloud discussion. Despite its distant third position behind AWS and Microsoft or even fourth, if you include Alibaba without Kubernetes Google probably would be much less prominent or possibly even irrelevant in cloud, enterprise cloud. Okay. Let's wrap up with some comments on the state of Kubernetes and maybe a thought or two about, you know, where we're headed. So look, no shocker Kubernetes for all its improbable beginning has gone mainstream in the past year or so. We're seeing much more maturity and support for state full workloads and big ecosystem support with respect to better security and continued simplification. But you know, it's still pretty complex. It's getting better, but it's not VMware level of maturity. For example, of course. Now adoption has always been strong for Kubernetes, for cloud native companies who start with containers on day one, but we're seeing many more. IT organizations adopting Kubernetes as it matures. It's interesting, you know, Docker set out to be the system of the cloud and Kubernetes has really kind of become that. Docker desktop is where Docker's action really is. That's where Docker is thriving. It sold off Docker swarm to Mirantis has made some tweaks. Docker has made some tweaks to its licensing model to be able to continue to evolve its its business. To hear more about that at DockerCon. And as we said, years ago we expected Kubernetes to become less visible Stu Miniman and I talked about this in one of our predictions post and really become more embedded into other platforms. And that's exactly what's happening here but it's still complicated. Remember, remember the... Go back to the early and mid cycle of VMware understanding things like application performance you needed folks in lab coats to really remediate problems and dig in and peel the onion and scale the system you know, and in some ways you're seeing that dynamic repeated with Kubernetes, security performance scale recovery, when something goes wrong all are made more difficult by the rapid pace at which the ecosystem is evolving Kubernetes. But it's definitely headed in the right direction. So what's next for Kubernetes we would expect further simplification and you're going to see more abstractions. We live in this world of almost perpetual abstractions. Now, as Kubernetes improves support from multi cluster it will be begin to treat those clusters as a unified group. So kind of abstracting multiple clusters and treating them as, as one to be managed together. And this is going to create a lot of ecosystem focus on scaling globally. Okay, once you do that, you're going to have to worry about latency and then you're going to have to keep pace with security as you expand the, the threat area. And then of course recovery what happens when something goes wrong, more complexity, the harder it is to recover and that's going to require new services to share resources across clusters. So look for that. You also should expect more automation. It's going to be driven by the host cloud providers as Kubernetes supports more state full applications and begins to extend its cluster management. Cloud providers will inject as much automation as possible into the system. Now and finally, as these capabilities mature we would expect to see better support for data intensive workloads like, AI and Machine learning and inference. Schedule with these workloads becomes harder because they're so resource intensive and performance management becomes more complex. So that's going to have to evolve. I mean, frankly, many of the things that Kubernetes team way back when, you know they back burn it early on, for example, you saw in Docker swarm or Mesos they're going to start to enter the scene now with Kubernetes as they start to sort of prioritize some of those more complex functions. Now, the last thing I'll ask you to think about is what's next beyond Kubernetes, you know this isn't it right with serverless and IOT in the edge and new data, heavy workloads there's something that's going to disrupt Kubernetes. So in that, by the way, in that CNCF survey nearly 40% of respondents were using serverless and that's going to keep growing. So how is that going to change the development model? You know, Andy Jassy once famously said that if they had to start over with Amazon retail, they'd start with serverless. So let's keep an eye on the horizon to see what's coming next. All right, that's it for now. I want to thank my colleagues, Stephanie Chan who helped research this week's topics and Alex Myerson on the production team, who also manages the breaking analysis podcast, Kristin Martin and Cheryl Knight help get the word out on socials, so thanks to all of you. Remember these episodes, they're all available as podcasts wherever you listen, just search breaking analysis podcast. Don't forget to check out ETR website @etr.ai. We'll also publish. We publish a full report every week on wikibon.com and Silicon angle.com. You can get in touch with me, email me directly david.villane@Siliconangle.com or DM me at D Vollante. You can comment on our LinkedIn post. This is Dave Vollante for theCUBE insights powered by ETR. Have a great week, everybody. Thanks for watching. Stay safe, be well. And we'll see you next time. (upbeat music)

(upbeat music) >> Hello, and welcome to this startup showcase. It's great to be here and talk about some of the innovations we are doing at AWS, how we work with our partner community, especially our open source partners. My name is Deepak Singh. I run our compute services organization, which is a very vague way of saying that I run a number of things that are connected together through compute. Very specifically, I run a container services organization. So for those of you who are into containers, ECS, EKS, fargate, ECR, App Runner Those are all teams that are within my org. I also run the Amazon Linux and BottleRocketing. So anything AWS does with Linux, both externally and internally, as well as our high-performance computing team. And perhaps very relevant to this discussion, I run the Amazon open source program office. Serving at AWS for over 13 years, almost 14, involved with compute in various ways, including EC2. What that has done has given me a vantage point of seeing how our customers use the services that we build for them, how they leverage various partner solutions, and along the way, how AWS itself has gotten involved with opensource. And I'll try and talk to you about some of those factors and how they impact, how you consume our services. So why don't we get started? So for many of you, you know, one of the things, there's two ways to look at AWS and open-source and Amazon in general. One is the number of contributors you may have. And the number of repositories that contribute to. Those are just a couple of measures. There are people that I work with on a regular basis, who will remind you that, those are not perfect measures. Sometimes you could just contribute to one thing and have outsized impact because of the nature of that thing. But it address being what it is, increasingly we'll look at different ways in which we can help contribute and enhance open source 'cause we consume a lot of it as well. I'll talk about it very specifically from the space that I work in the container space in particular, where we've worked a lot with people in the Kubernetes community. We've worked a lot with people in the broader CNCF community, as well as, you know, small projects that our customers might have got started off with. For example, I want to like talking about is Argo CD from Intuit. We were very actively involved with helping them figure out what to do with it. And it was great to see how into it. And we worked, etc, came together to think about get-ups at the Kubernetes level. And while those are their projects, we've always been involved with them. So we try and figure out what's important to our customers, how we can help and then take because of that. Well, let's talk about a little bit more, here's some examples of the kinds of open source projects that Amazon and AWS contribute to. They arranged from the open JDK. I think we even now have our own implementation of Java, the Corretto open source project. We contribute to projects like rust, where we are very active in the rest foundation from a leadership role as well, the robot operating system, just to pick some, we collaborate with Facebook and actively involved with the pirates project. And there's many others. You can see all the logos in here where we participate either because they're important to us as AWS in the services that we run or they're important to our customers and the services that they consume or the open source projects they care about and how we get to those. How we get and make those decisions is often depends on the importance of that particular project. At that point in time, how much impact they're having to AWS customers, or sometimes very feel that us contributing to that project is super critical because it helps us build more robust services. I'll talk about it in a completely, you know, somewhat different basis. You may have heard of us talk about our new next generation of Amazon Linux 2022, which is based on fedora as its sub stream. One of the reasons we made this decision was it allows us to go and participate in the preneurial project and make sure that the upstream project is robust, stays robust. And that, that what that ends up being is that Amazon Linux 2022 will be a robust operating system with the kinds of capabilities that our customers are asking for. That's just one example of how we think about it. So for example, you know, the Python software foundation is something that we work with very closely because so many of our customers use Python. So we help run something like PyPy which is many, you know, if you're a Python developer, I happened to be a Ruby one, but lots of our customers use Python and helping the Python project be robust by making sure PyPy is available to everybody is something that we help provide credits for help support in other ways. So it's not just code. It can mean many different ways of contributing as well, but in the end code and operations is where we hang our happens. Good examples of this is projects that we will create an open source because it makes sense to make sure that we open source some of the core primitives or foundations that are part of our own services. A great example of that, whether this be things that we open source or things that we contribute to. And I'll talk about both and I'll talk about things near and dear to my heart. There's many examples I've picked the two that I like talking about. The first of these is firecracker. Many of you have heard about it, a firecracker for those of you who don't know is a very lightweight virtual machine manager, which allows you to run these micro VMs. And why was this important many years ago when we started Lambda and quite honestly, Fugate and foggy, it still runs quite a bit in that mode, we used to have to run on VMs like everything else and finding the right VM for the size of tasks that somebody asks for the size of function that somebody asks for is requires us to provision capacity ahead of time. And it also wastes a lot of capacity because Lambda function is small. You won't even if you find the smallest VM possible, those can be a little that can be challenging. And you know, there's a lot of resources that are being wasted. VM start at a particular speed because they have to do a whole bunch of things before the operating system spins up and the virtual machine spins up and we asked ourselves, can we do better? come up with something that allows us to create right size, very lightweight, very fast booting. What's your machines, micro virtual machine that we ended up calling them. That's what led to firecracker. And we open source the project. And today firecrackers use, not just by AWS Lambda or foggy, but by a number of other folks, there's companies like fly IO that are using it. We know people using firecracker to run Kubernetes on prem on bare metal as an example. So we've seen a lot of other folks embrace it and use it as the foundation for building their own serverless services, their own container services. And we think there's a lot of value and learnings that we can bring to the table because we get the experience of operating at scale, but other people can bring to the table cause they may have specific requirements that we may not find it as important from an AWS perspective. So that's firecracker an example of a project where we contribute because we feel it's fundamentally important to us as continually. We were found, you know, we've been involved with continuity from the beginning. Today, we are a whole team that does nothing else, but contribute to container D because container D underlies foggy. It underlies our Kubernetes offerings. And it's increasingly being used by customers directly by their placement. You know, where they're running container D instead of running a full on Docker or similar container engine, what it has allowed us to do is focus on what's important so that we can operate continuously at scale, keep it robust and secure, add capabilities to it that AWS customers need manifested often through foggy Kubernetes, but in the end, it's a win-win for everybody. It makes continuously better. If you want to use containers for yourself on AWS, that's a great way to you. You know, you still, you still benefit from all the work that we're doing. The decision we took was since it's so important to us and our customers, we wanted a team that lived in breathed container D and made sure a super robust and there's many, many examples like that. No, that we ended up participating in, either by taking a project that exists or open sourcing our own. Here's an example of some of the open source projects that we have done from an AWS on Amazon perspective. And there's quite a few when I was looking at this list, I was quite surprised, not quite surprised I've seen the reports before, but every time I do, I have to recount and say, that's a lot more than one would have thought, even though I'd been looking at it for such a long time, examples of this in my world alone are things like, you know, what work had to do with Amazon Linux BottleRocket, which is a container host operating system. That's been open-sourced from day one. Firecracker is something we talked about. We have a project called AWS peril cluster, which allows you to spin up high performance computing clusters on AWS using the kind of schedulers you may use to use like slum. And that's an open source project. We have plenty of source projects in the web development space, in the security space. And more recently things like the open 3d engine, which is something that we are very excited about and that'd be open sourced a few months ago. And so there's a number of these projects that cover everything from tooling to developer, application frameworks, all the way to database and analytics and machine learning. And you'll notice that in a few areas, containers, as an example, machine learning as an example, our default is to go with open source option is where we can open source. And it makes sense for us to do so where we feel the product community might benefit from it. That's our default stance. The CNCF, the cloud native computing foundation is something that we've been involved with quite a bit. You know, we contribute to Kubernetes, be contribute to Envoy. I talked about continuity a bit. We've also contributed projects like CDK 8, which marries the AWS cloud development kit with Kubernetes. It's now a sandbox project in Kubernetes, and those are some of the areas. CNCF is such a wide surface area. We don't contribute to everything, but we definitely participate actively in CNCF with projects like HCB that are critical to eat for us. We are very, very active in just how the project evolves, but also try and see which of the projects that are important to our customers who are running Kubernetes maybe by themselves or some other project on AWS. Envoy is a good example. Kubernetes itself is a good example because in the end, we want to make sure that people running Kubernetes on AWS, even if they are not using our services are successful and we can help them, or we can work on the projects that are important to them. That's kind of how we think about the world. And it's worked pretty well for us. We've done a bunch of work on the Kubernetes side to make sure that we can integrate and solve a customer problem. We've, you know, from everything from models to work that we have done with gravity on our arm processor to a virtual GPU plugin that allows you to share and media GPU resources to the elastic fabric adapter, which are the network device for high performance computing that it can use at Kubernetes on AWS, along with things that directly impact Kubernetes customers like the CDKs project. I talked about work that we do with the container networking interface to the Amazon control of a Kubernetes, which is an open source project that allows you to use other AWS services directly from Kubernetes clusters. Again, you notice success, Kubernetes, not EKS, which is a managed Kubernetes service, because if we want you to be successful with Kubernetes and AWS, whether using our managed service or running your own, or some third party service. Similarly, we worked with premetheus. We now have a managed premetheus service. And at reinvent last year, we announced the general availability of this thing called carpenter, which is a provisioning and auto-scaling engine for Kubernetes, which is also an open source project. But here's the beauty of carpenter. You don't have to be using EKS to use it. Anyone running Kubernetes on AWS can leverage it. We focus on the AWS provider, but we've built it in such a way that if you wanted to take carpenter and implemented on prem or another cloud provider, that'd be completely okay. That's how it's designed and what we anticipated people may want to do. I talked a little bit about BottleRocket it's our Linux-based open-source operating system. And the thing that we have done with BottleRocket is make sure that we focus on security and the needs of customers who want to run orchestrated container, very focused on that problem. So for example, BottleRocket only has essential software needed to run containers, se Linux. I just notice it says that's the lineups, but I'm sure that, you know, Lena Torvalds will be pretty happy. And seeing that SE linux is enabled by default, we use things like DM Verity, and it has a read only root file system, no shell, you can assess it. You can install it if you wanted to. We allowed it to create different bill types, variants as we call them, you can create a variant for a non AWS resource as well. If you have your own homegrown container orchestrator, you can create a variant for that. It's designed to be used in many different contexts and all of that is open sourced. And then we use the update framework to publish and secure repository and kind of how this transactional system way of updating the software. And it's something that we didn't invent, but we have embraced wholeheartedly. It's a bottle rockets, completely open source, you know, have partners like Aqua, where who develop security tools for containers. And for them, you know, something I bought in rocket is a natural partnership because people are running a container host operating system. You can use Aqua tooling to make sure that they have a secure Indiana environment. And we see many more examples like that. You may think so over us, it's all about AWS proprietary technology because Lambda is a proprietary service. But you know, if you look peek under the covers, that's not necessarily true. Lambda runs on top of firecracker, as we've talked about fact crackers and open-source projects. So the foundation of Lambda in many ways is open source. What it also allows people to do is because Lambda runs at such extreme scale. One of the things that firecracker is really good for is running at scale. So if you want to build your own firecracker base at scale service, you can have most of the confidence that as long as your workload fits the design parameters, a firecracker, the battle hardening the robustness is being proved out day-to-day by services at scale like Lambda and foggy. For those of you who don't know service support services, you know, in the end, our goal with serverless is to make sure that you don't think about all the infrastructure that your applications run on. We focus on business logic as much as you can. That's how we think about it. And serverless has become its own quote-unquote "Sort of environment." The number of partners and open-source frameworks and tools that are spun up around serverless. In which case mostly, I mean, Lambda, API gateway. So it says like that is pretty high. So, you know, number of open source projects like Zappa server serverless framework, there's so many that have come up that make it easier for our customers to consume AWS services like Lambda and API gateway. We've also done some of our own tooling and frameworks, a serverless application model, AWS jealous. If you're a Python developer, we have these open service runtimes for Lambda, rust dot other options. We have amount of number of tools that we opened source. So in general, you'll find that tooling that we do runtime will tend to be always be open-sourced. We will often take some of the guts of the things that we use to build our systems like firecracker and open-source them while the control plane, etc, AWS services may end up staying proprietary, which is the case in Lambda. Increasingly our customers build their applications and leverage the broader AWS partner network. The AWS partner network is a network of partnerships that we've built of trusted partners. when you go to the APN website and find a partner, they know that that partner meets a certain set of criteria that AWS has developed, and you can rely on those partners for your own business. So whether you're a little tiny business that wants some function fulfill that you don't have the resources for or large enterprise that wants all these applications that you've been using on prem for a long time, and want to keep leveraging them in the cloud, you can go to APN and find that partner and then bring their solution on as part of your cloud infrastructure and could even be a systems integrator, for example, to help you solve this specific development problem that you may have a need for. Increasingly, you know, one of the things we like to do is work with an apartment community that is full of open-source providers. So a great one, there's so many, and you have, we have a panel discussion with many other partners as well, who make it easier for you to build applications on AWS, all open source and built on open source. But I like to call it a couple of them. The first one of them is TIDELIFT. TIDELIFT, For those of you who don't know is a company that provides SAS based tools to curate track, manage open source catalogs. You know, they have a whole network of maintainers and providers. They help, if you're an independent open developer, or a smart team should probably get to know TIDELIFT. They provide you benefits and, you know, capabilities as a developer and maintainer that are pretty unique and really help. And I've seen a number of our open source community embraced TIDELIFT quite honestly, even before they were part of the APN. But as part of the partner network, they get to participate in things like ISP accelerate and they get to they're officially an advanced tier partner because they are, they migrated the SAS offering onto AWS. But in the end, if you're part of the open source supply chain, you're a maintainer, you are a developer. I would recommend working with TIDELIFT because their goal is making all of you who are developing open source solutions, especially on AWS, more successful. And that's why I enjoy this partnership with them. And I'm looking to do a lot more because I think as a company, we want to make sure that open source developers don't feel like they are not supported because all you have to do is read various forums. It's challenging often to be a maintainer, especially of a small project. So I think with helping with licensing license management, security identification remediation, helping these maintainers is a big part of what TIDELIFT to us and it was great to see them as part of a partner network. Another partner that I like to call sysdig. I actually got introduced to them many years ago when they first launched. And one of the things that happened where they were super interested in some of our serverless stuff. And we've been trying to figure out how we can work together because all of our customers are interested in the capabilities that cystic provides. And over the last few years, he found a number of areas where we can collaborate. So sysdig, I know them primarily in a security company. So people use cystic to secure the bills, detect, you know, do threat response, threat detection, completely continuously validate their posture, get this continuous analytics signal on how they're doing and monitor performance. At the end of it, it's a SAS platform. They have a very nice open source security stack. The one I'm most familiar with. And I think most of you are probably familiar with is Falco. You know, sysdig, a CNCF project has been super popular. It's just to go SSS what 3, 37, 40 million downloads by now. So that's pretty, pretty cool. And they have been a great partner because we've had to do make sure that their solution works at target, which is not a natural place for their software to run, but there was enough demand and interest from our customers that, you know, or both companies leaned in to make sure they can be successful. So last year sister got a security competency. We have a number of specific competencies that we for our partners, they have integration and security hub is great. partners are lean in the way cystic has onto making our customer successful. And working with us are the best partners that we have. And there's a number of open source companies out there built on open source where their entire portfolio is built on open source software or the active participants like we are that we love working with on a day to day basis. So, you know, I think the thing I would like to, as we wind this out in this presentation is, you know, AWS is constantly looking for partnerships because our partners enable our customers. They could be with companies like Redis with Mongo, confluent with Databricks customers. Your default reaction might be, "Hey, these are companies that maybe compete with AWS." but no, I mean, I think we are partners as well, like from somebody at the lower end of the spectrum where people run on top of the services that I own on Linux and containers are SE 2, For us, these partners are just as important customers as any AWS service or any third party, 20 external customer. And so it's not a zero sum game. We look forward to working with all these companies and open source projects from an AWS perspective, a big part of how, where my open source program spends its time is making it easy for our developers to contribute, to open source, making it easy for AWS teams to decide when to open source software or participate in open source projects. Over the last few years, we've made significant changes in how we reduce the friction. And I think you can see it in the results that I showed you earlier in this stock. And the last one is one of the most important things that I say and I'll keep saying that, that we do as AWS is carry the pager. There's a lot of open source projects out there, operationalizing them, running them at scale is not easy. It's not all for whatever reason. It may not have anything to do with the software itself. But our core competency is taking that and being really good at operating it and becoming experts at operating it. And then ideally taking that expertise and experience and operating that project, that software and contributing back upstream. Cause that makes it better for everybody. And I think you'll see us do a lot more of that going forward. We've been doing that for the last few years, you know, in the container space, we do it every day. And I'm excited about the possibilities. With that. Thank you very much. And I hope you enjoy the rest of the showcase. >> Okay. Welcome back. We have Deepak sing here. We just had the keynote closing keynote vice-president of compute services. Deepak. Great to a great keynote, great wisdom and insight from that session. A very notable highlights and cutting edge trends and product information. Thanks for sharing. >> No, anytime it's always good to be here. It's too bad that we still doing this virtually, but always good to talk to you, John. >> We'll get hopefully through this way pretty quickly, I want to jump right in. Cause we don't have a lot of time. I want to get some quick question. You've brought up a good things. Open source innovation. Okay. Going next level. You've seen the rise of super clouds and super apps developing at open source. You're seeing big companies contributing, you know, you mentioned Argo into it. You're seeing that dynamic where companies are forming around this. This is a rising tide. This is, this is actually real. It's not the old school of, okay, here's a project. And then someone manages support and commercialization of it. It's actually platform in cloud scale. This is next gen. >> Yeah. And actually I think it started a few years ago. We can talk about a company that, you know, you're very familiar with as part of this event, which is armory many years ago, Netflix spun off this project called Spinnaker. A Spinnaker is CISED you know, CSED system that was developed at Netflix for their own purposes, but they chose to open solicit. And since then, it's become very popular with customers who want to use it even on prem. And you have a company that spun up on it. I think what's making this world very unique is you have very large companies like Facebook that will build things for themselves like VITAS or Netflix with Spinnaker and open source them. And you can have a lot of discussion about why they chose to do so, etc. But increasingly that's becoming the default when Amazon or Netflix or Facebook or Mehta, I guess you call them these days, build something for themselves for their own needs. The first question we ask ourselves is, should it be opensource? And increasingly we are all saying yes. And here's what happens because of that. It gives an opportunity depending on how you open source it for innovation through commercial deployments, so that you get SaaS companies, you know, that are going to take that product and make it relevant and useful to a very broad number of customers. You build partnerships with cloud providers like AWS, because our customers love this open source project and they need help. And they may choose an AWS managed service, or they may end up working with this partner on a day-to-day basis. And we want to work with that partner because they're making our customers successful, which is one reason all of us are here. So you're having this set of innovation from large companies from, you know, whether they are just consumer companies like Metta infrastructure companies like us, or just random innovation that's happening in an open source project that which ends up in companies being spun up and that foster that innovative innovation and that flywheel that's happening right now. And I think you said that like, this is unique. I mean, you never saw this happen before from so many different directions. >> It really is a nice progression on the business model side as well. You mentioned Argo, which is a great organic thing that was Intuit developed. We just interviewed code fresh. They just presented here in the showcase as well. You seeing the formation around these projects develop now in the community at a different scale. I mean, look at code fresh. I mean, Intuit did it Argo and they're not just supporting it. They're building a platform. So you seeing the dynamics of tools and now emerging the platforms, you mentioned Lambda, okay. Which is proprietary for AWS and your talk powered by open source. So again, open source combined with cloud scale allows for new potential super applications or super clouds that are developing. This is a new phenomenon. This isn't just lift and shift and host on the cloud. This is actually a construction production developer workflow. >> Yeah. And you are seeing consumers, large companies, enterprises, startups, you know, it used to be that startups would be comfortable adopting some of these solutions, but now you see companies of all sizes doing so. And I said, it's not just software it's software, the services increasingly becoming the way these are given, delivered to customers. I actually think the innovation is just getting going, which is why we have this. We have so many partners here who are all in inventing and innovating on top of open source, whether it's developed by them or a broader community. >> Yeah. I liked, I liked the represent container. Do you guys have, did that drove that you've seen a lot of changes and again, with cloud scale and open source, you seeing the dynamics change, whether you're enabling that, and then you see kind of like real big change. So let's take snowflake, a big customer of AWS. They started out as a startup too, but they weren't a data warehouse. They were bringing data warehouse like functionality and then changing everything differently and making it consumable for the cloud. And hence they're huge. So that's a disruption into an incumbent leader or sector. Then you've got new capabilities emerging. What's your thoughts, Deepak? Can you share your vision on how you have the disruption to existing leaders, old guard, if you will, as you guys call them and then new capabilities as these new platforms emerge at a net new functionality, how do you see that emerging? >> Yeah. So I speak from my side of the world. I've lived in over the last few years, which has containers and serverless, right? There's a lot of, if you go to any enterprise and ask them, do you want to modernize the infrastructure? Do you want to take advantage of automated software delivery, continuous delivery infrastructure as code modern observability, all of them will say yes, but they also are still a large enterprise, which has these enterprise level requirements. I'm using the word enterprise a lot. And I usually it's a trigger word for me because so many customers have similar requirements, but I'm using it here as large company with a lot of existing software and existing practices. I think the innovation that's coming and I see a lot of companies doing that is saying, "Hey, we understand the problems you want to solve. We understand the world where you live in, which could be regulated." You want to use all these new modalities. How do we allow you to use all of them? Keep the advantages of switching to a Lambda or switching to, and a service running on far gate, but give you the same capabilities. And I think I'll bring up cystic here because we work so closely with them on Falco. As an example, I just talked about them in my keynote. They could have just said, "Oh no, we'll just support the SE2 and be done with it." They said, "No, we're going to make sure that serverless containers in particular are something that you're going to be really good at because our customers want to use them, but requires us to think differently. And then they ended up developing new things like Falco that are born in this new world, but understand the requirements of the old world. If you get what I'm saying. And I think that a real example. >> Yeah. Oh, well, I mean, first of all, they're smart. So that was pretty obvious for most people that know, sees that you can connect the dots on serverless, which is a great point, but not everyone can see that again, this is what's new and and systig was just found in his backyard. As I found out on my interview, a great, great founder, they would do a new thing. So it was a very easy to connect the dots there again, that's the trend. Well, I got to ask if they're doing that for serverless, you mentioned graviton in your speech and what came out of you mentioned graviton in your speech and what came out of re-invent this past year was all the innovation going on at the compute level with gravitron at many levels in the Silicon. How should companies and open source developers think about how to innovate with graviton? >> Yeah, I mean, you've seen examples from people blogging and tweeting about how fast their applications run and grab it on the price performance benefits that they get, whether it's on, you know, whether it's an observability or other places. something that AWS is going to embrace across a compute something that AWS is going to embrace across a compute portfolio. Obviously you can go find EC2 instances, the gravitron two instances and run on them and that'll be great. But we know that most of our customers, many of our customers are building new applications on serverless containers and serveless than even as containers increasingly with things like foggy, where they don't want to operate the underlying infrastructure. A big part of what we're doing is to make sure that graviton is available to you on every compute modality. You can run it on a C2 forever. You've been running, being able to use ECS and EKS and run and grab it on almost since launch. What do you want me to take it a step further? You elastic Beanstalk customers, elastic Beanstalk has been around for a decade, but you can now use it with graviton. people running ECS on for gate can now use graviton. Lambda customers can pick graviton as well. So we're taking this price performance benefits that you get So we're taking this price performance benefits that you get from graviton and basically putting it across the entire compute portfolio. What it means is every high level service that gets built on compute infrastructure. And you get the price performance benefits, you get the price performance benefits of the lower power consumption of arm processes. So I'm personally excited like crazy. And you know, this has graviton 2 graviton 3 is coming. >> That's incredible. It's an opportunity like serverless was it's pretty obvious. And I think hopefully everyone will jump on that final question as the time's ticking here. I want to get your thoughts quickly. If you look at what's happened with containers over the past say eight years since the original founding of the first Docker instance, if you will, to how that's evolved and then the introduction of Kubernetes and the cloud native wave we're seeing now, what is, how would you describe the relationship between the success Docker, seeing now with Kubernetes in the cloud native construct what's different and why is this combination so successful? >> Yeah. I often say that containers would have, let me rephrase that. what I say is that people would have adopted sort of the modern way of running applications, whether containers came around or not. But the fact that containers came around made that migration and that journey is so much more efficient for people. So right from, I still remember the first doc that Solomon gave Billy announced DACA and starting to use it on customers, starting to get interested all the way to the more sort of advanced orchestration that we have now for containers across the board. And there's so many examples of the way you can do that. Kubernetes being the most, most well-known one. Here's the thing that I think has changed. I think what Kubernetes or Docker, or the whole sort of modern way of building applications has done is it's taken people who would have taken years adopting these practices and by bringing it right to the fingertips and rebuilding it into the APIs. And in the case of Kubernetes building an entire sort of software world around it, the number of, I would say number of decisions people have to take has gone smaller in many ways. There's so many options, the number of decisions that become higher, but the com the speed at which they can get to a result and a production version of an application that works for them is way low. I have not seen anything like what I've seen in the last 6, 7, 8 years of how quickly the most you know, the most I would say is, you know, a company that you would think would never adopt modern technology has been able to go from, this is interesting to getting a production really quickly. And I think it's because the tooling makes it So, and the fact that you see the adoption that you see right and the fact that you see the adoption that you see right from the fact that you could do Docker run Docker, build Docker, you know, so easily back in the day, all the way to all the advanced orchestration you can do with container orchestrator is today. sort of taking all of that away as well. there's never been a better time to be a developer independent of whatever you're trying to build. And I think containers are a big central part of why that's happened. >> Like the recipe, the combination of cloud-scale, the timing of Kubernetes and the containerization concepts just explode as a beautiful thing. And it creates more opportunities and will challenges, which are opportunities that are net new, but it solves the automation piece that we're seeing this again, it's only makes things go faster. >> Yes. >> And that's the key trend. Deepak, thank you so much for coming on. We're seeing tons of open cloud innovations, thanks to the success of your team at AWS and being great participants in the community. We're seeing innovations from startups. You guys are helping enabling that. Of course, they want to live on their own and be successful and build their super clouds and super app. So thank you for spending the time with us. Appreciate. >> Yeah. Anytime. And thank you. And you know, this is a great event. So I look forward to people running software and building applications, using AWS services and all these wonderful partners that we have. >> Awesome, great stuff. Great startups, great next generation leaders emerging. When you see startups, when they get successful, they become the modern software applications platforms out there powering business and changing the world. This is the cube you're watching the AWS startup showcase. Season two episode one open cloud innovations on John Furrier your host, see you next time.

>>and hello, we're back. I've got my panel and we are doing things real time here. So sorry for the delay a few minutes late. So the way let's talk about things, the reason we're here and we're going around the room and introduce everybody. Got three special guests here. I got my evil or my john and the normal And we're going to talk about get ops I called it future office just because I want to think about what's the next thing for that at the end, we're gonna talk about what our ideas for what's next for getups, right? Um, because we're all starting to just get into get ups now. But of course a lot of us are always thinking about what's next? What's better? How can we make this thing better? So we're going to take your questions. That's the reason we're here, is to take your questions and answer them. Or at least the best we can for the next hour. And all right, so let's go around the room and introduce yourself. My name is Brett. I am streaming from Brett from that. From Brett. From Virginia Beach in Virginia beach, Virginia, United States. Um, and I talk about things on the internet, I sell courses on you, to me that talk about Docker and kubernetes Ive or introduce yourself. >>How's it going? Everyone, I'm a software engineer at axel Springer, currently based in Berlin and I happen to be Brett Brett's teaching assistant. >>All right, that's right. We're in, we're in our courses together almost every day. Mm john >>hey everyone, my name is john Harris, I used to work at Dhaka um, I now work at VM ware is a star field engineer. Um, so yeah, >>and normal >>awesome by the way, you are streaming from Brett Brett, >>I answered from breath to breath. >>Um I'm normal method. I'm a distinguished engineer with booz allen and I'm also a doctor captain and it's good to see either in person and it's good to see you again john it's been a little while. >>It has the pre covid times, right? You're up here in Seattle. >>Yeah. It feels, it feels like an eternity ago. >>Yeah, john shirt looks red and reminds me of the Austin T shirt. So I was like, yeah, so we all, we all have like this old limited edition doctor on E. >>T. That's a, that's a classic. >>Yeah, I scored that one last year. Sometimes with these old conference church, you have to like go into people's closets. I'm not saying I did that. Um, but you know, you have to go steal stuff, you to find ways to get the swag >>post post covid. If you ever come to my place, I'm going to have to lock the closets. That >>that's right, That's right. >>So the second I think it was the second floor of the doctor HQ in SAn Francisco was where they kept all the T shirts, just boxes and boxes and boxes floor to ceiling. So every time I went to HQ you just you just as many as you can fit in your luggage. I think I have about 10 of these. You >>bring an extra piece of luggage just for your your shirt shirt grab. Um All right, so I'm going to start scanning questions uh so that you don't have to you can you help you all are welcome to do that. And I'm going to start us off with the topic. Um So let's just define the parameters. Like we can talk about anything devops and here we can go down and plenty of rabbit holes. But the kind of, the goal here is to talk about get ups and get ups if you haven't heard about it is essentially uh using versioning systems like get like we've all been getting used to as developers to track your infrastructure changes, not just your code changes and then automate that with a bunch of tooling so that the robots take over. And essentially you have get as a central source of truth and then get log as a central source of history and then there's a bunch of magic little bits in the middle and then supposedly everything is wonderful. It's all automatic. The reality is is what it's often quite messy, quite tricky to get everything working. And uh the edges of this are not perfect. Um so it is a relatively new thing. It's probably three, maybe four years old as an official thing from. We've uh so we're gonna get into it and I'll let's go around the room and the same word we did before and um not to push on that, put you on the spot or anything. But what is, what is one of the things you either like or either hate about getups um that you've enjoyed either using it or you know, whatever for me. I really, I really love that I can point people to a repo that basically is hopefully if they look at the log a tracking, simplistic tracking of what might have changed in that part of the world or the environment. I remember many years past where, you know, I've had executive or some mid level manager wants to see what the changes were or someone outside my team went to see what we just changed. It was okay, they need access to this system into that dashboard and that spreadsheet and then this thing and it was always so complicated and now in a world where if we're using get up orbit bucket or whatever where you can just say, hey go look at that repo if there was three commits today, probably three changes happened. That's I love that particular part about it. Of course it's always more complicated than that. But um Ive or I know you've been getting into this stuff recently. So um any thoughts? Yeah, I think >>my favorite part about get ops is >>reproducibility. Um >>you know the ability to just test something and get it up and running >>and then just tear it down. >>Uh not >>being worried that how did I configure it the first time? I think that's my favorite part about >>it. I'm changing your background as we do this. >>I was going to say, did you just do it get ups pushed to like change his >>background, just a dialogue that different for that green screen equals false? Uh Change the background. Yeah, I mean, um and I mean I think last year was really my first year of actually using it on anything significant, like a real project. Um so I'm still, I still feel like I'm very new to john you anything. >>Yeah, it's weird getups is that thing which kind of crystallizes maybe better than anything else, the grizzled veteran life cycle of emotions with the technology because I think it's easy to get super excited about something new. And when I first looked into get up, so I think this is even before it was probably called getups, we were looking at like how to use guest source of truth, like everything sounds great, right? You're like, wait, get everyone knows, get gets the source of truth, There's a load of robust tooling. This just makes a sense. If everything dies, we can just apply the get again, that would be great. Um and then you go through like the trough of despair, right? We're like, oh no, none of this works. The application is super stateless if this doesn't work and what do we do with secrets and how do we do this? Like how do we get people access in the right place and then you realize everything is terrible again and then everything it equalizes and you're kind of, I think, you know, it sounds great on paper and they were absolutely fantastic things about it, but I think just having that measured approach to it, like it's, you know, I think when you put it best in the beginning where you do a and then there's a magic and then you get C. Right, like it's the magic, which is >>the magic is the mystery, >>right? >>Magic can be good and bad and in text so >>very much so yeah, so um concurrence with with john and ever uh in terms of what I like about it is the potential to apply it to moving security to left and getting closer to a more stable infrastructures code with respect to the whole entire environment. Um And uh and that reconciliation loop, it reminds me of what, what is old is new again? Right? Well, quote unquote old um in terms of like chef and puppet and that the reconciliation loop applied in a in a more uh in a cleaner interface and and into the infrastructure that we're kind of used to already, once you start really digging into kubernetes what I don't like and just this is in concurrence with the other Panelist is it's relatively new. It has um, so it has a learning curve and it's still being, you know, it's a very active um environment and community and that means that things are changing and constantly and there's like new ways and new patterns as people are exploring how to use it. And I think that trough of despair is typically figuring out incrementally what it actually is doing for you and what it's not going to solve for you, right, john, so like that's that trough of despair for a bit and then you realize, okay, this is where it fits potentially in my architecture and like anything, you have to make that trade off and you have to make that decision and accept the trade offs for that. But I think it has a lot of promise for, for compliance and security and all that good stuff. >>Yeah. It's like it's like the potentials, there's still a lot more potential than there is uh reality right now. I think it's like I feel like we're very early days and the idea of especially when you start getting into tooling that doesn't appreciate getups like you're using to get up to and use something else and that tool has no awareness of the concept so it doesn't flow well with all of the things you're trying to do and get um uh things that aren't state based and all that. So this is going to lead me to our first question from Camden asking dumb questions by the way. No dumb questions here. Um How is get apps? Not just another name for C. D. Anybody want to take that as an answer as a question. How is get up is not just another name for C. D. I have things but we can talk about it. I >>feel like we need victor foster kids. Yeah, sure you would have opinions. Yeah, >>I think it's a very yeah. One person replied said it's a very specific it's an opinionated version of cd. That's a great that's a great answer like that. Yeah. >>It's like an implement. Its it's an implementation of deployment if you want it if you want to use it for that. All right. I realize now it's kind of hard in terms of a physical panel and a virtual panel to figure out who on the panel is gonna, you know, ready to jump in to answer a question. But I'll take it. So um I'll um I'll do my best inner victor and say, you know, it's it's an implementation of C. D. And it's it's a choice right? It's one can just still do docker build and darker pushes and doctor pulls and that's fine. Or use other technologies to deploy containers and pods and change your, your kubernetes infrastructure. But get apps is a different implementation, a different method of doing that same thing at the end of the day. Yeah, >>I like it. I like >>it and I think that goes back to your point about, you know, it's kind of early days still, I think to me what I like about getups in that respect is it's nice to see kubernetes become a platform where people are experimenting with different ways of doing things, right? And so I think that encourages like lots of different patterns and overall that's going to be a good thing for the community because then more, you know, and not everything needs to settle in terms of only one way of doing things, but a lot of different ways of doing things helps people fit, you know, the tooling to their needs, or helps fit kubernetes to their needs, etcetera. Yeah, >>um I agree with that, the, so I'm gonna, since we're getting a load of good questions, so um one of the, one of the, one of the, I want to add to that real quick that one of the uh from the, we've people themselves, because I've had some on the show and one of things that I look at it is distinguishing is with continuous deployment tools, I sort of think that it's almost like previous generation and uh continuous deployment tools can be anything like we would consider Jenkins cd, right, if you if you had an association to a server and do a doctor pull and you know, dr up or dr composed up rather, or if it did a cube control apply uh from you know inside an ssh tunnel or something like that was considered considered C. D. Well get ops is much more rigid I think in terms of um you you need to apply, you have a specific repo that's all about your deployments and because of what tool you're using and that one your commit to a specific repo or in a specific branch that repo depends on how you're setting it up. That is what kicks off a workflow. And then secondly there's an understanding of state. So a lot of these tools now I have uh reconciliation where they they look at the cluster and if things are changing they will actually go back and to get and the robots will take over and will commit that. Hey this thing has changed um and you maybe you human didn't change it, something else might have changed it. So I think that's where getups is approaching it, is that ah we we need to we need to consider more than just a couple of commands that be runnin in a script. Like there needs to be more than that for a getups repo to happen anyway, that's just kind of the the take back to take away I took from a previous conversation with some people um >>we've I don't think that lost, its the last piece is really important, right? I think like for me, C d like Ci cd, they're more philosophical ideas, write a set of principles, right? Like getting an idea or a code change to environments promoting it. It's very kind of pipeline driven um and it's very imperative driven, right? Like our existing CD tools are a lot of the ways that people think about Cd, it would be triggered by an event, maybe a code push and then these other things are happening in sequence until they either fail or pass, right? And then we're done. Getups is very much sitting on the, you know, the reconciliation side, it's changing to a pull based model of reconciliation, right? Like it's very declarative, it's just looking at the state and it's automatically pulling changes when they happen, rather than this imperative trigger driven model. That's not to say that there aren't city tools which we're doing pull based or you can do pull based or get ups is doing anything creatively revolutionary here, but I think that's one of the main things that the ideas that are being introduced into those, like existing C kind of tools and pipelines, um certainly the pull based model and the reconciliation model, which, you know, has a lot in common with kubernetes and how those kind of controllers work, but I think that's the key idea. Yeah. >>Um This is a pretty specific one Tory asks, does anyone have opinions about get ops in a mono repo this is like this is getting into religion a little bit. How many repos are too many repose? How um any thoughts on that? Anyone before I rant, >>go >>for it, go for it? >>Yeah. How I'm using it right now in a monitor repo uh So I'm using GIT hub. Right, so you have what? The workflow and then inside a workflow? Yeah, mo file, I'll >>track the >>actual changes to the workflow itself, as well as a folder, which is basically some sort of service in Amman Arepa, so if any of those things changes, it'll trigger the actual pipeline to run. So that's like the simplest thing that I could figure out how to, you know, get it set up using um get hubs, uh workflow path future. Yeah. And it's worked for me for writing, you know? That's Yeah. >>Yeah, the a lot of these things too, like the mono repo discussion will, it's very tool specific. Each tool has various levels of support for branch branching and different repos and subdirectories are are looking at the defense and to see if there's changes in that specific directory. Yeah. Sorry, um john you're going to say something, >>I was just going to say, I've never really done it, but I imagine the same kind of downsides of mono repo to multiple report would exist there. I mean, you've got the blast radius issues, you've got, you know, how big is the mono repo? Do we have to pull does the tool have to pull that or cashier every time it needs to determine def so what is the support for being able to just look at directories versus you know, I think we can get way down into a deeper conversation. Maybe we'll save it for later on in the conversation about what we're doing. Get up, how do we structure our get reposed? We have super granular repo per environment, Perper out reaper, per cluster repo per whatever or do we have directories per environment or branches per environment? How how is everything organized? I think it's you know, it's going to be one of those, there's never one size fits all. I'll give the class of consultant like it depends answer. Right? >>Yeah, for sure. It's very similar to the code struggle because it depends. >>Right? >>Uh Yeah, it's similar to the to the code problem of teams trying to figure out how many repose for their code. Should they micro service, should they? Semi micro service, macro service. Like I mean, you know because too many repose means you're doing a bunch of repo management, a bunch of changes on your local system, you're constantly get pulling all these different things and uh but if you have one big repo then it's it's a it's a huge monolithic thing that you usually have to deal with. Path based issues of tools that only need to look at a specific directory and um yeah, it's a it's a culture, I feel like yeah, like I keep going back to this, it's a culture thing. Does your what is your team prefer? What do you like? What um what's painful for everyone and who's what's the loudest pain that you need to deal with? Is it is it repo management? That's the pain um or is it uh you know, is that that everyone's in one place and it's really hard to keep too many cooks out of the kitchen, which is a mono repo problem, you know? Um How do we handle security? So this is a great one from Tory again. Another great question back to back. And that's the first time we've done that um security as it pertains to get up to anyone who can commit can change the infrastructure. Yes. >>Yes. So the tooling that you have for your GIT repo and the authentication, authorization and permissions that you apply to the GIT repo using a get server like GIT hub or get lab or whatever your flavor of the day is is going to be how security is handled with respect to changes in your get ups configuration repository. So um that is completely specific to your implementation of that or ones implementation of of how they're handling that. Get repositories that the get ups tooling is looking at. To reconcile changes with respect to the permissions of the for lack of better term robot itself. Right? They get up tooling like flux or Argosy. D Um one kid would would create a user or a service account or uh other kind of authentication measures to limit the permissions for that service account that the Gaddafi's tooling needs to be able to read the repose and and send commits etcetera. So that is well within the realm of what you have already for your for your get your get um repo. Yeah. >>Yeah. A related question is from a g what they like about get apps if done nicely for a newbie it's you can get stuff done easily if you what they dislike about it is when you have too many get repose it becomes just too complicated and I agree. Um was making a joke with a team the other week that you know the developer used to just make one commit and they would pass pass it on to a QA team that would then eventually emerging in the master. But they made the commits to these feature branches or whatever. But now they make a commit, they make a pR there for their code then they go make a PR in the helm chart to update the thing to do that and then they go make a PR in the get ups repeal for Argo. And so we talked about that they're probably like four or five P. R. Is just to get their code in the production. But we were talking about the negative of that but the reality was It's just five or 4 or five prs like it wasn't five different systems that had five different methodologies and tooling and that. So I looked at it I was like well yeah that's kind of a pain in the get sense but you're also dealing with one type. It's a repetitive action but it's it's the one thing I don't have to go to five different systems with five different ways of doing it. And once in the web and one's on the client wants a command line that I don't remember. Um Yeah so it's got pros and cons I think when you >>I think when you get to the scale where those kind of issues are a problem then you're probably at the scale where you can afford to invest some time into automation into that. Right? Like what I've when I've seen this in larger customers or larger organizations if there ever at that stage where okay apps are coming up all the time. You know, there's a 10 X 100 X developer to operations folks who may be creating get repose setting up permissions then that stuff gets automated, right? Like, you know, maybe ticket based systems or whatever. Developers say I need a new app. It templates things or more often using the same model, right of reconciliation and operators and the horrific abuse of cogs that we're seeing in the communities community right now. Um You know, developers can create a crd which just says, hey, I'm creating a new app is called app A and then a controller will pick up that app a definition. It will go create a get a repo Programmatically it will add the right definitely will look up and held up the developers and the permissions that need to be able to get to that repo it will create and template automatically some name space and the clusters that it needs in the environments that it needs, depending on, you know, some metadata it might read. So I think, you know, those are definite problems and they're definitely like a teething, growing pain thing. But once you get to that scale, you kind of need to step back and say, well look, we just need to invest in time into the operational aspect of this and automating this pain away, I think. Yeah, >>yeah. And that ultimately ends in Yeah. Custom tooling, which it's hard to avoid it at scale. I mean, there's there's two, there's almost two conversations here, right. There is what I call the Solo admin Solo devops, I bought that domain Solo devops dot com because, you know, whenever I'm talking to dr khan in the real world, it's like I asked people to raise hands, I don't know how we can raise hands here, but I would ask people to raise hands and see how many of you here are. The sole person responsible for deploying the app that your team makes and like a quarter of the room would raise their hand. So I call that solo devops like those, that person can't make all the custom tooling in the world. So they really need dr like solutions where it's opinionated, the workflow is sort of built in and they don't have to wrangle things together with a bunch of glue, you know, in other words bash. Um and so this kind of comes to a conversation uh starting this question from lee he's asking how do you combine get ops with ci cd, especially the continuous bit. How do you avoid having a human uh sort of the complaint the team I was working with has, how do you avoid a human editing and get committing for every single deploy? They've settled on customized templates and a script for routine updates. So as a seed for this conference, this question I'm gonna ask you all uh instead of that specific question cause it's a little open ended. Um Tell me whether you agree with this. I I kind of look at the image, the image artifact because the doctor image or container image in general is an artifact that I I view it that way and that thing going into the registry with the right label or right part of the label. Um That tag rather not the label but the tag that to me is like one of the great demarche points of, we're kind of done with Ci and we're now into the deployment phase and it doesn't necessarily mean the tooling is a clear cut there, but that artifact being shipped in a specific way or promoted as we sometimes say. Um what do you think? Does anyone have opinions on that? I don't even know if that's the right opinion to have so mhm. >>So um I think what you're, what you're getting at is that get ups, models can trigger off of different events um to trigger the reconciliation loop. And one way to do that is if the image, if it notices a image change in the registry, the other is if there's a commit event on a specific rebo and branch and it's up to, you are up to the person that's implementing their get ups model, what event to trigger there, that reconciliation loop off of, You can do both, you can do one or the other. It also depends on the Templeton engine that you're using on top of um on top of kubernetes, such as helm or um you know, the other ones that are out there or if you're not even doing that, then, you know straight. Yeah, mo um so it kind of just depends, but those are the typically the two options one has and a combination of of those to trigger that event. You can also just trigger it manually, right? You can go into the command line and force a a, you know, a really like a scan or a new reconciliation loop to occur. So it kind of just, I don't want to say this, but it depends on what you're trying to do and what makes sense in your pipeline. Right? So if you're if you're set up where you are tag, if you're doing it based off of image tags, then you probably want to use get ups in a way that you're using the image tags. Right. And the pattern that you've established there, if you're not really doing that and you're more around, like, different branches are mapped to different environments, then triggered off of the correct branch. And that's where the permissions also come into play. Where if you don't want someone to touch production and you've got your getups for your production cluster based off of like uh you know, a main branch, then whoever can push a change to that main branch has the authority to push that change to production. Right? So that's your authentication and permissions um system same for the registry itself. Right. So >>Yeah. Yeah. Sorry, anyone else have any thoughts on that? I was about to go to the next topic, >>I was going to say. I think certain tools dictate the approach, like, if you're using Argosy d it's I think I'm correct me if I'm wrong, but I think the only way to use it right now is just through image modification. Like, the manifest changes, it looks at a specific directory and anything changes then it will do its thing. And uh Synchronize the cost there with whatever's and get >>Yeah, flux has both. Yeah, and flux has both. So it it kind of depends. I think you can make our go do that too, but uh this is back to what we were saying in the beginning, uh you know, these things are changing, right? So that might be what it is right now in terms of triggering the reconciliation loops and get ups, tooling, but there might be other events in the future that might trigger it, and it's not completely stand alone because you still need you're tooling to do any kind of testing or whatever you have in terms of like the specific pipeline. So oftentimes you're bolting in getups into some other part of broader Cfd solution. That makes sense. Yeah, >>we've got a lot of questions about secrets or people that are asking about secrets. >>So my my tongue and cheek answered the secrets question was, what's the best practices for kubernetes? Secrets? That's the same thing for secrets with good apps? Uh getups is not last time I checked and last time I was running this stuff get ups is not has nothing to do with secrets in that sense. It's just there to get your stuff running on communities. So, um there's probably a really good session on secrets at dr concept. I >>would agree with you, I agree with you. Yeah, I mean, get off stools, I mean every every project of mine handles secrets differently. Uh huh. And I think I'm not sure if it was even when I was talking to but talking to someone recently that I'm very bullish on get up actions, I love get up actions, it's not great for deployments yet, but we do have this new thing and get hub environments, I think it's called. So it allows me at least the store secrets per environment, which it didn't have the concept of that before, which you know, if you if any of you running kubernetes out there, you typically end up when you start running kubernetes, you end up with more than one kubernetes, like you're going to end up with a lot of clusters at some point, at least many multiple, more than two. Um and so if you're trying to store secret somewhere, you do have and there's a discussion happening in chat right now where people are talking about um sealed secrets which if you haven't heard of that, go look that up and just be versed on what sealed secrets is because it's a it's a fantastic concept for how to store secrets in the public. Um I love it because I'm a big P. K. I nerd but um it's not the only way and it doesn't fit all models. So I have clients that use A W. S. Secrets because they're in A W. S. And then they just have to use the kubernetes external secret. But again like like like normal sand, you know, it's that doesn't really affect get ops, get ops is just applying whatever helm charts or jahmal or images that you're, you're you're deploying, get off. It was more about the approach of when the changes happen and whether it's a push or pull model like we're talking about and you know, >>I would say there's a bunch of prerequisites to get ups secrets being one of them because the risk of you putting a secret into your git repo if you haven't figured out your community secrets architecture and start diving into getups is high and removing secrets from get repose is you know, could be its own industry, right. It's >>a thing, >>how do >>I hide this? How do I obscure this commit that's already now on a dozen machines. >>So there are some prerequisites in terms of when you're ready to adopt get up. So I think is the right way of saying the answer to that secrets being one of them. >>I think the secrets was the thing that made me, you know, like two or three years ago made me kind of see the ah ha moment when it came to get ups which, which was that the premier thing that everyone used to say about get up about why it was great. Was its the single source of truth. There's no state anywhere else. You just need to look at git. Um and then secrets may be realized along with a bunch of other things down the line that is not true and will never be true. So as soon as you can lose the dogmatism about everything is going to be and get it's fantastic. As long as you've understood everything is not going to get. There are things which will absolutely never be and get some tools just don't deal with that. They need to earn their own state, especially in communities, some controls on their own state. You know, cuz sealed secrets and and other projects like SOps and I think there are two or three others. That's a great way of dealing with secrets if you want to keep them in get. But you know, projects like vault more kind of like what I would say, production grade secret strategies. Right? And if you're in AWS or a cloud, you're more likely to be using their secrets. Your secret policy is maybe not dictated by you in large organizations might be dictated by CSO or security or Great. Like I think once if you, if you're trying to adopt getups or you're thinking about it, get the dogmatism of get as a single point of truth out of your mind and think about getups more as a philosophy and a set of best practice principles, then you will be in much better stead, >>right? Yeah. >>People are asking more questions in chat like infrastructure as code plus C d essentially get ups or C I rather, um, these are all great questions and a part of the debate, I'm actually just going to throw up on screen. I'm gonna put this in chat, but this is, this is to me the source, Right? So we worked with when they coined the term. We, a lot of us have been trying to get, if we talk about the history for a minute and then tell me if I'm getting this right. Um, a lot of us were trying to automate all these different parts of the puzzle, but a lot of them, they, some things might have been infrastructure as code. Some things weren't, some things were sort of like settings is coded, like you're going to Jenkins and type in secrets and settings or type in a certain thing in the settings of Jenkins and then that it wasn't really in get and so what we was trying to go for was a way to have almost like eventually a two way state understanding where get might change your infrastructure but then your infrastructure might also change and needs to be reflected in the get if the get is trying to be the single source of truth. Um and like you're saying the reality is that you're never gonna have one repo that has all of your infrastructure in it, like you would have to have, you have to have all your terra form, anything else you're spinning up. Right. Um but anyway, I'm gonna put this link in chat. So this guide actually, uh one of things they talk about is what it's not, so it's, it's kind of great to read through the different requirements and like what I was saying well ago um mhm. Having having ci having infrastructure as code and then trying a little bit of continuous deployment out, it's probably a prerequisite. Forget ops so it's hard to just jump into that when you don't already have infrastructure as code because a machine doing stuff on your behalf, it means that you have to have things documented and somewhere and get repo but let me put this in the in the >>chitty chat, I would like to know if the other panelists agree, but I think get apps is a okay. I would say it's a moderate level, it's not a beginner level communities thing, it's like a moderate level advanced, a little bit more advanced level. Um One can start off using it but you definitely have to have some pre recs in place or some understanding of like a pattern in place. Um So what do the other folks think about that opinion? >>I think if you're if you're trying to use get out before, you know what problem you have, you're probably gonna be in trouble. Right. It's like having a solution to it probably don't have yet. Mhm. Right. I mean if if you're just evil or and you're just typing, keep control apply, you're one person right, Get off. It doesn't seem like a big a big jump, like, I mean it doesn't like why would I do that? I'm just, I'm just gonna inside, it's the type of get commit right, I'm typing Q control apply. But I think one of the rules from we've is none of your developers and none of your admins can have cute control access to the cluster because if you can't, if you do have access and you can just apply something, then that's just infrastructure as code. That's just continuous deployment, that's, that's not really get ops um, getups implies that the only way things get into the cluster is through the get up, get automation that you're using with, you know, flux Argo, we haven't talked about, what's the other one that Victor Farsi talks about, by the way people are asking about victor, because victor would love to talk about this stuff, but he's in my next life, so come back in an hour and a half or whatever and victor is going to be talking about sys, admin list with me. Um >>you gotta ask him nothing but get up questions in the next, >>confuse them, confuse them. But anyway, that, that, that's um, it's hard, it's hard to understand and without having tried it, I think conceptually it's a little challenging >>one thing with getups, especially based off the we've works blog post that you just put up on there. It's an opinionated way of doing something. Uh you know, it's an opinionated way of of delivering changes to an environment to your kubernetes environment. So it's opinionated were often not used to seeing things that are very opinionated in this sense, in the in the ecosystem, but get apps is a opinionated thing. It's it's one way of doing it. Um there are ways to change it and like there are options um like what we were talking about in terms of the events that trigger, but the way that it's structured is an opinion opinionated way both from like a tooling perspective, like using get etcetera, but also from a devops cultural perspective, right? Like you were talking about not having anyone access cube control and changing the cluster directly. That's a philosophical opinion that get ups forces you to adopt otherwise. It kind of breaks the model and um I just I want everyone to just understand that. That is very opinion, anything in that sense. Yeah, >>polygamy is another thing. Infrastructure as code. Um someone's mentioning plummy and chat, I just had actually my life show self plug bread that live go there. I'm on Youtube every week. I did the same thing. These these are my friends um and had palami on two weeks ago uh last week, remember uh and it was in the last couple of weeks and we talked about their infrastructure as code solution. Were actually writing code instead of um oh that's an interesting take on uh developer team sort of owning coding the infrastructure through code rather than Yamil as a data language. I don't really have an opinion on it yet because I haven't used it in production or anything in the real real world, but um, I'm not sure how much they are applying trying to go towards the get up stuff. I will do a plug for Solomon hikes. Who has a, the beginning of the day, it's already happened so you can go back and watch it. It's a, it's a, what's it called? Q. Rethinking application delivery with Q. And build kit. So go look this up. This is the found co founder of Dr and former CTO Solomon hikes at the beginning of the day. He has a tool called dagger. I'm not sure why the title of the talk is delivering with Q. And built it, but the tool is showing off in there for an hour is called dagger. And it's, it's an interesting idea on how to apply a lot of this opinionated automated stuff to uh, to deployment and it's get off space and you use Q language. It's a graph language. I watched most of it and it was a really interesting take. I'm excited to see if that takes off and if they try that because it's another way that you can get a little bit more advanced with your you're get deployments and without having to just stick everything in Yemen, which is kind of what we're in today with helm charts and what not. All right. More questions about secrets, I think. I think we're not going to have a whole lot of more, a lot more about secrets basically. Uh put secrets in your cluster to start with and kubernetes in encrypted, you know, thing. And then, you know, as it gets harder, then you have to find another solution when you have five clusters, you don't wanna have to do it five times. That's when you have to go for Walton A W. S secrets and all >>that. Right? I'm gonna post it note. Yeah. Crm into the cluster. Just kidding. >>Yes, there are recordings of this. Yes, they will be later. Uh, because we're that these are all gonna be on youtube later. Um, yeah, detects secrets cushion saying detect secrets or get Guardian are absolute requirements. I think it's in reference to your secrets comment earlier. Um, Camels asking about Cuban is dropping support for Docker that this is not the place to ask for that, but it, it is uh, basically it's a Nonevent Marantz has actually just created that same plug in available in a different repos. So if you want to keep using Docker and kubernetes, you know, you can do it like it's no big deal. Most of us aren't using doctor in our communities anyway, so we're using like container D or whatever is provided to us by our provider. Um yeah, thank you so much for all these comments. These are great people helping each other and chat. I feel like we're just here to make sure the chats available so people can help each other. >>I feel like I want to pick up on something when you mentioned pollux me, I think there's a um we're talking about getups but I think in the original like the origination of that I guess was deploying applications to clusters right, picking up deployment manifest. But I think with the gloomy and I obviously terra form and things have been around a long time, folks are starting to apply this I think I found one earlier which was like um kub stack the Terror Forms get ups framework. Um but also with the advent of things like cluster A. P. I. Um in the Cuban at the space where you can declare actively build the infrastructure for your clusters and build the cluster right? We're not just talking about deploying applications, the cluster A. P. I will talk to a W. S. Spin up, VPc spin up machines, you know, we'll do the same kind of things that terra form does and and those other tools do I think applying getups principles to the infrastructure spin up right, the proper infrastructure as code stuff, constantly applying Terror form um you know, plans and whatever, constantly applying cluster Api resources spinning up stuff in those clouds. That's a super interesting. Um you know, extension of this area, I'd be curious to see if what the folks think about that. >>Yeah, that's why I picked this topic is one of my three. Uh I got I got to pick the topics. I was like the three things that there like the most bleeding edge exciting. Most people haven't, we haven't basically we haven't figured all this out yet. We as an industry, so um it's I think we're gonna see more ideas on it. Um what's the one with the popsicle as the as the icon victor talks about all the time? It's not it's another getups like tool, but it's um it's getups for you use this kubernetes limit and then we have to look it up, >>You're talking about cross plane. >>So >>my >>wife is over here with the sound effects and the first sound effect of the day that she chooses to use is one. >>All right, can we pick it? Let's let's find another question bret >>I'm searching >>so many of them. All right, so uh I think one really quick one is getups only for kubernetes, I think the main to tooling to tools that we're talking about, our Argosy D and flux and they're mostly geared toward kubernetes deployments but there's a, it seems like they're organized in a way that there's a clean abstraction in with respect to the agent that's doing the deployment and the tooling that that can interact with. So I would imagine that in the future and this might be true already right now that get ups could be applied to other types of deployments at some point in the future. But right now it's mostly focused and treats kubernetes as a first class citizen or the tooling on top of kubernetes, let's say something like how as a first class citizen? Yeah, to Brett, >>to me the field, back to you bret the thing I was looking for is cross plane. So that's another tool. Um Victor has been uh sharing a lot about it in Youtube cross plane and that is basically runs inside a kubernetes, but it handles your other infrastructure besides your app. It allows you to like get ops, you're a W. S stuff by using the kubernetes state engine as a, as a way to manage that. And I have not used it yet, but he does some really great demos on Youtube. So people are liking this idea of get off, so they're trying to figure out how do we, how do we manage state? How do we uh because the probably terra form is that, well, there's many problems, but it's always a lot of problems, but in the get outs world it's not quite the right fit yet, It might be, but you still, it's still largely as expected for people to, you know, like type the command, um, and it keeps state locally the ss, clouds and all that. And but the other thing is I'm I'm now realizing that when I saw the demo from Solomon, I'm going back to the Solomon hikes thing. He was using the demo and he was showing it apply deploying something on S three buckets, employing internet wifi and deploying it on google other things beyond kubernetes and saying that it's all getups approach. So I think we're just at the very beginning of seeing because it all started with kubernetes and now there's a swarm one, you can look up swarm, get office and there's a swarm, I can't take the name of it. Swarm sink I think is what's called swarm sink on git hub, which allows you to do swarm based getups like things. And now we're seeing these other tools coming out. They're saying we're going to try to do the get ups concepts, but not for kubernetes specifically and that's I think, you know, infrastructure as code started with certain areas of the world and then now then now we all just assume that you're going to have an infrastructure as code way of doing whatever that is and I think get off is going to have that same approach where pretty soon, you know, we'll have get apps for all the clouds stuff and it won't just be flexor Argo. And then that's the weird thing is will flex and Argo support all those things or will it just be focused on kubernetes apps? You know, community stuff? >>There's also, I think this is what you're alluding to. There is a trend of using um kubernetes and see rDS to provision and control things that are outside of communities like the cloud service providers services as if they were first class entities within kubernetes so that you can use the kubernetes um focus tooling for things that are not communities through the kubernetes interface communities. Yeah, >>yeah, even criticism. >>Yeah, yeah, I'm just going to say that sounds like cross plane. >>Yeah, yeah, I mean, I think that's that's uh there were, you know, for the last couple of years, it's been flux and are going back and forth. Um they're like frenemies, you know, and they've been going back and forth with iterating on these ideas of how do we manage this complicated thing? That is many kubernetes clusters? Um because like Argo, I don't know if the flux V two can do this, but Argo can manage multiple clusters now from one cluster, so your, you can manage other clusters, technically external things from a single entity. Um Originally flux couldn't do that, but I'm going to say that V two can, I don't actually >>know. Um I think all that is gonna, I think that's going to consolidate in the future. All right. In terms of like the common feature set, what Iver and john what do you think? >>I mean, I think it's already begun, right, I think haven't, didn't they collaborate on a common engine? I don't know whether it's finished yet, but I think they're working towards a common getups engine and then they're just going to layer on features on top. But I think, I mean, I think that's interesting, right, because where it runs and where it interacts with, if we're talking about a pull based model, it shouldn't, it's decentralized to a certain extent, right? We need get and we need the agent which is pulling if we're saying there's something else which is orchestrating something that we start to like fuzzy the model even right. Like is this state living somewhere else, then I think that's just interesting as well. I thought flux was completely decentralized, but I know you install our go somewhere like the cargo has a server as well, but it's been a while since I've looked in depth at them. But I think the, you know, does that muddy the agent only pull model? >>I'm reading a >>Yeah, I would say that there's like a process of natural selection going on as as the C. N. C. F. Landscape evolves and grows bigger and a lot of divide and conquer right now. But I think as certain things kind of get more prominent >>and popular, I think >>it starts to trend and it inspires other things and then it starts to aggregate and you know, kind of get back into like a unified kind of like core. Maybe like for instance, cross plane, I feel like it shouldn't even really exist. It should be, it like it's a communities add on, but it should be built in, it should be built into kubernetes, like why doesn't this exist already >>for like controlling a cloud? >>Yeah, like just, you know, having this interface with the cloud provider and be able to Yeah, >>exactly. Yeah, and it kinda, you're right. That kinda happens because you do, I mean when you start talking about storage providers and networking providers was very specific implementations of operators or just individual controllers that do operate and control other resources in the cloud, but certainly not universally right. Not every feature of AWS is available to kubernetes out of the box. Um and you know, it, one of the challenges across plane is you gotta have kubernetes before you can deploy kubernetes. Like there's a chicken and egg issue there where if you're going to use, if you're going to use our cross plane for your other infrastructure, but it's gotta, but it has to run on kubernetes who creates that first kubernetes in order for you to put that on there. And victor talks about one of his videos, the same problem with flux and Argo where like Argo, you can't deploy Argo itself with getups. There has to be that initial, I did a thing with, I'm a human and I typed in some commands on a server and things happened but they don't really have an easy deployment method for getting our go up and running using simply nothing but a get push to an existing system. There's something like that. So it's a it's an interesting problem of day one infrastructure which is again only day one, I think data is way more interesting and hard, but um how can we spend these things up if they're all depending on each other and who is the first one to get started? >>I mean it's true of everything though, I mean at the end of that you need some kind of big bang kind of function too, you know, I started running start everything I >>think without going over that, sorry, without going off on a tangent. I was, I was gonna say there's a, if folks have heard of kind which is kubernetes and Docker, which is a mini kubernetes cluster, you can run in a Docker container or each container will run as a as a node. Um you know, that's been a really good way to spin up things like clusters. KPI because they boot strap a local kind, install the manifests, it will go and spin up a fully sized cluster, it will transfer its resources over there and then it will die itself. Right? So that, that's kind of bootstrapping itself. And I think a couple of folks in the community, Jason to Tiberius, I think he works for Quinyx metal um has, has experimented with like an even more minimal just Api server, so we're really just leveraging the kubernetes ideas of like a reconciliation loop and a controller. We just need something to bootstrap with those C R D s and get something going and then go away again. So I think that's gonna be a pattern that comes up kind of more and more >>Yeah, for sure. Um, and uh, the next, next quick answer to the question, Angel asked what your thoughts on getups being a niche to get or versus others vcs tools? Well, if I knew anyone who is using anything other than get, I would say no, you know, get ops is a horrible name. It should just be CVS office, but that doesn't or vcs ops or whatever like that, but that doesn't roll off the tongue. So someone had to come up with the get ups phrase. Um but absolutely, it's all about version control solutions used for infrastructure, not code. Um might get doctor asks a great question, we're not gonna have time for it, but maybe people can reply and chat with what they think but about infrastructure and code, the lines being blurred and that do develop, how much of infrastructure does developer do developers need to know? Essentially, they're having to know all the things. Um so unfortunately we've had way more questions like every panel here today with all the great community, we've got way more questions we can handle in this time. So we're gonna have to wrap it up and say goodbye. Go to the next live panel. I believe the next one is um on developer, developer specific setups that's gonna be peter running that panel. Something about development in containers and I'm sure it's gonna be great. Just like this one. So let's go around the room where can people find you on the internet? I'm at Brett fisher on twitter. That's where you can usually find me most days you are? >>Yeah, I'm on twitter to um, I'll put it in the chat. It's kind of confusing because the TSR seven. >>Okay. Yeah, that's right. You can't just say it. You can also look at the blow of the video and like our faces are there and if you click on them, it tells you our twitter in Arlington and stuff, john >>John Harris 85, pretty much everywhere. Get hub Twitter slack, etc. >>Yeah >>and normal, normal faults or just, you know, living on Youtube live with Brett. >>Yeah, we're all on the twitter so go check us out there and thank you so much for joining. Uh thank you so much to you all for being here. I really appreciate you taking time in your busy schedule to join me for a little chit chat. Um Yes, all the, all the cheers, yes. >>And I think this kid apps loop has been declarative lee reconciled. >>Yeah, there we go. And with that ladies and gentlemen, uh bid you would do, we will see you in the next, next round coming up next with Peter >>bye.

>>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.

>> Narrator: From around the globe, its theCUBE with digital coverage of Mirantis Launchpad 2020 brought to you by Mirantis . >> Welcome back, I'm Stu Miniman and this is theCUBE coverage of Mirantis Launchpad 2020, really looking at how Mirantis Docker Enterprise are coming together, changes happening in the field and to help us dig into that customer and product discussion. Happy to welcome to the program, Shaun O'Meara. He is the global Field Chief Technology Officer with Mirantis coming to us from Germany. Shaun thanks so much for joining us. >> Thanks for having me. >> All right, so let's start with the customers. I always love talking to the Field CTOs you're out there. You're talking strategy, you're getting into some of the architecture, lots of customers, probably still, trying to figure out that whole cloud native containerization, Kubernetes and modernization piece. So when you talk to your customers, what are some of their biggest challenges they're facing and those main discussion points that bring them to talk to Mirantis. >> Very good question, I think you've just laid it out yourself in many ways. It's complexity our customers are dealing with more and more change, more and more options, and it's driving complexity in their environments, and they're looking for ways to deal with that complexity and to allow more and more access and reduce barriers to getting applications and getting tools to market. And if we look at it and we look at the way the world is going today, we have multiple cloud environments. We have every single developer on the face of the planet wants to use different tools, different ways to build applications that don't want to be dictated to. Now, if you turn that around and you look at what operators have to deal with, it's just more and more complexity. Ultimately, that complexity is growing and we're looking for ways to make it easier, simpler, and subsequently increase the speed of getting applications to market for our customers. >> Yeah, You know we talk a bit about some of the macro challenges that customers have. What talk you kind of teed up a little bit, the operators and the developers. I remember a couple of years ago, I had the opportunity to interview Solomon Hykes and of course the founder from Docker. And there was that talk of well, containerization, it's this wonderful thing for developers. And he's like, hold on Stu we actually, really started looking at this or the operators we want that unit of operation to be closer to the application. So it should be simpler, it used to be okay, how many different applications do they have on a server or VMs all over the place and containers I could really have this microservice or this application is a container. So there is some operational simplicity there, but how is that dynamic inside the customer? Of course, we've seen the growth and the importance and the embracing of developers, but there's still the DevOps adoption and we'd love to be able to say one of these years that, oh, we don't have silos anymore and everybody works together and we're all on the same page. >> Oh yeah, the reality is in the big enterprise companies and the companies that are building applications for market today, your big financial services companies, there's still a very clear separation between operators and developers. A lot of that is driven by legislation, a lot of that's driven by just old fashioned thinking in many ways, but developers are starting to have a lot more influence on what applications are used and the infrastructure. We just see with the rise of AWS, all the contenders to AWS in the form of Azure and Google. Developers are starting to have a lot more power over that decision, but they're still highly dependent on operators to deliver those platforms that they use, and to make sure that the platforms that they're running their applications on top of, are stable and run well in production situations. There's a big difference between building something on your laptop in one or two instances, and then trying to push it out to a massive scalable cloud platform. And I think those are the areas that we can have a lot of impact, and that's where we are building our tools for at the moment. >> Well, great. Let's dig into those tools a little bit, as I said, at the beginning, we're familiar, Mirantis had the Mirantis Cloud Platform for a few years, big embrace of Kubernetes and then Docker Enterprise, it comes into the mix. So help me understand a little bit, what is kind of the solution set to portfolio? How does Mirantis present that today? >> Yeah, well, it's been an interesting eight, nine months now of the whole process since with the Docker Enterprise business, a couple of key areas. So if we look at what MCP was, and MCP still here today apparently, it focuses on delivering all the components necessary to have an effective cloud platform. So lifecycle management, lifecycle management of all those underlying components, which in their own right is extremely complex set of software. What we focused on there was understanding in enterprise infrastructure, the right way to do that. As soon as you bring in from the Docker Enterprise business is that they have a scalable, large, well deployed container platform. And many thousands of users across the world in all sorts of different scales and production systems. We are merging that knowledge that we have around infrastructure, infrastructure management, and simplifying access to infrastructure with this platform that provides for all that application, hosting provides for all the control of containers, plus all the security components around the container lifecycle. And delivering in such a way that you can choose your underlying preference. So we're no longer looking to lock you in to say, you have to go on-prem, you have to go into cloud. We're saying, we'll give you the choice, but we'll also give you a standardized platform for your developers across all of those potential infrastructure environments, so I'll use it again, public cloud, private cloud, bare metal on-premise, or your options like the VMware of this world. By consolidating all of that into one platform, we're giving you that as a developer, the ability to write applications that'll run anyway and sorry, go on. >> No, please finish up, I've just got to follow, yeah. >> But that simplicity drives and like that's simple choice across all those platforms essentially drives speed. It takes away the typical barriers that we're seeing in our customers. We hear every reason, we love Docker Enterprise because it solves the problem of getting containers, it solves a problem of securing containers, but it takes four teams to deploy it. Same for the MCP, we're saying is we cannot do that in a day and provide other self sets. So you can deploy a brand new container cloud in minutes rather than days or weeks. And that's one of the biggest changes that we're bringing to the product. >> Yeah, so absolutely what we hear from customers that agility, that speed that you talk about is the imperative, especially talk about 2020, everybody has had to readjust often accelerating some of the plans they had to meet the realities of what we have today. What I want to understand is when you talk about that single platform being able to be in any environment, oftentimes there's a misnomer that it's about portability. Most customers we talked to, they're not moving things lots of places. They do want that operational consistency, wherever they go. At the same time, you mentioned the rise of AWS and the hyperscalers often when they're now going to have to manage multiple clusters, it's not that I choose one Kubernetes and I use it anywhere, but I might be using AKS Azure had an early version of it, of course, Amazon has a couple of options now for enterprises. So help us understand how the Mirantis solutions, fit with the clouds, leverage cloud services and if I have multiple clusters, you even mentioned VMware, I might have a VMware cluster, have something from Mirantis, have something from one of the hyperscalers. Is that what you're seeing from your customers today? And how do they and how do they want to manage that going forward? Because we understand this is still a maturing space. >> So I mean, that's exactly the point. What we're seeing from our customers is that they have policies to go cloud first. They still have a lot of infrastructure on-premise. The question is which cloud, which cloud suits their needs in which region. Now, all of a sudden you've got a risk management policy from an organization that says, well, I have to go to Azure and I have to go to AWS. That's using them as examples. The deployment and management of those two platforms is completely different. Just the learning curve for a developer who wants to focus on writing code, to build a platform on top of AWS is barely extensive. Yes, it's easy to get started, but if you really want to deal with the fine print of how to run some in production, it's not that simple. There are potentially a thousand different buttons, you can click when deploying an instance on Amazon. So what we're saying is, instead of you having to deal with that we're going to abstract that pain from you. We're going to say we'll deploy Docker Enterprise on top of Amazon, on top of Google, on top of Azure, on top of your VMware cluster, give you a consistent interface to that, consistent set of tools across all those platforms, still consuming those platforms as you would, but solve all those dependency problems. To set up a cube cluster on top of Amazon, I'm not talking about an AKS or something like that right now, but the sort of cube cluster means I have to set up load balances, I have to set up networks, I have to set up monitors, I have to set up the instances, I have to deploy Kubernetes, and then I'm only getting started. I still haven't integrated that to my corporate identity management. We're saying we'll bring all that to give them, we are bringing all that together in the form of Docker Enterprise container cloud. >> Yeah, definitely as you said, we need more simplicity here. The promise of cloud it's supposed to be simplicity and now of course we have the paradox of choice when it comes there. >> Yeah. >> One of the other things we've seen, rapid change a lot the last year or so is many of the offerings out there are now managed services. So as you said, I don't want to have to build all of those pieces. I want to just be able to go to somebody. What are you hearing from your customers? How does manage service fit into what Mirantis is doing? >> Great, well, what we're hearing from customers is they want the pain to go away. The answer to that could be delivered through software that's really easy to use and doesn't set up any barriers and gets them started fast, which is where we focus from a product perspective. Mirantis also has a strong manage services on so we've been doing manage services for some of the biggest enterprises in the world for MCP products for many years. We've brought those teams forward and we're now offering those same managed services on top of all of our platforms. So Docker Enterprise container cloud, we'll deploy it for you, we'll manage it for you. We'll handle all the dependencies around getting container cloud up and running within your organization, and then offer you that hands on service. So when you build clusters, when you want clusters that are much more longer lived, we can handle all the extra detail that goes around those. Short term, so if you just want quick clusters for your developers, easy access, you still have that as part of the service. So we're focusing on how fast can we get you started? How fast can you get up the cushions to market, not put any infrastructure barriers on the way, or where there are traditional infrastructure barriers find ways around us. That still acceptable to those enterprise operators who still have list as long as my arm, probably twice as long as my arm of fine print that they have to comply with for everything under the sun, the regulators, et cetera. >> Yeah, Shaun since you are based in Europe, I'm wondering if you can give us a little bit of the perspective on cloud adoption there, here in North America, discussion point has been for many years, just that massive movement to public cloud, of course governance the key issue in Europe and above also kind of the COVID impact, anecdotally there's lots of discussions of acceleration of public cloud. So what's the reality on the ground? How do your enterprise customers look at public cloud? How fast or slow are they moving and what is the 2020 impact? >> So interesting if you'd asked me this question, six months ago, seven months ago, pre COVID, I would have said public cloud is growing. People are still building some small private clouds for very unique use cases, looking at where our customers are now, all of a sudden there's a risk balance. So they're driving into public cloud, but they want those public clouds to be with European companies and European operators, or at least to have some level of security. You know, recently the European community canceled the privacy shield legislation that was in place between the US and Europe, which meant all of a sudden, a lot of companies in Europe had to look for other places to store their data, or had to deal with different rules around storing the data that they may have but in the US previously. What we're seeing customers saying is we have to go multicloud. The drive is no longer we can accept one vendor risk. We want to remove that risk, we will still have equipment on-premise. So on-prem equipment is still important to us, but as a backup to the public cloud, and as a way to secure our data and the mechanisms that we own and can touch and control. That's the operator's view. If we talk to developers, people writing applications, if they are not forced to, they will go public cloud almost every time. It's just easier for them. And that's really what we're, that's really the challenge that we're also trying to focus on here. >> Yeah, I'm curious, are there any European cloud providers that are rising to the top the big three have such a large megaphone that they kind of drown out a lot of discussion and understand that there's pockets and many local suppliers, and of course thousands of kind of cloud service providers out there, but any ones that are good partners of Mirantis or ones that you're hearing. >> There are a couple. >> Yeah. >> Sorry, there are a couple, I dunno if I can mention them here, but there's some great ones providing very unique businesses, places like the Netherlands, very unique, very focused business where they're taking advantage of specific laws within, well, the Netherlands and Germany, there's another company that we're working very closely with that feels that they can do a much more affordable, much more hands on service or cloud. So their cloud experience provide everything developers want, but at the same time handle those operator requirements and those enterprise requirements within Germany. So focusing on the GDPR laws, focusing on German technology laws, which are very complex, very much focused on privacy. And there are a few unique companies like that across Europe, I know of one in Italy, there's a company that focuses on providing cloud services to the EU government themselves, who we've worked with in the past. So yeah, but as you say, it's the big three, they're growing, they're dealing with those challenges. We see them as resources, we see them as partners to what we're trying to achieve. We certainly not trying to compete with them at that level. >> Absolutely, all right, Shaun final question I have for you, tell us what your customers see as the real differentiation, what draws them to Mirantis and what we should expect to see over the coming months? >> So I think choice is a key differentiator. We're offering choice, we're not trying to tell you you can only use one cloud platform or one cloud provider. And that's extremely important as one of the key differentiators. I've mentioned this many times, simplicity, driving simplicity at all levels, from the operator through to the developer, to the consumer of the cloud, let's make it easy. Let's truly reduce the friction to getting started, all right that's one of the really key focus areas for us and that's something we talk about all the time in every meeting and we question ourselves constantly is, does this make it easier? And then security is a major component for us. We really focus on security as part of our tool sets, providing that standardized platform and that standardized security across all of these environments, and ultimately reducing the complexity. >> Shaun O'Meara, thank you so much. Great to hear that the real customer interaction and what they're dealing with today. >> Sure, thank you very much. >> Be sure to check out the tracks for developers, for infrastructure as well as all the rest theCUBE interviews on the Mirantis Launchpad site of course powered by CUBE365. I'm Stu Miniman and thank you for watching theCUBE. (upbeat music)

>> Narrator: From theCUBE studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is a CUBE Conversation. >> Hey, welcome back everybody. Jeff Frick here with theCUBE. We're in our Palo Alto studios today, having ongoing conversations about diversity and really adding more women and also people of color into the corporate environment. And we're really excited to have somebody who's an expert in the field. Joining us for the first time from the East coast. She's Beth Stewart, founder and CEO of Trewstar. Before we get going, tell us a little bit about Trewstar and what you guys are all about. >> Well, we're a search firm and we specialize at the board level, so we don't do executive search. And we further focus on female candidates, and much more recently, I wouldn't want to say we never focused on racial diversity, but let's just say it's getting a lot more attention and that would include men and women. >> Right, right, so that makes a lot of sense. And specifically, what's different about running a search firm that's focused on board members than a search firm that's focused on traditional kind of leadership roles, CEO or other senior executives? >> Well, there are a couple of things. First of all, one of the criteria to be a partner at Trewstar is that you have to have been a board member yourself. And I don't think at other search firms that do the board work as part of their overall practice that that's as important, that's not to say some partners at other firms aren't board members, but it's not as consistent as it is at Trewstar. So one, we feel like we really understand what our clients' issues are. A second thing that differentiates us is that, we spend really all day every day thinking about and sourcing and meeting with and getting referrals from people about diversity candidates. So, I think other firms are focused on people that they can place into leadership positions which aren't necessarily people who are or have been or could be a board member. And going back to that focus on having been in the board room, we have a pretty good sense of who's right and who isn't maybe quite ready or never will be ready to go on a board. >> So I wonder if you could just pull the curtain back a little bit for us, 'cause everyone has worked for a manager or been a manager and had some level of exposure to kind of the senior management in their companies or CEOs. We see him speak at keynotes. That's very different than what happens in the board. So, when you talk about the candidates, and you just mentioned, some people may never be ready for a board position. What are the kind of candidate attributes that you look for that you know is somebody that's good for corporate board? >> Well, so first, it has to start with the skill set that the company has requested, based on their analysis and sometimes we help with this. But their analysis of where there is a gap in the skills on the board. And there are a lot of different people that might fit that skill. Let's just take the audit chair, because it's such an obvious one, there are many, many people who can chair an audit committee. But what we also are going to look for is somebody who you'd like to have dinner with or lunch with. Now I realize when we're in COVID times, everybody's not doing that, but assuming things return to some level of normalcy, you want to have people who are personable, who are easy to get along with, who aren't going to talk too much, who aren't going to talk over each other and who are skilled at the top of their game, if you will. So, for people who might be audit chairs, we're looking for either a CFO or a retired audit partner. And in that case, we might be looking for audit partners who have had leadership positions in their firms that's just an indication of their sort of level of outstandingness. >> Right. >> And when you look for a CFO, you might say, is this a CFO who came up through an investment banking or Treasurer background or is it a CFO who came up through an accounting background? All these depend on the situation, but those are the kinds of considerations for us. >> Right, and one of the things that came up in doing a little research for this interview, is you talked about crafting modern dynamic boards and I think probably a lot of people's perception is that boards just don't turn over that often. And I think even you've said in some of your literature, that the problem's not really a supply side problem, it's a demand side problem. So, I wonder if you can share some insight as to kind of what is happening with boards in terms of turnovers and making seats available for new people, whether that be women or women of color or whomever. Is that changing over time? Are you seeing a dynamic start to change where you're starting to get more fresh blood into corporate boards, where before that was probably a pretty glacial paced activity I would imagine? >> I wouldn't want you to think that anybody's sprinting at this point, we haven't gone from glacial to sprints, but change has happened. And so you talked about a dynamic boardroom, if you can imagine the number of people that are on corporate boards that haven't worked since before the iPhone or before the trade wars with China and other places or before #metoo or before COVID or before dealing with millennials in the workplace. So, there are a lot of people that fall in that category that do offer wisdom and stability on a board, but it's really, I believe, incumbent on them to get that sort of new perspectives and literally new information and skills and have it be a better blend. And you can't do that unless you do create openings, you can always increase the size of the board, but you can't do that unless you take the difficult step of asking some of the longer tenured and older board members to retire. Now, having said that, it's not just an ageist thing. There are often board members that for instance, on a pre-IPO company, who were venture capitalists, and the venture capitalists may not actually know the issues of a public board, they know the issues of smaller companies and growing in a private market. And sometimes you get somebody who's in the middle of their career, who doesn't have the time to spend, because they are in a full-time role. So really, what it comes down to is, someone appropriately managing the boardroom by saying, "who's really got the skills and the time and the personality that we need." And what I find most interesting, Jeff, is you can speak to anybody on a board and they know who it is that shouldn't be there anymore. It doesn't require a whole process and bringing in outsiders and doing exhaustive studies, everybody knows who it is. It's just whether there's somebody who's willing to have those difficult conversations. >> So, it's interesting 'cause you say someone willing to have those difficult conversations which would imply that there's not kind of a systematic way to make sure that things are refreshed to make sure that there's some turnover to make sure that maybe institutionally everybody knows that there's going to be turns if it's really kind of a one off conversation every time and I think, again, doing some research, you talked about, some really older folks that have been around for a long time, not necessarily because they don't have the qualifications anymore, but it's just time for them to potentially give up that chair. So, you're saying that it's not that institutionalized in terms of making sure that this thing is refreshed at some type of frequency? >> Yes, that's what I'm saying. I just don't know how to say it any differently, but it doesn't happen consistently, but what is consistently true, is the dread with which the senior person on the board, the chair of nominating governance, the chair of the board, maybe it's the CEO, has about having the conversation about asking somebody to not stand for re-election, that's consistent and systematized. And there are some other sort of old fashion ways we can expand the board while expanding the board if you've been in a board room, it's a trivial issue. Somebody makes a motion and the board's expanded by one or we can't ask somebody to retire, because their term's not up. Well, why can't you? You're supposed to be representing the shareholders. If they're not doing as great a job as the next person. Having them stay for another 18 months isn't really in the best interest of the shareholders. So, I feel it's a little bit the dirty little secret in corporate boards. This unwillingness of people to either ask somebody to move on or to move on themselves. >> Well, then there's the whole chairman-CEO thing, which I've never quite understood that how you can be both the chairman of the board as well as the CEO of the company if the board is supposed to be the CEO's boss? But I don't think we're going to solve that problem here today. >> That's a third rail that I'm not going to get into and I would suspect that it really varies by person and by situation. Sometimes I'm sure that works just perfectly well and other times, there is a reason to have a separation. >> Right, let's shift gears a little bit and talk about some positive news. You had an article that you did, it's been a while now, December 18th, saying that you placed more women in boards, the first quarter of Q1 2018, it's an old article, than you had in all 2017 which is kind of a nice interesting indicator of trending in the right direction. And as you just mentioned, before we turned on the cameras, your phones are lighting up with all this stuff going on with the black lives matter movement. So, people do seem to be in a better place than they were. So how do you see it kind of progressing? What are some ways that other people can contribute to help make sure that the momentum is going up in the correct direction? >> Sure, why don't I talk about what I think caused the change? And there's plenty of room for other people to take these actions. Certainly there has been for many years there were not for profit organizations and academic institutions that wrote about the reasons, wrote about, had conferences etcetera, about the reasons there should be diversity on boards. I have to say, parenthetically, this notion of diversity for me it goes a lot back to the idea of the dynamic board. So, it's not just being a woman per se or racially diverse person per se. It could be a person who actually has those needed skills. But anyway, so, for a long time these not for profits were focused on this. But it was March 7th, 2017, when State Street came out with their proclamation that they were not going to support chairs of nominating governance who didn't create diverse boards. And you might remember when they put the statue of the girl with her arms spread out in front of the bull on Wall Street. That was incredible and that led a number of other financial institutions who voted proxies to support that, that was huge. Another movement or another action that mattered, is the state of California, saying that they're setting up quotas. I'm no fan of quotas, but now that I've actually seen what happens in the state of California. And what's happened to the quality, we aren't putting people who aren't high quality on these boards, we're putting outstanding women on the boards, but there's more of an opportunity. And then the third thing that happened and I realized we're now getting into January of 2020, but I mention it because there are many more, so there are many more states that can do what California did. There are many more financial institutions that can do explicitly what State Street did, and many have, but there's still more. And then the last thing happened at Davos in January of 2020, when David Solomon, who's the CEO of Goldman Sachs, said that they will not take any companies public, unless this year there's at least one woman on the board and next year, two women on the board, and this is huge. So, what I would point out to you is that, in the case of State Street and in the case of Goldman Sachs, the senior member of the organization actually stepped in and did something and set a tone and set an expectation and sort of, if you will, created a rule, which is different than saying my head of diversity and inclusion is going to take care of it. Head of talent is responsible for this, it really has to come from the top. So, there are many, many other organizations with people at the top who can put in similar recommendations or basically new ways of working. >> Right, Beth, but we know from real data and real evidence that a diversity of opinion leads to better outcome and it leads to better business results. So it's funny that even with that kind of data, you still need kind of that personal touch to push it over the line, to really make it. The fearless girl statue is an amazing story, I'm happy to say I've tracked her down and got a couple pictures. I've got a few daughters that I shared it with and kind of the rallying cry that that became in fact, I think they've even moved it to a more prominent position from across from the bull, really is interesting that there's these small little symbols that can mark significant progress in kind of this ongoing journey. >> Yes, I agree with you completely, but maybe it goes back to that whole notion of why can't you? Why don't people want to retire from boards? And what's really these various things have done is it's just forced the conversation and it's forced the action. Being on a board is a great thing. You get paid a lot, you're at the top of the hierarchy, it's the pinnacle of somebody's career. So I'm very sympathetic to why nobody wants to move on, but that doesn't mean it's right. We're supposed to be doing what's right for the company and the shareholders. >> Okay, so before we let you go, just a couple of concrete things that you suggest to people that they can do to kind of help this mission along. >> Well, so back to what differentiates us, we present slates of all women. And what we recommend is interview the women first. And if we don't find a candidate who matches what you need, both the specific skills and the personality, we'll open the search to men. And while we have placed men, whenever we started with an all female slate, we've never been asked to open the slate to men. So, what does it mean? That's not us, we're a client service business, it's the client who's never asked us. So it's incumbent upon us not to just have a slate of women, but to have a slate of outstanding women. And that goes back to focusing on this and spending every day and talking to so many women in advance. So that's the first thing I would say, is that you start with an all female slate. The second thing I would say is people say to me, what's the most important thing about to get a woman on a board, and I say it starts with a signed engagement letter. And so what does that imply? What that implies is that we're a for profit organization doing this from soup to nuts. We don't just find the women and send their resumes out, we run the whole process. We understand the company, we give them materials, we organize the interviews, we do the reference checks, we do what I call the last mile logistics, so that in a three to four month period, which is quite fast for the world of boards, somebody goes on the board. We've never had a failed search. So, it's really managing a whole process. And the signed engagement letter means, somebody actually hired us to do that. So, we start in the very beginning with a board who wants the whole process and wants to have a diverse candidate. So it's not like a question at the end or whatever, it's all lined up. And we try to leave no stone unturned and I would say that that's very important when you start thinking about, there are a lot of databases out there. But sometimes when you just go to a database and get a name, it doesn't actually turn into a woman on the board. >> Right, and I'm just curious to get your personal take, since you've been doing this for a while and as you said, your phone's been lighting up looking for more diverse candidates, not just women, but people of color, etcetera. Do you see a change in attitude from the senior people that are hiring you to move beyond? "I need to check a box, I'm getting pressure I need to do this", versus, "wow I see real benefit, I see this as real important. It's important for me, it's important for my company, it's important, really, to our shareholders, our stakeholders and our constituents to actually take maybe an uncomfortable step or a step", maybe uncomfortable is the wrong word, "that I'm not necessarily used to or is new or foreign to me, to take this action and move this thing down the road." >> Yeah, I would say absolutely, but I think that even if they start with, "I know I have to do this, I might not know why I want to do it, but I'm going to do it anyway." Even for the people that are in that, like take an all male board. Truthfully the all male boards aren't really wild about this, they've been forced for one reason or another. But what's amazing is if you come up with a high quality slate of candidates, what we find over and over again is the inability to choose between one candidate and another, and often the decision to add two women. And that to me is a testament to one the openness of those all male boards to recognizing quality, and being able to now see with a live person, if you will, how that new director could really help them. So, that's terrific that that happens. Now, just to mention on the racial diversity, we're doing the exact same thing or basically, if you will, beefing up, expanding all of our connections in those areas. And one of the things that's different is we've had searches that were underway, whoever is leading the search on the side of the company has said, "Stop. It has to be a racially diverse person, stop whatever you're doing." We did a search for a media company and we had 21 African-American women on the slate that met the spec for one reason or another. And then, of the new calls that we've been getting, I'd say 60 or 70% of them we don't want anything other than a racially diverse man or woman. You talked about the phones lighting up, it's like a set of fireworks at the fourth of July in terms of what's happened here. And we're completely behind it and we've had a lot of conversations with a lot of people about what's the right way to approach this in terms of having the conversations with those racially diverse people. And anyway, we're doing all sorts of things. And we're bound and determined to be helpful and to be action-oriented in this current situation. >> That's great news, Beth, because when I talked to some of my black friends, specifically, as this has been going on, a lot of them come back and say, "I don't know why this is so different, we've been having these issues for a long period of time." So, it's nice to find some examples where hopefully, there's some step function activity going on here. And I think what you just outlined very much supports that, that this isn't just more of the same, but actually, there are changes slowly being affected kind of across many fronts, all at the same time, which would certainly be supported by what you just said. >> So, I'd love to Jeff, I don't know whether we're running out of time or not, but I had a conversation with a senior African-American male board member. 'Cause one, he's on the board of a company that's our client, I know how terrific everybody thinks he is and he chairs audit committees and he chairs nominating governance committees. And so I asked him about how to handle this. And in any case, one of the things he told me is that he would advise his friends that if anybody was going on a board to figure out the sincerity of the board, he said, "'cause I don't want to go on a board and check the box. I want to go on a board because I'm part of a company trying to make strides in these areas and where I can add value." He said, "I would tell them up front, "that if all you've got is a black woman in diversity and inclusion, that I don't think you're sincere. And if I find that you're not sincere, I'm going to resign. And when I resign, you the board, will then have to explain to everybody why I resigned and that won't be pleasant." (chuckles) So, I thought, wow, that's- >> You're putting your mouth where your money is, that's for sure. That's terrific. >> Yeah. >> Well, Beth, we could go on and on and on. Unfortunately, we have other work to do and I'm sure you do as well. But our paths cross because of some of the fantastic women that we've had on theCUBE who are also clients of yours and getting placed in board seats, which is terrific news. We're happy to highlight some of these terrific individuals, as you said, they're not just women or people of color, they're fantastic people first, and terrific executives and kind of representatives of the company. So, really excited for you and what you're doing to help put some really qualified people in places where they can make a difference. >> Yes, well, it's a wonderful job I created for myself and as I say, I only talk to successful people, because unsuccessful ones aren't available to be interviewed for board roles. >> (chuckles) All right, well, we will leave it at that. So Beth, thanks a lot and have a terrific week. >> Thank you, same to you. Thank you, Jeff. >> All right, thanks a lot. >> Bye-bye. >> All right, she's Beth, I'm Jeff, you're watching theCUBE from Palo Alto. Thanks for watching, we'll see you next time. (mellow music)

(water running) (upbeat music) (electric buzzing) >> Fuel up! (upbeat music) (audience clapping) (upbeat music) >> Announcer: From around the globe. It's the queue with digital coverage of DockerCon live 2020, brought to you by Docker and its ecosystem partners. >> Hello everyone, welcome to DockerCon 2020. I'm John Furrier with theCUBE I'm in our Palo Alto studios with our quarantine crew. We have a great lineup here for DockerCon 2020. Virtual event, normally it was in person face to face. I'll be with you throughout the day from an amazing lineup of content, over 50 different sessions, cube tracks, keynotes, and we've got two great co-hosts here with Docker, Jenny Burcio and Bret Fisher. We'll be with you all day today, taking you through the program, helping you navigate the sessions. I'm so excited. Jenny, this is a virtual event. We talk about this. Can you believe it? Maybe the internet gods be with us today and hope everyone's having-- >> Yes. >> Easy time getting in. Jenny, Bret, thank you for-- >> Hello. >> Being here. >> Hey. >> Hi everyone, so great to see everyone chatting and telling us where they're from. Welcome to the Docker community. We have a great day planned for you. >> Guys great job getting this all together. I know how hard it is. These virtual events are hard to pull off. I'm blown away by the community at Docker. The amount of sessions that are coming in the sponsor support has been amazing. Just the overall excitement around the brand and the opportunities given this tough times where we're in. It's super exciting again, made the internet gods be with us throughout the day, but there's plenty of content. Bret's got an amazing all day marathon group of people coming in and chatting. Jenny, this has been an amazing journey and it's a great opportunity. Tell us about the virtual event. Why DockerCon virtual. Obviously everyone's canceling their events, but this is special to you guys. Talk about DockerCon virtual this year. >> The Docker community shows up at DockerCon every year, and even though we didn't have the opportunity to do an in person event this year, we didn't want to lose the time that we all come together at DockerCon. The conversations, the amazing content and learning opportunities. So we decided back in December to make DockerCon a virtual event. And of course when we did that, there was no quarantine we didn't expect, you know, I certainly didn't expect to be delivering it from my living room, but we were just, I mean we were completely blown away. There's nearly 70,000 people across the globe that have registered for DockerCon today. And when you look at DockerCon of past right live events, really and we're learning are just the tip of the iceberg and so thrilled to be able to deliver a more inclusive global event today. And we have so much planned I think. Bret, you want to tell us some of the things that you have planned? >> Well, I'm sure I'm going to forget something 'cause there's a lot going on. But, we've obviously got interviews all day today on this channel with John and the crew. Jenny has put together an amazing set of all these speakers, and then you have the captain's on deck, which is essentially the YouTube live hangout where we just basically talk shop. It's all engineers, all day long. Captains and special guests. And we're going to be in chat talking to you about answering your questions. Maybe we'll dig into some stuff based on the problems you're having or the questions you have. Maybe there'll be some random demos, but it's basically not scripted, it's an all day long unscripted event. So I'm sure it's going to be a lot of fun hanging out in there. >> Well guys, I want to just say it's been amazing how you structured this so everyone has a chance to ask questions, whether it's informal laid back in the captain's channel or in the sessions, where the speakers will be there with their presentations. But Jenny, I want to get your thoughts because we have a site out there that's structured a certain way for the folks watching. If you're on your desktop, there's a main stage hero. There's then tracks and Bret's running the captain's tracks. You can click on that link and jump into his session all day long. He's got an amazing set of line of sleet, leaning back, having a good time. And then each of the tracks, you can jump into those sessions. It's on a clock, it'll be available on demand. All that content is available if you're on your desktop. If you're on your mobile, it's the same thing. Look at the calendar, find the session that you want. If you're interested in it, you could watch it live and chat with the participants in real time or watch it on demand. So there's plenty of content to navigate through. We do have it on a clock and we'll be streaming sessions as they happen. So you're in the moment and that's a great time to chat in real time. But there's more, Jenny, getting more out of this event. You guys try to bring together the stimulation of community. How does the participants get more out of the the event besides just consuming some of the content all day today? >> Yes, so first set up your profile, put your picture next to your chat handle and then chat. John said we have various setups today to help you get the most out of your experience are breakout sessions. The content is prerecorded, so you get quality content and the speakers and chat so you can ask questions the whole time. If you're looking for the hallway track, then definitely check out the captain's on deck channel. And then we have some great interviews all day on the queue. So set up your profile, join the conversation and be kind, right? This is a community event. Code of conduct is linked on every page at the top, and just have a great day. >> And Bret, you guys have an amazing lineup on the captain, so you have a great YouTube channel that you have your stream on. So the folks who were familiar with that can get that either on YouTube or on the site. The chat is integrated in, So you're set up, what do you got going on? Give us the highlights. What are you excited about throughout your day? Take us through your program on the captains. That's going to be probably pretty dynamic in the chat too. >> Yeah, so I'm sure we're going to have lots of, stuff going on in chat. So no cLancaerns there about, having crickets in the chat. But we're going to be basically starting the day with two of my good Docker captain friends, (murmurs) and Laura Taco. And we're going to basically start you out and at the end of this keynote, at the end of this hour and we're going to get you going and then you can maybe jump out and go to take some sessions. Maybe there's some stuff you want to check out and other sessions that you want to chat and talk with the instructors, the speakers there, and then you're going to come back to us, right? Or go over, check out the interviews. So the idea is you're hopping back and forth and throughout the day we're basically changing out every hour. We're not just changing out the guests basically, but we're also changing out the topics that we can cover because different guests will have different expertise. We're going to have some special guests in from Microsoft, talk about some of the cool stuff going on there, and basically it's captains all day long. And if you've been on my YouTube live show you've watched that, you've seen a lot of the guests we have on there. I'm lucky to just hang out with all these really awesome people around the world, so it's going to be fun. >> Awesome and the content again has been preserved. You guys had a great session on call for paper sessions. Jenny, this is good stuff. What other things can people do to make it interesting? Obviously we're looking for suggestions. Feel free to chirp on Twitter about ideas that can be new. But you guys got some surprises. There's some selfies, what else? What's going on? Any secret, surprises throughout the day. >> There are secret surprises throughout the day. You'll need to pay attention to the keynotes. Bret will have giveaways. I know our wonderful sponsors have giveaways planned as well in their sessions. Hopefully right you feel conflicted about what you're going to attend. So do know that everything is recorded and will be available on demand afterwards so you can catch anything that you miss. Most of them will be available right after they stream the initial time. >> All right, great stuff, so they've got the Docker selfie. So the Docker selfies, the hashtag is just DockerCon hashtag DockerCon. If you feel like you want to add some of the hashtag no problem, check out the sessions. You can pop in and out of the captains is kind of the cool kids are going to be hanging out with Bret and then all they'll knowledge and learning. Don't miss the keynote, the keynote should be solid. We've got chain Governor from red monk delivering a keynote. I'll be interviewing him live after his keynote. So stay with us. And again, check out the interactive calendar. All you got to do is look at the calendar and click on the session you want. You'll jump right in. Hop around, give us feedback. We're doing our best. Bret, any final thoughts on what you want to share to the community around, what you got going on the virtual event, just random thoughts? >> Yeah, so sorry we can't all be together in the same physical place. But the coolest thing about as business online, is that we actually get to involve everyone, so as long as you have a computer and internet, you can actually attend DockerCon if you've never been to one before. So we're trying to recreate that experience online. Like Jenny said, the code of conduct is important. So, we're all in this together with the chat, so try to be nice in there. These are all real humans that, have feelings just like me. So let's try to keep it cool. And, over in the Catherine's channel we'll be taking your questions and maybe playing some music, playing some games, giving away some free stuff, while you're, in between sessions learning, oh yeah. >> And I got to say props to your rig. You've got an amazing setup there, Bret. I love what your show, you do. It's really bad ass and kick ass. So great stuff. Jenny sponsors ecosystem response to this event has been phenomenal. The attendance 67,000. We're seeing a surge of people hitting the site now. So if you're not getting in, just, Wade's going, we're going to crank through the queue, but the sponsors on the ecosystem really delivered on the content side and also the sport. You want to share a few shout outs on the sponsors who really kind of helped make this happen. >> Yeah, so definitely make sure you check out the sponsor pages and you go, each page is the actual content that they will be delivering. So they are delivering great content to you. So you can learn and a huge thank you to our platinum and gold authors. >> Awesome, well I got to say, I'm super impressed. I'm looking forward to the Microsoft Amazon sessions, which are going to be good. And there's a couple of great customer sessions there. I tweeted this out last night and let them get you guys' reaction to this because there's been a lot of talk around the COVID crisis that we're in, but there's also a positive upshot to this is Cambridge and explosion of developers that are going to be building new apps. And I said, you know, apps aren't going to just change the world, they're going to save the world. So a lot of the theme here is the impact that developers are having right now in the current situation. If we get the goodness of compose and all the things going on in Docker and the relationships, this real impact happening with the developer community. And it's pretty evident in the program and some of the talks and some of the examples. how containers and microservices are certainly changing the world and helping save the world, your thoughts. >> Like you said, a number of sessions and interviews in the program today that really dive into that. And even particularly around COVID, Clement Beyondo is sharing his company's experience, from being able to continue operations in Italy when they were completely shut down beginning of March. We have also in theCUBE channel several interviews about from the national Institute of health and precision cancer medicine at the end of the day. And you just can really see how containerization and developers are moving in industry and really humanity forward because of what they're able to build and create, with advances in technology. >> Yeah and the first responders and these days is developers. Bret compose is getting a lot of traction on Twitter. I can see some buzz already building up. There's huge traction with compose, just the ease of use and almost a call for arms for integrating into all the system language libraries, I mean, what's going on with compose? I mean, what's the captain say about this? I mean, it seems to be really tracking in terms of demand and interest. >> I think we're over 700,000 composed files on GitHub. So it's definitely beyond just the standard Docker run commands. It's definitely the next tool that people use to run containers. Just by having that we just buy, and that's not even counting. I mean that's just counting the files that are named Docker compose YAML. So I'm sure a lot of you out there have created a YAML file to manage your local containers or even on a server with Docker compose. And the nice thing is is Docker is doubling down on that. So we've gotten some news recently, from them about what they want to do with opening the spec up, getting more companies involved because compose is already gathered so much interest from the community. You know, AWS has importers, there's Kubernetes importers for it. So there's more stuff coming and we might just see something here in a few minutes. >> All right, well let's get into the keynote guys, jump into the keynote. If you missing anything, come back to the stream, check out the sessions, check out the calendar. Let's go, let's have a great time. Have some fun, thanks and enjoy the rest of the day we'll see you soon. (upbeat music) (upbeat music) >> Okay, what is the name of that Whale? >> Molly. >> And what is the name of this Whale? >> Mobby. >> That's right, dad's got to go, thanks bud. >> Bye. >> Bye. Hi, I'm Scott Johnson, CEO of Docker and welcome to DockerCon 2020. This year DockerCon is an all virtual event with more than 60,000 members of the Docker Community joining from around the world. And with the global shelter in place policies, we're excited to offer a unifying, inclusive virtual community event in which anyone and everyone can participate from their home. As a company, Docker has been through a lot of changes since our last DockerCon last year. The most important starting last November, is our refocusing 100% on developers and development teams. As part of that refocusing, one of the big challenges we've been working on, is how to help development teams quickly and efficiently get their app from code to cloud And wouldn't it be cool, if developers could quickly deploy to the cloud right from their local environment with the commands and workflow they already know. We're excited to give you a sneak preview of what we've been working on. And rather than slides, we thought we jumped right into the product. And joining me demonstrate some of these cool new features, is enclave your DACA. One of our engineers here at Docker working on Docker compose. Hello Lanca. >> Hello. >> We're going to show how an application development team collaborates using Docker desktop and Docker hub. And then deploys the app directly from the Docker command line to the clouds in just two commands. A development team would use this to quickly share functional changes of their app with the product management team, with beta testers or other development teams. Let's go ahead and take a look at our app. Now, this is a web app, that randomly pulls words from the database, and assembles them into sentences. You can see it's a pretty typical three tier application with each tier implemented in its own container. We have a front end web service, a middle tier, which implements the logic to randomly pull the words from the database and assemble them and a backend database. And here you can see the database uses the Postgres official image from Docker hub. Now let's first run the app locally using Docker command line and the Docker engine in Docker desktop. We'll do a Doc compose up and you can see that it's pulling the containers from our Docker organization account. Wordsmith, inc. Now that it's up. Let's go ahead and look at local host and we'll confirm that the application is functioning as desired. So there's one sentence, let's pull and now you and you can indeed see that we are pulling random words and assembling into sentences. Now you can also see though that the look and feel is a bit dated. And so Lanca is going to show us how easy it is to make changes and share them with the rest of the team. Lanca, over to you. >> Thank you, so I have, the source code of our application on my machine and I have updated it with the latest team from DockerCon 2020. So before committing the code, I'm going to build the application locally and run it, to verify that indeed the changes are good. So I'm going to build with Docker compose the image for the web service. Now that the image has been built, I'm going to deploy it locally. Wait to compose up. We can now check the dashboard in a Docker desktop that indeed our containers are up and running, and we can access, we can open in the web browser, the end point for the web service. So as we can see, we have the latest changes in for our application. So as you can see, the application has been updated successfully. So now, I'm going to push the image that I have just built to my organization's shared repository on Docker hub. So I can do this with Docker compose push web. Now that the image has been updated in the Docker hub repository, or my teammates can access it and check the changes. >> Excellent, well, thank you Lanca. Now of course, in these times, video conferencing is the new normal, and as great as it is, video conferencing does not allow users to actually test the application. And so, to allow us to have our app be accessible by others outside organizations such as beta testers or others, let's go ahead and deploy to the cloud. >> Sure we, can do this by employing a context. A Docker context, is a mechanism that we can use to target different platforms for deploying containers. The context we hold, information as the endpoint for the platform, and also how to authenticate to it. So I'm going to list the context that I have set locally. As you can see, I'm currently using the default context that is pointing to my local Docker engine. So all the commands that I have issued so far, we're targeting my local engine. Now, in order to deploy the application on a cloud. I have an account in the Azure Cloud, where I have no resource running currently, and I have created for this account, dedicated context that will hold the information on how to connect it to it. So now all I need to do, is to switch to this context, with Docker context use, and the name of my cloud context. So all the commands that I'm going to run, from now on, are going to target the cloud platform. So we can also check very, more simpler, in a simpler way we can check the running containers with Docker PS. So as we see no container is running in my cloud account. Now to deploy the application, all I need to do is to run a Docker compose up. And this will trigger the deployment of my application. >> Thanks Lanca. Now notice that Lanca did not have to move the composed file from Docker desktop to Azure. Notice you have to make any changes to the Docker compose file, and nor did she change any of the containers that she and I were using locally in our local environments. So the same composed file, same images, run locally and upon Azure without changes. While the app is deploying to Azure, let's highlight some of the features in Docker hub that helps teams with remote first collaboration. So first, here's our team's account where it (murmurs) and you can see the updated container sentences web that Lanca just pushed a couple of minutes ago. As far as collaboration, we can add members using their Docker ID or their email, and then we can organize them into different teams depending on their role in the application development process. So and then Lancae they're organized into different teams, we can assign them permissions, so that teams can work in parallel without stepping on each other's changes accidentally. For example, we'll give the engineering team full read, write access, whereas the product management team will go ahead and just give read only access. So this role based access controls, is just one of the many features in Docker hub that allows teams to collaboratively and quickly develop applications. Okay Lanca, how's our app doing? >> Our app has been successfully deployed to the cloud. So, we can easily check either the Azure portal to verify the containers running for it or simpler we can run a Docker PS again to get the list with the containers that have been deployed for it. In the output from the Docker PS, we can see an end point that we can use to access our application in the web browser. So we can see the application running in clouds. It's really up to date and now we can take this particular endpoint and share it within our organization such that anybody can have a look at it. >> That's cool Onka. We showed how we can deploy an app to the cloud in minutes and just two commands, and using commands that Docker users already know, thanks so much. In that sneak preview, you saw a team developing an app collaboratively, with a tool chain that includes Docker desktop and Docker hub. And simply by switching Docker context from their local environment to the cloud, deploy that app to the cloud, to Azure without leaving the command line using Docker commands they already know. And in doing so, really simplifying for development team, getting their app from code to cloud. And just as important, what you did not see, was a lot of complexity. You did not see cloud specific interfaces, user management or security. You did not see us having to provision and configure compute networking and storage resources in the cloud. And you did not see infrastructure specific application changes to either the composed file or the Docker images. And by simplifying a way that complexity, these new features help application DevOps teams, quickly iterate and get their ideas, their apps from code to cloud, and helping development teams, build share and run great applications, is what Docker is all about. A Docker is able to simplify for development teams getting their app from code to cloud quickly as a result of standards, products and ecosystem partners. It starts with open standards for applications and application artifacts, and active open source communities around those standards to ensure portability and choice. Then as you saw in the demo, the Docker experience delivered by Docker desktop and Docker hub, simplifies a team's collaborative development of applications, and together with ecosystem partners provides every stage of an application development tool chain. For example, deploying applications to the cloud in two commands. What you saw on the demo, well that's an extension of our strategic partnership with Microsoft, which we announced yesterday. And you can learn more about our partnership from Amanda Silver from Microsoft later today, right here at DockerCon. Another tool chain stage, the capability to scan applications for security and vulnerabilities, as a result of our partnership with Sneak, which we announced last week. You can learn more about that partnership from Peter McKay, CEO Sneak, again later today, right here at DockerCon. A third example, development team can automate the build of container images upon a simple get push, as a result of Docker hub integrations with GitHub and Alaska and Bitbucket. As a final example of Docker and the ecosystem helping teams quickly build applications, together with our ISV partners. We offer in Docker hub over 500 official and verified publisher images of ready to run Dockerized application components such as databases, load balancers, programming languages, and much more. Of course, none of this happens without people. And I would like to take a moment to thank four groups of people in particular. First, the Docker team, past and present. We've had a challenging 12 months including a restructuring and then a global pandemic, and yet their support for each other, and their passion for the product, this community and our customers has never been stronger. We think our community, Docker wouldn't be Docker without you, and whether you're one of the 50 Docker captains, they're almost 400 meetup organizers, the thousands of contributors and maintainers. Every day you show up, you give back, you teach new support. We thank our users, more than six and a half million developers who have built more than 7 million applications and are then sharing those applications through Docker hub at a rate of more than one and a half billion poles per week. Those apps are then run, are more than 44 million Docker engines. And finally, we thank our customers, the over 18,000 docker subscribers, both individual developers and development teams from startups to large organizations, 60% of which are outside the United States. And they spend every industry vertical, from media, to entertainment to manufacturing. healthcare and much more. Thank you. Now looking forward, given these unprecedented times, we would like to offer a challenge. While it would be easy to feel helpless and miss this global pandemic, the challenge is for us as individuals and as a community to instead see and grasp the tremendous opportunities before us to be forces for good. For starters, look no further than the pandemic itself, in the fight against this global disaster, applications and data are playing a critical role, and the Docker Community quickly recognize this and rose to the challenge. There are over 600 COVID-19 related publicly available projects on Docker hub today, from data processing to genome analytics to data visualization folding at home. The distributed computing project for simulating protein dynamics, is also available on Docker hub, and it uses spirit compute capacity to analyze COVID-19 proteins to aid in the design of new therapies. And right here at DockerCon, you can hear how Clemente Biondo and his company engineering in Gagne area Informatica are using Docker in the fight with COVID-19 in Italy every day. Now, in addition to fighting the pandemic directly, as a community, we also have an opportunity to bridge the disruption the pandemic is wreaking. It's impacting us at work and at home in every country around the world and every aspect of our lives. For example, many of you have a student at home, whose world is going to be very different when they returned to school. As employees, all of us have experienced the stresses from working from home as well as many of the benefits and in fact 75% of us say that going forward, we're going to continue to work from home at least occasionally. And of course one of the biggest disruptions has been job losses, over 35 million in the United States alone. And we know that's affected many of you. And yet your skills are in such demand and so important now more than ever. And that's why here at DockerCon, we want to try to do our part to help, and we're promoting this hashtag on Twitter, hashtag DockerCon jobs, where job seekers and those offering jobs can reach out to one another and connect. Now, pandemics disruption is accelerating the shift of more and more of our time, our priorities, our dollars from offline to online to hybrid, and even online only ways of living. We need to find new ways to collaborate, new approaches to engage customers, new modes for education and much more. And what is going to fill the needs created by this acceleration from offline, online? New applications. And it's this need, this demand for all these new applications that represents a great opportunity for the Docker community of developers. The world needs us, needs you developers now more than ever. So let's seize this moment. Let us in our teams, go build share and run great new applications. Thank you for joining today. And let's have a great DockerCon. >> Okay, welcome back to the DockerCon studio headquarters in your hosts, Jenny Burcio and myself John Furrier. u@farrier on Twitter. If you want to tweet me anything @DockerCon as well, share what you're thinking. Great keynote there from Scott CEO. Jenny, demo DockerCon jobs, some highlights there from Scott. Yeah, I love the intro. It's okay I'm about to do the keynote. The little green room comes on, makes it human. We're all trying to survive-- >> Let me answer the reality of what we are all doing with right now. I had to ask my kids to leave though or they would crash the whole stream but yes, we have a great community, a large community gather gathered here today, and we do want to take the opportunity for those that are looking for jobs, are hiring, to share with the hashtag DockerCon jobs. In addition, we want to support direct health care workers, and Bret Fisher and the captains will be running a all day charity stream on the captain's channel. Go there and you'll get the link to donate to directrelief.org which is a California based nonprofit, delivering and aid and supporting health care workers globally response to the COVID-19 crisis. >> Okay, if you jumping into the stream, I'm John Farrie with Jenny Webby, your hosts all day today throughout DockerCon. It's a packed house of great content. You have a main stream, theCUBE which is the mainstream that we'll be promoting a lot of cube interviews. But check out the 40 plus sessions underneath in the interactive calendar on dockercon.com site. Check it out, they're going to be live on a clock. So if you want to participate in real time in the chat, jump into your session on the track of your choice and participate with the folks in there chatting. If you miss it, it's going to go right on demand right after sort of all content will be immediately be available. So make sure you check it out. Docker selfie is a hashtag. Take a selfie, share it. Docker hashtag Docker jobs. If you're looking for a job or have openings, please share with the community and of course give us feedback on what you can do. We got James Governor, the keynote coming up next. He's with Red monk. Not afraid to share his opinion on open source on what companies should be doing, and also the evolution of this Cambrin explosion of apps that are going to be coming as we come out of this post pandemic world. A lot of people are thinking about this, the crisis and following through. So stay with us for more and more coverage. Jenny, favorite sessions on your mind for people to pay attention to that they should (murmurs)? >> I just want to address a few things that continue to come up in the chat sessions, especially breakout sessions after they play live and the speakers in chat with you, those go on demand, they are recorded, you will be able to access them. Also, if the screen is too small, there is the button to expand full screen, and different quality levels for the video that you can choose on your end. All the breakout sessions also have closed captioning, so please if you would like to read along, turn that on so you can, stay with the sessions. We have some great sessions, kicking off right at 10:00 a.m, getting started with Docker. We have a full track really in the how to enhance on that you should check out devs in action, hear what other people are doing and then of course our sponsors are delivering great content to you all day long. >> Tons of content. It's all available. They'll always be up always on at large scale. Thanks for watching. Now we got James Governor, the keynote. He's with Red Monk, the analyst firm and has been tracking open source for many generations. He's been doing amazing work. Watch his great keynote. I'm going to be interviewing him live right after. So stay with us and enjoy the rest of the day. We'll see you back shortly. (upbeat music) >> Hi, I'm James Governor, one of the co-founders of a company called RedMonk. We're an industry research firm focusing on developer led technology adoption. So that's I guess why Docker invited me to DockerCon 2020 to talk about some trends that we're seeing in the world of work and software development. So Monk Chips, that's who I am. I spent a lot of time on Twitter. It's a great research tool. It's a great way to find out what's going on with keep track of, as I say, there's people that we value so highly software developers, engineers and practitioners. So when I started talking to Docker about this event and it was pre Rhona, should we say, the idea of a crowd wasn't a scary thing, but today you see something like this, it makes you feel uncomfortable. This is not a place that I want to be. I'm pretty sure it's a place you don't want to be. And you know, to that end, I think it's interesting quote by Ellen Powell, she says, "Work from home is now just work" And we're going to see more and more of that. Organizations aren't feeling the same way they did about work before. Who all these people? Who is my cLancaern? So GitHub says has 50 million developers right on its network. Now, one of the things I think is most interesting, it's not that it has 50 million developers. Perhaps that's a proxy for number of developers worldwide. But quite frankly, a lot of those accounts, there's all kinds of people there. They're just Selena's. There are data engineers, there are data scientists, there are product managers, there were tech marketers. It's a big, big community and it goes way beyond just software developers itself. Frankly for me, I'd probably be saying there's more like 20 to 25 million developers worldwide, but GitHub knows a lot about the world of code. So what else do they know? One of the things they know is that world of code software and opensource, is becoming increasingly global. I get so excited about this stuff. The idea that there are these different software communities around the planet where we're seeing massive expansions in terms of things like open source. Great example is Nigeria. So Nigeria more than 200 million people, right? The energy there in terms of events, in terms of learning, in terms of teaching, in terms of the desire to code, the desire to launch businesses, desire to be part of a global software community is just so exciting. And you know, these, this sort of energy is not just in Nigeria, it's in other countries in Africa, it's happening in Egypt. It's happening around the world. This energy is something that's super interesting to me. We need to think about that. We've got global that we need to solve. And software is going to be a big part of that. At the moment, we can talk about other countries, but what about frankly the gender gap, the gender issue that, you know, from 1984 onwards, the number of women taking computer science degrees began to, not track but to create in comparison to what men were doing. The tech industry is way too male focused, there are men that are dominant, it's not welcoming, we haven't found ways to have those pathways and frankly to drive inclusion. And the women I know in tech, have to deal with the massively disproportionate amount of stress and things like online networks. But talking about online networks and talking about a better way of living, I was really excited by get up satellite recently, was a fantastic demo by Alison McMillan and she did a demo of a code spaces. So code spaces is Microsoft online ID, new platform that they've built. And online IDs, we're never quite sure, you know, plenty of people still out there just using the max. But, visual studio code has been a big success. And so this idea of moving to one online IDE, it's been around that for awhile. What they did was just make really tight integration. So you're in your GitHub repo and just be able to create a development environment with effectively one click, getting rid of all of the act shaving, making it super easy. And what I loved was it the demo, what Ali's like, yeah cause this is great. One of my kids are having a nap, I can just start (murmurs) and I don't have to sort out all the rest of it. And to me that was amazing. It was like productivity as inclusion. I'm here was a senior director at GitHub. They're doing this amazing work and then making this clear statement about being a parent. And I think that was fantastic. Because that's what, to me, importantly just working from home, which has been so challenging for so many of us, began to open up new possibilities, and frankly exciting possibilities. So Alley's also got a podcast parent-driven development, which I think is super important. Because this is about men and women rule in this together show parenting is a team sport, same as software development. And the idea that we should be thinking about, how to be more productive, is super important to me. So I want to talk a bit about developer culture and how it led to social media. Because you know, your social media, we're in this ad bomb stage now. It's TikTok, it's like exercise, people doing incredible back flips and stuff like that. Doing a bunch of dancing. We've had the world of sharing cat gifts, Facebook, we sort of see social media is I think a phenomenon in its own right. Whereas the me, I think it's interesting because it's its progenitors, where did it come from? So here's (murmurs) So 1971, one of the features in the emergency management information system, that he built, which it's topical, it was for medical tracking medical information as well, medical emergencies, included a bulletin board system. So that it could keep track of what people were doing on a team and make sure that they were collaborating effectively, boom! That was the start of something big, obviously. Another day I think is worth looking at 1983, Sorania Pullman, spanning tree protocol. So at DEC, they were very good at distributed systems. And the idea was that you can have a distributed system and so much of the internet working that we do today was based on radius work. And then it showed that basically, you could span out a huge network so that everyone could collaborate. That is incredibly exciting in terms of the trends, that I'm talking about. So then let's look at 1988, you've got IRC. IRC what developer has not used IRC, right. Well, I guess maybe some of the other ones might not have. But I don't know if we're post IRC yet, but (murmurs) at a finished university, really nailed it with IRC as a platform that people could communicate effectively with. And then we go into like 1991. So we've had IRC, we've had finished universities, doing a lot of really fantastic work about collaboration. And I don't think it was necessarily an accident that this is where the line is twofold, announced Linux. So Linux was a wonderfully packaged, idea in terms of we're going to take this Unix thing. And when I say package, what a package was the idea that we could collaborate on software. So, it may have just been the work of one person, but clearly what made it important, made it interesting, was finding a social networking pattern, for software development so that everybody could work on something at scale. That was really, I think, fundamental and foundational. Now I think it's important, We're going to talk about Linus, to talk about some things that are not good about software culture, not good about open source culture, not good about hacker culture. And that's where I'm going to talk about code of conduct. We have not been welcoming to new people. We got the acronyms, JFTI, We call people news, that's super unhelpful. We've got to find ways to be more welcoming and more self-sustaining in our communities, because otherwise communities will fail. And I'd like to thank everyone that has a code of conduct and has encouraged others to have codes of conduct. We need to have codes of conduct that are enforced to ensure that we have better diversity at our events. And that's what women, underrepresented minorities, all different kinds of people need to be well looked off to and be in safe and inclusive spaces. And that's the online events. But of course it's also for all of our activities offline. So Linus, as I say, I'm not the most charming of characters at all time, but he has done some amazing technology. So we got to like 2005 the creation of GIT. Not necessarily the distributed version control system that would win. But there was some interesting principles there, and they'd come out of the work that he had done in terms of trying to build and sustain the Linux code base. So it was very much based on experience. He had an itch that he needed to scratch and there was a community that was this building, this thing. So what was going to be the option, came up with Git foundational to another huge wave of social change, frankly get to logical awesome. April 20 April, 2008 GitHub, right? GiHub comes up, they've looked at Git, they've packaged it up, they found a way to make it consumable so the teams could use it and really begin to take advantage of the power of that distributed version control model. Now, ironically enough, of course they centralized the service in doing so. So we have a single point of failure on GitHub. But on the other hand, the notion of the poll request, the primitives that they established and made usable by people, that changed everything in terms of software development. I think another one that I'd really like to look at is Slack. So Slack is a huge success used by all different kinds of businesses. But it began specifically as a pivot from a company called Glitch. It was a game company and they still wanted, a tool internally that was better than IRC. So they built out something that later became Slack. So Slack 2014, is established as a company and basically it was this Slack fit software engineering. The focus on automation, the conversational aspects, the asynchronous aspects. It really pulled things together in a way that was interesting to software developers. And I think we've seen this pattern in the world, frankly, of the last few years. Software developers are influences. So Slack first used by the engineering teams, later used by everybody. And arguably you could say the same thing actually happened with Apple. Apple was mainstreamed by developers adopting that platform. Get to 2013, boom again, Solomon Hikes, Docker, right? So Docker was, I mean containers were not new, they were just super hard to use. People found it difficult technology, it was Easter Terek. It wasn't something that they could fully understand. Solomon did an incredible job of understanding how containers could fit into modern developer workflows. So if we think about immutable images, if we think about the ability to have everything required in the package where you are, it really tied into what people were trying to do with CICD, tied into microservices. And certainly the notion of sort of display usability Docker nailed that, and I guess from this conference, at least the rest is history. So I want to talk a little bit about, scratching the itch. And particularly what has become, I call it the developer authentic. So let's go into dark mode now. I've talked about developers laying out these foundations and frameworks that, the mainstream, frankly now my son, he's 14, he (murmurs) at me if I don't have dark mode on in an application. And it's this notion that developers, they have an aesthetic, it does get adopted I mean it's quite often jokey. One of the things we've seen in the really successful platforms like GitHub, Docker, NPM, let's look at GitHub. Let's look at over that Playfulness. I think was really interesting. And that changes the world of work, right? So we've got the world of work which can be buttoned up, which can be somewhat tight. I think both of those companies were really influential, in thinking that software development, which is a profession, it's also something that can and is fun. And I think about how can we make it more fun? How can we develop better applications together? Takes me to, if we think about Docker talking about build, share and run, for me the key word is share, because development has to be a team sport. It needs to be sharing. It needs to be kind and it needs to bring together people to do more effective work. Because that's what it's all about, doing effective work. If you think about zoom, it's a proxy for collaboration in terms of its value. So we've got all of these airlines and frankly, add up that their share that add up their total value. It's currently less than Zoom. So video conferencing has become so much of how we live now on a consumer basis. But certainly from a business to business perspective. I want to talk about how we live now. I want to think about like, what will come out all of this traumatic and it is incredibly traumatic time? I'd like to say I'm very privileged. I can work from home. So thank you to all the frontline workers that are out there that they're not in that position. But overall what I'm really thinking about, there's some things that will come out of this that will benefit us as a culture. Looking at cities like Paris, Milan, London, New York, putting a new cycling infrastructure, so that people can social distance and travel outside because they don't feel comfortable on public transport. I think sort of amazing widening pavements or we can't do that. All these cities have done it literally overnight. This sort of changes is exciting. And what does come off that like, oh there are some positive aspects of the current issues that we face. So I've got a conference or I've got a community that may and some of those, I've been working on. So Katie from HashiCorp and Carla from container solutions basically about, look, what will the world look like in developer relations? Can we have developer relations without the air miles? 'Cause developer advocates, they do too much travel ends up, you know, burning them out, develop relations. People don't like to say no. They may have bosses that say, you know, I was like, Oh that corporates went great. Now we're going to roll it out worldwide to 47 cities. That's stuff is terrible. It's terrible from a personal perspective, it's really terrible from an environmental perspective. We need to travel less. Virtual events are crushing it. Microsoft just at build, right? Normally that'd be just over 10,000 people, they had 245,000 plus registrations. 40,000 of them in the last day, right? Red Hat summit, 80,000 people, IBM think 90,000 people, GitHub Crushed it as well. Like this is a more inclusive way people can dip in. They can be from all around the world. I mentioned Nigeria and how fantastic it is. Very often Nigerian developers and advocates find it hard to get visas. Why should they be shut out of events? Events are going to start to become remote first because frankly, look at it, if you're turning in those kinds of numbers, and Microsoft was already doing great online events, but they absolutely nailed it. They're going to have to ask some serious questions about why everybody should get back on a plane again. So if you're going to do remote, you've got to be intentional about it. It's one thing I've learned some exciting about GitLab. GitLab's culture is amazing. Everything is documented, everything is public, everything is transparent. Think that really clear and if you look at their principles, everything, you can't have implicit collaboration models. Everything needs to be documented and explicit, so that anyone can work anywhere and they can still be part of the team. Remote first is where we're at now, Coinbase, Shopify, even Barkley says the not going to go back to having everybody in offices in the way they used to. This is a fundamental shift. And I think it's got significant implications for all industries, but definitely for software development. Here's the thing, the last 20 years were about distributed computing, microservices, the cloud, we've got pretty good at that. The next 20 years will be about distributed work. We can't have everybody living in San Francisco and London and Berlin. The talent is distributed, the talent is elsewhere. So how are we going to build tools? Who is going to scratch that itch to build tools to make them more effective? Who's building the next generation of apps, you are, thanks.

absolutely build on some of Ben's comments because I think what he articulated is one of the killer use cases of VMware cloud on a to us that I think is driving that momentum right which is we think it's one of the best solutions in the marketplace and customers have told us this to enable them to migrate and modernize right so let's talk about the migrate piece first right you have customers that have these tremendous enterprise class applications running on vSphere and their data centers they're built on top of that platform they depend upon it for performance availability everything else with VMware Club a native us we can migrate those applications with zero downtime no refactoring no additional cost in a matter of weeks or months as opposed to if you had to refactor everything to take years and millions of dollars right so that cloud migration use case I would say is that is the killer for us and that's you know exactly what Ben was we're definitely seeing that and I think that's the thing that really got me excited about a year ago was watching enterprises make that transition and say you know what the center of gravity has gone from architectures inside the on-prem data center is now moved to in the cloud I mean that shift has happened it happened to people talked about it five years ago but they didn't mean it and now when you talk to enterprises they are actually moving into the cloud not just talking about it and they're saying where that is the center of gravity and what's interesting to me was I think even just the tone of Andy Jesse today and what he was talking about was it's once you define what your architecture is you push it everywhere so cloud 1.0 and 2.0 was really more about taking my architecture that was on prem and pushing it into the cloud so let me take virtual appliance a virtual router basically my hardware router packaged it up put it on the cloud that's not cloud native it's cloud naive as we talk right and so what's the chase has happened is now everybody realizes the center of gravity is in the cloud and you start seeing things like outposts you see things like wavelength you see things like you know tgw network manager things getting pushed out the architecture of the cloud now actually pushing out and extending out into on-premises I've been at it for a couple of decades so in the beginning there was a lot of evangelism that this is safe it's consumable by the enterprise it's not some kind of crazy idea to bring open-source you're not going to lose your intellectual property or things like that those days I mean I I'm sure you can find an exception but those days are largely over in this in the sense that open-source has gone mainstream so I would say open-source is one most large enterprises have an open-source strategy they consider open source as critical to not only how they source software from vendors but also how they build their own applications so the world has really really evolved and now it's really a question of where are you partnering with vendors to build infrastructure that's critical to your business but not your differentiator and where are you leveraging open-source internally for your to differentiate your business I think that's a more sophisticated view it's not the safety question it's not is it is it legally you know that you're bringing legal concerns into the picture it's really a much different conversation and people in the enterprise are looking how can we contribute to these projects so that's really it's pretty exciting actually both are a great place for startups right they're not meters cluesive so I think if you go horizontal the amount of data being created by your applications your infrastructure your sensors time series data ridiculously large amount right and that's not going away anytime soon I recent did investment ain't chronosphere did you guys covered over at coupon a few weeks ago that's talking about metrics and absorbedly data time series data so they're gonna handle that horizontal amount of data petabytes and petabytes how can it query this quickly deeply with a lot of insight that's one play right cheaper better faster at scale the next play like you said is vertical it's how do I own data or slice the data the more contacts they know as can have we talked about like the virtual cycle of data right this the system of the tile well bye own set of da to be healthcare government or self-driving car data that no one else has I can build a solution and to end and go deep and so either pick a lane or pick a geography you can go either way it's hard to do both though it's hard for start-up any big company it's very few companies can do two things well starves especially succeed by doing one thing very well I'm impressed they got two CEOs the CEO of goldman sachs david solomon the CEO of Cerner coming to the show that's kind of rare that the CEO of your customer comes to the show I guess the second thing I'd say is you know Amazon is not a rinse and repeat company at these shows although they are when it comes to shock and awe so they ticked the Box on shock and awe but you're right John they're talking a lot about transformation I would sort of think of it as a disruption here's what I would say to that Amazon has a dual disruption agenda one is its disrupting the horizontal technology stack and two it's disrupting industries it wants to be the platform of which startups in particular but also incumbents can disrupt industries and it's in their DNA because it's in Amazon's DNA and I think it's the last thing I'll say as Amazon is the retai Amazon retail is the you can buy anything here store and now to your point Justin Amazon Web Services is you can get AWS anywhere at the edge and a little mini data centers that they're built on outpost and of course in the cloud absolutely you know I'd say primarily were most kind of pleased with the variety of workloads and these cases the customers are bringing us into you know I think when we started out on this journey we saw a tremendous promise for the technology to really improve the aw psycho system and customer experience for people that wanted to consume block storage in the cloud what we learned as we started working with customers is that because of the way we've architected the product brought a lot of the same capabilities we deliver on our flash arrays today into AWS it's a lot of customers to take us into all the same types of workloads that they put flush arrays into right so that's their Tier one you know mission-critical environments there VMware workloads their Oracle workloads or safety workloads they're also looking at us from everything from you know to do lifts and shifts test and dev in the cloud as well as dr right and and that again i think you know speaks to a couple things it speaks to the durability the higher level of service that were able to deliver in AWS but also the compatibility with which we're able to deliver the same sets of features and you know have it operate in exactly the same way on prime in the cloud because it's look if you're gonna dr the last time you know the last point in time you want to discover that there's a caveat hey this feature doesn't quite work the way you expect is when you have a dr failover and so the fact that we set out with this mission in mind to create that exact level of sameness you know it's really paying dividends in the types of use cases the customers are bringing us into I think we're delighted you know Mike obviously and I've been friends for years he's had some connections with VMware in his past that that that certainly helped in setting up this partnership so we're grateful to Mike and Andy and the team for that and it's you know two and a half to three years now since we announced it tremendous amount of customer interest listen you know we said at the beginning of this when you take sort of the king of the public cloud and the king the private cloud together and don't force customers to say these have to be separate doors you can do them both together customers like that message and what we've been really doing over the course the last 12 18 months is perfecting use cases for this platform I think to us the key word is migrations cloud migrations when people are moving their workloads of an app off vmware vsphere or our cloud foundation we want this to be the best place for it to land we are more cloud and AWS for migration opportunity and anything short of that refactoring app would be you know not something that would be a good use of people's time and money because they should be then modernizing with all the wonderful services that Amazon's built once they've migrated so we've really perfected our message in the course the last six 12 months to two ms migrated and modernized migrated modernized so we could migrate you into this avenue and then modernized with a set of container and other services so that mess is working we put on stage at VMware and there are many of them here too big Amazon customers VMware cloud and Amazon Freddie Mac and IHS market and they were telling are tens of thousands customers at those shows and similarly many of them here that that's the best option to be able to do things yeah so if you know public sector public sector actually has a lot of Windows or Microsoft workloads in it and so we're seeing a lot of public sector customers looking to modernize their Windows workloads in fact we made several announcements just yesterday around helping more public sector customers modernize for example one is Windows Server 2003 and 2008 will go out of support and so we have a great new offering with technology that can help them to not refactor but actually abstract those layers and move quickly to 2016 and 2019 because both of those will go out of support in January and Dave mentioned you know cloud first strategies but we're also seeing a lot of movement around data you know data is really powerful Andy mentioned this as well yesterday but for example in our partner keynote where I just came from we had on stage Avis yeah hey this not public sector customer but what they're doing is the the gentleman said you know your car can now talk to you and that data is now being given to local state officials local city officials they can use it for emergency response systems so that public and private use of data coming together is also a big trend that we're seeing it's all about breaking down I mean if devops is all about breaking down silos between Devon operations and in other parts of the business Deb sack ops or secure dev ops or whatever we want to call it is just bringing more people into the fold and helping security join that party and get at things earlier in the cycle so we can catch it before it you know before before there's a breach that's in the news so you know I think there's going to continue to be convergence between Amazon business in AWS over time and in the marketplace we offer kind of a goods marketplace they offer a software marketplace and a services marketplace and so I think we're still working on how do we harmonize that experience better and we've got a lot of work to do there we have a saying at Amazon that it's always day one and that's a great example where we still have a lot of work to do but one of the things that is another one of our partners Koopa which is a procure-to-pay a platform and a longtime Amazon business partner we've done some pretty creative things to improve the user experience and make it easier for customers use both Koopa and Amazon business and in concert together Koopa announced a couple months ago they've built an integration to the AWS marketplace and so that's a pretty exciting opportunity where people who are provisioning services via AWS be a Dobis marketplace can have that that transaction flows seamlessly into their prepare to pay solution and let you know the user who's provisioning that focus on what they want to do which is developing new solutions to serve customers I mean the spectrum is massive so the our biggest challenge is keeping up with everything and continuing to innovate with all the things that are happening but again the benefits of the platform that we have enables us to do that and the enhancements we weight made this year this year now that our platform is is more open we can connect a collect data from multiple entities not just the New Relic agents that we've that we were built on so the concept of observability and being able to observe the entire application environment it is built on the fact that data's got to come from all these different places then we need to turn that around and curate it into the right experience in the right use case that the customer is looking for so all I can say is that our company's built on innovation we try and stay on the cutting edge of all that trying to stay current with that and meet the customers needs as as everyone here is innovating like crazy at scale well I mean there's a lot of a lot of the technology we build comes from things that we're doing ourselves you know and that we're learning ourselves it's kind of how we started thinking about microservices serverless - we saw the need we know we would have we would build all these functions that when some kind of object came into an object store we would spin up compute all those tasks would take like three or four hundred milliseconds then we spin it back down and yet we'd have to keep a cluster up in multiple availability zones because we needed that fault tolerance and it was we just said this is wasteful and that's part of how we came up with lambda and you know when we were thinking about land that people understandably said well if we build lambda and we build this serverless event-driven computing a lot of people were keeping clusters of instances aren't going to use them anymore it's going to lead to less absolute revenue for us but we we have learned this lesson over the last 20 years at Amazon which is if it's something it's good for customers you're much better off cannibalizing yourself and doing the right thing for customers and being part of shaping something and I think if you look at the history of technology you always build things and people say well that's going to cannibalize this and people are gonna spend less money what really ends up happening is they spend spend less money per unit of compute but it allows them to do so much more that they ultimately long-term end up being you know more significant customer look I mean the the SHA this show estate Volante says amazon always delivers with the shock and awe you know broadest and deepest so many pieces here you know I took a selfie with many people and the biggest celebrity of the show AWS outpost the rack it's over in the corner there and people asking me about all the gear inside I said you should stop asking about that because you will never touch it only AWS will so put a curtain around it it's managed as a service and that's what I think people are still trying to understand we've been talking about cloud for what 15 years now but Amazon's positioning on cloud is still different than everyone else's when I think back to some of the waves there's that buzzword and there's one or two that really architectural er different in deliver and Amazon laid out their strategy even more and through the geeky pieces and transformation was the theme you [Music]

la from Las Vegas it's the cube covering AWS reinvent 2019 brought to you by Amazon Web Services and Vinum care along with its ecosystem partners hello everyone welcome to the cube we're here live in Las Vegas for AWS reinvent 2019 I'm John Farrar your host is silicon Angles flagship the cube we're extract a signal noise leader in event coverage with day Volante my co-host and justin warren tech analysts Forbes contributor guru of cube host guys keynote for J&E jassie first of all I don't know how he does it he's just like continues hissing Marc loved the live music in there but a slew of announcements this is a reinvention of AWS you can tell that they're just essentially trying to go the next level on what the cloud means how they're gonna bring it to customers and you know they've been criticized for you know kind of nut I won't say falling behind I could say Microsoft's been probably praised more for catching up and it's been a lot of discussion around that the loss of the Jedi contract variety of enterprise wins Microsoft has the field Salesforce Google's just kind of retooling but Amazon clearly the leader with a little pressure for the first time in the rearview mirror they've got someone on their on their tail win and Microsoft's far back but this isn't a statement from from chassis and Amazon of okay you want to see the Jets we're gonna we're gonna turn on the Jets and blow pass everybody Jesse gets cocky self Justin what do you think yeah so a lot of signaling to enterprise that it's safe to come here it's this is where you can have everything that you need to get everything that you need done you can get all of it in one place so there there is a real signal there to say Enterprise if you want to do cloud there's only one place to do cloud enterprise customers they tried out some big names Goldman Sachs not a small enterprise they had all the classic born in the cloud but you know we put out this concept on I'm on our Silicon angle post called reborn in the cloud almost born-again enterprise you start to see the telegraphing of what their core message is which is transform just don't kick the tires and fall into the Microsoft trap go with em is on and transform your business model transform your miss not just run IT a better way than before well yeah I mean I'm impressed they got two CEOs the CEO of Goldman Sachs David Solomon the CEO of Cerner coming to the show it's kind of rare that the CEO of your customer comes to the show I guess the second thing I'd say is you know Amazon is not a rinse and repeat company at these shows although they are when it comes to shock and awe so they ticked the Box on shock and awe but you're right John they're talking a lot about transformation I sort of think of it as disruption here's what I would say to that Amazon has a dual disruption agenda one is its disrupting the horizontal technology stack and 2 its disrupting industries it wants to be the platform of which startups in particular but also incumbents can disrupt industries and it's in their DNA because it's in Amazon's DNA and I think it's the last thing I'll say as Amazon is the reach a Amazon retailers the you can buy anything here store and now to your point Justin Amazon Web Services is you can get AWS anywhere at the edge and a little mini data centers that they're built on outpost and of course in the cloud all right I want to get you guys reactions a couple things I saw and I want to just analyze the keynote one as we saw Jesse come out with the transformation message that's really more of their posture to the market you should be transforming we're gonna take Amazon as a center of gravity and push it out to the edge without post so kind of a customer company posture there on the industry then you had the announcements and I thought that the sage maker studio was pretty robust a lot of data and announcements so you had the transformation message a lot of core data and then they kind of said hey we're open we got open source databases we got kubernetes and multiple flavors a couple steers from the Twitter crowd on that one and then finally outpost with the edge where they're essentially you know four years ago Dave they said no more data centers in ten years now they're saying we're gonna push Amazon to the your datacenter so you know a posture for the company a lot of data centric data ops almost program and build I'm also DevOps feel to it what's your reaction to that I think the most interesting part for me was the change there was a bit of a shift there I think he made the statement of rather than bringing the data to the computer we want to bring the compute to the data and I think that's that's acknowledging reality that data has gravity and it's very difficult for enterprises particularly if you've already invested a lot in building a data Lake so being able to just pick that up and then move it to any cloud nothing let alone AWS just moving that around is is a big effort so if you're going to transform your business you have to kind of rethink completely how you address some of these issues and one of that would be well what if rather than let's just pick everything up and move it to cloud what if we could actually do something a little bit better than that and we can pick and choose what we want to suit our particular solution and your point Dave I think that's where Amazon strength comes from is it they are the everything store so you can buy whatever you want be at this tiny little piece that only five companies need or the same thing that everyone else on the planet needs you can come and buy everything from us and that's what I think they're trying to signal to an organization that says look if you want to transform and you're concerned that it'll be difficult to do we've got you we've got something here that will suit your needs and we will be able to work with you to transform your business and we're seeing you know Amazon years ago we wouldn't talk about hybrid and now they're going really all-in on hybrid and it's not outpost is no longer just this thing they're doing with VMware it's now a fundamental piece of their infrastructure for the edge and I think the key point there is the the edge is going to be one with developers and Amazon is essentially bringing its development platform to the edge without posts as the the underpinning and I like the strategy much much better than I like what I'm seeing from some of the guys like HP and Dell which is they're throwing boxes you know over the fence with really without a strong developer angle your thoughts I mean my my big takeaway was I think this is key knows about a next-generation shift on the business model but that's the transformation he didn't come out and say it I said it in my post but I truly believe if you're not born in the cloud or reborn in the cloud you'll probably be out of business and as a startup were to ask them of the VCS this question how do you go after and target some of those people who aren't gonna be reborn in the cloud to have the scale advantage but the data announcements was really the big story here because we look at DevOps infrastructure as code programming infrastructure we've seen that that that's of now an established practice now you start to see this new concept around data ops some people call it AI ops whatever but Dana now the new programmability it's almost a devops culture - data and I think what got my attention the most was the IDE for stage maker which kind of brings in this cool feature of what everyone was which is I want machine learning but I can't hire anybody and I got to make I got a democratized machine learning I got to make application developers get value out of the data because the apps need to tap the data it's got to be addressable so I think this is a stake in the ground for the next five to ten years of a massive shift from increasing the DevOps mission to add a layer making that manageable multiple databases he's totally right on that it's not one database if you want time series for real-time graph for you know network constructs it's pick your database you know that shouldn't be it inhibitor at all I think the data story is real that's the top story in my mind the data future what that's going to enable and then the outpost is just a continuation of Amazon realizing that the center of the cloud is not the end game it's just the center of gravity and I think you gonna start to see edge become really huge I mean I count ten into ten purpose-built databases now and jesse was unequivocal he said you gotta have the right database tool for the right job you're seeing the same thing with their machine learning and AI tools it's been shocking dozens and dozens of services each with their own sort of unique primitives that give you that flexibility and so where you can disagree with the philosophy but their philosophy is very clear we're gonna go very granular and push a lot of stuff out there I think there's two bits at play there that I can see you know I think you're right on the data thing and something that people don't quite realize is that modern data analysis is programming like it's code your data scientists know how to code so there was a lot of talk there about notebooks going in there like they love their notebooks they love using different frameworks to solve different problems and they need to be able to use for this one I need tens of flow for another one I might need MX net yeah so if you couple that that idea that we need to it's all about the data and you couple that with developers and AWS knows developers really really well so you've got modern enterprises lot wanting to do more with the data that they have the age or business problem of I've got all this information I need to process I need to do be out bi I need to do data analysis and you couple that with the Pala that iws has with developers I think it's a pretty strong story then you know in my interview with Jesse I asked him the question and I stole the line from Steve Moe Mulaney from aviatrix you take the tea out of cloud native it's cloud naive and I think what I've been seeing is a lot of customers have been naive about what cloud is and it's actually been buying IT and so they really don't are not sensitive to the capabilities message so I asked Jeff see I'm like you got these capabilities that's cool if you want to go to the store and buy everything or look at everything and buy what you want and construct and transform check no problem I buy that however some customers just want a package solution and Amazon has not always been great on having something packaged for customers so he kind of addressed that and this might be an Achilles heel for Amazon as Microsoft has such entrenched sales sales presence that they might be pushing a solution that frankly customers might not care about capabilities we did see one bit where there was a little bit of a nudge towards is fees and and systems integrators and I think that that really for me is there needs to be a lot more work done by Amazon there because that's what Enterprise me enterprise is used to dealing with systems integrators that will help them to use the raw materials that ados provides to solve that promote you said there are two segments of developers and customers one that wants all the low level building blocks and others want simpler faster results with abstractions aka packaging so they're going down the road but again they're not shy don't like hey we're just going to continue to build we're not going to try to move off our trajectory they're gonna stay with adding more power and frankly some digs at snowflake I fought with red shift and I thought the dig to the kubernetes community with we code our own stuff wink wink we don't have to slow down was a nice jab at the CN CF I thought because he's saying hey you know what we're not in committees deciding features which is the customers and implementing them so a kind of a jab well sure that's gonna rapid a I would say the snowflake is sort of a copycat separating compute from stores that's what snowflakes has been doing forever but he did take direct jabs at IBM Oracle and obviously Microsoft with with Windows so I like to see that you know usually Jessie doesn't do that it's good take the gloves so much so many announcements out there you got to go to silk and angled comm will have all the stories but one of the top stories coming into the reinvent that we didn't hear anything about but if you squint through and connect the dots on Jessie's keynote it is pretty evident what the strategy is and that's multi-cloud so I'll see multi-cloud is a word that Amazon is not using at all onstage as you can tell they don't really they're in well they're one cloud they don't really care about the other clouds but their customers do so guys multi cloud is a legit conversation how they get multi cloud is debatable acquisition sprawl by the end of the day multiple clouds is reality I think Jessie was kind of predicting and laying down some early narratives around the multi cloud story by saying hey we have more capabilities we're faster we're doing more stuff so I think he's trying to cede the base on the concept of hey if you want to go look at other clouds try to go apples to apples NIT that other than that he didn't really address at all multi-cloud what do you guys think about multi cloud yeah what it's pretty much that if you're gonna have multiple clouds at least one of them's gonna be AWS so they're gonna get some of your money if we came a bi can't get all your money I'll get at least get some of your money that's reasonable but I think part of the multi cloud conversation is that enterprises are actually trying to clarify their existing way of doing things so cloud isn't a destination it's not like a it's not a physical location it's a state of mind it's a way of operating things an enterprise that that's that's the transformation part that enterprises are trying to do so transform the way that they operate themselves to be more cloud like so part of the multi cloud piece I think that people are kind of missing is well it's not just Amazon or some of its competitors its existing on-site infrastructure and making that into a cloud which i think is where something like outpost becomes a really strong proposition and I've said a million times multiplied cloud is more of a symptom than it is a strategy that'll start to change they will see an equilibrium there you know right cloud for the right job but today it's a problem that CIOs are asked being asked to clean up the crime scene all right let's wrap up by summarizing the keynote each of you guys give me your take on I'll start I think this was a inflection point for AWS and Jesse in the sense of they now know they have to go the next gen loud it's Amazon enterprise it's data it's outpost it's all these things it's truly next-gen I think this is going to be all about data it's all gonna be about large-scale infrastructure and data scaling and with edge and outpost I think is really an amazing move for them in the sense that's gonna probably put in motion another five to ten years of continuing architectural reshipping and I think that if you're not born in the cloud or reborn in the cloud you're gonna be naive to the fact that you're not gonna have the capabilities to be success when I think that's going to be an opportunity for entrepreneurs and for companies pivoting into enterprises so I think this goes will go might go down as one of the most pax keynotes but I think it'll look back as one of the instrumental transitions for Amazon so I think he did a good job beginning and to rush 30 announcements in three hours marathon but overall I thought he did a great job I think I would agree Jesse always does a good job he's giving a message to you know CEOs as opposed to the CIO and he had two CEOs on stage I thought there was quite a gap between you know that message of transformation and then sort of geeking out on all the new services so there's still some work to be done there but I think it's a lot of developers in the audience I'm seeing them tell your boss to get on the train it's a very hard keynote to serve both audiences but so it's a start but there's a lot of work to be done there Justin yeah I agree with that I think this is probably one of the first keynotes maybe last year but certainly this year there's like AWS is very serious about enterprise and is trying to talk to enterprise a lot more than it ever has it still talks to developers but we didn't see anywhere near as much interesting in kind of the startup ecosystem it's like no no cloud is for serious companies doing serious work and I think that we're just going to see Amazon talking about that more and more and more because that's where all the money is yeah next-generation cloud new architectures all about the enterprise guys this is the cube opening day for three days of wall-to-wall coverage keynote analysis from Andy Jessie and Amazon Andy Jessie will be on Thursday at 3 o'clock we got a lot of top Amazon executives will who'll help us open and unpack all these to make mega announcements stay with us for more cube coverage and go to Silicon angle comm cube net for the videos be back back after this short break [Music]

>>live from Boston, Massachusetts. It's the Q covering I. F s World Conference 2019. Brought to you by I. F. S. >>Welcome back to Boston, everybody. You're watching The Cube. The leader in live tech coverage is Day one coverage of the I. F s World Conference. Darren Russo's here is the CEO of F S Darren. Thanks for coming back in the Cube. Great TV again. So last year was your first year. He was kind of laid out your vision at the World Conference. How's progress? >>Yeah, Look, it's going incredibly well. We were really focused on how we go from being a pretty fragment of global business to being, you know, an integrated business where we were able to operate. You know, its scale globally in a very homogenous way, where the customer experience was the same, irrespective where they engaged with us. And, you know, we've made a tremendous amount of progress with it, So you know, the business is growing really strongly. Net revenues up 22% year on year. I lost its revenues up 40% year on year are clouds up in the triple digits, so you know it's tough to be critical of how it's going so far. >>That's great, Great. You're growing faster than your peers. I think the stat was you gave us three Ex factory except in the industry would be awesome. Is that means that your primary benchmark do you want? You want to gain share? You want to go faster than the big whales, I presume. I >>think two things One is customer satisfaction, we believe, is the key indicator of long term success. S O. You know, we're the number one ranked European efforts. Salmon gotten appearance sites. That's that is and always will be my number. One metric. Can we be way the number one from a customer satisfaction perspective? And then I believe the revenue stats will follow and you know that's where we are. So certainly, if you look at our our core peers, the big G R P vendors, all of them are flat on. Dhe were growing 20 ships since >>one of the things you mentioned in your Cube interview last year was one of the things that you wanted to focus on was I'll call regional alignment. Paul and I used to work for I D. G. I worked for I. D. C. You were editor in chief of Computer World. We work for a company, had more offices overseas and IBM, and it was really hard to herd the cats. And that was one of the things that you cited. Have you been able to get people generally poor or at the same time? And how has that affected your business? Yeah. Look, I >>think the big challenge before I arrived was that there wasn't really a strategy of global strategy for the business. My face had a way of working and there was a strong culture, but there wasn't really a strategy. And obviously it's difficult to be critical of people when they not following the strategy when there isn't one s o. You know, Step one was really making sure that we had a strategy on DDE that was really about being focused on the five industries that we focused on, focused on three solutions on dhe focused on the six segments of customer, which is half a 1,000,000,000 to 5 billion. So now, globally, you know, irrespective the office that you go to, um anywhere in the world, they're focused on those five industries they focused on those three solutions and they're focused on their customer segments. So it helps me. P. M >>I said during our preview video video this morning that I've been around this industry as long as I f s has, until last year had never even heard of it. Is that just me being clueless? There's something there >>that we were just saying before we started that we're the definitely the biggest software business you've never heard of. Um, and and and that's common, I think, you know, we were There are a couple of factors. One is that the business was very European centric. Andi didn't really engaged in a tremendous amount of marketing and media prison. So, you know, those are elements that, you know, I think we're doing a better job off now, But we have a long way to go. The challenge that we have is that where we compete, we win when we get in and were able to tell our story, and we're able to show the value we win. We just don't get into as many deals as we need to. And that's the challenge we have. >>Yeah, there was a lot of talk this morning about the importance of those five pillars of those five industries. If you're going to become the next S A P, you're gonna have to branch out beyond that. What is your thinking about diversify >>becoming the next? They say he is definitely not my ambition, You know, I think way remain focused on customer satisfaction. And, you know, I think that there's a there's a difference. Whatever it is leading them, it's not customer satisfaction. You worked >>there for four years. >>I worked there for four years. I know. I think the big thing for me is is that we've got to stay focused on their customer voice. They focused on what delivers value for our customers beyond just the rhetoric and hyperbole. You know, I think when you when you listen to a lot of the complexity that our customers are facing today, any customers are facing. Companies are facing increasingly disruptive times, and the tech industry is making life more difficult for them. The more best of breed solutions get both. The more fragments that potential the landscape is, the more complex it becomes for customers if they have to try and figure out. How do we integrate these things and derive value from this highly fragmented landscape? So you know, we're trying to solve that problem. How do we make it easier for customers to challenge in their industry? And that's where this whole for the challenges has check comes from. How do we help him to be disruptive in their industry? Have competitive advantage? >>That seems to be a sort of a fundamentally different thing about your approach, though. Is this focus on those vertical industry's most e r P companies did not do that. Is that something that is core to your values? >>Look, I >>think what we recognize is that as you move to the cloud, you have to drive to standard. That's just the reality of going to the cloud on what's happening for the horizontal E. R B vendors. So the locks of ASAP and Oracle is that they have one e r P solution that fits every industry. So if it's good for health insurance and it's good for a bank, then it's difficult to really get your head around the fact that it could be good for a defense manufacturer, but the functional requirements is simply vastly different on that means that you have to customize them. If you have to customize that, they can go to the cloud. So what we believe is that you have to have this vertical specialization, the five industries that we serve us all. A lot of commonality in the process is that they use. And that's why that vertical strategy is so key to our success. So you won't see us going into financial service is, or health care or retail worth that core application. We may in time in many years to come branch out. That will be a different solutions. >>So your tailor, that app for that module for that industry, Yes, just go deep, deep functionality. You're known for that, but at the same time you're also messaging. You want your customers to be able to tailor this for their environment. So square that circle for me. >>So I think when we talk about a choice and and I think tailoring is the wrong word, we talk about choice. We're talking about choice of deployments on Prem or in the cloud choice of customer choice of partner, rather who they're going to deploy with on Dhe, then The solution is really an industry solution that comes with that functional death. And we don't we don't advocate their customers customized that all. We really don't want them to customize it. What we explain to them in some detail is that the real value comes from adopting the solution for two standard and staying on a vanilla application. Because that vanilla application, you're going to be able to withstand future upgrades, the total cost of ownership gets lower. The processes that are embedded in that application or best of breed at the box. That's what they're intended to do, and that works when you have a vertical application. When you have a horizontal application and you're trying to have a do things that it shouldn't naturally be doing, that becomes company. >>Well, correct me if I'm wrong, but wasn't that essentially the message ASAP had when it went through? It's hyper growth in the late nineties. I mean, there was a Y two k thing there, too, but ah, lot of the message was around. Do it our way and and then you don't have to get stuck in a rut, >>So I think that when it came out with that generation of application. That certainly was what they had hoped would happen. But what happened in practice is that the system integrators came in and the whole business process reengineering explosion happened on Dhe. That's not how it how it manifested itself. So what you see is, you see, he's very large, monolithic ASAP applications that were customized over in some cases decades, not not. You know, if a customer is deploying for two standard, then they should be able to deploy in a period mission. In weeks, we spoke about our deployment with Racing Point. If one team and going live in 12 weeks, you know, we're a 700 million global business. We deployed a knife s in 24 weeks. You know, if a customer's deploying for two standard, it's measured in weeks. As soon as they start to talk about two years or three years or five years or seven years there, customizing the solution significantly. Yeah, I >>mean, it became just sort of a perpetual upgrade, maintenance and up for the time it had a business impact. But boy, you think a cloud today agility, you know, getting rid of waterfall approaches, Missus. Antithetical to today's Look >>what I don't point fingers here. I think that this just maturity come with experience. The line of business applications you'll see our EMS and your HR solutions have taught people that you can, if you think about this is look at sea. Are Emma's an example? You had Siebel before people would implement stable. They would customize Siebel that would take long implementations. They were highly bespoke applications and then sells. Force came along and just destroyed them, and they destroyed them. Because what people learned very quickly was that there was a really easy to consume, really easy to use application that functionally might be inferior. But the compromises that you'd make from a functionality perspective will weigh, outweighed by their time to value in ease of use. And and the learnings from CR mnh are in procurement. Those line of business applications have now being backed into in the e. R. P >>world. So in terms of capital allocation, you're owned by private equity, which is actually a public company. I'm interested in how you're allocating capital R and D, where you're where your emphasis is. You don't have to you have to do stock buy back, but, you know, describe the P relationship. >>So look, one of my learning's to see survive this is that not all private equity firms or equal they have different strategies are very fortunate to be with Ekiti, who are a growth investor. They're known as a growth investor on dhe, and they buy companies that are strong growth tech firms on dhe. They've been hugely supportive of us investing because they understand that the investment in technology is important. So, you know, just looking at some detail today we invest twice as much in R and D as we did three years ago, just to give you, you know, one data point. So there's a big focus on technology, and the thing is, is that we we have to invest in technology to drive those attributes that are discussed earlier. How do we How do we enable customers to adopt a solution? It's a standard so they can go alive quicker. How do we enable customers to be able to sit down in the front of the application like we do with the mobile phone and intuitively know how to use it? How do we reduce the total cost of ownership through automation. Those are capabilities that you know that they don't come for free. We have to invest in them. So big investments in technology. And >>I think the private equity guys, at least the modern ones, have realized Why should the V. C's have all the fun they realize? Hey, we can actually put some money in tow and the transforming we can have a bigger exit and actually make much better returns than sucking the company drive. Yeah, well, look, I think the other >>thing is is that you know, in public companies, you have the downside off. You know this this courtly metric Ondas quarterly cadence. Andi, you see very compromising decisions being made because you know, people can't afford to miss 1/4. There's no long term planning that's done on dhe. That's fundamentally not the case and the private equity world, you know, not unusual now for four p firms to hold companies for 5678 years on, and that allows you to take a very long term strategic view. If if if a shift from perpetual to subscription is the right thing to happen, they can do that without worrying that, you know, because of the definite earnings are revenue that you're going to get caned by the market next quarter. Andi. I think that that needs to, I think, better decision making for the long term. >>A lot of companies are struggling. >>If you have the right P for because you get bought by the firm of events, you want to go public. But the the you said something this morning that 50% of your customers each year or net knew, How are you pulling that off >>That 50% of our license revenue? Eso way we went about 300 odd new customers a year. Obviously, that's growing, as I said, you know, 40%. But you know, it's ah, I think, having done this for 25 years, there are companies that are or good at extracting revenue from their installed based. One of the analysts here has as a hashtag wallet Fracking is what do you think It's such a great So you know, they're good at Wallick fracking and and I think the customers that that our customers off those vendors know exactly who they are and you know I think that for us to that the fact that we're able to go out and win 50% of our license revenue from net new name customers, I think is a really strong indicator of the health of the business. It's much harder to do than just extracting revenue out of the install base. You know, we don't have a compliance practice. We've never charged a customer for you in direct access. You know, these are principles that we stand by, and it's easier to say that your customer centric on get 80% of your revenue, have your installed base because you're doing compliance rounds. But, you know, we put our money where our mouth is, and that's not that's not how we do it. >>Are these net new customers? Are they? Are they migrating from QuickBooks or they migrating from a Competitors >>know, because of the segment that we're in this half a 1,000,000,000 to 5 billion? I would say the majority of them are what I would call first generation the Rp solution. So you know you're talking about you know, the original generation of Microsoft's acquisitions, the divisions and the eggs actors and the Solomon's and so on on. And then, you know, it's a P R two and our three customers you're talking about customer sitting on, you know, the solutions that in for hoovered up the matrix B picks type customers, ace 400 customers. So they're you know, they're first generation your P solutions that simply don't have the flexibility to deal with the complexity and demands of modern business world. >>From 2009 about 2017 I f. S was pretty inquisitive and then just actually, I was gonna ask you >>when I started, you stopped >>it, right? But then, you know, today you announced an extra small acquisition, But how should we think about M and a >>look? The first year for me was really about trying to build a functional business. You know, we spoke about how fragmented this really hit to Jenna's business. Andi just occurred to me. You know, if we go out and we start to buy things, how do we integrate them into a business that's completely fragments? And you know, it had no identity or culture. So, you know, the last year has been focused on how do we build their common understanding of what it is that we're doing. We now have a very clear strategy. Five industries, three solutions, one segment. And you know, when you when you have that clarity of vision that it's really easy to guard and do him and I because you know what fits and what doesn't fit, you can understand exactly how you're gonna build value for customers on dhe. That's why the S t a deal is so good for us. Because we're now the undisputed leader in field service management, you know, 8000 our customers globally, which is way more than anybody else. Scott, Andi, you know, you should absolutely expect more from us. But it will be in the five industries, three technology segments and one customers. Isaac. >>Well, in the A p I enablement should obviously facility. >>Absolutely. I mean, I was just with a partner of ours now, and they have this amazing augmented reality solution. You know, it will be a combination of off going out there to build market, share a cz well, as finding you know, really innovative solutions that can help us advance the technology that we provide customers. >>You have a new slogan this year for the challengers, which seems to be aimed at companies that that imagine themselves as challenging the Giants, which is great. But if you're not a company that season sees themselves that way. Are the studies level home with I have s Look, >>I I think I was with a group of CEOs from one of the big analyst rooms, and they had the portfolio companies and their private equity firm and analysts that CEOs of the companies are having a conversation with him about digital transformation. And I I made a rather provocative statement which, you know, got unanimous agreement, which is that all of the CEOs there with either in an industry that was being disrupted and we're trying to figure out how they respond to that disruption or they would soon not every job and they all acknowledge that they absolutely fit into that category. In other words, all of them were being disrupted. All of them were facing a challenge. It was kind of like, you know, if it is happening to all of us at a more rapid pace than we have ever had before. So my view is, is that you know if if you're in the room and you're going, you know, if it's might not be for us because we're not a challenger. Yeah, The lights may not be on >>for Long s o double click on that. What role does I s play in terms of digital transformation? >>If I could just hold on there because the thing is, there are leaders in Mama, there challenges. And there are leaders. The leaders typically are gonna go with seif solution. They're gonna go with one of the legacy our peace. So I'm not suggesting that everybody necessarily is a challenger. There are leaders, you know, Nokia was a leader until they weren't because they were complacent. Andi, I think they you know, they didn't run on I office. So, you know, I think there are two segments. There are leaders and there are challenges, and we're there for the ones that are ready to disrupt. Sorry. >>Please clarify that. No. Good. So So get back to it. Sort of digital transformation and disruption. What do you see? Is the role of AARP generally, but specifically I f s. >>Look, I think we digital information. A lot of discussion about it on the stage this morning. I've just touched on it now. I think that it takes very different forms. What most industries are finding is that they're facing a lot of non traditional competition and they're having to innovate around their business models. They can't going to market in the same way as they did before. They're having to innovate because of this non traditional competition. Andi. Understanding your your customer's understanding, your your staff, understanding your supply chain understanding your financials are all critical parts of being able to respond to whatever their changes, and that's where the RP solution comes into it. I think there's an interesting challenge now, which is that as those applications have become more fragmented and you've got more based debris cloud applications Ah, lot of the value often E. R P was that you had this integrated set of applications that you had this one source of the truth andan. Fortunately for many customers today, they don't have that because they've got import all of these best of breed applications and they don't have one source of the truth that multiple invoices made it multiple versions of their customer in the databases. Andi we still stand for a single integrated the r p. So, you know, I think understanding those elements of your businesses key. I was with a customer of ours in Nebraska a short while ago, and they were talking about our existing office customer. They were talking about the steel import duties that were imposed through the trade war with China. And they were saying, Look, that they had been able to respond to that in a way that they had good visibility of the supply chain, who was improved, imposing the tariffs, how they were going to impact them when they were going to impact them. And because they had this integrated Siara AARP. They were able to pass those pricing changes onto their customers, and they survived this. What could have been a cataclysmic event for their business had they not had an integrated your pee? They not being able to have this visibility into the supply chain and the customer base. They may well have gone out of business just because of that one change >>to meet all day and all comes back to the data, putting their putting data at the core of their business. That integrated data pipeline is essentially what they get out of that last question. So thinking about the next 18 to 24 months, what are the milestones that observers should look for? One of the barometers that we should be watching. >>So look, in the next two years, it's it's really about us building incremental scale. We have, ah, four year plan, which I built when I came in. We're halfway through that plan. We've hit all of the metrics and exceeded most the metrics that we had on their plan. It's really continue to focus on the strategy. As I said, we focus on those five industries, continue to build market share, continue to focus on those three solution types and build market share and market dominance on those three solutions. Andi in that segment that I defined before, so no change from a strategy perspective. I think there's really value in the consistency that we bring on on their talk track and, you know, along the way we passed the $1,000,000,000 mark, which we will do, I think, in 2021 organically if we accelerate, some of the money will pass the 1,000,000,000 before, but you know business. The margins continue to expand. We focus on customer satisfaction and, you know, it's a It's a pretty straight, you know, traditional prey book that we have to execute on now. >>Well, congratulations. It's a great playbook, and you're growing very nicely. So love that. Look, we really an honor to the last couple of years. Learn a little bit about the company in your industry. So appreciate meeting you guys. Thank you. All right. And thank you for watching over right back with our next guest. Ready for this short break day Volonte with Paul Gill in. You're watching the Cube from I f s World Conference from Boston 2019 right back.