(upbeat music) >> Hey everyone, welcome to this event: Build Your Cloud Center of Excellence. I'm your host, Lisa Martin, and I have two guests here with me today to talk about the hybrid cloud, the multi-cloud trends, and specifically the complexity. While we know these trends provide agility and flexibility for customers, they also bring in complexity. And this session is going to focus on exploring that with RBI and HitachiVantara. Please welcome my guests, Adithya Sastry the SVP of Digital Solutions at HitachiVantara and Werner Mayer, head of group core IT and head of group data at RBI International. Guys, welcome to the program. >> Thank you Lisa. Werner, nice to see you again. >> Great to see you both. >> And Werner, we're going to start with you. Talk about RBI. Tell the audience a little bit about what the business is and then we're going to get into your cloud transformation journey over the last couple of years. >> Yes, thank you. So Raiffeisen Bank International is international working banking groups. So our core markets are Central Eastern European, Central Eastern Europe and Austria. And we are serving around 50 million clients in this market. So we active in 13 markets. >> Got it. Talk to me, Werner about the cloud transformation journey that RBI has been on over the last couple of years and some of the complexities that you've experienced as you've launched it. >> Sure. Thank you for the question. So in 2020, we decided that we have to renew our IT strategy. And the aim of the strategy was to change the organization in a way that it can react and adapt fast to the future challenges. So one of the important pillars for us was that we are adapting fast also for new technologies. And this was core pillar in our strategy. So we're searching for technologies which are fit in to our HR transformation. And we found that the cloud and the public cloud environment fits to this venture. So we tested that. We are building up also the competent centers for that and also established the group cloud platform for that. Because our invoice to onboard our international group with the 13 units to this group cloud platform. So that means we have a lot to do to hardening the platforms in terms of security to put in. We have standard for that. We have to introduce large scale programs to train hundreds of engineers. We tested the approach, We convinced the top management and we implemented this, this program. So one of the highlights was, of course, also the the safeguarding of the Ukraine, let's say, banking environment. So we had to lift and shift the complete bank in three months. And it shows that let's say our platforms works. And let's say the approach is proven that we can scale it over the group. >> That's a big challenge. A lot of complexity especially with some of the global things going on. Adithya, these challenges are, are not unique to RBI. A lot of your customers are facing challenges with complexity around cloud management, cloud ops. What can you unpack was the real issue is here? >> Yeah, Lisa, absolutely. And you know, before I answer your question, I do want to, you know, just say a couple of things about Raiffeisen Bank. And you know, we've had the pleasure of working with them for about a year, a little bit more than a year now. And, and, and the way they approach the cloud transformation journey is - should be a template for a lot of the organizations in terms of the preparation in terms of understanding, you know. How other companies have done it and what are the pitfalls. What's worked, and really what's the recipe for their, you know, journey, right? Which is very unique because, you know, you look at you know, being present across 30 different countries within central and eastern Europe as Werner said. And the complexities of dealing with local regulations, GDPR and all these other issues that come with it, right? And not to mention the language variation from country to country. So, you know, phenomenal story there. The journey and the journey still goes, right Werner? It's not complete yet. But Lisa, to your question, you know. When we look at, you know, the complexities of this transformation, that most modern enterprises are going through. It's not very unique, right? What is unique for a Raiffeisen Bank is - has been the preparation. As you get into this journey of moving workloads to cloud, be it refactoring, modernizing, migrating, etc. One of the things that really is often overlooked is: "Are my applications and data workloads resilient on the cloud?" Meaning  how is the performance? Are they just running or are they performing with high availability to meet your customers goals? Is it scalable? And are my cost in line with what I projected when I moved prep. >> Because that's one of the areas we are seeing where you know, what enterprises projected from a cost savings to what they're realizing a year and a half into the journey is a pretty big delta, right? And, and, and a lot of it is dependent on are the cloud - are the applications and the workloads cloud, designed for the cloud? Or are they designed for on-prem which you just move to the cloud. >> So Werner, it sounds like what Adithya said is a compliment to, to you guys and the team at RBI in terms of this being a template for managing complexity. Give us, Werner, your perspective in terms of modern cloud ops. What's in? What's out? What is it that customers really need to be focusing on to be successful? >> Thanks for the compliment, Lisa. And I think this is a great relationship also in the journey. Topic is, is, is a - is a complex program where a lot of things have to fit together. But it was mentioning the resilience. The course, we call it finops, security operations and so on have to come together and have to work on spot. At the end, it's also, let's say, how we are able enabling our teams and how we are ramping out the skills of our teams to deal with these multidimensional, let's say environments. And this is something what we spend a lot of time in order to prepare, but also to bring up the people on a certain level that they can operate at. Because card guard handling is, is different than before. Because beforehand you have central operations team. They do everything for you. But in this world let's say we are also putting the responsibility of the run component of the absent to the - in the tribes and the application teams. And they have to do much more than before. On the other hand, we have first central rules. We have monitoring functions. We have support functions on that in order to best support them in their journey. So this is a hybrid between, let's say, what the teams have to do with the responsibility in the teams, but also with the central functions which are supporting them. And everything have to work together and goes hand in - right, to go hand-in-hand. >> Yeah. Yeah. And if, if I could just add Lisa really quick and and Werner hit the nail on the head, right? Because you cannot look at cloud operation the way we have traditionally looked at managed services. That's the key thing, right? You cannot, you know, traditional managed services you had L1, L2, L3 and then it goes into some sort of a vacuum and then all of a sudden somebody calls you at some point, right? >> Werner: Exactly. >> And it really has flipped, right? To, to Werner's point. And Werner hit that name on the head because you really have to understand. Bring an engineering led approach to make sure that the problems, you know, when you see an issue that you have some level of automation in terms of problem isolation. And then the problem is routed the right individual ie the application engineering team or the data engineering team for resolution in a rapid manner. Right? I think that the key - >> Yes. A very important point with that is said, yeah. So you cannot traditional transport let's say, the operation model what you have now into the cloud because this will not work, yeah. And finally at the end you will not benefit on the technology possibilities there. So super important point. My vision in the cloud and this is also something what we are working on is a sort of zero-ops environment, yeah? Because we're ultimately dealing with the automatization technologies and so on, you can that much - to much more compared to the traditional environment and the benefit of the cloud is: You can test it. You can give it feedback when it is not working, yeah? So it's a completely different operating model. What we try to establish in the cloud environment. >> So really what this seems like guys is is quite a delicate balance that you're solving for. Not the only delicate balance but Werner sticking with you. Talk to us about some of the challenges that you've had around cloud cost management in particular. Help us understand that. >> Thanks for the question. So in principle, we are doing very well on the cost side, surprisingly. And we also started the cloud journey that is said this is not the cost case. Because as I said before, let's say one of the pillars in the strategy strategy was the enablement of technology to the benefit of customer solutions to be adaptive, to be faster. But at the end it turned out that let's say with giving the responsibility of the operation to the dedicated team, they found they - they were working much closer to the cost, and let's say monitoring the cost, then we headed into traditional environments, yeah? I also saw some examples in the group where sort of gamification of the cost were going on. To say who can save more To say who can save more and make more much more out of that what you have in the cloud. And at the end we see that in minimum the cost are balance to the traditional environments in the data centers. But we also saw that let's say, the cost were brought down much more than before. So at the beginning we were relative conservative with the assumptions, yeah? But it turns out that we are really getting the benefit. The things are getting faster and also the costs are going down. And we see this in real cases. >> Yeah. And, and, and Lisa, if I could add something really quick, right? Because - There's been a mad rush to the cloud, right? Everybody kind of, it was, you know, the buzz the buzz was let's get to the cloud. We'll start to realize all these savings. And all of a sudden, everything kind of magically gets better, right? And what we have seen is also, you know, companies or customers or enterprises that have started this journey about 5, 6 years ago and are about, you know, a few years into it. What we are realizing is the cloud costs have increased significantly to what their projections were early on. And the way they're trying to address the cloud cost is by creating a FinOps organization that's looking at, you know, the cost of cloud from a structure standpoint and support as a reactive measure. Saying, "Hey if we move from Azure or one provider to another is there any benefit? If we move certain applications from the cloud back to on-prem, is there any benefit?" When in fact, one of the things that we have noticed really is: The problem needs to shift left to the engineering teams. Because if you are designing the applications and the systems the right way to begin with, then you can manage the data cost issues or the cost overruns, right? So you design for the cloud as opposed to designing and then looking at how do we optimize cloud. >> So Adithya, you talked about the RBI use case as really kind of a template but also some of the challenges with respect to hybrid and multi-cloud are kind of like a chicken and egg scenario. Talk to us kind of like overall about how Hitachi is really helping customers address these challenges and maximize the benefits to get the flexibility to get the agility so that they can deliver what their end user customers are expecting. >> Yeah, yeah. So, so one of the things we are doing, Lisa, when we work with customers, is really trying to understand, you know, look at their entire portfolio of applications, right? And, and look at what the intent of the applications is between customer facing, external customer, internal customer, high availability, production, etc., right? And then we go through a methodology called E3 which is envision, enable and execute. Which is really envision what the end stage should be regardless of what the environment is, right? And then we enable, which is really kind of go through a proof of value to move a few workloads, to modernize, rearchitect, replatform, etc. And look at the benefit of that application on its destination. If it's a cloud - if it's a cloud service provider or if it's another data center, whatever it may be, right? And finally, you know, once we've proven the value and the benefit and and say and kind of monetize the, you know realize the value of it from an agility, from a cost, from security and resilience, etc. Then we go through the execution, which was look we look at the entire portfolio, the entire landscape. And we go through a very disciplined manner working with our customers to roadmap it. And then we execute in a very deliberate manner where you can see value every 2-3 months. Because gone the days when you can do things as a science project that took 2-3 years, right? We, we - Everyone wants to see value, want to see - wants to see progress, and most importantly we want to see cost benefit and agility sooner than later. >> Those are incredibly important outcomes. You guys have done a great job explaining what you're doing together. This sounds like a great relationship. All right, so my last question to both of you is: "If I'm a customer and I'm planning a cloud transformation for my company, what are the two things you want me to remember and consider as I plan this? Werner, we'll start with you. >> I would pick up two things, yeah? The first one is: When you are organizing your company in HR way, then cloud is the HR technology for the HR transformation. Because HR teams needs HR technology. And the second important thing is, what I would say is: Cloud is a large scale and fast moving technology enabler to the company. So if your company is going forward to say: Technology is their enabler tool from a future business then cloud can support this journey. >> Excellent. I'm going to walk away with those. And Adithya, same question to you. I'm a, I'm a customer. I'm at an organization. I'm planning a cloud transformation. Top two things you want me to walk away with. >> Yeah. And I think Werner kind of actually touched on that in the second one, which is: it's not a tech, just an IT or a technology initiative. It is a business initiative, right? Because ultimately what you do from this cloud journey should drive, you know, should lead into business transformation or help your business grow top line or drive margin expansion, etc. So couple of things I would say, right? One is, you know, get Being and prioritize. Work with your business owners, with, you know with the cross-functional team not just the technology team. That's one. The second thing is: as the technology team or the IT team shepherds this journey, you know, keep everyone informed and engaged as you go through this journey. Because as you go through moving workloads modernizing workload, there is an impact to, you know receivables through omnichannel experiences the way customers interact and transact with you, right? And that comes with making making sure your businesses are aware your business stakeholders are aware. So in turn the end customers are aware. So you know, it's not a one and done from an engagement, it's a journey. And bring in the right experts. Talk to people who've done it, done this before, who have kind of stepped in all the pitfalls so you don't have to, right? That's the key. >> That's great advice. That's great advice for anything in life, I think. You talk about the collaboration, the importance of the business and the technology folks coming together. It really has to be - It's a delicate balance as we said before but it really has to be a holistic collaborative approach. Guys, thank you so much for joining me talking through what HitachiVantara and RBI are doing together. It sounds like you're well into this journey and it sounds like it's going quite well. We thank you so much for your insights and your perspectives. >> Thank you, Lisa. Werner, thank you again. >> Good stuff guys. For my guests, I'm Lisa Martin. Thank you so much for watching our event: Build Your Cloud Center of Excellence. (upbeat music)

(soothing music) >> Hey everyone, welcome to this event, "Build Your Cloud Center of Excellence." I'm your host, Lisa Martin. In the next 15 minutes or so my guest and I are going to be talking about redefining cloud operations, an application modernization for customers, and specifically how partners are helping to speed up that process. As you saw on our first two segments, we talked about problems enterprises are facing with cloud operations. We talked about redefining cloud operations as well to solve these problems. This segment is going to be focusing on how Hitachi Vantara's partners are really helping to speed up that process. We've got Johnson Controls here to talk about their partnership with Hitachi Vantara. Please welcome both of my guests, Prem Balasubramanian is with us, SVP and CTO Digital Solutions at Hitachi Vantara. And Suresh Mothikuru, SVP Customer Success Platform Engineering and Reliability Engineering from Johnson Controls. Gentlemen, welcome to the program, great to have you. >> Thank. >> Thank you, Lisa. >> First question is to both of you and Suresh, we'll start with you. We want to understand, you know, the cloud operations landscape is increasingly complex. We've talked a lot about that in this program. Talk to us, Suresh, about some of the biggest challenges and pin points that you faced with respect to that. >> Thank you. I think it's a great question. I mean, cloud has evolved a lot in the last 10 years. You know, when we were talking about a single cloud whether it's Azure or AWS and GCP, and that was complex enough. Now we are talking about multi-cloud and hybrid and you look at Johnson Controls, we have Azure we have AWS, we have GCP, we have Alibaba and we also support on-prem. So the architecture has become very, very complex and the complexity has grown so much that we are now thinking about whether we should be cloud native or cloud agnostic. So I think, I mean, sometimes it's hard to even explain the complexity because people think, oh, "When you go to cloud, everything is simplified." Cloud does give you a lot of simplicity, but it also really brings a lot more complexity along with it. So, and then next one is pretty important is, you know, generally when you look at cloud services, you have plenty of services that are offered within a cloud, 100, 150 services, 200 services. Even within those companies, you take AWS they might not know, an individual resource might not know about all the services we see. That's a big challenge for us as a customer to really understand each of the service that is provided in these, you know, clouds, well, doesn't matter which one that is. And the third one is pretty big, at least at the CTO the CIO, and the senior leadership level, is cost. Cost is a major factor because cloud, you know, will eat you up if you cannot manage it. If you don't have a good cloud governance process it because every minute you are in it, it's burning cash. So I think if you ask me, these are the three major things that I am facing day to day and that's where I use my partners, which I'll touch base down the line. >> Perfect, we'll talk about that. So Prem, I imagine that these problems are not unique to Johnson Controls or JCI, as you may hear us refer to it. Talk to me Prem about some of the other challenges that you're seeing within the customer landscape. >> So, yeah, I agree, Lisa, these are not very specific to JCI, but there are specific issues in JCI, right? So the way we think about these are, there is a common issue when people go to the cloud and there are very specific and unique issues for businesses, right? So JCI, and we will talk about this in the episode as we move forward. I think Suresh and his team have done some phenomenal step around how to manage this complexity. But there are customers who have a lesser complex cloud which is, they don't go to Alibaba, they don't have footprint in all three clouds. So their multi-cloud footprint could be a bit more manageable, but still struggle with a lot of the same problems around cost, around security, around talent. Talent is a big thing, right? And in Suresh's case I think it's slightly more exasperated because every cloud provider Be it AWS, JCP, or Azure brings in hundreds of services and there is nobody, including many of us, right? We learn every day, nowadays, right? It's not that there is one service integrator who knows all, while technically people can claim as a part of sales. But in reality all of us are continuing to learn in this landscape. And if you put all of this equation together with multiple clouds the complexity just starts to exponentially grow. And that's exactly what I think JCI is experiencing and Suresh's team has been experiencing, and we've been working together. But the common problems are around security talent and cost management of this, right? Those are my three things. And one last thing that I would love to say before we move away from this question is, if you think about cloud operations as a concept that's evolving over the last few years, and I have touched upon this in the previous episode as well, Lisa, right? If you take architectures, we've gone into microservices, we've gone into all these server-less architectures all the fancy things that we want. That helps us go to market faster, be more competent to as a business. But that's not simplified stuff, right? That's complicated stuff. It's a lot more distributed. Second, again, we've advanced and created more modern infrastructure because all of what we are talking is platform as a service, services on the cloud that we are consuming, right? In the same case with development we've moved into a DevOps model. We kind of click a button put some code in a repository, the code starts to run in production within a minute, everything else is automated. But then when we get to operations we are still stuck in a very old way of looking at cloud as an infrastructure, right? So you've got an infra team, you've got an app team, you've got an incident management team, you've got a soft knock, everything. But again, so Suresh can talk about this more because they are making significant strides in thinking about this as a single workload, and how do I apply engineering to go manage this? Because a lot of it is codified, right? So automation. Anyway, so that's kind of where the complexity is and how we are thinking, including JCI as a partner thinking about taming that complexity as we move forward. >> Suresh, let's talk about that taming the complexity. You guys have both done a great job of articulating the ostensible challenges that are there with cloud, especially multi-cloud environments that you're living in. But Suresh, talk about the partnership with Hitachi Vantara. How is it helping to dial down some of those inherent complexities? >> I mean, I always, you know, I think I've said this to Prem multiple times. I treat my partners as my internal, you know, employees. I look at Prem as my coworker or my peers. So the reason for that is I want Prem to have the same vested interest as a partner in my success or JCI success and vice versa, isn't it? I think that's how we operate and that's how we have been operating. And I think I would like to thank Prem and Hitachi Vantara for that really been an amazing partnership. And as he was saying, we have taken a completely holistic approach to how we want to really be in the market and play in the market to our customers. So if you look at my jacket it talks about OpenBlue platform. This is what JCI is building, that we are building this OpenBlue digital platform. And within that, my team, along with Prem's or Hitachi's, we have built what we call as Polaris. It's a technical platform where our apps can run. And this platform is automated end-to-end from a platform engineering standpoint. We stood up a platform engineering organization, a reliability engineering organization, as well as a support organization where Hitachi played a role. As I said previously, you know, for me to scale I'm not going to really have the talent and the knowledge of every function that I'm looking at. And Hitachi, not only they brought the talent but they also brought what he was talking about, Harc. You know, they have set up a lot and now we can leverage it. And they also came up with some really interesting concepts. I went and met them in India. They came up with this concept called IPL. Okay, what is that? They really challenged all their employees that's working for GCI to come up with innovative ideas to solve problems proactively, which is self-healing. You know, how you do that? So I think partners, you know, if they become really vested in your interests, they can do wonders for you. And I think in this case Hitachi is really working very well for us and in many aspects. And I'm leveraging them... You started with support, now I'm leveraging them in the automation, the platform engineering, as well as in the reliability engineering and then in even in the engineering spaces. And that like, they are my end-to-end partner right now? >> So you're really taking that holistic approach that you talked about and it sounds like it's a very collaborative two-way street partnership. Prem, I want to go back to, Suresh mentioned Harc. Talk a little bit about what Harc is and then how partners fit into Hitachi's Harc strategy. >> Great, so let me spend like a few seconds on what Harc is. Lisa, again, I know we've been using the term. Harc stands for Hitachi application reliability sectors. Now the reason we thought about Harc was, like I said in the beginning of this segment, there is an illusion from an architecture standpoint to be more modern, microservices, server-less, reactive architecture, so on and so forth. There is an illusion in your development methodology from Waterfall to agile, to DevOps to lean, agile to path program, whatever, right? Extreme program, so on and so forth. There is an evolution in the space of infrastructure from a point where you were buying these huge humongous servers and putting it in your data center to a point where people don't even see servers anymore, right? You buy it, by a click of a button you don't know the size of it. All you know is a, it's (indistinct) whatever that name means. Let's go provision it on the fly, get go, get your work done, right? When all of this is advanced when you think about operations people have been solving the problem the way they've been solving it 20 years back, right? That's the issue. And Harc was conceived exactly to fix that particular problem, to think about a modern way of operating a modern workload, right? That's exactly what Harc. So it brings together finest engineering talent. So the teams are trained in specific ways of working. We've invested and implemented some of the IP, we work with the best of the breed partner ecosystem, and I'll talk about that in a minute. And we've got these facilities in Dallas and I am talking from my office in Dallas, which is a Harc facility in the US from where we deliver for our customers. And then back in Hyderabad, we've got one more that we opened and these are facilities from where we deliver Harc services for our customers as well, right? And then we are expanding it in Japan and Portugal as we move into 23. That's kind of the plan that we are thinking through. However, that's what Harc is, Lisa, right? That's our solution to this cloud complexity problem. Right? >> Got it, and it sounds like it's going quite global, which is fantastic. So Suresh, I want to have you expand a bit on the partnership, the partner ecosystem and the role that it plays. You talked about it a little bit but what role does the partner ecosystem play in really helping JCI to dial down some of those challenges and the inherent complexities that we talked about? >> Yeah, sure. I think partners play a major role and JCI is very, very good at it. I mean, I've joined JCI 18 months ago, JCI leverages partners pretty extensively. As I said, I leverage Hitachi for my, you know, A group and the (indistinct) space and the cloud operations space, and they're my primary partner. But at the same time, we leverage many other partners. Well, you know, Accenture, SCL, and even on the tooling side we use Datadog and (indistinct). All these guys are major partners of our because the way we like to pick partners is based on our vision and where we want to go. And pick the right partner who's going to really, you know make you successful by investing their resources in you. And what I mean by that is when you have a partner, partner knows exactly what kind of skillset is needed for this customer, for them to really be successful. As I said earlier, we cannot really get all the skillset that we need, we rely on the partners and partners bring the the right skillset, they can scale. I can tell Prem tomorrow, "Hey, I need two parts by next week", and I guarantee it he's going to bring two parts to me. So they let you scale, they let you move fast. And I'm a big believer, in today's day and age, to get things done fast and be more agile. I'm not worried about failure, but for me moving fast is very, very important. And partners really do a very good job bringing that. But I think then they also really make you think, isn't it? Because one thing I like about partners they make you innovate whether they know it or not but they do because, you know, they will come and ask you questions about, "Hey, tell me why you are doing this. Can I review your architecture?" You know, and then they will try to really say I don't think this is going to work. Because they work with so many different clients, not JCI, they bring all that expertise and that's what I look from them, you know, just not, you know, do a T&M job for me. I ask you to do this go... They just bring more than that. That's how I pick my partners. And that's how, you know, Hitachi's Vantara is definitely one of a good partner from that sense because they bring a lot more innovation to the table and I appreciate about that. >> It sounds like, it sounds like a flywheel of innovation. >> Yeah. >> I love that. Last question for both of you, which we're almost out of time here, Prem, I want to go back to you. So I'm a partner, I'm planning on redefining CloudOps at my company. What are the two things you want me to remember from Hitachi Vantara's perspective? >> So before I get to that question, Lisa, the partners that we work with are slightly different from from the partners that, again, there are some similar partners. There are some different partners, right? For example, we pick and choose especially in the Harc space, we pick and choose partners that are more future focused, right? We don't care if they are huge companies or small companies. We go after companies that are future focused that are really, really nimble and can change for our customers need because it's not our need, right? When I pick partners for Harc my ultimate endeavor is to ensure, in this case because we've got (indistinct) GCI on, we are able to operate (indistinct) with the level of satisfaction above and beyond that they're expecting from us. And whatever I don't have I need to get from my partners so that I bring this solution to Suresh. As opposed to bringing a whole lot of people and making them stand in front of Suresh. So that's how I think about partners. What do I want them to do from, and we've always done this so we do workshops with our partners. We just don't go by tools. When we say we are partnering with X, Y, Z, we do workshops with them and we say, this is how we are thinking. Either you build it in your roadmap that helps us leverage you, continue to leverage you. And we do have minimal investments where we fix gaps. We're building some utilities for us to deliver the best service to our customers. And our intention is not to build a product to compete with our partner. Our intention is to just fill the wide space until they go build it into their product suite that we can then leverage it for our customers. So always think about end customers and how can we make it easy for them? Because for all the tool vendors out there seeing this and wanting to partner with Hitachi the biggest thing is tools sprawl, especially on the cloud is very real. For every problem on the cloud. I have a billion tools that are being thrown at me as Suresh if I'm putting my installation and it's not easy at all. It's so confusing. >> Yeah. >> So that's what we want. We want people to simplify that landscape for our end customers, and we are looking at partners that are thinking through the simplification not just making money. >> That makes perfect sense. There really is a very strong symbiosis it sounds like, in the partner ecosystem. And there's a lot of enablement that goes on back and forth it sounds like as well, which is really, to your point it's all about the end customers and what they're expecting. Suresh, last question for you is which is the same one, if I'm a partner what are the things that you want me to consider as I'm planning to redefine CloudOps at my company? >> I'll keep it simple. In my view, I mean, we've touched upon it in multiple facets in this interview about that, the three things. First and foremost, reliability. You know, in today's day and age my products has to be reliable, available and, you know, make sure that the customer's happy with what they're really dealing with, number one. Number two, my product has to be secure. Security is super, super important, okay? And number three, I need to really make sure my customers are getting the value so I keep my cost low. So these three is what I would focus and what I expect from my partners. >> Great advice, guys. Thank you so much for talking through this with me and really showing the audience how strong the partnership is between Hitachi Vantara and JCI. What you're doing together, we'll have to talk to you again to see where things go but we really appreciate your insights and your perspectives. Thank you. >> Thank you, Lisa. >> Thanks Lisa, thanks for having us. >> My pleasure. For my guests, I'm Lisa Martin. Thank you so much for watching. (soothing music)

(soothing music) >> Hey everyone, welcome to this event, "Build Your Cloud Center of Excellence." I'm your host, Lisa Martin. In the next 15 minutes or so my guest and I are going to be talking about redefining cloud operations, an application modernization for customers, and specifically how partners are helping to speed up that process. As you saw on our first two segments, we talked about problems enterprises are facing with cloud operations. We talked about redefining cloud operations as well to solve these problems. This segment is going to be focusing on how Hitachi Vantara's partners are really helping to speed up that process. We've got Johnson Controls here to talk about their partnership with Hitachi Vantara. Please welcome both of my guests, Prem Balasubramanian is with us, SVP and CTO Digital Solutions at Hitachi Vantara. And Suresh Mothikuru, SVP Customer Success Platform Engineering and Reliability Engineering from Johnson Controls. Gentlemen, welcome to the program, great to have you. >> Thank. >> Thank you, Lisa. >> First question is to both of you and Suresh, we'll start with you. We want to understand, you know, the cloud operations landscape is increasingly complex. We've talked a lot about that in this program. Talk to us, Suresh, about some of the biggest challenges and pin points that you faced with respect to that. >> Thank you. I think it's a great question. I mean, cloud has evolved a lot in the last 10 years. You know, when we were talking about a single cloud whether it's Azure or AWS and GCP, and that was complex enough. Now we are talking about multi-cloud and hybrid and you look at Johnson Controls, we have Azure we have AWS, we have GCP, we have Alibaba and we also support on-prem. So the architecture has become very, very complex and the complexity has grown so much that we are now thinking about whether we should be cloud native or cloud agnostic. So I think, I mean, sometimes it's hard to even explain the complexity because people think, oh, "When you go to cloud, everything is simplified." Cloud does give you a lot of simplicity, but it also really brings a lot more complexity along with it. So, and then next one is pretty important is, you know, generally when you look at cloud services, you have plenty of services that are offered within a cloud, 100, 150 services, 200 services. Even within those companies, you take AWS they might not know, an individual resource might not know about all the services we see. That's a big challenge for us as a customer to really understand each of the service that is provided in these, you know, clouds, well, doesn't matter which one that is. And the third one is pretty big, at least at the CTO the CIO, and the senior leadership level, is cost. Cost is a major factor because cloud, you know, will eat you up if you cannot manage it. If you don't have a good cloud governance process it because every minute you are in it, it's burning cash. So I think if you ask me, these are the three major things that I am facing day to day and that's where I use my partners, which I'll touch base down the line. >> Perfect, we'll talk about that. So Prem, I imagine that these problems are not unique to Johnson Controls or JCI, as you may hear us refer to it. Talk to me Prem about some of the other challenges that you're seeing within the customer landscape. >> So, yeah, I agree, Lisa, these are not very specific to JCI, but there are specific issues in JCI, right? So the way we think about these are, there is a common issue when people go to the cloud and there are very specific and unique issues for businesses, right? So JCI, and we will talk about this in the episode as we move forward. I think Suresh and his team have done some phenomenal step around how to manage this complexity. But there are customers who have a lesser complex cloud which is, they don't go to Alibaba, they don't have footprint in all three clouds. So their multi-cloud footprint could be a bit more manageable, but still struggle with a lot of the same problems around cost, around security, around talent. Talent is a big thing, right? And in Suresh's case I think it's slightly more exasperated because every cloud provider Be it AWS, JCP, or Azure brings in hundreds of services and there is nobody, including many of us, right? We learn every day, nowadays, right? It's not that there is one service integrator who knows all, while technically people can claim as a part of sales. But in reality all of us are continuing to learn in this landscape. And if you put all of this equation together with multiple clouds the complexity just starts to exponentially grow. And that's exactly what I think JCI is experiencing and Suresh's team has been experiencing, and we've been working together. But the common problems are around security talent and cost management of this, right? Those are my three things. And one last thing that I would love to say before we move away from this question is, if you think about cloud operations as a concept that's evolving over the last few years, and I have touched upon this in the previous episode as well, Lisa, right? If you take architectures, we've gone into microservices, we've gone into all these server-less architectures all the fancy things that we want. That helps us go to market faster, be more competent to as a business. But that's not simplified stuff, right? That's complicated stuff. It's a lot more distributed. Second, again, we've advanced and created more modern infrastructure because all of what we are talking is platform as a service, services on the cloud that we are consuming, right? In the same case with development we've moved into a DevOps model. We kind of click a button put some code in a repository, the code starts to run in production within a minute, everything else is automated. But then when we get to operations we are still stuck in a very old way of looking at cloud as an infrastructure, right? So you've got an infra team, you've got an app team, you've got an incident management team, you've got a soft knock, everything. But again, so Suresh can talk about this more because they are making significant strides in thinking about this as a single workload, and how do I apply engineering to go manage this? Because a lot of it is codified, right? So automation. Anyway, so that's kind of where the complexity is and how we are thinking, including JCI as a partner thinking about taming that complexity as we move forward. >> Suresh, let's talk about that taming the complexity. You guys have both done a great job of articulating the ostensible challenges that are there with cloud, especially multi-cloud environments that you're living in. But Suresh, talk about the partnership with Hitachi Vantara. How is it helping to dial down some of those inherent complexities? >> I mean, I always, you know, I think I've said this to Prem multiple times. I treat my partners as my internal, you know, employees. I look at Prem as my coworker or my peers. So the reason for that is I want Prem to have the same vested interest as a partner in my success or JCI success and vice versa, isn't it? I think that's how we operate and that's how we have been operating. And I think I would like to thank Prem and Hitachi Vantara for that really been an amazing partnership. And as he was saying, we have taken a completely holistic approach to how we want to really be in the market and play in the market to our customers. So if you look at my jacket it talks about OpenBlue platform. This is what JCI is building, that we are building this OpenBlue digital platform. And within that, my team, along with Prem's or Hitachi's, we have built what we call as Polaris. It's a technical platform where our apps can run. And this platform is automated end-to-end from a platform engineering standpoint. We stood up a platform engineering organization, a reliability engineering organization, as well as a support organization where Hitachi played a role. As I said previously, you know, for me to scale I'm not going to really have the talent and the knowledge of every function that I'm looking at. And Hitachi, not only they brought the talent but they also brought what he was talking about, Harc. You know, they have set up a lot and now we can leverage it. And they also came up with some really interesting concepts. I went and met them in India. They came up with this concept called IPL. Okay, what is that? They really challenged all their employees that's working for GCI to come up with innovative ideas to solve problems proactively, which is self-healing. You know, how you do that? So I think partners, you know, if they become really vested in your interests, they can do wonders for you. And I think in this case Hitachi is really working very well for us and in many aspects. And I'm leveraging them... You started with support, now I'm leveraging them in the automation, the platform engineering, as well as in the reliability engineering and then in even in the engineering spaces. And that like, they are my end-to-end partner right now? >> So you're really taking that holistic approach that you talked about and it sounds like it's a very collaborative two-way street partnership. Prem, I want to go back to, Suresh mentioned Harc. Talk a little bit about what Harc is and then how partners fit into Hitachi's Harc strategy. >> Great, so let me spend like a few seconds on what Harc is. Lisa, again, I know we've been using the term. Harc stands for Hitachi application reliability sectors. Now the reason we thought about Harc was, like I said in the beginning of this segment, there is an illusion from an architecture standpoint to be more modern, microservices, server-less, reactive architecture, so on and so forth. There is an illusion in your development methodology from Waterfall to agile, to DevOps to lean, agile to path program, whatever, right? Extreme program, so on and so forth. There is an evolution in the space of infrastructure from a point where you were buying these huge humongous servers and putting it in your data center to a point where people don't even see servers anymore, right? You buy it, by a click of a button you don't know the size of it. All you know is a, it's (indistinct) whatever that name means. Let's go provision it on the fly, get go, get your work done, right? When all of this is advanced when you think about operations people have been solving the problem the way they've been solving it 20 years back, right? That's the issue. And Harc was conceived exactly to fix that particular problem, to think about a modern way of operating a modern workload, right? That's exactly what Harc. So it brings together finest engineering talent. So the teams are trained in specific ways of working. We've invested and implemented some of the IP, we work with the best of the breed partner ecosystem, and I'll talk about that in a minute. And we've got these facilities in Dallas and I am talking from my office in Dallas, which is a Harc facility in the US from where we deliver for our customers. And then back in Hyderabad, we've got one more that we opened and these are facilities from where we deliver Harc services for our customers as well, right? And then we are expanding it in Japan and Portugal as we move into 23. That's kind of the plan that we are thinking through. However, that's what Harc is, Lisa, right? That's our solution to this cloud complexity problem. Right? >> Got it, and it sounds like it's going quite global, which is fantastic. So Suresh, I want to have you expand a bit on the partnership, the partner ecosystem and the role that it plays. You talked about it a little bit but what role does the partner ecosystem play in really helping JCI to dial down some of those challenges and the inherent complexities that we talked about? >> Yeah, sure. I think partners play a major role and JCI is very, very good at it. I mean, I've joined JCI 18 months ago, JCI leverages partners pretty extensively. As I said, I leverage Hitachi for my, you know, A group and the (indistinct) space and the cloud operations space, and they're my primary partner. But at the same time, we leverage many other partners. Well, you know, Accenture, SCL, and even on the tooling side we use Datadog and (indistinct). All these guys are major partners of our because the way we like to pick partners is based on our vision and where we want to go. And pick the right partner who's going to really, you know make you successful by investing their resources in you. And what I mean by that is when you have a partner, partner knows exactly what kind of skillset is needed for this customer, for them to really be successful. As I said earlier, we cannot really get all the skillset that we need, we rely on the partners and partners bring the the right skillset, they can scale. I can tell Prem tomorrow, "Hey, I need two parts by next week", and I guarantee it he's going to bring two parts to me. So they let you scale, they let you move fast. And I'm a big believer, in today's day and age, to get things done fast and be more agile. I'm not worried about failure, but for me moving fast is very, very important. And partners really do a very good job bringing that. But I think then they also really make you think, isn't it? Because one thing I like about partners they make you innovate whether they know it or not but they do because, you know, they will come and ask you questions about, "Hey, tell me why you are doing this. Can I review your architecture?" You know, and then they will try to really say I don't think this is going to work. Because they work with so many different clients, not JCI, they bring all that expertise and that's what I look from them, you know, just not, you know, do a T&M job for me. I ask you to do this go... They just bring more than that. That's how I pick my partners. And that's how, you know, Hitachi's Vantara is definitely one of a good partner from that sense because they bring a lot more innovation to the table and I appreciate about that. >> It sounds like, it sounds like a flywheel of innovation. >> Yeah. >> I love that. Last question for both of you, which we're almost out of time here, Prem, I want to go back to you. So I'm a partner, I'm planning on redefining CloudOps at my company. What are the two things you want me to remember from Hitachi Vantara's perspective? >> So before I get to that question, Lisa, the partners that we work with are slightly different from from the partners that, again, there are some similar partners. There are some different partners, right? For example, we pick and choose especially in the Harc space, we pick and choose partners that are more future focused, right? We don't care if they are huge companies or small companies. We go after companies that are future focused that are really, really nimble and can change for our customers need because it's not our need, right? When I pick partners for Harc my ultimate endeavor is to ensure, in this case because we've got (indistinct) GCI on, we are able to operate (indistinct) with the level of satisfaction above and beyond that they're expecting from us. And whatever I don't have I need to get from my partners so that I bring this solution to Suresh. As opposed to bringing a whole lot of people and making them stand in front of Suresh. So that's how I think about partners. What do I want them to do from, and we've always done this so we do workshops with our partners. We just don't go by tools. When we say we are partnering with X, Y, Z, we do workshops with them and we say, this is how we are thinking. Either you build it in your roadmap that helps us leverage you, continue to leverage you. And we do have minimal investments where we fix gaps. We're building some utilities for us to deliver the best service to our customers. And our intention is not to build a product to compete with our partner. Our intention is to just fill the wide space until they go build it into their product suite that we can then leverage it for our customers. So always think about end customers and how can we make it easy for them? Because for all the tool vendors out there seeing this and wanting to partner with Hitachi the biggest thing is tools sprawl, especially on the cloud is very real. For every problem on the cloud. I have a billion tools that are being thrown at me as Suresh if I'm putting my installation and it's not easy at all. It's so confusing. >> Yeah. >> So that's what we want. We want people to simplify that landscape for our end customers, and we are looking at partners that are thinking through the simplification not just making money. >> That makes perfect sense. There really is a very strong symbiosis it sounds like, in the partner ecosystem. And there's a lot of enablement that goes on back and forth it sounds like as well, which is really, to your point it's all about the end customers and what they're expecting. Suresh, last question for you is which is the same one, if I'm a partner what are the things that you want me to consider as I'm planning to redefine CloudOps at my company? >> I'll keep it simple. In my view, I mean, we've touched upon it in multiple facets in this interview about that, the three things. First and foremost, reliability. You know, in today's day and age my products has to be reliable, available and, you know, make sure that the customer's happy with what they're really dealing with, number one. Number two, my product has to be secure. Security is super, super important, okay? And number three, I need to really make sure my customers are getting the value so I keep my cost low. So these three is what I would focus and what I expect from my partners. >> Great advice, guys. Thank you so much for talking through this with me and really showing the audience how strong the partnership is between Hitachi Vantara and JCI. What you're doing together, we'll have to talk to you again to see where things go but we really appreciate your insights and your perspectives. Thank you. >> Thank you, Lisa. >> Thanks Lisa, thanks for having us. >> My pleasure. For my guests, I'm Lisa Martin. Thank you so much for watching. (soothing music)

(upbeat music) >> Hey everyone, welcome to this event: Build Your Cloud Center of Excellence. I'm your host, Lisa Martin, and I have two guests here with me today to talk about the hybrid cloud, the multi-cloud trends, and specifically the complexity. While we know these trends provide agility and flexibility for customers, they also bring in complexity. And this session is going to focus on exploring that with RBI and HitachiVantara. Please welcome my guests, Adithya Sastry the SVP of Digital Solutions at HitachiVantara and Werner Mayer, head of group core IT and head of group data at RBI International. Guys, welcome to the program. >> Thank you Lisa. Werner, nice to see you again. >> Great to see you both. >> And Werner, we're going to start with you. Talk about RBI. Tell the audience a little bit about what the business is and then we're going to get into your cloud transformation journey over the last couple of years. >> Yes, thank you. So Raiffeisen Bank International is international working banking groups. So our core markets are Central Eastern European, Central Eastern Europe and Austria. And we are serving around 50 million clients in this market. So we active in 13 markets. >> Got it. Talk to me, Werner about the cloud transformation journey that RBI has been on over the last couple of years and some of the complexities that you've experienced as you've launched it. >> Sure. Thank you for the question. So in 2020, we decided that we have to renew our IT strategy. And the aim of the strategy was to change the organization in a way that it can react and adapt fast to the future challenges. So one of the important pillars for us was that we are adapting fast also for new technologies. And this was core pillar in our strategy. So we're searching for technologies which are fit in to our HR transformation. And we found that the cloud and the public cloud environment fits to this venture. So we tested that. We are building up also the competent centers for that and also established the group cloud platform for that. Because our invoice to onboard our international group with the 13 units to this group cloud platform. So that means we have a lot to do to hardening the platforms in terms of security to put in. We have standard for that. We have to introduce large scale programs to train hundreds of engineers. We tested the approach, We convinced the top management and we implemented this, this program. So one of the highlights was, of course, also the the safeguarding of the Ukraine, let's say, banking environment. So we had to lift and shift the complete bank in three months. And it shows that let's say our platforms works. And let's say the approach is proven that we can scale it over the group. >> That's a big challenge. A lot of complexity especially with some of the global things going on. Adithya, these challenges are, are not unique to RBI. A lot of your customers are facing challenges with complexity around cloud management, cloud ops. What can you unpack was the real issue is here? >> Yeah, Lisa, absolutely. And you know, before I answer your question, I do want to, you know, just say a couple of things about Raiffeisen Bank. And you know, we've had the pleasure of working with them for about a year, a little bit more than a year now. And, and, and the way they approach the cloud transformation journey is - should be a template for a lot of the organizations in terms of the preparation in terms of understanding, you know. How other companies have done it and what are the pitfalls. What's worked, and really what's the recipe for their, you know, journey, right? Which is very unique because, you know, you look at you know, being present across 30 different countries within central and eastern Europe as Werner said. And the complexities of dealing with local regulations, GDPR and all these other issues that come with it, right? And not to mention the language variation from country to country. So, you know, phenomenal story there. The journey and the journey still goes, right Werner? It's not complete yet. But Lisa, to your question, you know. When we look at, you know, the complexities of this transformation, that most modern enterprises are going through. It's not very unique, right? What is unique for a Raiffeisen Bank is - has been the preparation. But as you get into this journey of moving workloads to cloud, be it refactoring, modernizing, migrating, etc. One of the things that really is often overlooked is: "Are my applications applications and data workloads resilient on, on the, on the cloud?" Meaning are they - How is the performance? Are they just running or are they performing with high availability to meet your customers goals? Is it scalable? And are my cost in line with what I projected when I moved prep, right? Because that's one of the areas we are seeing where you know, what enterprises projected from a cost savings to what they're realizing a year and a half into the journey is a pretty big delta, right? And, and, and a lot of it is dependent on are the cloud - are the applications and the workloads cloud, designed for the cloud? Or are they designed for on-prem which you just move to the cloud. >> So Werner, it sounds like what Adithya said is a compliment to, to you guys and the team at RBI in terms of this being a template for managing complexity. Give us, Werner, your perspective in terms of modern cloud ops. What's in? What's out? What is it that customers really need to be focusing on to be successful? >> Thanks for the compliment, Lisa. And I think this is a great relationship also in the journey. Topic is, is, is a - is a complex program where a lot of things have to fit together. But it was mentioning the resilience. The course, we call it finops, security operations and so on have to come together and have to work on spot. At the end, it's also, let's say, how we are able enabling our teams and how we are ramping out the skills of our teams to deal with these multidimensional, let's say environments. And this is something what we spend a lot of time in order to prepare, but also to bring up the people on a certain level that they can operate at. Because card guard handling is, is different than before. Because beforehand you have central operations team. They do everything for you. But in this world let's say we are also putting the responsibility of the run component of the absent to the - in the tribes and the application teams. And they have to do much more than before. On the other hand, we have first central rules. We have monitoring functions. We have support functions on that in order to best support them in their journey. So this is a hybrid between, let's say, what the teams have to do with the responsibility in the teams, but also with the central functions which are supporting them. And everything have to work together and goes hand in - right, to go hand-in-hand. >> Yeah. Yeah. And if, if I could just add Lisa really quick and and Werner hit the nail on the head, right? Because you cannot look at cloud operation the way we have traditionally looked at managed services. That's the key thing, right? You cannot, you know, traditional managed services you had L1, L2, L3 and then it goes into some sort of a vacuum and then all of a sudden somebody calls you at some point, right? >> Werner: Exactly. >> And it really has flipped, right? To, to Werner's point. And Werner hit that name on the head because you really have to understand. Bring an engineering led approach to make sure that the problems, you know, when you see an issue that you have some level of automation in terms of problem isolation. And then the problem is routed the right individual ie the application engineering team or the data engineering team for resolution in a rapid manner. Right? I think that the key - >> Yes. A very important point with that is said, yeah. So you cannot traditional transport let's say, the operation model what you have now into the cloud because this will not work, yeah. And finally at the end you will not benefit on the technology possibilities there. So super important point. My vision in the cloud and this is also something what we are working on is a sort of zero-ops environment, yeah? Because we're ultimately dealing with the automatization technologies and so on, you can that much - to much more compared to the traditional environment and the benefit of the cloud is: You can test it. You can give it feedback when it is not working, yeah? So it's a completely different operating model. What we try to establish in the cloud environment. >> So really what this seems like guys is is quite a delicate balance that you're solving for. Not the only delicate balance but Werner sticking with you. Talk to us about some of the challenges that you've had around cloud cost management in particular. Help us understand that. >> Thanks for the question. So in principle, we are doing very well on the cost side, surprisingly. And we also started the cloud journey that is said this is not the cost case. Because as I said before, let's say one of the pillars in the strategy strategy was the enablement of technology to the benefit of customer solutions to be adaptive, to be faster. But at the end it turned out that let's say with giving the responsibility of the operation to the dedicated team, they found they - they were working much closer to the cost, and let's say monitoring the cost, then we headed into traditional environments, yeah? I also saw some examples in the group where sort of gamification of the cost were going on. To say who can save more To say who can save more and make more much more out of that what you have in the cloud. And at the end we see that in minimum the cost are balance to the traditional environments in the data centers. But we also saw that let's say, the cost were brought down much more than before. So at the beginning we were relative conservative with the assumptions, yeah? But it turns out that we are really getting the benefit. The things are getting faster and also the costs are going down. And we see this in real cases. >> Yeah. And, and, and Lisa, if I could add something really quick, right? Because - You know, there's been a mad rush to the cloud, right? Everybody kind of, it was, you know, the buzz the buzz was let's get to the cloud. We'll start to realize all these savings. And all of a sudden, everything kind of magically gets better, right? And what we have seen is also, you know, companies or customers or enterprises that have started this journey about 5, 6 years ago and are about, you know, a few years into it. What we are realizing is the cloud costs have increased significantly to what their projections were early on. And the way they're trying to address the cloud cost is by creating a FinOps organization that's looking at, you know, the cost of cloud from a structure standpoint and support as a reactive measure. Saying, "Hey if we move from Azure or one provider to another is there any benefit? If we move certain applications from the cloud back to on-prem, is there any benefit?" When in fact, one of the things that we have noticed really is: The problem needs to shift left to the engineering teams. Because if you are designing the applications and the systems the right way to begin with, then you can manage the data cost issues or the cost overruns, right? So you design for the cloud as opposed to designing and then looking at how do we optimize cloud. >> So Adithya, you talked about the RBI use case as really kind of a template but also some of the challenges with respect to hybrid and multi-cloud are kind of like a chicken and egg scenario. Talk to us kind of like overall about how Hitachi is really helping customers address these challenges and maximize the benefits to get the flexibility to get the agility so that they can deliver what their end user customers are expecting. >> Yeah, yeah. So, so one of the things we are doing, Lisa, when we work with customers, is really trying to understand, you know, look at their entire portfolio of applications, right? And, and look at what the intent of the applications is between customer facing, external customer, internal customer, high availability, production, etc., right? And then we go through a methodology called E3 which is envision, enable and execute. Which is really envision what the end stage should be regardless of what the environment is, right? And then we enable, which is really kind of go through a proof of value to move a few workloads, to modernize, rearchitect, replatform, etc. And look at the benefit of that application on its destination. If it's a cloud - if it's a cloud service provider or if it's another data center, whatever it may be, right? And finally, you know, once we've proven the value and the benefit and and say and kind of monetize the, you know realize the value of it from an agility, from a cost, from security and resilience, etc. Then we go through the execution, which was look we look at the entire portfolio, the entire landscape. And we go through a very disciplined manner working with our customers to roadmap it. And then we execute in a very deliberate manner where you can see value every 2-3 months. Because gone the days when you can do things as a science project that took 2-3 years, right? We, we - Everyone wants to see value, want to see - wants to see progress, and most importantly we want to see cost benefit and agility sooner than later. >> Those are incredibly important outcomes. You guys have done a great job explaining what you're doing together. This sounds like a great relationship. All right, so my last question to both of you is: "If I'm a customer and I'm planning a cloud transformation for my company, what are the two things you want me to remember and consider as I plan this? Werner, we'll start with you. >> I would pick up two things, yeah? The first one is: When you are organizing your company in HR way, then cloud is the HR technology for the HR transformation. Because HR teams needs HR technology. And the second important thing is, what I would say is: Cloud is a large scale and fast moving technology enabler to the company. So if your company is going forward to say: Technology is their enabler tool from a future business then cloud can support this journey. >> Excellent. I'm going to walk away with those. And Adithya, same question to you. I'm a, I'm a customer. I'm at an organization. I'm planning a cloud transformation. Top two things you want me to walk away with. >> Yeah. And I think Werner kind of actually touched on that in the second one, which is: it's not a tech, just an IT or a technology initiative. It is a business initiative, right? Because ultimately what you do from this cloud journey should drive, you know, should lead into business transformation or help your business grow top line or drive margin expansion, etc. So couple of things I would say, right? One is, you know, get Being and prioritize. Work with your business owners, with, you know with the cross-functional team not just the technology team. That's one. The second thing is: as the technology team or the IT team shepherds this journey, you know, keep everyone informed and engaged as you go through this journey. Because as you go through moving workloads modernizing workload, there is an impact to, you know receivables through omnichannel experiences the way customers interact and transact with you, right? And that comes with making making sure your businesses are aware your business stakeholders are aware. So in turn the end customers are aware. So you know, it's not a one and done from an engagement, it's a journey. And bring in the right experts. Talk to people who've done it, done this before, who have kind of stepped in all the pitfalls so you don't have to, right? That's the key. >> That's great advice. That's great advice for anything in life, I think. You talk about the collaboration, the importance of the business and the technology folks coming together. It really has to be - It's a delicate balance as we said before but it really has to be a holistic collaborative approach. Guys, thank you so much for joining me talking through what HitachiVantara and RBI are doing together. It sounds like you're well into this journey and it sounds like it's going quite well. We thank you so much for your insights and your perspectives. >> Thank you, Lisa. Werner, thank you again. >> Good stuff guys. For my guests, I'm Lisa Martin. Thank you so much for watching our event: Build Your Cloud Center of Excellence. (upbeat music)

(soothing music) >> Hey everyone, welcome to this event, "Build Your Cloud Center of Excellence." I'm your host, Lisa Martin. In the next 15 minutes or so my guest and I are going to be talking about redefining cloud operations, an application modernization for customers, and specifically how partners are helping to speed up that process. As you saw on our first two segments, we talked about problems enterprises are facing with cloud operations. We talked about redefining cloud operations as well to solve these problems. This segment is going to be focusing on how Hitachi Vantara's partners are really helping to speed up that process. We've got Johnson Controls here to talk about their partnership with Hitachi Vantara. Please welcome both of my guests, Prem Balasubramanian is with us, SVP and CTO Digital Solutions at Hitachi Vantara. And Suresh Mothikuru, SVP Customer Success Platform Engineering and Reliability Engineering from Johnson Controls. Gentlemen, welcome to the program, great to have you. >> Thank. >> Thank you, Lisa. >> First question is to both of you and Suresh, we'll start with you. We want to understand, you know, the cloud operations landscape is increasingly complex. We've talked a lot about that in this program. Talk to us, Suresh, about some of the biggest challenges and pin points that you faced with respect to that. >> Thank you. I think it's a great question. I mean, cloud has evolved a lot in the last 10 years. You know, when we were talking about a single cloud whether it's Azure or AWS and GCP, and that was complex enough. Now we are talking about multi-cloud and hybrid and you look at Johnson Controls, we have Azure we have AWS, we have GCP, we have Alibaba and we also support on-prem. So the architecture has become very, very complex and the complexity has grown so much that we are now thinking about whether we should be cloud native or cloud agnostic. So I think, I mean, sometimes it's hard to even explain the complexity because people think, oh, "When you go to cloud, everything is simplified." Cloud does give you a lot of simplicity, but it also really brings a lot more complexity along with it. So, and then next one is pretty important is, you know, generally when you look at cloud services, you have plenty of services that are offered within a cloud, 100, 150 services, 200 services. Even within those companies, you take AWS they might not know, an individual resource might not know about all the services we see. That's a big challenge for us as a customer to really understand each of the service that is provided in these, you know, clouds, well, doesn't matter which one that is. And the third one is pretty big, at least at the CTO the CIO, and the senior leadership level, is cost. Cost is a major factor because cloud, you know, will eat you up if you cannot manage it. If you don't have a good cloud governance process it because every minute you are in it, it's burning cash. So I think if you ask me, these are the three major things that I am facing day to day and that's where I use my partners, which I'll touch base down the line. >> Perfect, we'll talk about that. So Prem, I imagine that these problems are not unique to Johnson Controls or JCI, as you may hear us refer to it. Talk to me Prem about some of the other challenges that you're seeing within the customer landscape. >> So, yeah, I agree, Lisa, these are not very specific to JCI, but there are specific issues in JCI, right? So the way we think about these are, there is a common issue when people go to the cloud and there are very specific and unique issues for businesses, right? So JCI, and we will talk about this in the episode as we move forward. I think Suresh and his team have done some phenomenal step around how to manage this complexity. But there are customers who have a lesser complex cloud which is, they don't go to Alibaba, they don't have footprint in all three clouds. So their multi-cloud footprint could be a bit more manageable, but still struggle with a lot of the same problems around cost, around security, around talent. Talent is a big thing, right? And in Suresh's case I think it's slightly more exasperated because every cloud provider Be it AWS, JCP, or Azure brings in hundreds of services and there is nobody, including many of us, right? We learn every day, nowadays, right? It's not that there is one service integrator who knows all, while technically people can claim as a part of sales. But in reality all of us are continuing to learn in this landscape. And if you put all of this equation together with multiple clouds the complexity just starts to exponentially grow. And that's exactly what I think JCI is experiencing and Suresh's team has been experiencing, and we've been working together. But the common problems are around security talent and cost management of this, right? Those are my three things. And one last thing that I would love to say before we move away from this question is, if you think about cloud operations as a concept that's evolving over the last few years, and I have touched upon this in the previous episode as well, Lisa, right? If you take architectures, we've gone into microservices, we've gone into all these server-less architectures all the fancy things that we want. That helps us go to market faster, be more competent to as a business. But that's not simplified stuff, right? That's complicated stuff. It's a lot more distributed. Second, again, we've advanced and created more modern infrastructure because all of what we are talking is platform as a service, services on the cloud that we are consuming, right? In the same case with development we've moved into a DevOps model. We kind of click a button put some code in a repository, the code starts to run in production within a minute, everything else is automated. But then when we get to operations we are still stuck in a very old way of looking at cloud as an infrastructure, right? So you've got an infra team, you've got an app team, you've got an incident management team, you've got a soft knock, everything. But again, so Suresh can talk about this more because they are making significant strides in thinking about this as a single workload, and how do I apply engineering to go manage this? Because a lot of it is codified, right? So automation. Anyway, so that's kind of where the complexity is and how we are thinking, including JCI as a partner thinking about taming that complexity as we move forward. >> Suresh, let's talk about that taming the complexity. You guys have both done a great job of articulating the ostensible challenges that are there with cloud, especially multi-cloud environments that you're living in. But Suresh, talk about the partnership with Hitachi Vantara. How is it helping to dial down some of those inherent complexities? >> I mean, I always, you know, I think I've said this to Prem multiple times. I treat my partners as my internal, you know, employees. I look at Prem as my coworker or my peers. So the reason for that is I want Prem to have the same vested interest as a partner in my success or JCI success and vice versa, isn't it? I think that's how we operate and that's how we have been operating. And I think I would like to thank Prem and Hitachi Vantara for that really been an amazing partnership. And as he was saying, we have taken a completely holistic approach to how we want to really be in the market and play in the market to our customers. So if you look at my jacket it talks about OpenBlue platform. This is what JCI is building, that we are building this OpenBlue digital platform. And within that, my team, along with Prem's or Hitachi's, we have built what we call as Polaris. It's a technical platform where our apps can run. And this platform is automated end-to-end from a platform engineering standpoint. We stood up a platform engineering organization, a reliability engineering organization, as well as a support organization where Hitachi played a role. As I said previously, you know, for me to scale I'm not going to really have the talent and the knowledge of every function that I'm looking at. And Hitachi, not only they brought the talent but they also brought what he was talking about, Harc. You know, they have set up a lot and now we can leverage it. And they also came up with some really interesting concepts. I went and met them in India. They came up with this concept called IPL. Okay, what is that? They really challenged all their employees that's working for GCI to come up with innovative ideas to solve problems proactively, which is self-healing. You know, how you do that? So I think partners, you know, if they become really vested in your interests, they can do wonders for you. And I think in this case Hitachi is really working very well for us and in many aspects. And I'm leveraging them... You started with support, now I'm leveraging them in the automation, the platform engineering, as well as in the reliability engineering and then in even in the engineering spaces. And that like, they are my end-to-end partner right now? >> So you're really taking that holistic approach that you talked about and it sounds like it's a very collaborative two-way street partnership. Prem, I want to go back to, Suresh mentioned Harc. Talk a little bit about what Harc is and then how partners fit into Hitachi's Harc strategy. >> Great, so let me spend like a few seconds on what Harc is. Lisa, again, I know we've been using the term. Harc stands for Hitachi application reliability sectors. Now the reason we thought about Harc was, like I said in the beginning of this segment, there is an illusion from an architecture standpoint to be more modern, microservices, server-less, reactive architecture, so on and so forth. There is an illusion in your development methodology from Waterfall to agile, to DevOps to lean, agile to path program, whatever, right? Extreme program, so on and so forth. There is an evolution in the space of infrastructure from a point where you were buying these huge humongous servers and putting it in your data center to a point where people don't even see servers anymore, right? You buy it, by a click of a button you don't know the size of it. All you know is a, it's (indistinct) whatever that name means. Let's go provision it on the fly, get go, get your work done, right? When all of this is advanced when you think about operations people have been solving the problem the way they've been solving it 20 years back, right? That's the issue. And Harc was conceived exactly to fix that particular problem, to think about a modern way of operating a modern workload, right? That's exactly what Harc. So it brings together finest engineering talent. So the teams are trained in specific ways of working. We've invested and implemented some of the IP, we work with the best of the breed partner ecosystem, and I'll talk about that in a minute. And we've got these facilities in Dallas and I am talking from my office in Dallas, which is a Harc facility in the US from where we deliver for our customers. And then back in Hyderabad, we've got one more that we opened and these are facilities from where we deliver Harc services for our customers as well, right? And then we are expanding it in Japan and Portugal as we move into 23. That's kind of the plan that we are thinking through. However, that's what Harc is, Lisa, right? That's our solution to this cloud complexity problem. Right? >> Got it, and it sounds like it's going quite global, which is fantastic. So Suresh, I want to have you expand a bit on the partnership, the partner ecosystem and the role that it plays. You talked about it a little bit but what role does the partner ecosystem play in really helping JCI to dial down some of those challenges and the inherent complexities that we talked about? >> Yeah, sure. I think partners play a major role and JCI is very, very good at it. I mean, I've joined JCI 18 months ago, JCI leverages partners pretty extensively. As I said, I leverage Hitachi for my, you know, A group and the (indistinct) space and the cloud operations space, and they're my primary partner. But at the same time, we leverage many other partners. Well, you know, Accenture, SCL, and even on the tooling side we use Datadog and (indistinct). All these guys are major partners of our because the way we like to pick partners is based on our vision and where we want to go. And pick the right partner who's going to really, you know make you successful by investing their resources in you. And what I mean by that is when you have a partner, partner knows exactly what kind of skillset is needed for this customer, for them to really be successful. As I said earlier, we cannot really get all the skillset that we need, we rely on the partners and partners bring the the right skillset, they can scale. I can tell Prem tomorrow, "Hey, I need two parts by next week", and I guarantee it he's going to bring two parts to me. So they let you scale, they let you move fast. And I'm a big believer, in today's day and age, to get things done fast and be more agile. I'm not worried about failure, but for me moving fast is very, very important. And partners really do a very good job bringing that. But I think then they also really make you think, isn't it? Because one thing I like about partners they make you innovate whether they know it or not but they do because, you know, they will come and ask you questions about, "Hey, tell me why you are doing this. Can I review your architecture?" You know, and then they will try to really say I don't think this is going to work. Because they work with so many different clients, not JCI, they bring all that expertise and that's what I look from them, you know, just not, you know, do a T&M job for me. I ask you to do this go... They just bring more than that. That's how I pick my partners. And that's how, you know, Hitachi's Vantara is definitely one of a good partner from that sense because they bring a lot more innovation to the table and I appreciate about that. >> It sounds like, it sounds like a flywheel of innovation. >> Yeah. >> I love that. Last question for both of you, which we're almost out of time here, Prem, I want to go back to you. So I'm a partner, I'm planning on redefining CloudOps at my company. What are the two things you want me to remember from Hitachi Vantara's perspective? >> So before I get to that question, Lisa, the partners that we work with are slightly different from from the partners that, again, there are some similar partners. There are some different partners, right? For example, we pick and choose especially in the Harc space, we pick and choose partners that are more future focused, right? We don't care if they are huge companies or small companies. We go after companies that are future focused that are really, really nimble and can change for our customers need because it's not our need, right? When I pick partners for Harc my ultimate endeavor is to ensure, in this case because we've got (indistinct) GCI on, we are able to operate (indistinct) with the level of satisfaction above and beyond that they're expecting from us. And whatever I don't have I need to get from my partners so that I bring this solution to Suresh. As opposed to bringing a whole lot of people and making them stand in front of Suresh. So that's how I think about partners. What do I want them to do from, and we've always done this so we do workshops with our partners. We just don't go by tools. When we say we are partnering with X, Y, Z, we do workshops with them and we say, this is how we are thinking. Either you build it in your roadmap that helps us leverage you, continue to leverage you. And we do have minimal investments where we fix gaps. We're building some utilities for us to deliver the best service to our customers. And our intention is not to build a product to compete with our partner. Our intention is to just fill the wide space until they go build it into their product suite that we can then leverage it for our customers. So always think about end customers and how can we make it easy for them? Because for all the tool vendors out there seeing this and wanting to partner with Hitachi the biggest thing is tools sprawl, especially on the cloud is very real. For every problem on the cloud. I have a billion tools that are being thrown at me as Suresh if I'm putting my installation and it's not easy at all. It's so confusing. >> Yeah. >> So that's what we want. We want people to simplify that landscape for our end customers, and we are looking at partners that are thinking through the simplification not just making money. >> That makes perfect sense. There really is a very strong symbiosis it sounds like, in the partner ecosystem. And there's a lot of enablement that goes on back and forth it sounds like as well, which is really, to your point it's all about the end customers and what they're expecting. Suresh, last question for you is which is the same one, if I'm a partner what are the things that you want me to consider as I'm planning to redefine CloudOps at my company? >> I'll keep it simple. In my view, I mean, we've touched upon it in multiple facets in this interview about that, the three things. First and foremost, reliability. You know, in today's day and age my products has to be reliable, available and, you know, make sure that the customer's happy with what they're really dealing with, number one. Number two, my product has to be secure. Security is super, super important, okay? And number three, I need to really make sure my customers are getting the value so I keep my cost low. So these three is what I would focus and what I expect from my partners. >> Great advice, guys. Thank you so much for talking through this with me and really showing the audience how strong the partnership is between Hitachi Vantara and JCI. What you're doing together, we'll have to talk to you again to see where things go but we really appreciate your insights and your perspectives. Thank you. >> Thank you, Lisa. >> Thanks Lisa, thanks for having us. >> My pleasure. For my guests, I'm Lisa Martin. Thank you so much for watching. (soothing music)

(upbeat music) >> Hey everyone, welcome to this event: Build Your Cloud Center of Excellence. I'm your host, Lisa Martin, and I have two guests here with me today to talk about the hybrid cloud, the multi-cloud trends, and specifically the complexity. While we know these trends provide agility and flexibility for customers, they also bring in complexity. And this session is going to focus on exploring that with RBI and HitachiVantara. Please welcome my guests, Adithya Sastry the SVP of Digital Solutions at HitachiVantara and Werner Mayer, head of group core IT and head of group data at RBI International. Guys, welcome to the program. >> Thank you Lisa. Werner, nice to see you again. >> Great to see you both. >> And Werner, we're going to start with you. Talk about RBI. Tell the audience a little bit about what the business is and then we're going to get into your cloud transformation journey over the last couple of years. >> Yes, thank you. So Raiffeisen Bank International is international working banking groups. So our core markets are Central Eastern European, Central Eastern Europe and Austria. And we are serving around 50 million clients in this market. So we active in 13 markets. >> Got it. Talk to me, Werner about the cloud transformation journey that RBI has been on over the last couple of years and some of the complexities that you've experienced as you've launched it. >> Sure. Thank you for the question. So in 2020, we decided that we have to renew our IT strategy. And the aim of the strategy was to change the organization in a way that it can react and adapt fast to the future challenges. So one of the important pillars for us was that we are adapting fast also for new technologies. And this was core pillar in our strategy. So we're searching for technologies which are fit in to our HR transformation. And we found that the cloud and the public cloud environment fits to this venture. So we tested that. We are building up also the competent centers for that and also established the group cloud platform for that. Because our invoice to onboard our international group with the 13 units to this group cloud platform. So that means we have a lot to do to hardening the platforms in terms of security to put in. We have standard for that. We have to introduce large scale programs to train hundreds of engineers. We tested the approach, We convinced the top management and we implemented this, this program. So one of the highlights was, of course, also the the safeguarding of the Ukraine, let's say, banking environment. So we had to lift and shift the complete bank in three months. And it shows that let's say our platforms works. And let's say the approach is proven that we can scale it over the group. >> That's a big challenge. A lot of complexity especially with some of the global things going on. Adithya, these challenges are, are not unique to RBI. A lot of your customers are facing challenges with complexity around cloud management, cloud ops. What can you unpack was the real issue is here? >> Yeah, Lisa, absolutely. And you know, before I answer your question, I do want to, you know, just say a couple of things about Raiffeisen Bank. And you know, we've had the pleasure of working with them for about a year, a little bit more than a year now. And, and, and the way they approach the cloud transformation journey is - should be a template for a lot of the organizations in terms of the preparation in terms of understanding, you know. How other companies have done it and what are the pitfalls. What's worked, and really what's the recipe for their, you know, journey, right? Which is very unique because, you know, you look at you know, being present across 30 different countries within central and eastern Europe as Werner said. And the complexities of dealing with local regulations, GDPR and all these other issues that come with it, right? And not to mention the language variation from country to country. So, you know, phenomenal story there. The journey and the journey still goes, right Werner? It's not complete yet. But Lisa, to your question, you know. When we look at, you know, the complexities of this transformation, that most modern enterprises are going through. It's not very unique, right? What is unique for a Raiffeisen Bank is - has been the preparation. But as you get into this journey of moving workloads to cloud, be it refactoring, modernizing, migrating, etc. One of the things that really is often overlooked is: "Are my applications applications and data workloads resilient on, on the, on the cloud?" Meaning are they - How is the performance? Are they just running or are they performing with high availability to meet your customers goals? Is it scalable? And are my cost in line with what I projected when I moved prep, right? Because that's one of the areas we are seeing where you know, what enterprises projected from a cost savings to what they're realizing a year and a half into the journey is a pretty big delta, right? And, and, and a lot of it is dependent on are the cloud - are the applications and the workloads cloud, designed for the cloud? Or are they designed for on-prem which you just move to the cloud. >> So Werner, it sounds like what Adithya said is a compliment to, to you guys and the team at RBI in terms of this being a template for managing complexity. Give us, Werner, your perspective in terms of modern cloud ops. What's in? What's out? What is it that customers really need to be focusing on to be successful? >> Thanks for the compliment, Lisa. And I think this is a great relationship also in the journey. Topic is, is, is a - is a complex program where a lot of things have to fit together. But it was mentioning the resilience. The course, we call it finops, security operations and so on have to come together and have to work on spot. At the end, it's also, let's say, how we are able enabling our teams and how we are ramping out the skills of our teams to deal with these multidimensional, let's say environments. And this is something what we spend a lot of time in order to prepare, but also to bring up the people on a certain level that they can operate at. Because card guard handling is, is different than before. Because beforehand you have central operations team. They do everything for you. But in this world let's say we are also putting the responsibility of the run component of the absent to the - in the tribes and the application teams. And they have to do much more than before. On the other hand, we have first central rules. We have monitoring functions. We have support functions on that in order to best support them in their journey. So this is a hybrid between, let's say, what the teams have to do with the responsibility in the teams, but also with the central functions which are supporting them. And everything have to work together and goes hand in - right, to go hand-in-hand. >> Yeah. Yeah. And if, if I could just add Lisa really quick and and Werner hit the nail on the head, right? Because you cannot look at cloud operation the way we have traditionally looked at managed services. That's the key thing, right? You cannot, you know, traditional managed services you had L1, L2, L3 and then it goes into some sort of a vacuum and then all of a sudden somebody calls you at some point, right? >> Werner: Exactly. >> And it really has flipped, right? To, to Werner's point. And Werner hit that name on the head because you really have to understand. Bring an engineering led approach to make sure that the problems, you know, when you see an issue that you have some level of automation in terms of problem isolation. And then the problem is routed the right individual ie the application engineering team or the data engineering team for resolution in a rapid manner. Right? I think that the key - >> Yes. A very important point with that is said, yeah. So you cannot traditional transport let's say, the operation model what you have now into the cloud because this will not work, yeah. And finally at the end you will not benefit on the technology possibilities there. So super important point. My vision in the cloud and this is also something what we are working on is a sort of zero-ops environment, yeah? Because we're ultimately dealing with the automatization technologies and so on, you can that much - to much more compared to the traditional environment and the benefit of the cloud is: You can test it. You can give it feedback when it is not working, yeah? So it's a completely different operating model. What we try to establish in the cloud environment. >> So really what this seems like guys is is quite a delicate balance that you're solving for. Not the only delicate balance but Werner sticking with you. Talk to us about some of the challenges that you've had around cloud cost management in particular. Help us understand that. >> Thanks for the question. So in principle, we are doing very well on the cost side, surprisingly. And we also started the cloud journey that is said this is not the cost case. Because as I said before, let's say one of the pillars in the strategy strategy was the enablement of technology to the benefit of customer solutions to be adaptive, to be faster. But at the end it turned out that let's say with giving the responsibility of the operation to the dedicated team, they found they - they were working much closer to the cost, and let's say monitoring the cost, then we headed into traditional environments, yeah? I also saw some examples in the group where sort of gamification of the cost were going on. To say who can save more To say who can save more and make more much more out of that what you have in the cloud. And at the end we see that in minimum the cost are balance to the traditional environments in the data centers. But we also saw that let's say, the cost were brought down much more than before. So at the beginning we were relative conservative with the assumptions, yeah? But it turns out that we are really getting the benefit. The things are getting faster and also the costs are going down. And we see this in real cases. >> Yeah. And, and, and Lisa, if I could add something really quick, right? Because - You know, there's been a mad rush to the cloud, right? Everybody kind of, it was, you know, the buzz the buzz was let's get to the cloud. We'll start to realize all these savings. And all of a sudden, everything kind of magically gets better, right? And what we have seen is also, you know, companies or customers or enterprises that have started this journey about 5, 6 years ago and are about, you know, a few years into it. What we are realizing is the cloud costs have increased significantly to what their projections were early on. And the way they're trying to address the cloud cost is by creating a FinOps organization that's looking at, you know, the cost of cloud from a structure standpoint and support as a reactive measure. Saying, "Hey if we move from Azure or one provider to another is there any benefit? If we move certain applications from the cloud back to on-prem, is there any benefit?" When in fact, one of the things that we have noticed really is: The problem needs to shift left to the engineering teams. Because if you are designing the applications and the systems the right way to begin with, then you can manage the data cost issues or the cost overruns, right? So you design for the cloud as opposed to designing and then looking at how do we optimize cloud. >> So Adithya, you talked about the RBI use case as really kind of a template but also some of the challenges with respect to hybrid and multi-cloud are kind of like a chicken and egg scenario. Talk to us kind of like overall about how Hitachi is really helping customers address these challenges and maximize the benefits to get the flexibility to get the agility so that they can deliver what their end user customers are expecting. >> Yeah, yeah. So, so one of the things we are doing, Lisa, when we work with customers, is really trying to understand, you know, look at their entire portfolio of applications, right? And, and look at what the intent of the applications is between customer facing, external customer, internal customer, high availability, production, etc., right? And then we go through a methodology called E3 which is envision, enable and execute. Which is really envision what the end stage should be regardless of what the environment is, right? And then we enable, which is really kind of go through a proof of value to move a few workloads, to modernize, rearchitect, replatform, etc. And look at the benefit of that application on its destination. If it's a cloud - if it's a cloud service provider or if it's another data center, whatever it may be, right? And finally, you know, once we've proven the value and the benefit and and say and kind of monetize the, you know realize the value of it from an agility, from a cost, from security and resilience, etc. Then we go through the execution, which was look we look at the entire portfolio, the entire landscape. And we go through a very disciplined manner working with our customers to roadmap it. And then we execute in a very deliberate manner where you can see value every 2-3 months. Because gone the days when you can do things as a science project that took 2-3 years, right? We, we - Everyone wants to see value, want to see - wants to see progress, and most importantly we want to see cost benefit and agility sooner than later. >> Those are incredibly important outcomes. You guys have done a great job explaining what you're doing together. This sounds like a great relationship. All right, so my last question to both of you is: "If I'm a customer and I'm planning a cloud transformation for my company, what are the two things you want me to remember and consider as I plan this? Werner, we'll start with you. >> I would pick up two things, yeah? The first one is: When you are organizing your company in HR way, then cloud is the HR technology for the HR transformation. Because HR teams needs HR technology. And the second important thing is, what I would say is: Cloud is a large scale and fast moving technology enabler to the company. So if your company is going forward to say: Technology is their enabler tool from a future business then cloud can support this journey. >> Excellent. I'm going to walk away with those. And Adithya, same question to you. I'm a, I'm a customer. I'm at an organization. I'm planning a cloud transformation. Top two things you want me to walk away with. >> Yeah. And I think Werner kind of actually touched on that in the second one, which is: it's not a tech, just an IT or a technology initiative. It is a business initiative, right? Because ultimately what you do from this cloud journey should drive, you know, should lead into business transformation or help your business grow top line or drive margin expansion, etc. So couple of things I would say, right? One is, you know, get Being and prioritize. Work with your business owners, with, you know with the cross-functional team not just the technology team. That's one. The second thing is: as the technology team or the IT team shepherds this journey, you know, keep everyone informed and engaged as you go through this journey. Because as you go through moving workloads modernizing workload, there is an impact to, you know receivables through omnichannel experiences the way customers interact and transact with you, right? And that comes with making making sure your businesses are aware your business stakeholders are aware. So in turn the end customers are aware. So you know, it's not a one and done from an engagement, it's a journey. And bring in the right experts. Talk to people who've done it, done this before, who have kind of stepped in all the pitfalls so you don't have to, right? That's the key. >> That's great advice. That's great advice for anything in life, I think. You talk about the collaboration, the importance of the business and the technology folks coming together. It really has to be - It's a delicate balance as we said before but it really has to be a holistic collaborative approach. Guys, thank you so much for joining me talking through what HitachiVantara and RBI are doing together. It sounds like you're well into this journey and it sounds like it's going quite well. We thank you so much for your insights and your perspectives. >> Thank you, Lisa. Werner, thank you again. >> Good stuff guys. For my guests, I'm Lisa Martin. Thank you so much for watching our event: Build Your Cloud Center of Excellence. (upbeat music)

(bright upbeat music) >> Welcome back, everyone, to the "Supercloud 22." I'm John Furrier, host of "The Cube." This is the Cloud-erati panel, the distinguished experts who have been there from day one, watching the cloud grow, from building clouds, and all open source stuff as well. Just great stuff. Good friends of "The Cube," and great to introduce back on "The Cube," Adrian Cockcroft, formerly with Netflix, formerly AWS, retired, now commentating here in "The Cube," as well as other events. Great to see you back out there, Adrian. Lori MacVittie, Cloud Evangelist with F5, also wrote a great blog post on supercloud, as well as Dave Vellante as well, setting up the supercloud conversation, which we're going to get into, and Chris Hoff, who's the CTO and CSO of LastPass who's been building clouds, and we know him from "The Cube" before with security and cloud commentary. Welcome, all, back to "The Cube" and supercloud. >> Thanks, John. >> Hi. >> All right, Lori, we'll start with you to get things going. I want to try to sit back, as you guys are awesome experts, and involved from building, and in the trenches, on the front lines, and Adrian's coming out of retirement, but Lori, you wrote the post setting the table on supercloud. Let's start with you. What is supercloud? What is it evolving into? What is the north star, from your perspective? >> Well, I don't think there's a north star yet. I think that's one of the reasons I wrote it, because I had a clear picture of this in my mind, but over the past, I don't know, three, four years, I keep seeing, in research, my own and others', complexity, multi-cloud. "We can't manage it. They're all different. "We have trouble. What's going on? "We can't do anything right." And so digging into it, you start looking into, "Well, what do you mean by complexity?" Well, security. Migration, visibility, performance. The same old problems we've always had. And so, supercloud is a concept that is supposed to overlay all of the clouds and normalize it. That's really what we're talking about, is yet another abstraction layer that would provide some consistency that would allow you to do the same security and monitor things correctly. Cornell University actually put out a definition way back in 2016. And they said, "It's an architecture that enables migration "across different zones or providers," and I think that's important, "and provides interfaces to everything, "makes it consistent, and normalizes the network," basically brings it all together, but it also extends to private clouds. Sometimes we forget about that piece of it, and I think that's important in this, so that all your clouds look the same. So supercloud, big layer on top, makes everything wonderful. It's unicorns again. >> It's interesting. We had multiple perspectives. (mumbles) was like Snowflake, who built on top of AWS. Jerry Chan, who we heard from earlier today, Greylock Penn's "Castles in the Cloud" saying, "Hey, you can have a moat, "you can build an advantage and have differentiation," so startups are starting to build on clouds, that's the native cloud view, and then, of course, they get success and they go to all the other clouds 'cause they got customers in the ecosystem, but it seems that all the cloud players, Chris, you commented before we came on today, is that they're all fighting for the customer's workloads on their infrastructure. "Come bring your stuff over to here, "and we'll make it run better." And all your developers are going to be good. Is there a problem? I mean, or is this something else happening here? Is there a real problem? >> Well, I think the north star's over there, by the way, Lori. (laughing) >> Oh, there it is. >> Right there. The supercloud north star. So indeed I think there are opportunities. Whether you call them problems or not, John, I think is to be determined. Most companies have, especially if they're a large enterprise, whether or not they've got an investment in private cloud or not, have spent time really trying to optimize their engineering and workload placement on a single cloud. And that, regardless of your choice, as we take the big three, whether it's Amazon, Google, or Microsoft, each of them have their pros and cons for various types of workloads. And so you'll see a lot of folks optimizing for a particular cloud, and it takes a huge effort up and down the stack to just get a single cloud right. That doesn't take into consideration integrations with software as a service, instantiated, oftentimes, on top of infrastructure of the service that you need to supplement where the obstruction layer ends in infrastructure of the service. You've seen most IS players starting to now move up-chain, as we predicted years ago, to platform as a service, but platforms of various types. So I definitely see it as an opportunity. Previous employers have had multiple clouds, but they were very specifically optimized for the types of workloads, for example, in, let's say, AWS versus GCP, based on the need for different types and optimized compute platforms that each of those providers ran. We never, in that particular case, thought about necessarily running the same workloads across both clouds, because they had different pricing models, different security models, et cetera. And so the challenge is really coming down to the fact that, what is the cost benefit analysis of thinking about multi-cloud when you can potentially engineer the resiliency or redundancy, all the in-season "ilities" that you might need to factor into your deployments on a single cloud, if they are investing at the pace in which they are? So I think it's an opportunity, and it's one that continues to evolve, but this just reminds me, your comments remind me, of when we were talking about OpenStack versus AWS. "Oh, if there were only APIs that existed "that everybody could use," and you saw how that went. So I think that the challenge there is, what is the impetus for a singular cloud provider, any of the big three, deciding that they're going to abstract to a single abstraction layer and not be able to differentiate from the competitors? >> Yeah, and that differentiation's going to be big. I mean, assume that the clouds aren't going to stay still like AWS and just not stop innovating. We see the devs are doing great, Adrian, open source is bigger and better than ever, but now that's been commercialized into enterprise. It's an ops problem. So to Chris's point, the cost benefit analysis is interesting, because do companies have to spin up multiple operations teams, each with specialized training and tooling for the clouds that they're using, and does that open up a can of worms, or is that a good thing? I mean, can you design for this? I mean, is there an architecture or taxonomy that makes it work, or is it just the cart before the horse, the solution before the problem? >> Yeah, well, I think that if you look at any large vendor... Sorry, large customer, they've got a bit of everything already. If you're big enough, you've bought something from everybody at some point. So then you're trying to rationalize that, and trying to make it make sense. And I think there's two ways of looking at multi-cloud or supercloud, and one is that the... And practically, people go best of breed. They say, "Okay, I'm going to get my email "from Google or Microsoft. "I'm going to run my applications on AWS. "Maybe I'm going to do some AI machine learning on Google, "'cause those are the strengths of the platforms." So people tend to go where the strength is. So that's multi-cloud, 'cause you're using multiple clouds, and you still have to move data and make sure they're all working together. But then what Lori's talking about is trying to make them all look the same and trying to get all the security architectures to be the same and put this magical layer, this unicorn magical layer that, "Let's make them all look the same." And this is something that the CIOs have wanted for years, and they keep trying to buy it, and you can sell it, but the trouble is it's really hard to deliver. And I think, when I go back to some old friends of ours at Enstratius who had... And back in the early days of cloud, said, "Well, we'll just do an API that abstracts "all the cloud APIs into one layer." Enstratius ended up being sold to Dell a few years ago, and the problem they had was that... They didn't have any problem selling it. The problem they had was, a year later, when it came up for renewal, the developers all done end runs around it were ignoring it, and the CIOs weren't seeing usage. So you can sell it, but can you actually implement it and make it work well enough that it actually becomes part of your core architecture without, from an operations point of view, without having the developers going directly to their favorite APIs around them? And I'm not sure that you can really lock an organization down enough to get them onto a layer like that. So that's the way I see it. >> You just defined- >> You just defined shadow shadow IT. (laughing) That's pretty- (crosstalk) >> Shadow shadow IT, yeah. >> Yeah, shadow shadow it. >> Yeah. >> Yeah. >> I mean, this brings up the question, I mean, is there really a problem? I mean, I guess we'll just jump to it. What is supercloud? If you can have the magic outcome, what is it? Enstratius rendered in with automation? The security issues? Kubernetes is hot. What is the supercloud dream? I guess that's the question. >> I think it's got easier than it was five, 10 years ago. Kubernetes gives you a bunch of APIs that are common across lots of different areas, things like Snowflake or MongoDB Atlas. There are SaaS-based services, which are across multiple clouds from vendors that you've picked. So it's easier to build things which are more portable, but I still don't think it's easy to build this magic API that makes them all look the same. And I think that you're going to have leaky abstractions and security being... Getting the security right's going to be really much more complex than people think. >> What about specialty superclouds, Chris? What's your view on that? >> Yeah, I think what Adrian is alluding to, those leaky abstractions, are interesting, especially from the security perspective, 'cause I think what you see is if you were to happen to be able to thin slice across a set of specific types of workloads, there is a high probability given today that, at least on two of the three major clouds, you could get SaaS providers that sit on those same infrastructure of the service clouds for you, string them together, and have a service that technically is abstracted enough from the things you care about to work on one, two, or three, maybe not all of them, but most SaaS providers in the security space, or identity space, data space, for example, coexist on at least Microsoft and AWS, if not all three, with Google. And so you could technically abstract a service to the point that you let that level of abstract... Like Lori said, no computer science problem could not be... So, no computer science problem can't be solved with more layers of abstraction or misdirection... Or redirection. And in that particular case, if you happen to pick the right vendors that run on all three clouds, you could possibly get close. But then what that really talks about is then, if you built your seven-layer dip model, then you really have specialty superclouds spanning across infrastructure of the service clouds. One for your identity apps, one for data and data layers, to normalize that, one for security, but at what cost? Because you're going to be charged not for that service as a whole, but based on compute resources, based on how these vendors charge across each cloud. So again, that cost-benefit ratio might start being something that is rather imposing from a budgetary perspective. >> Lori, weigh in on this, because the enterprise people love to solve complexity with more complexity. Here, we need to go the other way. It's a commodity. So there has to be a better way. >> I think I'm hearing two fundamental assumptions. One, that a supercloud would force the existing big three to implement some sort of equal API. Don't agree with that. There's no business case for that. There's no reason that could compel them to do that. Otherwise, we would've convinced them to do that, what? 10, 15 years ago when we said we need to be interoperable. So it's not going to happen there. They don't have a good reason to do that. There's no business justification for that. The other presumption, I think, is that we would... That it's more about the services, the differentiated services, that are offered by all of these particular providers, as opposed to treating the core IaaS as the commodity it is. It's compute, it's some storage, it's some networking. Look at that piece. Now, pull those together by... And it's not OpenStack. That's not the answer, it wasn't the answer, it's not the answer now, but something that can actually pull those together and abstract it at a different layer. So cloud providers don't have to change, 'cause they're not going to change, but if someone else were to build that architecture to say, "all right, I'm going to treat all of this compute "so you can run your workloads," as Chris pointed out, "in the best place possible. "And we'll help you do that "by being able to provide those cost benefit analysis, "'What's the best performance, what are you doing,' "And then provide that as a layer." So I think that's really where supercloud is going, 'cause I think that's what a lot of the market actually wants in terms of where they want to run their workloads, because we're seeing that they want to run workloads at the edge, "a lot closer to me," which is yet another factor that we have to consider, and how are you going to be moving individual workloads around? That's the holy grail. Let's move individual workloads to where they're the best performance, the security, cost optimized, and then one layer up. >> Yeah, I think so- >> John Considine, who ultimately ran CloudSwitch, that sold to Verizon, as well as Tom Gillis, who built Bracket, are both rolling in their graves, 'cause what you just described was exactly that. (Lori laughing) Well, they're not even dead yet, so I can't say they're rolling in their graves. Sorry, Tom. Sorry, John. >> Well, how do hyperscalers keep their advantage with all this? I mean, to that point. >> Native services and managed services on top of it. Look how many flavors of managed Kubernetes you have. So you have a choice. Roll your own, or go with a managed service, and then differentiate based on the ability to take away and simplify some of that complexity. Doesn't mean it's more secure necessarily, but I do think we're seeing opportunities where those guys are fighting tooth and nail to keep you on a singular cloud, even though, to Lori's point, I agree, I don't think it's about standardized APIs, 'cause I think that's never going to happen. I do think, though, that SaaS-y supercloud model that we were talking about, layering SaaS that happens to span all the three infrastructure of the service are probably more in line with what Lori was talking about. But I do think that portability of workload is given to you today within lots of ways. But again, how much do you manage, and how much performance do you give up by running additional abstraction layers? And how much security do you give up by having to roll your own and manage that? Because the whole point was, in many cases... Cloud is using other people's computers, so in many cases, I want to manage as little of it as I possibly can. >> I like this whole SaaS angle, because if you had the old days, you're on Amazon Web Services, hey, if you build a SaaS application that runs on Amazon, you're all great, you're born in the cloud, just like that generations of startups. Great. Now when you have this super pass layer, as Dave Vellante was riffing on his analysis, and Lori, you were getting into this pass layer that's kind of like SaaS-y, what's the SaaS equation look like? Because that, to me, sounds like a supercloud version of saying, "I have a workload that runs on all the clouds equally." I just don't think that's ever going to happen. I agree with you, Chris, on that one. But I do see that you can have an abstraction that says, "Hey, I don't really want to get in the weeds. "I don't want to spend a lot of ops time on this. "I just want it to run effectively, and magic happens," or, as you said, some layer there. How does that work? How do you see this super pass layer, if anything, enabling a different SaaS game? >> I think you hit on it there. The last like 10 or so years, we've been all focused on developers and developer productivity, and it's all about the developer experience, and it's got to be good for them, 'cause they're the kings. And I think the next 10 years are going to be very focused on operations, because once you start scaling out, it's not about developers. They can deliver fast or slow, it doesn't matter, but if you can't scale it out, then you've got a real problem. So I think that's an important part of it, is really, what is the ops experience, and what is the best way to get those costs down? And this would serve that purpose if it was done right, which, we can argue about whether that's possible or not, but I don't have to implement it, so I can say it's possible. >> Well, are we going to be getting into infrastructure as code moves into "everything is code," security, data, (laughs) applications is code? I mean, "blank" is code, fill in the blank. (Lori laughing) >> Yeah, we're seeing more of that with things like CDK and Pulumi, where you are actually coding up using a real language rather than the death by YAML or whatever. How much YAML can you take? But actually having a real language so you're not trying to do things in parsing languages. So I think that's an interesting trend. You're getting some interesting templates, and I like what... I mean, the counterexample is that if you just go deep on one vendor, then maybe you can go faster and it is simpler. And one of my favorite vendor... Favorite customers right now that I've been talking to is Liberty Mutual. Went very deep and serverless first on AWS. They're just doing everything there, and they're using CDK Patterns to do it, and they're going extremely fast. There's a book coming out called "The Value Flywheel" by Dave Anderson, it's coming out in a few months, to just detail what they're doing, but that's the counterargument. If you could pick one vendor, you can go faster, you can get that vendor to do more for you, and maybe get a bigger discount so you're not splitting your discounts across vendors. So that's one aspect of it. But I think, fundamentally, you're going to find the CIOs and the ops people generally don't like sitting on one vendor. And if that single vendor is a horizontal platform that's trying to make all the clouds look the same, now you're locked into whatever that platform was. You've still got a platform there. There's still something. So I think that's always going to be something that the CIOs want, but the developers are always going to just pick whatever the best tool for building the thing is. And a analogy here is that the developers are dating and getting married, and then the operations people are running the family and getting divorced. And all the bad parts of that cycle are in the divorce end of it. You're trying to get out of a vendor, there's lawyers, it's just a big mess. >> Who's the lawyer in this example? (crosstalk) >> Well... (laughing) >> Great example. (crosstalk) >> That's why ops people don't like lock-in, because they're the ones trying to unlock. They aren't the ones doing the lock-in. They're the ones unlocking, when developers, if you separate the two, are the ones who are going, picking, having the fun part of it, going, trying a new thing. So they're chasing a shiny object, and then the ops people are trying to untangle themselves from the remains of that shiny object a few years later. So- >> Aren't we- >> One way of fixing that is to push it all together and make it more DevOps-y. >> Yeah, that's right. >> But that's trying to put all the responsibilities in one place, like more continuous improvement, but... >> Chris, what's your reaction to that? Because you're- >> No, that's exactly what I was going to bring up, yeah, John. And 'cause we keep saying "devs," "dev," and "ops" and I've heard somewhere you can glue those two things together. Heck, you could even include "sec" in the middle of it, and "DevSecOps." So what's interesting about what Adrian's saying though, too, is I think this has a lot to do with how you structure your engineering teams and how you think about development versus operations and security. So I'm building out a team now that very much makes use of, thanks to my brilliant VP of Engineering, a "Team Topologies" approach, which is a very streamlined and product oriented way of thinking about, for example, in engineering, if you think about team structures, you might have people that build the front end, build the middle tier, and the back end, and then you have a product that needs to make use of all three components in some form. So just from getting stuff done, their ability then has to tie to three different groups, versus building a team that's streamlined that ends up having front end, middleware, and backend folks that understand and share standards but are able to uncork the velocity that's required to do that. So if you think about that, and not just from an engineering development perspective, but then you couple in operations as a foundational layer that services them with embedded capabilities, we're putting engineers and operations teams embedded in those streamlined teams so that they can run at the velocity that they need to, they can do continuous integration, they can do continuous deployment. And then we added CS, which is continuously secure, continuous security. So instead of having giant, centralized teams, we're thinking there's a core team, for example, a foundational team, that services platform, makes sure all the trains are running on time, that we're doing what we need to do foundationally to make the environments fully dev and operator and security people functional. But then ultimately, we don't have these big, monolithic teams that get into turf wars. So, to Adrian's point about, the operators don't like to be paned in, well, they actually have a say, ultimately, in how they architect, deploy, manage, plan, build, and operate those systems. But at the same point in time, we're all looking at that problem across those teams and go... Like if one streamline team says, "I really want to go run on Azure, "because I like their services better," the reality is the foundational team has a larger vote versus opinion on whether or not, functionally, we can satisfy all of the requirements of the other team. Now, they may make a fantastic business case and we play rock, paper, scissors, and we do that. Right now, that hasn't really happened. We look at the balance of AWS, we are picking SaaS-y, supercloud vendors that will, by the way, happen to run on three platforms, if we so choose to expand there. So we have a similar interface, similar capability, similar processes, but we've made the choice at LastPass to go all in on AWS currently, with respect to how we deliver our products, for all the reasons we just talked about. But I do think that operations model and how you build your teams is extremely important. >> Yeah, and to that point- >> And has the- (crosstalk) >> The vendors themselves need optionality to the customer, what you're saying. So, "I'm going to go fast, "but I need to have that optionality." I guess the question I have for you guys is, what is today's trade-off? So if the decision point today is... First of all, I love the go-fast model on one cloud. I think that's my favorite when I look at all this, and then with the option, knowing that I'm going to have the option to go to multiple clouds. But everybody wants lock-in on the vendor side. Is that scale, is that data advantage? I mean, so the lock-in's a good question, and then also the trade-offs. What do people have to do today to go on a supercloud journey to have an ideal architecture and taxonomy, and what's the right trade-offs today? >> I think that the- Sorry, just put a comment and then let Lori get a word in, but there's a lot of... A lot of the market here is you're building a product, and that product is a SaaS product, and it needs to run somewhere. And the customers that you're going to... To get the full market, you need to go across multiple suppliers, most people doing AWS and Azure, and then with Google occasionally for some people. But that, I think, has become the pattern that most of the large SaaS platforms that you'd want to build out of, 'cause that's the fast way of getting something that's going to be stable at scale, it's got functionality, you'd have to go invest in building it and running it. Those platforms are just multi-cloud platforms, they're running across them. So Snowflake, for example, has to figure out how to make their stuff work on more than one cloud. I mean, they started on one, but they're going across clouds. And I think that that is just the way it's going to be, because you're not going to get a broad enough view into the market, because there isn't a single... AWS doesn't have 100% of the market. It's maybe a bit more than them, but Azure has got a pretty solid set of markets where it is strong, and it's market by market. So in some areas, different people in some places in the world, and different vertical markets, you'll find different preferences. And if you want to be across all of them with your data product, or whatever your SaaS product is, you're just going to have to figure this out. So in some sense, the supercloud story plays best with those SaaS providers like the Snowflakes of this world, I think. >> Lori? >> Yeah, I think the SaaS product... Identity, whatever, you're going to have specialized. SaaS, superclouds. We already see that emerging. Identity is becoming like this big SaaS play that crosses all clouds. It's not just for one. So you get an evolution going on where, yes, I mean, every vendor who provides some kind of specific functionality is going to have to build out and be multi-cloud, as it were. It's got to work equally across them. And the challenge, then, for them is to make it simple for both operators and, if required, dev. And maybe that's the other lesson moving forward. You can build something that is heaven for ops, but if the developers won't use it, well, then you're not going to get it adopted. But if you make it heaven for the developers, the ops team may not be able to keep it secure, keep everything. So maybe we have to start focusing on both, make it friendly for both, at least. Maybe it won't be the perfect experience, but gee, at least make it usable for both sides of the equation so that everyone can actually work in concert, like Chris was saying. A more comprehensive, cohesive approach to delivery and deployment. >> All right, well, wrapping up here, I want to just get one final comment from you guys, if you don't mind. What does supercloud look like in five years? What's the Nirvana, what's the steady state of supercloud in five to 10 years? Or say 10 years, make it easier. (crosstalk) Five to 10 years. Chris, we'll start with you. >> Wow. >> Supercloud, what's it look like? >> Geez. A magic pane, a single pane of glass. (laughs) >> Yeah, I think- >> Single glass of pain. >> Yeah, a single glass of pain. Thank you. You stole my line. Well, not mine, but that's the one I was going to use. Yeah, I think what is really fascinating is ultimately, to answer that question, I would reflect on market consolidation and market dynamics that happens even in the SaaS space. So we will see SaaS companies combining in focal areas to be able to leverage the positions, let's say, in the identity space that somebody has built to provide a set of compelling services that help abstract that identity problem or that security problem or that instrumentation and observability problem. So take your favorite vendors today. I think what we'll end up seeing is more consolidation in SaaS offerings that run on top of infrastructure of the service offerings to where a supercloud might look like something I described before. You have the combination of your favorite interoperable identity, observability, security, orchestration platforms run across them. They're sold as a stack, whether it be co-branded by an enterprise vendor that sells all of that and manages it for you or not. But I do think that... You talked about, I think you said, "Is this an innovator's dilemma?" No, I think it's an integrator's dilemma, as it has always ultimately been. As soon as you get from Genesis to Bespoke Build to product to then commoditization, the cycle starts anew. And I think we've gotten past commoditization, and we're looking at niche areas. So I see just the evolution, not necessarily a revolution, of what we're dealing with today as we see more consolidation in the marketplace. >> Lori, what's your take? Five years, 10 years, what does supercloud look like? >> Part of me wants to take the pie in the sky unicorn approach. "No, it will be beautiful. "One button, and things will happen," but I've seen this cycle many times before, and that's not going to happen. And I think Chris has got it pretty close to what I see already evolving. Those different kinds of super services, basically. And that's really what we're talking about. We call them SaaS, but they're... X is a service. Everything is a service, and it's really a supercloud that can run anywhere, but it presents a different interface, because, well, it's easier. And I think that's where we're going to go, and that's just going to get more refined. And yes, a lot of consolidation, especially on the observability side, but that's also starting to consume the security side, which is really interesting to watch. So that could be a little different supercloud coming on there that's really focused on specific types of security, at least, that we'll layer across, and then we'll just hook them all together. It's an API first world, and it seems like that's going to be our standard for the next while of how we integrate everything. So superclouds or APIs. >> Awesome. Adrian... Adrian, take us home. >> Yeah, sure. >> What's your- I think, and just picking up on Lori's point that these are web services, meaning that you can just call them from anywhere, they don't have to run everything in one place, they can stitch it together, and that's really meant... It's somewhat composable. So in practice, people are going to be composable. Can they compose their applications on multiple platforms? But I think the interesting thing here is what the vendors do, and what I'm seeing is vendors running software on other vendors. So you have Google building platforms that, then, they will support on AWS and Azure and vice versa. You've got AWS's distro of Kubernetes, which they now give you as a distro so you can run it on another platform. So I think that trend's going to continue, and it's going to be, possibly, you pick, say, an AWS or a Google software stack, but you don't run it all on AWS, you run it in multiple places. Yeah, and then the other thing is the third tier, second, third tier vendors, like, I mean, what's IBM doing? I think in five years time, IBM is going to be a SaaS vendor running on the other clouds. I mean, they're already halfway there. To be a bit more controversial, I guess it's always fun to... Like I don't work for a corporate entity now. No one tells me what I can say. >> Bring it on. >> How long can Google keep losing a billion dollars a quarter? They've either got to figure out how to make money out of this thing, or they'll end up basically being a software stack on another cloud platform as their, likely, actual way they can make money on it. Because you've got to... And maybe Oracle, is that a viable cloud platform that... You've got to get to some level of viability. And I think the second, third tier of vendors in five, 10 years are going to be running on the primary platform. And I think, just the other final thing that's really driving this right now. If you try and place an order right now for a piece of equipment for your data center, key pieces of equipment are a year out. It's like trying to buy a new fridge from like Sub-Zero or something like that. And it's like, it's a year. You got to wait for these things. Any high quality piece of equipment. So you go to deploy in your data center, and it's like, "I can't get stuff in my data center. "Like, the key pieces I need, I can't deploy a whole system. "We didn't get bits and pieces of it." So people are going to be cobbling together, or they're going, "No, this is going to cloud, because the cloud vendors "have a much stronger supply chain to just be able "to give you the system you need. "They've got the capacity." So I think we're going to see some pandemic and supply chain induced forced cloud migrations, just because you can't build stuff anymore outside the- >> We got to accelerate supercloud, 'cause they have the supply. They are the chain. >> That's super smart. That's the benefit of going last. So I'm going to scoop in real quick. I can't believe we can call this "Web3 Supercloud," because none of us said "Web3." Don't forget DAO. (crosstalk) (indistinct) You have blockchain, blockchain superclouds. I mean, there's some very interesting distributed computing stuff there, but we'll have to do- >> (crosstalk) We're going to call that the "Cubeverse." The "Cubeverse" is coming. >> Oh, the "Cubeverse." All right. >> We will be... >> That's very meta. >> In the metaverse, Cubeverse soon. >> "Stupor cloud," perhaps. But anyway, great points, Adrian and Lori. Loved it. >> Chris, great to see you. Adrian, Lori, thanks for coming on. We've known each other for a long time. You guys are part of the cloud-erati, the group that has been in there from day one, and watched it evolve, and you get the scar tissue to prove it, and the experience. So thank you so much for sharing your commentary. We'll roll this up and make it open to everybody as additional content. We'll call this the "outtakes," the longer version. But really appreciate your time, thank you. >> Thank you. >> Thanks so much. >> Okay, we'll be back with more "Supercloud 22" right after this. (bright upbeat music)

>>Yeah. Hello and welcome to the Cuba's International Women's Showcase, featuring International Women's Day. I'm John, host of the Kiwi here in California. Great remote guest. She's amazing founder and C e O of Cuba, and great to see you. Okay, thanks for coming on. Um, good to see you. >>You as well. Always a pleasure. You >>know, International Women's Day is the big celebration. We're doing a lot of interviews with great people making things happen, moving and shaking things. Um, but every day, International Women's Day, As far as I'm concerned, it's happening all around the world. But these are stories of innovation, the stories of changes, the stories of transformation for the better. You've been doing a lot of things. Um and I want to get into that. But let's start with your background. Tell us a bit about who you are and what you've got going on. >>Yeah, my background is a little strange. I used to be a maritime archaeologists. So dumb shit breaks for a little bit. That was amazing. I always just It's only partial just because it's actually a bit of truth to it, that learning how to, you know, handle things at depth really does train you to be a C e o. Because you learn to control your breath and and focus on the things that matter and not be so reactive because it's three activity that will panic that will kill you. Uh, always knowing how to reframe. Return to the basics. Um, there's a really good things to hold on to, even in the world of business. Right? So I at some point, ended up doing doing a lot of things. Largely business development, following my time diving and amazing woman. Um, another woman for International Women's Day named Doctor who was a biotech entrepreneur from Japan, stepping down as her role at the helm of her company. Um, and she wanted to launch a space for a young innovators from around the world who are doing amazing work to tackle this very complex challenges we all know exist, um, and figure out a way to give them time and space to do their best work and pursue their their highest visions for change. We decided that we would focus on for-profit companies largely who were using sustainable, scalable business models to pursue both profit and purpose. Um creating a virtuous cycle between the return of money to a company and putting that into to go even further and faster towards, um, solving a problem. Um, so we now have companies over 200 companies from around the world that we have helped support tackling every single, sustainable development goal. Um, and I'm proud to say, you know, particularly related to the subject that fifty-nine percent of our companies have a woman founder or CO-FOUNDER. Um, and 69% of the founder of color. Um, so we're working with entrepreneurs from every every area of the world. Many approximate to the problem that they are trying to solve, so they intimately understand it. Um, and they're doing amazing things. >>Yeah, you can help the great mission. You have a lot of other things going on your helping women encouraging them to your career in the tech sector. Um, good statistics could be better, right? Is higher and better. So, um, what are you guys doing? What, you specifically to help and encourage women to forge their career and tech? >>Yeah. I mean, look, the good news is I do think that it's getting better. I particularly think that we will see the adventure is improving. Um, it takes a while because the companies that have been funded up until now are still working in the biggest amount in the later stages. So I think that percentage hasn't been shifting. But I have to believe that that's a bit of an illusion, and then a couple of years, we're going to start to sea level out. But you know as well as I do that they're pretty poultry statistics in terms of the amount of venture that women like cos. Capture, Um, and the other ways that women are doubted, um, in terms of their ability and potential. Um, so we we love to work with any underrepresented group of entrepreneurs, and there's ways that we do that whether it's helping them sort of find their power and hold space and be confident. And, um, you know, be able to pitch to any room, talk to any investor, talk to any customer but also working to be directed about some of the systemic challenges, both in terms of talking to existing investors and trying to educate them to see the opportunities that they're missing because there is a an economic imperative to them understanding what they're missing. Um, but there's also some things that we're doing in-house to make sure that we're also helping to close capital gaps for all our entrepreneurs. So we actually now have a suite of three capital mechanisms that are entrepreneurs can access on the back end of our incubator, a microphone fund, which is very quick turnaround, small amounts of capital for entrepreneurs who existing opportunities owns, which is a tax destination. Just this in the U. S. But that's meant to be deployed so that they can access capital towards revenue without credit checks, collateral being put up, a slow moving pace of banks and C. D. S s. It's particularly useful for people who may not raise venture. And it's useful for, uh, you know, people who maybe don't have that friends and family check that they can expect similar. We've got a great angel network who look at the best impact deals from around the world. Um, and it doesn't have to be a housing company, just a great venture that's pursuing impact on profit. Um, and then lastly, we're just about to announce that we have a fund of our own on the back end of our incubator that funds only healthy and companies. Um, it's an early stage fund. Um, but watch this space because our pipeline is just increasing your every year. We used to sort of just 16 companies here. Now, we're serving 60 this year, so, um, yeah, it's really exciting. Um, and so obviously, it's really great that, you know, we're going to be able to help scale the impact that we want to see. Uh, ideally a lot. A lot faster. >>Well, you definitely taking control. I remember when we had a few years ago. I think four years ago, you just thinking about getting going and going now with great tailwind. Um, >>and the diversity >>of sources of capital as well as diversity of firms is increasing. That's helping, uh, that we're seeing, but you're also got the back end fun for the housing companies. But also, you've been involved in we capital for a long time. Can you talk about that? Because that's a specific supporting women entrepreneurs initiative. Um, yeah. What's up with capital share? That >>was That was another venture that I-i embarked on with such coz. Um as well as Sheila Johnson and Jonny Adam, Person who runs Rethink Impact. We capital is a group of about 16 women that I pulled together women investors to invest through rethink impact, which is another fun that is looking for impact businesses but predominantly looking for those businesses that are led by women. So this investment group is women supporting women. Um, through the use of deployment of capital, um, they're doing amazingly well. They've had some really stunning news recently that I'll let you dig up. >>I'll definitely thanks for the lead there. I'm gonna go jump on that story. >>Yeah, >>the Okay, Thanks for that lead on that trend, though in Silicon Valley and certainly in other areas that are hot like New York, Boston and D. C. Where you're at, um, you're seeing now multiple years in almost a decade in of the pioneers of these women, only funds or women only firms and your investment. Um, and it's starting to increase to under all underrepresented minorities and entrepreneurs. Right? So take us through how you see that because it's just getting more popular. Is that going to continue to accelerate in your mind? Are their networks of networks. They cross pollinating. >>Yeah, I think you know, it's It's I'm glad to see it. And, you know, it's been a long time coming. I think you know, I think we all look forward to a future where it's not necessary. Um, and you know, funds. Just invest in everyone Until then, making sure that we have specific pools of capital allocated to ensure that that, you know, those entrepreneurs who have not always been equally represented get to pursue their ideas not just because they deserve to pursue their ideas, but because the world needs their ideas. Right. And as I mentioned, there is a business imperative, right? We've got lots of examples of businesses like banks that you wouldn't have gotten a shot just because the investors just didn't understand the opportunity. Um, and I think that's normal. That's human. It happens to everyone. You are successful as an investor largely because you recognize patterns. And if something is, you know, outside of your life experience, you are not going to identify it. So it's very important that we create different kinds of capital run by different types of people. Um, and, uh, and you know. I know lots of investors have every type that are investing in these funds because they recognize that, you know, perhaps the highest growth potential is gonna come out of these, you know, particular kind of funds, which is really exciting. >>That's super important, because half the world is women, and that's just like the population is inspired by many new ventures. And that's super exciting trend. I wanna ask you about your other areas of doing a lot of work in the queue has been to buy multiple times, um, initially reporting on a region out there, and that's certainly isn't important part of the world. Um, you've got a lot of good news going on there. Can you share what's going on with, uh, the social entrepreneurship going on in Bahrain around the region? >>Yeah, I'm happy to. We we've actually been so privileged to work with a W S for a very long time. Almost since the start of the incubator they've supported are entrepreneurs, all of our entrepreneurs with access to cloud credits and services. Um, and we've sort of double down with a W S in the last couple of years in areas where We both want to create an uplift, um, for small businesses and rapidly growing tax solutions to these these social environmental problems. We see. So there's been an excellent partner to do that. And one of the areas we did in the water was with rain, particularly with women, tech startups, women tech startups in Bahrain. Yeah, we did that last year. We had an amazing group of women over in D. C. Um, and we continue to support them. One of them is actually in the process of raising. I think she just closed her seed round recently. And that's why for, um, al yet, um, and she created playbook, which is an amazing, uh, platform for women to take master classes and network and really sort of level up, as one says, Um, but also, um, the mall of work. Um uh, just really talented women over in Bahrain, um, pushing the envelope and all sorts of directions, and it was wonderful to get the opportunity to work with them. Um, that has now spawned another set of programs serving entrepreneurs in the Middle East in North Africa. They were also working on with us as well as the U S. State Department. Um, so we're going to be working for the next two years with entrepreneurs to help our recovery from covid. Um, in China. Um, and then I'm also proud to say that we're working with a W s in South Africa because there is just an extraordinary energy, you know, in the continent, Um, and some amazing entrepreneurial minds working on, you know, the many problems and opportunities that they're facing and recognizing. Um So we're supporting, you know, companies that are working on finding, um, skilled refugees to be able to help them resettle and use their talents and make money. Um, sadly, are very relevant company now with what's going on in Ukraine. Um, but also, uh, zombie and satellite company, um, companies that are preventing food, food waste by providing, um, solar-powered refrigerators to rural areas in South Africa. Um, so a lot of, um, you know, just incredible talent and ideas that we're seeing globally. Um, and happy to be doubling down on that with the help of a W s. >>That's awesome. Yeah, following the work when we met in D. C. And again, you always had this international view um it's International Women's Day. It's not North America >>Women's Day. It's >>International Women's Day. Can you share your thoughts on how that landscape is changing outside the U. S. For example, and around the world and how the international peace is important and you mentioned pattern matching? Um, you also, when you see patterns, they become trends. What do you see forming that have been that that are locked in on the U. C they're locked in on that are happening that are driving. What are some of those trends that you see on the international side that's evolving? >>Yeah. You know, I think the wonderful opportunity with the Internet and social media is that, you know, both, uh, we can be more transparent about areas for improvement and put a little pressure where maybe things are moving fast enough. We've all seen the power of that, Um, the other, um, you know, things that certainly in countries where women maybe as free to move and operate, they can still acquire skills education they can set up cos they can do so so much. Um, you know, through these amazing technologies that we now have at our disposal growing an amazing rates. Um, they can connect via zoom. Right? I think that while the pandemic definitely set women back and we should acknowledge that, um, uh, the things that the pandemic perhaps helped us to exponentially scale will move women forward. And perhaps that's the target to hang on to, to feel optimistic about where we're headed. >>And also, there's a lot of problems to solve. And I think one of the things we're seeing you mentioned the Ukraine situation. You're seeing the geopolitical landscape changing radically with technology driving a lot of value. So with problems comes opportunities. Um, innovation plays a big role. Can you share some of the successful stories that you were inspired by that you've seen, um, in the past couple of years. And as you look forward, what What some of those innovation stories look like? And what are you inspired by? >>Yeah. I mean, there's so, so many. Um, you know, we just, uh, had a couple of entrepreneurs, and just the last year, Um, you know, after I think everyone sort of took an initial breath with the pandemic, They realize that they either had an opportunity or they had a problem to solve to your point. Um, and they did that well or not. And or some of them, you know, just didn't didn't have any more cards to play and had to really pivot. Um, it was really interesting to see how everyone handled handled that particular moment in time. One company that I think of is everywhere. Um, and she had created a wearable device that you can just put on your ear. It looks like an earring right at the top of your ear. Um, and it was for her for herself because she suffered from pulmonary complications. And, uh, without more discreet wearable, you know, had to wear a huge device and look around and oxygen tank and, you know, just to sort of have a good quality of life. Um, it turns out, obviously, during covid, that is a very useful item, not just for patients suffering from covid and wanting to know what their oxygen levels were doing, but also potentially athletics. So, um, she's really been able to double down as a result of the trends from the pandemic. Um, and I'm really proud of part of her. And that's actually where another great one that we just just came through. Our last 15 is Maya. Um, and she had a brick and mortar store. Um, uh, called Cherry Blossom. Intimate where she helped women have an enjoyable experience finding, uh, and fitting bras post mastectomy to include sort of, you know, the necessary, um, prosthetics and things like that. Um, she even made it so that you could go with your friends who haven't had a mistake, and she could also find some lovely luxury. Um, but the pandemic meant that that experience was sort of off the table. Um, and what they did was she decided to make it a technological one. So now she's she's essentially will be part of it. You can, you know, go to my, um, online. And you can, um, you know, order, uh, measure yourself, work with a specialist, all online, get a few different options, figure out the one that's perfect for you and the rest back. Um, and I don't think without the pandemic, that would not have happened. So she's now able to serve exponentially more. Um, you know, women who deserve to feel like themselves post it to me. >>That's also a model and inspirational. I have to ask you for the young women out there watching. What advice would you share with them as they navigate into a world that's changing and evolving and getting better with other women, mentors and entrepreneurs and or just an ecosystem of community? What advice would you give them as they step into the world and have to engage and experience life? >>Yeah, gosh, part of me always wants to resist that they don't listen to anyone to do you follow your heart, follow your gut, or at least be careful who you listen to because a lot of people will want to give you advice. I would >>say, Uh, that's good advice. Don't take my advice. Well, you've been a great leader. Love the work, you're doing it and I'll say N D. C. But all around the world and again, there's so much change going on with innovation. I mean, just the advances in technology across the board, from with machine learning and AI from linguistics and understanding. And I think we're going to be a bigger community. Your thoughts on as you see community organically becoming a big part of how people are engaging. What's your what's your view As you look out across the landscape, communities becoming a big part of tribes. What's your vision on how the role of communities place? >>You know, we we actually do you think a lot about community and healthy. And we say that are you know, alchemy really is providing space, you know, physical and mental space to think, um, access access to capital access to networks, Um, community, Um, and the community piece is very, very important. Are entrepreneurs leave us like the number one thing that they miss is being among like-minded, um, you know, slightly slightly crazy audacious people. Um, and I often joked that we're building a kind army because it is, you know, it's people who want to do it differently if people want to do it with integrity. Is people who are in it for a very different motivations than just money. Um, and, you know, you start to feel the power of that group together and its entirety and what that might look like as as a community solving global problems. Um, and it really is inspiring. Um, I do think that people are starving for FaceTime and people time, real human time after the pandemic, I think they won't go away. It's a great tool, but we all want a little bit of that, and I will mention just along those lines. And if you don't mind a quick plug for an event that we're having March 16, Um, also in partnership with a W s called Build her relevant to International Women's Day as well. People can, either. If they're in the city, they can come in person. But we also have a virtual program, and we'll be listening to some of the most inspiring. Women leaders and entrepreneurs both in government and also the private sector share their knowledge on the side of the pandemic for for, you know, the next tribal group of women entrepreneurs and leaders. >>That's great. Well, you are on our website for sure. >>Thank you. Thank you. Appreciate it. >>And we love the fact that you're in our community as well. Doing great work. Thanks for spending time with the Cube and on International Women's Day celebration. Thanks for coming on and sharing. >>Thank you, John. >>Okay. The Cube International showcase Women's Day, featuring some great guests all around the world, Not just in the U S. But all over the world. I'm your host. Thanks for watching. Yeah, Yeah, yeah, hm, Yeah.

>>Individuals create developers, translate ideas to code, to create great applications and great applications. Touch everyone. A Docker. We know that collaboration is key to your innovation sharing ideas, working together. Launching the most secure applications. Docker is with you wherever your team innovates, whether it be robots or autonomous cars, we're doing research to save lives during a pandemic, revolutionizing, how to buy and sell goods online, or even going into the unknown frontiers of space. Docker is launching innovation everywhere. Join us on the journey to build, share, run the future. >>Hello and welcome to Docker con 2021. We're incredibly excited to have more than 80,000 of you join us today from all over the world. As it was last year, this year at DockerCon is 100% virtual and 100% free. So as to enable as many community members as possible to join us now, 100%. Virtual is also an acknowledgement of the continuing global pandemic in particular, the ongoing tragedies in India and Brazil, the Docker community is a global one. And on behalf of all Dr. Khan attendees, we are donating $10,000 to UNICEF support efforts to fight the virus in those countries. Now, even in those regions of the world where the pandemic is being brought under control, virtual first is the new normal. It's been a challenging transition. This includes our team here at Docker. And we know from talking with many of you that you and your developer teams are challenged by this as well. So to help application development teams better collaborate and ship faster, we've been working on some powerful new features and we thought it would be fun to start off with a demo of those. How about it? Want to have a look? All right. Then no further delay. I'd like to introduce Youi Cal and Ben, gosh, over to you and Ben >>Morning, Ben, thanks for jumping on real quick. >>Have you seen the email from Scott? The one about updates and the docs landing page Smith, the doc combat and more prominence. >>Yeah. I've got something working on my local machine. I haven't committed anything yet. I was thinking we could try, um, that new Docker dev environments feature. >>Yeah, that's cool. So if you hit the share button, what I should do is it will take all of your code and the dependencies and the image you're basing it on and wrap that up as one image for me. And I can then just monitor all my machines that have been one click, like, and then have it side by side, along with the changes I've been looking at as well, because I was also having a bit of a look and then I can really see how it differs to what I'm doing. Maybe I can combine it to do the best of both worlds. >>Sounds good. Uh, let me get that over to you, >>Wilson. Yeah. If you pay with the image name, I'll get that started up. >>All right. Sen send it over >>Cheesy. Okay, great. Let's have a quick look at what you he was doing then. So I've been messing around similar to do with the batter. I've got movie at the top here and I think it looks pretty cool. Let's just grab that image from you. Pick out that started on a dev environment. What this is doing. It's just going to grab the image down, which you can take all of the code, the dependencies only get brunches working on and I'll get that opened up in my idea. Ready to use. It's a here close. We can see our environment as my Molly image, just coming down there and I've got my new idea. >>We'll load this up and it'll just connect to my dev environment. There we go. It's connected to the container. So we're working all in the container here and now give it a moment. What we'll do is we'll see what changes you've been making as well on the code. So it's like she's been working on a landing page as well, and it looks like she's been changing the banner as well. So let's get this running. Let's see what she's actually doing and how it looks. We'll set up our checklist and then we'll see how that works. >>Great. So that's now rolling. So let's just have a look at what you use doing what changes she had made. Compare those to mine just jumped back into my dev container UI, see that I've got both of those running side by side with my changes and news changes. Okay. So she's put Molly up there rather than mobi or somebody had the same idea. So I think in a way I can make us both happy. So if we just jumped back into what we'll do, just add Molly and Moby and here I'll save that. And what we can see is, cause I'm just working within the container rather than having to do sort of rebuild of everything or serve, or just reload my content. No, that's straight the page. So what I can then do is I can come up with my browser here. Once that's all refreshed, refresh the page once hopefully, maybe twice, we should then be able to see your refresh it or should be able to see that we get Malia mobi come up. So there we go, got Molly mobi. So what we'll do now is we'll describe that state. It sends us our image and then we'll just create one of those to share with URI or share. And we'll get a link for that. I guess we'll send that back over to you. >>So I've had a look at what you were doing and I'm actually going to change. I think that might work for both of us. I wondered if you could take a look at it. If I send it over. >>Sounds good. Let me grab the link. >>Yeah, it's a dev environment link again. So if you just open that back in the doc dashboard, it should be able to open up the code that I've changed and then just run it in the same way you normally do. And that shouldn't interrupt what you're already working on because there'll be able to run side by side with your other brunch. You already got, >>Got it. Got it. Loading here. Well, that's great. It's Molly and movie together. I love it. I think we should ship it. >>Awesome. I guess it's chip it and get on with the rest of.com. Wasn't that cool. Thank you Joey. Thanks Ben. Everyone we'll have more of this later in the keynote. So stay tuned. Let's say earlier, we've all been challenged by this past year, whether the COVID pandemic, the complete evaporation of customer demand in many industries, unemployment or business bankruptcies, we all been touched in some way. And yet, even to miss these tragedies last year, we saw multiple sources of hope and inspiration. For example, in response to COVID we saw global communities, including the tech community rapidly innovate solutions for analyzing the spread of the virus, sequencing its genes and visualizing infection rates. In fact, if all in teams collaborating on solutions for COVID have created more than 1,400 publicly shareable images on Docker hub. As another example, we all witnessed the historic landing and exploration of Mars by the perseverance Rover and its ingenuity drone. >>Now what's common in these examples, these innovative and ambitious accomplishments were made possible not by any single individual, but by teams of individuals collaborating together. The power of teams is why we've made development teams central to Docker's mission to build tools and content development teams love to help them get their ideas from code to cloud as quickly as possible. One of the frictions we've seen that can slow down to them in teams is that the path from code to cloud can be a confusing one, riddle with multiple point products, tools, and images that need to be integrated and maintained an automated pipeline in order for teams to be productive. That's why a year and a half ago we refocused Docker on helping development teams make sense of all this specifically, our goal is to provide development teams with the trusted content, the sharing capabilities and the pipeline integrations with best of breed third-party tools to help teams ship faster in short, to provide a collaborative application development platform. >>Everything a team needs to build. Sharon run create applications. Now, as I noted earlier, it's been a challenging year for everyone on our planet and has been similar for us here at Docker. Our team had to adapt to working from home local lockdowns caused by the pandemic and other challenges. And despite all this together with our community and ecosystem partners, we accomplished many exciting milestones. For example, in open source together with the community and our partners, we open sourced or made major contributions to many projects, including OCI distribution and the composed plugins building on these open source projects. We had powerful new capabilities to the Docker product, both free and subscription. For example, support for WSL two and apple, Silicon and Docker, desktop and vulnerability scanning audit logs and image management and Docker hub. >>And finally delivering an easy to use well-integrated development experience with best of breed tools and content is only possible through close collaboration with our ecosystem partners. For example, this last year we had over 100 commercialized fees, join our Docker verified publisher program and over 200 open source projects, join our Docker sponsored open source program. As a result of these efforts, we've seen some exciting growth in the Docker community in the 12 months since last year's Docker con for example, the number of registered developers grew 80% to over 8 million. These developers created many new images increasing the total by 56% to almost 11 million. And the images in all these repositories were pulled by more than 13 million monthly active IP addresses totaling 13 billion pulls a month. Now while the growth is exciting by Docker, we're even more excited about the stories we hear from you and your development teams about how you're using Docker and its impact on your businesses. For example, cancer researchers and their bioinformatics development team at the Washington university school of medicine needed a way to quickly analyze their clinical trial results and then share the models, the data and the analysis with other researchers they use Docker because it gives them the ease of use choice of pipeline tools and speed of sharing so critical to their research. And most importantly to the lives of their patients stay tuned for another powerful customer story later in the keynote from Matt fall, VP of engineering at Oracle insights. >>So with this last year behind us, what's next for Docker, but challenge you this last year of force changes in how development teams work, but we felt for years to come. And what we've learned in our discussions with you will have long lasting impact on our product roadmap. One of the biggest takeaways from those discussions that you and your development team want to be quicker to adapt, to changes in your environment so you can ship faster. So what is DACA doing to help with this first trusted content to own the teams that can focus their energies on what is unique to their businesses and spend as little time as possible on undifferentiated work are able to adapt more quickly and ship faster in order to do so. They need to be able to trust other components that make up their app together with our partners. >>Docker is doubling down and providing development teams with trusted content and the tools they need to use it in their applications. Second, remote collaboration on a development team, asking a coworker to take a look at your code used to be as easy as swiveling their chair around, but given what's happened in the last year, that's no longer the case. So as you even been hinted in the demo at the beginning, you'll see us deliver more capabilities for remote collaboration within a development team. And we're enabling development team to quickly adapt to any team configuration all on prem hybrid, all work from home, helping them remain productive and focused on shipping third ecosystem integrations, those development teams that can quickly take advantage of innovations throughout the ecosystem. Instead of getting locked into a single monolithic pipeline, there'll be the ones able to deliver amps, which impact their businesses faster. >>So together with our ecosystem partners, we are investing in more integrations with best of breed tools, right? Integrated automated app pipelines. Furthermore, we'll be writing more public API APIs and SDKs to enable ecosystem partners and development teams to roll their own integrations. We'll be sharing more details about remote collaboration and ecosystem integrations. Later in the keynote, I'd like to take a moment to share with Docker and our partners are doing for trusted content, providing development teams, access to content. They can trust, allows them to focus their coding efforts on what's unique and differentiated to that end Docker and our partners are bringing more and more trusted content to Docker hub Docker official images are 160 images of popular upstream open source projects that serve as foundational building blocks for any application. These include operating systems, programming, languages, databases, and more. Furthermore, these are updated patch scan and certified frequently. So I said, no image is older than 30 days. >>Docker verified publisher images are published by more than 100 commercialized feeds. The image Rebos are explicitly designated verify. So the developers searching for components for their app know that the ISV is actively maintaining the image. Docker sponsored open source projects announced late last year features images for more than 200 open source communities. Docker sponsors these communities through providing free storage and networking resources and offering their community members unrestricted access repos for businesses allow businesses to update and share their apps privately within their organizations using role-based access control and user authentication. No, and finally, public repos for communities enable community projects to be freely shared with anonymous and authenticated users alike. >>And for all these different types of content, we provide services for both development teams and ISP, for example, vulnerability scanning and digital signing for enhanced security search and filtering for discoverability packaging and updating services and analytics about how these products are being used. All this trusted content, we make available to develop teams for them directly to discover poll and integrate into their applications. Our goal is to meet development teams where they live. So for those organizations that prefer to manage their internal distribution of trusted content, we've collaborated with leading container registry partners. We announced our partnership with J frog late last year. And today we're very pleased to announce our partnerships with Amazon and Miranda's for providing an integrated seamless experience for joint for our joint customers. Lastly, the container images themselves and this end to end flow are built on open industry standards, which provided all the teams with flexibility and choice trusted content enables development teams to rapidly build. >>As I let them focus on their unique differentiated features and use trusted building blocks for the rest. We'll be talking more about trusted content as well as remote collaboration and ecosystem integrations later in the keynote. Now ecosystem partners are not only integral to the Docker experience for development teams. They're also integral to a great DockerCon experience, but please join me in thanking our Dr. Kent on sponsors and checking out their talks throughout the day. I also want to thank some others first up Docker team. Like all of you this last year has been extremely challenging for us, but the Docker team rose to the challenge and worked together to continue shipping great product, the Docker community of captains, community leaders, and contributors with your welcoming newcomers, enthusiasm for Docker and open exchanges of best practices and ideas talker, wouldn't be Docker without you. And finally, our development team customers. >>You trust us to help you build apps. Your businesses rely on. We don't take that trust for granted. Thank you. In closing, we often hear about the tenant's developer capable of great individual feeds that can transform project. But I wonder if we, as an industry have perhaps gotten this wrong by putting so much emphasis on weight, on the individual as discussed at the beginning, great accomplishments like innovative responses to COVID-19 like landing on Mars are more often the results of individuals collaborating together as a team, which is why our mission here at Docker is delivered tools and content developers love to help their team succeed and become 10 X teams. Thanks again for joining us, we look forward to having a great DockerCon with you today, as well as a great year ahead of us. Thanks and be well. >>Hi, I'm Dana Lawson, VP of engineering here at get hub. And my job is to enable this rich interconnected community of builders and makers to build even more and hopefully have a great time doing it in order to enable the best platform for developers, which I know is something we are all passionate about. We need to partner across the ecosystem to ensure that developers can have a great experience across get hub and all the tools that they want to use. No matter what they are. My team works to build the tools and relationships to make that possible. I am so excited to join Scott on this virtual stage to talk about increasing developer velocity. So let's dive in now, I know this may be hard for some of you to believe, but as a former CIS admin, some 21 years ago, working on sense spark workstations, we've come such a long way for random scripts and desperate systems that we've stitched together to this whole inclusive developer workflow experience being a CIS admin. >>Then you were just one piece of the siloed experience, but I didn't want to just push code to production. So I created scripts that did it for me. I taught myself how to code. I was the model lazy CIS admin that got dangerous and having pushed a little too far. I realized that working in production and building features is really a team sport that we had the opportunity, all of us to be customer obsessed today. As developers, we can go beyond the traditional dev ops mindset. We can really focus on adding value to the customer experience by ensuring that we have work that contributes to increasing uptime via and SLS all while being agile and productive. We get there. When we move from a pass the Baton system to now having an interconnected developer workflow that increases velocity in every part of the cycle, we get to work better and smarter. >>And honestly, in a way that is so much more enjoyable because we automate away all the mundane and manual and boring tasks. So we get to focus on what really matters shipping, the things that humans get to use and love. Docker has been a big part of enabling this transformation. 10, 20 years ago, we had Tomcat containers, which are not Docker containers. And for y'all hearing this the first time go Google it. But that was the way we built our applications. We had to segment them on the server and give them resources. Today. We have Docker containers, these little mini Oasys and Docker images. You can do it multiple times in an orchestrated manner with the power of actions enabled and Docker. It's just so incredible what you can do. And by the way, I'm showing you actions in Docker, which I hope you use because both are great and free for open source. >>But the key takeaway is really the workflow and the automation, which you certainly can do with other tools. Okay, I'm going to show you just how easy this is, because believe me, if this is something I can learn and do anybody out there can, and in this demo, I'll show you about the basic components needed to create and use a package, Docker container actions. And like I said, you won't believe how awesome the combination of Docker and actions is because you can enable your workflow to do no matter what you're trying to do in this super baby example. We're so small. You could take like 10 seconds. Like I am here creating an action due to a simple task, like pushing a message to your logs. And the cool thing is you can use it on any the bit on this one. Like I said, we're going to use push. >>You can do, uh, even to order a pizza every time you roll into production, if you wanted, but at get hub, that'd be a lot of pizzas. And the funny thing is somebody out there is actually tried this and written that action. If you haven't used Docker and actions together, check out the docs on either get hub or Docker to get you started. And a huge shout out to all those doc writers out there. I built this demo today using those instructions. And if I can do it, I know you can too, but enough yapping let's get started to save some time. And since a lot of us are Docker and get hub nerds, I've already created a repo with a Docker file. So we're going to skip that step. Next. I'm going to create an action's Yammel file. And if you don't Yammer, you know, actions, the metadata defines my important log stuff to capture and the input and my time out per parameter to pass and puts to the Docker container, get up a build image from your Docker file and run the commands in a new container. >>Using the Sigma image. The cool thing is, is you can use any Docker image in any language for your actions. It doesn't matter if it's go or whatever in today's I'm going to use a shell script and an input variable to print my important log stuff to file. And like I said, you know me, I love me some. So let's see this action in a workflow. When an action is in a private repo, like the one I demonstrating today, the action can only be used in workflows in the same repository, but public actions can be used by workflows in any repository. So unfortunately you won't get access to the super awesome action, but don't worry in the Guild marketplace, there are over 8,000 actions available, especially the most important one, that pizza action. So go try it out. Now you can do this in a couple of ways, whether you're doing it in your preferred ID or for today's demo, I'm just going to use the gooey. I'm going to navigate to my actions tab as I've done here. And I'm going to in my workflow, select new work, hello, probably load some workflows to Claire to get you started, but I'm using the one I've copied. Like I said, the lazy developer I am in. I'm going to replace it with my action. >>That's it. So now we're going to go and we're going to start our commitment new file. Now, if we go over to our actions tab, we can see the workflow in progress in my repository. I just click the actions tab. And because they wrote the actions on push, we can watch the visualization under jobs and click the job to see the important stuff we're logging in the input stamp in the printed log. And we'll just wait for this to run. Hello, Mona and boom. Just like that. It runs automatically within our action. We told it to go run as soon as the files updated because we're doing it on push merge. That's right. Folks in just a few minutes, I built an action that writes an entry to a log file every time I push. So I don't have to do it manually. In essence, with automation, you can be kind to your future self and save time and effort to focus on what really matters. >>Imagine what I could do with even a little more time, probably order all y'all pieces. That is the power of the interconnected workflow. And it's amazing. And I hope you all go try it out, but why do we care about all of that? Just like in the demo, I took a manual task with both tape, which both takes time and it's easy to forget and automated it. So I don't have to think about it. And it's executed every time consistently. That means less time for me to worry about my human errors and mistakes, and more time to focus on actually building the cool stuff that people want. Obviously, automation, developer productivity, but what is even more important to me is the developer happiness tools like BS, code actions, Docker, Heroku, and many others reduce manual work, which allows us to focus on building things that are awesome. >>And to get into that wonderful state that we call flow. According to research by UC Irvine in Humboldt university in Germany, it takes an average of 23 minutes to enter optimal creative state. What we call the flow or to reenter it after distraction like your dog on your office store. So staying in flow is so critical to developer productivity and as a developer, it just feels good to be cranking away at something with deep focus. I certainly know that I love that feeling intuitive collaboration and automation features we built in to get hub help developer, Sam flow, allowing you and your team to do so much more, to bring the benefits of automation into perspective in our annual October's report by Dr. Nicole, Forsgren. One of my buddies here at get hub, took a look at the developer productivity in the stork year. You know what we found? >>We found that public GitHub repositories that use the Automational pull requests, merge those pull requests. 1.2 times faster. And the number of pooled merged pull requests increased by 1.3 times, that is 34% more poor requests merged. And other words, automation can con can dramatically increase, but the speed and quantity of work completed in any role, just like an open source development, you'll work more efficiently with greater impact when you invest the bulk of your time in the work that adds the most value and eliminate or outsource the rest because you don't need to do it, make the machines by elaborate by leveraging automation in their workflows teams, minimize manual work and reclaim that time for innovation and maintain that state of flow with development and collaboration. More importantly, their work is more enjoyable because they're not wasting the time doing the things that the machines or robots can do for them. >>And I remember what I said at the beginning. Many of us want to be efficient, heck even lazy. So why would I spend my time doing something I can automate? Now you can read more about this research behind the art behind this at October set, get hub.com, which also includes a lot of other cool info about the open source ecosystem and how it's evolving. Speaking of the open source ecosystem we at get hub are so honored to be the home of more than 65 million developers who build software together for everywhere across the globe. Today, we're seeing software development taking shape as the world's largest team sport, where development teams collaborate, build and ship products. It's no longer a solo effort like it was for me. You don't have to take my word for it. Check out this globe. This globe shows real data. Every speck of light you see here represents a contribution to an open source project, somewhere on earth. >>These arts reach across continents, cultures, and other divides. It's distributed collaboration at its finest. 20 years ago, we had no concept of dev ops, SecOps and lots, or the new ops that are going to be happening. But today's development and ops teams are connected like ever before. This is only going to continue to evolve at a rapid pace, especially as we continue to empower the next hundred million developers, automation helps us focus on what's important and to greatly accelerate innovation. Just this past year, we saw some of the most groundbreaking technological advancements and achievements I'll say ever, including critical COVID-19 vaccine trials, as well as the first power flight on Mars. This past month, these breakthroughs were only possible because of the interconnected collaborative open source communities on get hub and the amazing tools and workflows that empower us all to create and innovate. Let's continue building, integrating, and automating. So we collectively can give developers the experience. They deserve all of the automation and beautiful eye UIs that we can muster so they can continue to build the things that truly do change the world. Thank you again for having me today, Dr. Khan, it has been a pleasure to be here with all you nerds. >>Hello. I'm Justin. Komack lovely to see you here. Talking to developers, their world is getting much more complex. Developers are being asked to do everything security ops on goal data analysis, all being put on the rockers. Software's eating the world. Of course, and this all make sense in that view, but they need help. One team. I told you it's shifted all our.net apps to run on Linux from windows, but their developers found the complexity of Docker files based on the Linux shell scripts really difficult has helped make these things easier for your teams. Your ones collaborate more in a virtual world, but you've asked us to make this simpler and more lightweight. You, the developers have asked for a paved road experience. You want things to just work with a simple options to be there, but it's not just the paved road. You also want to be able to go off-road and do interesting and different things. >>Use different components, experiments, innovate as well. We'll always offer you both those choices at different times. Different developers want different things. It may shift for ones the other paved road or off road. Sometimes you want reliability, dependability in the zone for day to day work, but sometimes you have to do something new, incorporate new things in your pipeline, build applications for new places. Then you knew those off-road abilities too. So you can really get under the hood and go and build something weird and wonderful and amazing. That gives you new options. Talk as an independent choice. We don't own the roads. We're not pushing you into any technology choices because we own them. We're really supporting and driving open standards, such as ISEI working opensource with the CNCF. We want to help you get your applications from your laptops, the clouds, and beyond, even into space. >>Let's talk about the key focus areas, that frame, what DACA is doing going forward. These are simplicity, sharing, flexibility, trusted content and care supply chain compared to building where the underlying kernel primitives like namespaces and Seagraves the original Docker CLI was just amazing Docker engine. It's a magical experience for everyone. It really brought those innovations and put them in a world where anyone would use that, but that's not enough. We need to continue to innovate. And it was trying to get more done faster all the time. And there's a lot more we can do. We're here to take complexity away from deeply complicated underlying things and give developers tools that are just amazing and magical. One of the area we haven't done enough and make things magical enough that we're really planning around now is that, you know, Docker images, uh, they're the key parts of your application, but you know, how do I do something with an image? How do I, where do I attach volumes with this image? What's the API. Whereas the SDK for this image, how do I find an example or docs in an API driven world? Every bit of software should have an API and an API description. And our vision is that every container should have this API description and the ability for you to understand how to use it. And it's all a seamless thing from, you know, from your code to the cloud local and remote, you can, you can use containers in this amazing and exciting way. >>One thing I really noticed in the last year is that companies that started off remote fast have constant collaboration. They have zoom calls, apron all day terminals, shattering that always working together. Other teams are really trying to learn how to do this style because they didn't start like that. We used to walk around to other people's desks or share services on the local office network. And it's very difficult to do that anymore. You want sharing to be really simple, lightweight, and informal. Let me try your container or just maybe let's collaborate on this together. Um, you know, fast collaboration on the analysts, fast iteration, fast working together, and he wants to share more. You want to share how to develop environments, not just an image. And we all work by seeing something someone else in our team is doing saying, how can I do that too? I can, I want to make that sharing really, really easy. Ben's going to talk about this more in the interest of one minute. >>We know how you're excited by apple. Silicon and gravis are not excited because there's a new architecture, but excited because it's faster, cooler, cheaper, better, and offers new possibilities. The M one support was the most asked for thing on our public roadmap, EFA, and we listened and share that we see really exciting possibilities, usership arm applications, all the way from desktop to production. We know that you all use different clouds and different bases have deployed to, um, you know, we work with AWS and Azure and Google and more, um, and we want to help you ship on prime as well. And we know that you use huge number of languages and the containers help build applications that use different languages for different parts of the application or for different applications, right? You can choose the best tool. You have JavaScript hat or everywhere go. And re-ask Python for data and ML, perhaps getting excited about WebAssembly after hearing about a cube con, you know, there's all sorts of things. >>So we need to make that as easier. We've been running the whole month of Python on the blog, and we're doing a month of JavaScript because we had one specific support about how do I best put this language into production of that language into production. That detail is important for you. GPS have been difficult to use. We've added GPS suppose in desktop for windows, but we know there's a lot more to do to make the, how multi architecture, multi hardware, multi accelerator world work better and also securely. Um, so there's a lot more work to do to support you in all these things you want to do. >>How do we start building a tenor has applications, but it turns out we're using existing images as components. I couldn't assist survey earlier this year, almost half of container image usage was public images rather than private images. And this is growing rapidly. Almost all software has open source components and maybe 85% of the average application is open source code. And what you're doing is taking whole container images as modules in your application. And this was always the model with Docker compose. And it's a model that you're already et cetera, writing you trust Docker, official images. We know that they might go to 25% of poles on Docker hub and Docker hub provides you the widest choice and the best support that trusted content. We're talking to people about how to make this more helpful. We know, for example, that winter 69 four is just showing us as support, but the image doesn't yet tell you that we're working with canonical to improve messaging from specific images about left lifecycle and support. >>We know that you need more images, regularly updated free of vulnerabilities, easy to use and discover, and Donnie and Marie neuro, going to talk about that more this last year, the solar winds attack has been in the, in the news. A lot, the software you're using and trusting could be compromised and might be all over your organization. We need to reduce the risk of using vital open-source components. We're seeing more software supply chain attacks being targeted as the supply chain, because it's often an easier place to attack and production software. We need to be able to use this external code safely. We need to, everyone needs to start from trusted sources like photography images. They need to scan for known vulnerabilities using Docker scan that we built in partnership with sneak and lost DockerCon last year, we need just keep updating base images and dependencies, and we'll, we're going to help you have the control and understanding about your images that you need to do this. >>And there's more, we're also working on the nursery V2 project in the CNCF to revamp container signings, or you can tell way or software comes from we're working on tooling to make updates easier, and to help you understand and manage all the principals carrier you're using security is a growing concern for all of us. It's really important. And we're going to help you work with security. We can't achieve all our dreams, whether that's space travel or amazing developer products ever see without deep partnerships with our community to cloud is RA and the cloud providers aware most of you ship your occasion production and simple routes that take your work and deploy it easily. Reliably and securely are really important. Just get into production simply and easily and securely. And we've done a bunch of work on that. And, um, but we know there's more to do. >>The CNCF on the open source cloud native community are an amazing ecosystem of creators and lovely people creating an amazing strong community and supporting a huge amount of innovation has its roots in the container ecosystem and his dreams beyond that much of the innovation is focused around operate experience so far, but developer experience is really a growing concern in that community as well. And we're really excited to work on that. We also uses appraiser tool. Then we know you do, and we know that you want it to be easier to use in your environment. We just shifted Docker hub to work on, um, Kubernetes fully. And, um, we're also using many of the other projects are Argo from atheists. We're spending a lot of time working with Microsoft, Amazon right now on getting natural UV to ready to ship in the next few. That's a really detailed piece of collaboration we've been working on for a long term. Long time is really important for our community as the scarcity of the container containers and, um, getting content for you, working together makes us stronger. Our community is made up of all of you have. Um, it's always amazing to be reminded of that as a huge open source community that we already proud to work with. It's an amazing amount of innovation that you're all creating and where perhaps it, what with you and share with you as well. Thank you very much. And thank you for being here. >>Really excited to talk to you today and share more about what Docker is doing to help make you faster, make your team faster and turn your application delivery into something that makes you a 10 X team. What we're hearing from you, the developers using Docker everyday fits across three common themes that we hear consistently over and over. We hear that your time is super important. It's critical, and you want to move faster. You want your tools to get out of your way, and instead to enable you to accelerate and focus on the things you want to be doing. And part of that is that finding great content, great application components that you can incorporate into your apps to move faster is really hard. It's hard to discover. It's hard to find high quality content that you can trust that, you know, passes your test and your configuration needs. >>And it's hard to create good content as well. And you're looking for more safety, more guardrails to help guide you along that way so that you can focus on creating value for your company. Secondly, you're telling us that it's a really far to collaborate effectively with your team and you want to do more, to work more effectively together to help your tools become more and more seamless to help you stay in sync, both with yourself across all of your development environments, as well as with your teammates so that you can more effectively collaborate together. Review each other's work, maintain things and keep them in sync. And finally, you want your applications to run consistently in every single environment, whether that's your local development environment, a cloud-based development environment, your CGI pipeline, or the cloud for production, and you want that micro service to provide that consistent experience everywhere you go so that you have similar tools, similar environments, and you don't need to worry about things getting in your way, but instead things make it easy for you to focus on what you wanna do and what Docker is doing to help solve all of these problems for you and your colleagues is creating a collaborative app dev platform. >>And this collaborative application development platform consists of multiple different pieces. I'm not going to walk through all of them today, but the overall view is that we're providing all the tooling you need from the development environment, to the container images, to the collaboration services, to the pipelines and integrations that enable you to focus on making your applications amazing and changing the world. If we start zooming on a one of those aspects, collaboration we hear from developers regularly is that they're challenged in synchronizing their own setups across environments. They want to be able to duplicate the setup of their teammates. Look, then they can easily get up and running with the same applications, the same tooling, the same version of the same libraries, the same frameworks. And they want to know if their applications are good before they're ready to share them in an official space. >>They want to collaborate on things before they're done, rather than feeling like they have to officially published something before they can effectively share it with others to work on it, to solve this. We're thrilled today to announce Docker, dev environments, Docker, dev environments, transform how your team collaborates. They make creating, sharing standardized development environments. As simple as a Docker poll, they make it easy to review your colleagues work without affecting your own work. And they increase the reproducibility of your own work and decreased production issues in doing so because you've got consistent environments all the way through. Now, I'm going to pass it off to our principal product manager, Ben Gotch to walk you through more detail on Docker dev environments. >>Hi, I'm Ben. I work as a principal program manager at DACA. One of the areas that doc has been looking at to see what's hard today for developers is sharing changes that you make from the inner loop where the inner loop is a better development, where you write code, test it, build it, run it, and ultimately get feedback on those changes before you merge them and try and actually ship them out to production. Most amount of us build this flow and get there still leaves a lot of challenges. People need to jump between branches to look at each other's work. Independence. Dependencies can be different when you're doing that and doing this in this new hybrid wall of work. Isn't any easier either the ability to just save someone, Hey, come and check this out. It's become much harder. People can't come and sit down at your desk or take your laptop away for 10 minutes to just grab and look at what you're doing. >>A lot of the reason that development is hard when you're remote, is that looking at changes and what's going on requires more than just code requires all the dependencies and everything you've got set up and that complete context of your development environment, to understand what you're doing and solving this in a remote first world is hard. We wanted to look at how we could make this better. Let's do that in a way that let you keep working the way you do today. Didn't want you to have to use a browser. We didn't want you to have to use a new idea. And we wanted to do this in a way that was application centric. We wanted to let you work with all the rest of the application already using C for all the services and all those dependencies you need as part of that. And with that, we're excited to talk more about docket developer environments, dev environments are new part of the Docker experience that makes it easier you to get started with your whole inner leap, working inside a container, then able to share and collaborate more than just the code. >>We want it to enable you to share your whole modern development environment, your whole setup from DACA, with your team on any operating system, we'll be launching a limited beta of dev environments in the coming month. And a GA dev environments will be ID agnostic and supporting composts. This means you'll be able to use an extend your existing composed files to create your own development environment in whatever idea, working in dev environments designed to be local. First, they work with Docker desktop and say your existing ID, and let you share that whole inner loop, that whole development context, all of your teammates in just one collect. This means if you want to get feedback on the working progress change or the PR it's as simple as opening another idea instance, and looking at what your team is working on because we're using compose. You can just extend your existing oppose file when you're already working with, to actually create this whole application and have it all working in the context of the rest of the services. >>So it's actually the whole environment you're working with module one service that doesn't really understand what it's doing alone. And with that, let's jump into a quick demo. So you can see here, two dev environments up and running. First one here is the same container dev environment. So if I want to go into that, let's see what's going on in the various code button here. If that one open, I can get straight into my application to start making changes inside that dev container. And I've got all my dependencies in here, so I can just run that straight in that second application I have here is one that's opened up in compose, and I can see that I've also got my backend, my front end and my database. So I've got all my services running here. So if I want, I can open one or more of these in a dev environment, meaning that that container has the context that dev environment has the context of the whole application. >>So I can get back into and connect to all the other services that I need to test this application properly, all of them, one unit. And then when I've made my changes and I'm ready to share, I can hit my share button type in the refund them on to share that too. And then give that image to someone to get going, pick that up and just start working with that code and all my dependencies, simple as putting an image, looking ahead, we're going to be expanding development environments, more of your dependencies for the whole developer worst space. We want to look at backing up and letting you share your volumes to make data science and database setups more repeatable and going. I'm still all of this under a single workspace for your team containing images, your dev environments, your volumes, and more we've really want to allow you to create a fully portable Linux development environment. >>So everyone you're working with on any operating system, as I said, our MVP we're coming next month. And that was for vs code using their dev container primitive and more support for other ideas. We'll follow to find out more about what's happening and what's coming up next in the future of this. And to actually get a bit of a deeper dive in the experience. Can we check out the talk I'm doing with Georgie and girl later on today? Thank you, Ben, amazing story about how Docker is helping to make developer teams more collaborative. Now I'd like to talk more about applications while the dev environment is like the workbench around what you're building. The application itself has all the different components, libraries, and frameworks, and other code that make up the application itself. And we hear developers saying all the time things like, how do they know if their images are good? >>How do they know if they're secure? How do they know if they're minimal? How do they make great images and great Docker files and how do they keep their images secure? And up-to-date on every one of those ties into how do I create more trust? How do I know that I'm building high quality applications to enable you to do this even more effectively than today? We are pleased to announce the DACA verified polisher program. This broadens trusted content by extending beyond Docker official images, to give you more and more trusted building blocks that you can incorporate into your applications. It gives you confidence that you're getting what you expect because Docker verifies every single one of these publishers to make sure they are who they say they are. This improves our secure supply chain story. And finally it simplifies your discovery of the best building blocks by making it easy for you to find things that you know, you can trust so that you can incorporate them into your applications and move on and on the right. You can see some examples of the publishers that are involved in Docker, official images and our Docker verified publisher program. Now I'm pleased to introduce you to marina. Kubicki our senior product manager who will walk you through more about what we're doing to create a better experience for you around trust. >>Thank you, Dani, >>Mario Andretti, who is a famous Italian sports car driver. One said that if everything feels under control, you're just not driving. You're not driving fast enough. Maya Andretti is not a software developer and a software developers. We know that no matter how fast we need to go in order to drive the innovation that we're working on, we can never allow our applications to spin out of control and a Docker. As we continue talking to our, to the developers, what we're realizing is that in order to reach that speed, the developers are the, the, the development community is looking for the building blocks and the tools that will, they will enable them to drive at the speed that they need to go and have the trust in those building blocks. And in those tools that they will be able to maintain control over their applications. So as we think about some of the things that we can do to, to address those concerns, uh, we're realizing that we can pursue them in a number of different venues, including creating reliable content, including creating partnerships that expands the options for the reliable content. >>Um, in order to, in a we're looking at creating integrations, no link security tools, talk about the reliable content. The first thing that comes to mind are the Docker official images, which is a program that we launched several years ago. And this is a set of curated, actively maintained, open source images that, uh, include, uh, operating systems and databases and programming languages. And it would become immensely popular for, for, for creating the base layers of, of the images of, of the different images, images, and applications. And would we realizing that, uh, many developers are, instead of creating something from scratch, basically start with one of the official images for their basis, and then build on top of that. And this program has become so popular that it now makes up a quarter of all of the, uh, Docker poles, which essentially ends up being several billion pulse every single month. >>As we look beyond what we can do for the open source. Uh, we're very ability on the open source, uh, spectrum. We are very excited to announce that we're launching the Docker verified publishers program, which is continuing providing the trust around the content, but now working with, uh, some of the industry leaders, uh, in multiple, in multiple verticals across the entire technology technical spec, it costs entire, uh, high tech in order to provide you with more options of the images that you can use for building your applications. And it still comes back to trust that when you are searching for content in Docker hub, and you see the verified publisher badge, you know, that this is, this is the content that, that is part of the, that comes from one of our partners. And you're not running the risk of pulling the malicious image from an employee master source. >>As we look beyond what we can do for, for providing the reliable content, we're also looking at some of the tools and the infrastructure that we can do, uh, to create a security around the content that you're creating. So last year at the last ad, the last year's DockerCon, we announced partnership with sneak. And later on last year, we launched our DACA, desktop and Docker hub vulnerability scans that allow you the options of writing scans in them along multiple points in your dev cycle. And in addition to providing you with information on the vulnerability on, on the vulnerabilities, in, in your code, uh, it also provides you with a guidance on how to re remediate those vulnerabilities. But as we look beyond the vulnerability scans, we're also looking at some of the other things that we can do, you know, to, to, to, uh, further ensure that the integrity and the security around your images, your images, and with that, uh, later on this year, we're looking to, uh, launch the scope, personal access tokens, and instead of talking about them, I will simply show you what they look like. >>So if you can see here, this is my page in Docker hub, where I've created a four, uh, tokens, uh, read-write delete, read, write, read only in public read in public creeper read only. So, uh, earlier today I went in and I, I logged in, uh, with my read only token. And when you see, when I'm going to pull an image, it's going to allow me to pull an image, not a problem success. And then when I do the next step, I'm going to ask to push an image into the same repo. Uh, would you see is that it's going to give me an error message saying that they access is denied, uh, because there is an additional authentication required. So these are the things that we're looking to add to our roadmap. As we continue thinking about the things that we can do to provide, um, to provide additional building blocks, content, building blocks, uh, and, and, and tools to build the trust so that our DACA developer and skinned code faster than Mario Andretti could ever imagine. Uh, thank you to >>Thank you, marina. It's amazing what you can do to improve the trusted content so that you can accelerate your development more and move more quickly, move more collaboratively and build upon the great work of others. Finally, we hear over and over as that developers are working on their applications that they're looking for, environments that are consistent, that are the same as production, and that they want their applications to really run anywhere, any environment, any architecture, any cloud one great example is the recent announcement of apple Silicon. We heard from developers on uproar that they needed Docker to be available for that architecture before they could add those to it and be successful. And we listened. And based on that, we are pleased to share with you Docker, desktop on apple Silicon. This enables you to run your apps consistently anywhere, whether that's developing on your team's latest dev hardware, deploying an ARM-based cloud environments and having a consistent architecture across your development and production or using multi-year architecture support, which enables your whole team to collaborate on its application, using private repositories on Docker hub, and thrilled to introduce you to Hughie cower, senior director for product management, who will walk you through more of what we're doing to create a great developer experience. >>Senior director of product management at Docker. And I'd like to jump straight into a demo. This is the Mac mini with the apple Silicon processor. And I want to show you how you can now do an end-to-end arm workflow from my M one Mac mini to raspberry PI. As you can see, we have vs code and Docker desktop installed on a, my, the Mac mini. I have a small example here, and I have a raspberry PI three with an led strip, and I want to turn those LEDs into a moving rainbow. This Dockerfile here, builds the application. We build the image with the Docker, build X command to make the image compatible for all raspberry pies with the arm. 64. Part of this build is built with the native power of the M one chip. I also add the push option to easily share the image with my team so they can give it a try to now Dr. >>Creates the local image with the application and uploads it to Docker hub after we've built and pushed the image. We can go to Docker hub and see the new image on Docker hub. You can also explore a variety of images that are compatible with arm processors. Now let's go to the raspberry PI. I have Docker already installed and it's running Ubuntu 64 bit with the Docker run command. I can run the application and let's see what will happen from there. You can see Docker is downloading the image automatically from Docker hub and when it's running, if it's works right, there are some nice colors. And with that, if we have an end-to-end workflow for arm, where continuing to invest into providing you a great developer experience, that's easy to install. Easy to get started with. As you saw in the demo, if you're interested in the new Mac, mini are interested in developing for our platforms in general, we've got you covered with the same experience you've come to expect from Docker with over 95,000 arm images on hub, including many Docker official images. >>We think you'll find what you're looking for. Thank you again to the community that helped us to test the tech previews. We're so delighted to hear when folks say that the new Docker desktop for apple Silicon, it just works for them, but that's not all we've been working on. As Dani mentioned, consistency of developer experience across environments is so important. We're introducing composed V2 that makes compose a first-class citizen in the Docker CLI you no longer need to install a separate composed biter in order to use composed, deploying to production is simpler than ever with the new compose integration that enables you to deploy directly to Amazon ECS or Azure ACI with the same methods you use to run your application locally. If you're interested in running slightly different services, when you're debugging versus testing or, um, just general development, you can manage that all in one place with the new composed service to hear more about what's new and Docker desktop, please join me in the three 15 breakout session this afternoon. >>And now I'd love to tell you a bit more about bill decks and convince you to try it. If you haven't already it's our next gen build command, and it's no longer experimental as shown in the demo with built X, you'll be able to do multi architecture builds, share those builds with your team and the community on Docker hub. With build X, you can speed up your build processes with remote caches or build all the targets in your composed file in parallel with build X bake. And there's so much more if you're using Docker, desktop or Docker, CE you can use build X checkout tonus is talk this afternoon at three 45 to learn more about build X. And with that, I hope everyone has a great Dr. Khan and back over to you, Donnie. >>Thank you UA. It's amazing to hear about what we're doing to create a better developer experience and make sure that Docker works everywhere you need to work. Finally, I'd like to wrap up by showing you everything that we've announced today and everything that we've done recently to make your lives better and give you more and more for the single price of your Docker subscription. We've announced the Docker verified publisher program we've announced scoped personal access tokens to make it easier for you to have a secure CCI pipeline. We've announced Docker dev environments to improve your collaboration with your team. Uh, we shared with you Docker, desktop and apple Silicon, to make sure that, you know, Docker runs everywhere. You need it to run. And we've announced Docker compose version two, finally making it a first-class citizen amongst all the other great Docker tools. And we've done so much more recently as well from audit logs to advanced image management, to compose service profiles, to improve where you can run Docker more easily. >>Finally, as we look forward, where we're headed in the upcoming year is continuing to invest in these themes of helping you build, share, and run modern apps more effectively. We're going to be doing more to help you create a secure supply chain with which only grows more and more important as time goes on. We're going to be optimizing your update experience to make sure that you can easily understand the current state of your application, all its components and keep them all current without worrying about breaking everything as you're doing. So we're going to make it easier for you to synchronize your work. Using cloud sync features. We're going to improve collaboration through dev environments and beyond, and we're going to do make it easy for you to run your microservice in your environments without worrying about things like architecture or differences between those environments. Thank you so much. I'm thrilled about what we're able to do to help make your lives better. And now you're going to be hearing from one of our customers about what they're doing to launch their business with Docker >>I'm Matt Falk, I'm the head of engineering and orbital insight. And today I want to talk to you a little bit about data from space. So who am I like many of you, I'm a software developer and a software developer about seven companies so far, and now I'm a head of engineering. So I spend most of my time doing meetings, but occasionally I'll still spend time doing design discussions, doing code reviews. And in my free time, I still like to dabble on things like project oiler. So who's Oberlin site. What do we do? Portal insight is a large data supplier and analytics provider where we take data geospatial data anywhere on the planet, any overhead sensor, and translate that into insights for the end customer. So specifically we have a suite of high performance, artificial intelligence and machine learning analytics that run on this geospatial data. >>And we build them to specifically determine natural and human service level activity anywhere on the planet. What that really means is we take any type of data associated with a latitude and longitude and we identify patterns so that we can, so we can detect anomalies. And that's everything that we do is all about identifying those patterns to detect anomalies. So more specifically, what type of problems do we solve? So supply chain intelligence, this is one of the use cases that we we'd like to talk about a lot. It's one of our main primary verticals that we go after right now. And as Scott mentioned earlier, this had a huge impact last year when COVID hit. So specifically supply chain intelligence is all about identifying movement patterns to and from operating facilities to identify changes in those supply chains. How do we do this? So for us, we can do things where we track the movement of trucks. >>So identifying trucks, moving from one location to another in aggregate, same thing we can do with foot traffic. We can do the same thing for looking at aggregate groups of people moving from one location to another and analyzing their patterns of life. We can look at two different locations to determine how people are moving from one location to another, or going back and forth. All of this is extremely valuable for detecting how a supply chain operates and then identifying the changes to that supply chain. As I said last year with COVID, everything changed in particular supply chains changed incredibly, and it was hugely important for customers to know where their goods or their products are coming from and where they were going, where there were disruptions in their supply chain and how that's affecting their overall supply and demand. So to use our platform, our suite of tools, you can start to gain a much better picture of where your suppliers or your distributors are going from coming from or going to. >>So what's our team look like? So my team is currently about 50 engineers. Um, we're spread into four different teams and the teams are structured like this. So the first team that we have is infrastructure engineering and this team largely deals with deploying our Dockers using Kubernetes. So this team is all about taking Dockers, built by other teams, sometimes building the Dockers themselves and putting them into our production system, our platform engineering team, they produce these microservices. So they produce microservice, Docker images. They develop and test with them locally. Their entire environments are dockerized. They produce these doctors, hand them over to him for infrastructure engineering to be deployed. Similarly, our product engineering team does the same thing. They develop and test with Dr. Locally. They also produce a suite of Docker images that the infrastructure team can then deploy. And lastly, we have our R and D team, and this team specifically produces machine learning algorithms using Nvidia Docker collectively, we've actually built 381 Docker repositories and 14 million. >>We've had 14 million Docker pools over the lifetime of the company, just a few stats about us. Um, but what I'm really getting to here is you can see actually doctors becoming almost a form of communication between these teams. So one of the paradigms in software engineering that you're probably familiar with encapsulation, it's really helpful for a lot of software engineering problems to break the problem down, isolate the different pieces of it and start building interfaces between the code. This allows you to scale different pieces of the platform or different pieces of your code in different ways that allows you to scale up certain pieces and keep others at a smaller level so that you can meet customer demands. And for us, one of the things that we can largely do now is use Dockers as that interface. So instead of having an entire platform where all teams are talking to each other, and everything's kind of, mishmashed in a monolithic application, we can now say this team is only able to talk to this team by passing over a particular Docker image that defines the interface of what needs to be built before it passes to the team and really allows us to scalp our development and be much more efficient. >>Also, I'd like to say we are hiring. Um, so we have a number of open roles. We have about 30 open roles in our engineering team that we're looking to fill by the end of this year. So if any of this sounds really interesting to you, please reach out after the presentation. >>So what does our platform do? Really? Our platform allows you to answer any geospatial question, and we do this at three different inputs. So first off, where do you want to look? So we did this as what we call an AOI or an area of interest larger. You can think of this as a polygon drawn on the map. So we have a curated data set of almost 4 million AOIs, which you can go and you can search and use for your analysis, but you're also free to build your own. Second question is what you want to look for. We do this with the more interesting part of our platform of our machine learning and AI capabilities. So we have a suite of algorithms that automatically allow you to identify trucks, buildings, hundreds of different types of aircraft, different types of land use, how many people are moving from one location to another different locations that people in a particular area are moving to or coming from all of these different analyses or all these different analytics are available at the click of a button, and then determine what you want to look for. >>Lastly, you determine when you want to find what you're looking for. So that's just, uh, you know, do you want to look for the next three hours? Do you want to look for the last week? Do you want to look every month for the past two, whatever the time cadence is, you decide that you hit go and out pops a time series, and that time series tells you specifically where you want it to look what you want it to look for and how many, or what percentage of the thing you're looking for appears in that area. Again, we do all of this to work towards patterns. So we use all this data to produce a time series from there. We can look at it, determine the patterns, and then specifically identify the anomalies. As I mentioned with supply chain, this is extremely valuable to identify where things change. So we can answer these questions, looking at a particular operating facility, looking at particular, what is happening with the level of activity is at that operating facility where people are coming from, where they're going to, after visiting that particular facility and identify when and where that changes here, you can just see it's a picture of our platform. It's actually showing all the devices in Manhattan, um, over a period of time. And it's more of a heat map view. So you can actually see the hotspots in the area. >>So really the, and this is the heart of the talk, but what happened in 2020? So for men, you know, like many of you, 2020 was a difficult year COVID hit. And that changed a lot of what we're doing, not from an engineering perspective, but also from an entire company perspective for us, the motivation really became to make sure that we were lowering our costs and increasing innovation simultaneously. Now those two things often compete with each other. A lot of times you want to increase innovation, that's going to increase your costs, but the challenge last year was how to do both simultaneously. So here's a few stats for you from our team. In Q1 of last year, we were spending almost $600,000 per month on compute costs prior to COVID happening. That wasn't hugely a concern for us. It was a lot of money, but it wasn't as critical as it was last year when we really needed to be much more efficient. >>Second one is flexibility for us. We were deployed on a single cloud environment while we were cloud thought ready, and that was great. We want it to be more flexible. We want it to be on more cloud environments so that we could reach more customers. And also eventually get onto class side networks, extending the base of our customers as well from a custom analytics perspective. This is where we get into our traction. So last year, over the entire year, we computed 54,000 custom analytics for different users. We wanted to make sure that this number was steadily increasing despite us trying to lower our costs. So we didn't want the lowering cost to come as the sacrifice of our user base. Lastly, of particular percentage here that I'll say definitely needs to be improved is 75% of our projects never fail. So this is where we start to get into a bit of stability of our platform. >>Now I'm not saying that 25% of our projects fail the way we measure this is if you have a particular project or computation that runs every day and any one of those runs sale account, that is a failure because from an end-user perspective, that's an issue. So this is something that we know we needed to improve on and we needed to grow and make our platform more stable. I'm going to something that we really focused on last year. So where are we now? So now coming out of the COVID valley, we are starting to soar again. Um, we had, uh, back in April of last year, we had the entire engineering team. We actually paused all development for about four weeks. You had everyone focused on reducing our compute costs in the cloud. We got it down to 200 K over the period of a few months. >>And for the next 12 months, we hit that number every month. This is huge for us. This is extremely important. Like I said, in the COVID time period where costs and operating efficiency was everything. So for us to do that, that was a huge accomplishment last year and something we'll keep going forward. One thing I would actually like to really highlight here, two is what allowed us to do that. So first off, being in the cloud, being able to migrate things like that, that was one thing. And we were able to use there's different cloud services in a more particular, in a more efficient way. We had a very detailed tracking of how we were spending things. We increased our data retention policies. We optimized our processing. However, one additional piece was switching to new technologies on, in particular, we migrated to get lab CICB. >>Um, and this is something that the costs we use Docker was extremely, extremely easy. We didn't have to go build new new code containers or repositories or change our code in order to do this. We were simply able to migrate the containers over and start using a new CIC so much. In fact, that we were able to do that migration with three engineers in just two weeks from a cloud environment and flexibility standpoint, we're now operating in two different clouds. We were able to last night, I've over the last nine months to operate in the second cloud environment. And again, this is something that Docker helped with incredibly. Um, we didn't have to go and build all new interfaces to all new, different services or all different tools in the next cloud provider. All we had to do was build a base cloud infrastructure that ups agnostic the way, all the different details of the cloud provider. >>And then our doctors just worked. We can move them to another environment up and running, and our platform was ready to go from a traction perspective. We're about a third of the way through the year. At this point, we've already exceeded the amount of customer analytics we produce last year. And this is thanks to a ton more albums, that whole suite of new analytics that we've been able to build over the past 12 months and we'll continue to build going forward. So this is really, really great outcome for us because we were able to show that our costs are staying down, but our analytics and our customer traction, honestly, from a stability perspective, we improved from 75% to 86%, not quite yet 99 or three nines or four nines, but we are getting there. Um, and this is actually thanks to really containerizing and modularizing different pieces of our platform so that we could scale up in different areas. This allowed us to increase that stability. This piece of the code works over here, toxin an interface to the rest of the system. We can scale this piece up separately from the rest of the system, and that allows us much more easily identify issues in the system, fix those and then correct the system overall. So basically this is a summary of where we were last year, where we are now and how much more successful we are now because of the issues that we went through last year and largely brought on by COVID. >>But that this is just a screenshot of the, our, our solution actually working on supply chain. So this is in particular, it is showing traceability of a distribution warehouse in salt lake city. It's right in the center of the screen here. You can see the nice kind of orange red center. That's a distribution warehouse and all the lines outside of that, all the dots outside of that are showing where people are, where trucks are moving from that location. So this is really helpful for supply chain companies because they can start to identify where their suppliers are, are coming from or where their distributors are going to. So with that, I want to say, thanks again for following along and enjoy the rest of DockerCon.

>> Hello and welcome to the session featuring CarMax, driving efficiency and innovation with Ansible. I'm your host Christian Emery. I've been at CarMax for over 18 years in several roles ranging from operations to engineering. And in my current role, I'm responsible for CarMax's private cloud and continuous integration, continuous delivery pipelines. Now, my journey with automation started many years ago when I was a Unix and a Linux admin. Day after day, there was always that routine of manual tasks and processes like backups and routine maintenance. Each tasks had a lot of value to the business, but also required consistency, reliability and completion, and demanded quality for system stability. However, it was really boring to carry out the same thing every day. And personally I had a hunger to do more, bring greater value to the business, and need to realize greater satisfaction through my contributions in my career. And this is where automation came into my life. But before we jump into the presentation, I do want to share a little bit about CarMax. For those who may not know, CarMax has been a unique force in the used car industry since 1993. Through innovation and integrity, we've revolutionized the way people buy and sell used cars. We pride ourselves on the experience we provide our customers and our associates to make it possible. And by changing the way we assist our customers, we've also changed the journey of our associates, providing careers in exciting collaborative work environments. In today's presentation, I'm going to cover the early chapters of the CarMax Ansible story. Topics discussed will highlight business need, why we selected Ansible, rapid adoption and our results. And throughout the presentation, I'm also going to share a lot of thoughts and lessons learned to help you with your automation journey. And while listening to the story, I'd like to challenge you to think about your own business needs, technology challenges, and how your team organizes or organization improves approaches automation. Now in our first year, I was challenged to achieve 5,000 hours in efficiency using Ansible. That was a really intimidating number. But we met the challenge and exceeded it. And since then, we've continued to expand our automation through incremental improvements in everyday work to tackling larger operational challenges like regular changes to the environment, routine upgrades and improved infrastructure delivery. Additionally, we expanded automation adoption across multiple teams. We increased our user and contributor base by over five times. And some of that growth was through organic cross team collaboration. However, the greatest growth we had seen was through hackathons, innovation days where we're able to actively collaborate with other teams using Ansible to solve a business problem. And across all those users, we crossed over 15,000 hours of efficiency gain. And I use that term efficiency gained as a measurement to show not only just labor savings, but also tell the story behind other work we accomplished. And keep in mind, this is work that we wouldn't have been able to achieve without automation. And through that user base and hours of efficiency realized, we implemented over 150,000 successful changes. So how do we get there? Earlier I told you about my personal interest in automation and how I've carried that into my current role. And as a leader, I challenge my team to standardize processes and automate as much as possible. We started initially with really repetitive tasks, much like a game of whack-a-mole, but more importantly, through our experimentation, we quickly found we could get better and more consistent results. We soon applied the same approach to our automation for even greater success. But before Ansible, we started to run into issues where team members were taking a more siloed approach to the work. And in an early retrospective, we came to realize that there is a need for a bigger picture mindset. And from that point on, we agreed to standards to increase quality in our code. However, we still occasionally ran into quality issues. Some of these challenges were from homegrown technology, lack of integration and general infrastructure. Now, this is all compounded by the fact that we were using different scripting and programming languages, and not everyone on the team was familiar with Python when compared to say Bash or PowerShell. And while our homegrown solutions made a difference, we thought there could be better ways to meet that demand from the business to do more, better and faster. But like most things in technology, there's always a different tool and approach to get something done. However, some of these other tools required agents on servers making a deployment, a major effort on its own. And additionally, the learning curve was steeper for systems admins and engineers that don't have as much development experience. But this is where Ansible came into the picture. It was easy to use with human readable code. It was an agentless solution allowing us to get started without as much ramp up time. We also liked the fact that it was built on an open standard and a growing user community with an increasing engagement base from partner in vendor integrators. Even better, it had an API we could use to integrate our other platforms as needed. Most recently with the introduction of Ansible collections, we can use community content with greater focus on our automation while worrying less about building new tools. Now, once we select an Ansible as our automation platform, we took a three part approach to implementation and building a foundation for its use. And as I discuss each of these areas, I just like you to consider how to best prepare your teams or organizations for using Ansible. And while planning the transformation, be sure to identify any sort of constraints, roadblocks, and how you plan to measure those results. People, arguably people are the most important part of the equation. You can have all the processes and ways to measure return, but at the end of the day, you need your teams to make that work happen. Start by asking yourself, how well does the team handle change? Are there resource challenges with aligning people and work? Do the people have the right level of knowledge? Do they need training? And how do you start with one team to quickly begin or expand automation? Processes, documentation, standards. Processes are those great ingredients for success in any technology organization. How well are your existing processes documented? Are there any sort of defined standards methods to approaching work? What about your environments? How well does your organization handle executing processes or changes? And lastly, technology. We always need to show results for our investments and technology can help us show that math. Does your organization use metrics and measurements to track progress and results? How do you define or measure success for a project? How should return on investment be measured or quantified? Like I mentioned before, I can't stress it enough, your people, your teams are the most important part of implementing Ansible. They'll be responsible for implementing and developing, maintaining the platform as well as following standards to execute that transformation. And to be successful, they need to have tools, environments, and knowledge. But one of the great things about Ansible is its comparatively easy learning curve. Ansible playbooks are written in a human readable markup language. And I found that most systems admins and engineers are able to pick up Ansible relatively quickly. And for our adoption, some folks were able to pick it up and begin development, while others were a little bit more comfortable and confident with just a little bit of training. Now, Ansible also democratizes technology, freeing up admins and engineers from traditional OS defined silos. Additionally, Ansible playbooks can be consumed by teams without explicit knowledge of the systems or the underlying technology. That's only if a playbook is well written and returns consistent results each time. For us, we first used Ansible to improve our delivery and reduce repeatable manual tasks. Then we turned our attention to shifting left self-service and we're now focused on enabling developers by getting out of the way. These improvements afforded our teams more time to deliver new capabilities to the business. But another benefit to that is teams were able to devote more time to learning and experimenting. When teams first started automating, there's always that impulse or need to go after that biggest win. I would always caution folks to start simple, find small wins to build that experience. These incremental gains are going to feel small, but they quickly add up over time. And as you're going to see, the work should always be done in those smaller increments to return value faster while allowing the ability to quickly make corrections or change course all together. Now, another huge benefit of using that smaller code increment is reuse. These smaller building blocks can and will be used time and time again, reducing future development efforts. And as we quickly learned, one of the best places to start with automation are documented processes. Each step in a process is already documented, it's a huge opportunity to convert it to code and step through those manual processes. And at CarMax, one of the first places we started out was our server checklist process. The process was really thorough, had over a hundred steps to validate systems, make sure they have the right configuration security and specs for each build. And while that process really gave us good consistent results, it was time consuming. It was also prone to human error. But once we automated each of those steps in validations, we were able to turn our focus to the next bottleneck in the process to speed up delivery. And this is why it's always important to strive for quality through consistent predictable results. Automation is just another tool to help make that vision a reality. And when working with teams, it's also important to understand development best practices, keep it simple, and always use version control with code. Better yet, if you're from an ops background, I'd say partner with your development teams to help with this part of the journey. And lastly, when it comes to integrations between platforms and systems, use a modular design, be flexible because technology changes, and over time, so are your integrations. And when it comes to Ansible or just automation in general, there's always that need for efficiency, consistency, reliability, and flexible integrations. And to make this become a reality, you really need to take both a low tech and a high tech approach. If you recall earlier, I mentioned starting with documented processes. That low tech road involves using process mapping value stream analysis tools where you lay out processes end to end to determine the amount of time it takes to execute a process. These processes can be mapped out using whiteboard, sticky notes or by software tools. And from there, more importantly, you can visualize the process bottlenecks and the areas of improvement should be pretty visible. So for CarMax, what we did was we mapped out our infrastructure delivery. We found it was a huge opportunity. But it was also an area we were more comfortable automating given our deep knowledge of the process. So years ago, when we started the process, our time to deliver virtual environments was about two days. Fast forward to now, we can consistently deliver the same infrastructure in just minutes. And in turn, we reuse portions of that process and code for OS refreshes, virtual machine rehydration, system recovery and hypervisor upgrades, just to name a few. And by freeing up team members to do more knowledge work and spend less time on operations, we're able to pivot more resources on the team to align with the business on strategic initiatives. Team members also had more time to do training, research and development for new capabilities, and other areas for future innovation. Now, Ansible gave us a tool where we need to think more like a DevOps organization. And admittedly, a lot of what I've talked about so far has been very operation centric, but systems engineers were all of a sudden writing a testing code, building tools, delivering infrastructure via code, pipelines and API integrations. And as a result, we instantly had to build and strengthen the collaborative relationship between traditional development and operations teams, we had to break down those silos. But the developers appreciate it because they can focus on developing code and not necessarily worry about environments being ready in time or configured correctly. Conversely, operations teams can be focused more on improvements, new capabilities, and spending less time on firefighting. But regardless of the outcomes, you need data to tell that story. And these data elements can start with the hard numbers from reduced cycle times when we were mapping out processes, you can use delivery and SLA metrics. Those were some easy go to numbers. But also consider how you tell that efficiency story. And remember, ROI isn't always about money or the time savings. So as an example, metrics we used included the number of teams using the platform, active contributors, workflows, processes run, and efficiency gain calculations. And as we evolve our journey, the metrics may change along with that story that we need to tell. So to recap, at CarMax, we put people first and you should too. Think about the resources and knowledge your teams are going to need to be successful. And like I said earlier, remember to start small, reuse code as much as possible. This is going to help teams realize faster return on their efforts and start that snowball effect where gains quickly compound over time. Have a vision and decide on targeted outcomes for your team or organization. Then build ROI metrics to help tell that story. But a big part of innovation is experimenting and learning from mistakes. So take a chance, try something new. And in closing, I'd like to thank you for your time. I sincerely hope our results and lessons learned will help you on your automation journey wherever it takes you.

>> Hi, my name is Andy Clemenko. I'm a Senior Solutions Engineer at StackRox. Thanks for joining us today for my talk on labels, labels, labels. Obviously, you can reach me at all the socials. Before we get started, I like to point you to my GitHub repo, you can go to andyc.info/dc20, and it'll take you to my GitHub page where I've got all of this documentation, socials. Before we get started, I like to point you to my GitHub repo, you can go to andyc.info/dc20, (upbeat music) >> Hi, my name is Andy Clemenko. I'm a Senior Solutions Engineer at StackRox. Thanks for joining us today for my talk on labels, labels, labels. Obviously, you can reach me at all the socials. Before we get started, I like to point you to my GitHub repo, you can go to andyc.info/dc20, and it'll take you to my GitHub page where I've got all of this documentation, I've got the Keynote file there. YAMLs, I've got Dockerfiles, Compose files, all that good stuff. If you want to follow along, great, if not go back and review later, kind of fun. So let me tell you a little bit about myself. I am a former DOD contractor. This is my seventh DockerCon. I've spoken, I had the pleasure to speak at a few of them, one even in Europe. I was even a Docker employee for quite a number of years, providing solutions to the federal government and customers around containers and all things Docker. So I've been doing this a little while. One of the things that I always found interesting was the lack of understanding around labels. So why labels, right? Well, as a former DOD contractor, I had built out a large registry. And the question I constantly got was, where did this image come from? How did you get it? What's in it? Where did it come from? How did it get here? And one of the things we did to kind of alleviate some of those questions was we established a baseline set of labels. Labels really are designed to provide as much metadata around the image as possible. I ask everyone in attendance, when was the last time you pulled an image and had 100% confidence, you knew what was inside it, where it was built, how it was built, when it was built, you probably didn't, right? The last thing we obviously want is a container fire, like our image on the screen. And one kind of interesting way we can kind of prevent that is through the use of labels. We can use labels to address security, address some of the simplicity on how to run these images. So think of it, kind of like self documenting, Think of it also as an audit trail, image provenance, things like that. These are some interesting concepts that we can definitely mandate as we move forward. What is a label, right? Specifically what is the Schema? It's just a key-value. All right? It's any key and pretty much any value. What if we could dump in all kinds of information? What if we could encode things and store it in there? And I've got a fun little demo to show you about that. Let's start off with some of the simple keys, right? Author, date, description, version. Some of the basic information around the image. That would be pretty useful, right? What about specific labels for CI? What about a, where's the version control? Where's the source, right? Whether it's Git, whether it's GitLab, whether it's GitHub, whether it's Gitosis, right? Even SPN, who cares? Where are the source files that built, where's the Docker file that built this image? What's the commit number? That might be interesting in terms of tracking the resulting image to a person or to a commit, hopefully then to a person. How is it built? What if you wanted to play with it and do a git clone of the repo and then build the Docker file on your own? Having a label specifically dedicated on how to build this image might be interesting for development work. Where it was built, and obviously what build number, right? These kind of all, not only talk about continuous integration, CI but also start to talk about security. Specifically what server built it. The version control number, the version number, the commit number, again, how it was built. What's the specific build number? What was that job number in, say, Jenkins or GitLab? What if we could take it a step further? What if we could actually apply policy enforcement in the build pipeline, looking specifically for some of these specific labels? I've got a good example of, in my demo of a policy enforcement. So let's look at some sample labels. Now originally, this idea came out of label-schema.org. And then it was a modified to opencontainers, org.opencontainers.image. There is a link in my GitHub page that links to the full reference. But these are some of the labels that I like to use, just as kind of like a standardization. So obviously, Author's, an email address, so now the image is attributable to a person, that's always kind of good for security and reliability. Where's the source? Where's the version control that has the source, the Docker file and all the assets? How it was built, build number, build server the commit, we talked about, when it was created, a simple description. A fun one I like adding in is the healthZendpoint. Now obviously, the health check directive should be in the Docker file. But if you've got other systems that want to ping your applications, why not declare it and make it queryable? Image version, obviously, that's simple declarative And then a title. And then I've got the two fun ones. Remember, I talked about what if we could encode some fun things? Hypothetically, what if we could encode the Compose file of how to build the stack in the first image itself? And conversely the Kubernetes? Well, actually, you can and I have a demo to show you how to kind of take advantage of that. So how do we create labels? And really creating labels as a function of build time okay? You can't really add labels to an image after the fact. The way you do add labels is either through the Docker file, which I'm a big fan of, because it's declarative. It's in version control. It's kind of irrefutable, especially if you're tracking that commit number in a label. You can extend it from being a static kind of declaration to more a dynamic with build arguments. And I can show you, I'll show you in a little while how you can use a build argument at build time to pass in that variable. And then obviously, if you did it by hand, you could do a docker build--label key equals value. I'm not a big fan of the third one, I love the first one and obviously the second one. Being dynamic we can take advantage of some of the variables coming out of version control. Or I should say, some of the variables coming out of our CI system. And that way, it self documents effectively at build time, which is kind of cool. How do we view labels? Well, there's two major ways to view labels. The first one is obviously a docker pull and docker inspect. You can pull the image locally, you can inspect it, you can obviously, it's going to output as JSON. So you going to use something like JQ to crack it open and look at the individual labels. Another one which I found recently was Skopeo from Red Hat. This allows you to actually query the registry server. So you don't even have to pull the image initially. This can be really useful if you're on a really small development workstation, and you're trying to talk to a Kubernetes cluster and wanting to deploy apps kind of in a very simple manner. Okay? And this was that use case, right? Using Kubernetes, the Kubernetes demo. One of the interesting things about this is that you can base64 encode almost anything, push it in as text into a label and then base64 decode it, and then use it. So in this case, in my demo, I'll show you how we can actually use a kubectl apply piped from the base64 decode from the label itself from skopeo talking to the registry. And what's interesting about this kind of technique is you don't need to store Helm charts. You don't need to learn another language for your declarative automation, right? You don't need all this extra levels of abstraction inherently, if you use it as a label with a kubectl apply, It's just built in. It's kind of like the kiss approach to a certain extent. It does require some encoding when you actually build the image, but to me, it doesn't seem that hard. Okay, let's take a look at a demo. And what I'm going to do for my demo, before we actually get started is here's my repo. Here's a, let me actually go to the actual full repo. So here's the repo, right? And I've got my Jenkins pipeline 'cause I'm using Jenkins for this demo. And in my demo flask, I've got the Docker file. I've got my compose and my Kubernetes YAML. So let's take a look at the Docker file, right? So it's a simple Alpine image. The org statements are the build time arguments that are passed in. Label, so again, I'm using the org.opencontainers.image.blank, for most of them. There's a typo there. Let's see if you can find it, I'll show you it later. My source, build date, build number, commit. Build number and get commit are derived from the Jenkins itself, which is nice. I can just take advantage of existing URLs. I don't have to create anything crazy. And again, I've got my actual Docker build command. Now this is just a label on how to build it. And then here's my simple Python, APK upgrade, remove the package manager, kind of some security stuff, health check getting Python through, okay? Let's take a look at the Jenkins pipeline real quick. So here is my Jenkins pipeline and I have four major stages, four stages, I have built. And here in build, what I do is I actually do the Git clone. And then I do my docker build. From there, I actually tell the Jenkins StackRox plugin. So that's what I'm using for my security scanning. So go ahead and scan, basically, I'm staging it to scan the image. I'm pushing it to Hub, okay? Where I can see the, basically I'm pushing the image up to Hub so such that my StackRox security scanner can go ahead and scan the image. I'm kicking off the scan itself. And then if everything's successful, I'm pushing it to prod. Now what I'm doing is I'm just using the same image with two tags, pre-prod and prod. This is not exactly ideal, in your environment, you probably want to use separate registries and non-prod and a production registry, but for demonstration purposes, I think this is okay. So let's go over to my Jenkins and I've got a deliberate failure. And I'll show you why there's a reason for that. And let's go down. Let's look at my, so I have a StackRox report. Let's look at my report. And it says image required, required image label alert, right? Request that the maintainer, add the required label to the image, so we're missing a label, okay? One of the things we can do is let's flip over, and let's look at Skopeo. Right? I'm going to do this just the easy way. So instead of looking at org.zdocker, opencontainers.image.authors. Okay, see here it says build signature? That was the typo, we didn't actually pass in. So if we go back to our repo, we didn't pass in the the build time argument, we just passed in the word. So let's fix that real quick. That's the Docker file. Let's go ahead and put our dollar sign in their. First day with the fingers you going to love it. And let's go ahead and commit that. Okay? So now that that's committed, we can go back to Jenkins, and we can actually do another build. And there's number 12. And as you can see, I've been playing with this for a little bit today. And while that's running, come on, we can go ahead and look at the Console output. Okay, so there's our image. And again, look at all the build arguments that we're passing into the build statement. So we're passing in the date and the date gets derived on the command line. With the build arguments, there's the base64 encoded of the Compose file. Here's the base64 encoding of the Kubernetes YAML. We do the build. And then let's go down to the bottom layer exists and successful. So here's where we can see no system policy violations profound marking stack regimes security plugin, build step as successful, okay? So we're actually able to do policy enforcement that that image exists, that that label sorry, exists in the image. And again, we can look at the security report and there's no policy violations and no vulnerabilities. So that's pretty good for security, right? We can now enforce and mandate use of certain labels within our images. And let's flip back over to Skopeo, and let's go ahead and look at it. So we're looking at the prod version again. And there's it is in my email address. And that validated that that was valid for that policy. So that's kind of cool. Now, let's take it a step further. What if, let's go ahead and take a look at all of the image, all the labels for a second, let me remove the dash org, make it pretty. Okay? So we have all of our image labels. Again, author's build, commit number, look at the commit number. It was built today build number 12. We saw that right? Delete, build 12. So that's kind of cool dynamic labels. Name, healthz, right? But what we're looking for is we're going to look at the org.zdockerketers label. So let's go look at the label real quick. Okay, well that doesn't really help us because it's encoded but let's base64 dash D, let's decode it. And I need to put the dash r in there 'cause it doesn't like, there we go. So there's my Kubernetes YAML. So why can't we simply kubectl apply dash f? Let's just apply it from standard end. So now we've actually used that label. From the image that we've queried with skopeo, from a remote registry to deploy locally to our Kubernetes cluster. So let's go ahead and look everything's up and running, perfect. So what does that look like, right? So luckily, I'm using traefik for Ingress 'cause I love it. And I've got an object in my Kubernetes YAML called flask.doctor.life. That's my Ingress object for traefik. I can go to flask.docker.life. And I can hit refresh. Obviously, I'm not a very good web designer 'cause the background image in the text. We can go ahead and refresh it a couple times we've got Redis storing a hit counter. We can see that our server name is roundrobing. Okay? That's kind of cool. So let's kind of recap a little bit about my demo environment. So my demo environment, I'm using DigitalOcean, Ubuntu 19.10 Vms. I'm using K3s instead of full Kubernetes either full Rancher, full Open Shift or Docker Enterprise. I think K3s has some really interesting advantages on the development side and it's kind of intended for IoT but it works really well and it deploys super easy. I'm using traefik for Ingress. I love traefik. I may or may not be a traefik ambassador. I'm using Jenkins for CI. And I'm using StackRox for image scanning and policy enforcement. One of the things to think about though, especially in terms of labels is none of this demo stack is required. You can be in any cloud, you can be in CentOs, you can be in any Kubernetes. You can even be in swarm, if you wanted to, or Docker compose. Any Ingress, any CI system, Jenkins, circle, GitLab, it doesn't matter. And pretty much any scanning. One of the things that I think is kind of nice about at least StackRox is that we do a lot more than just image scanning, right? With the policy enforcement things like that. I guess that's kind of a shameless plug. But again, any of this stack is completely replaceable, with any comparative product in that category. So I'd like to, again, point you guys to the andyc.infodc20, that's take you right to the GitHub repo. You can reach out to me at any of the socials @clemenko or andy@stackrox.com. And thank you for attending. I hope you learned something fun about labels. And hopefully you guys can standardize labels in your organization and really kind of take your images and the image provenance to a new level. Thanks for watching. (upbeat music) >> Narrator: Live from Las Vegas It's theCUBE. Covering AWS re:Invent 2019. Brought to you by Amazon Web Services and Intel along with it's ecosystem partners. >> Okay, welcome back everyone theCUBE's live coverage of AWS re:Invent 2019. This is theCUBE's 7th year covering Amazon re:Invent. It's their 8th year of the conference. I want to just shout out to Intel for their sponsorship for these two amazing sets. Without their support we wouldn't be able to bring our mission of great content to you. I'm John Furrier. Stu Miniman. We're here with the chief of AWS, the chief executive officer Andy Jassy. Tech athlete in and of himself three hour Keynotes. Welcome to theCUBE again, great to see you. >> Great to be here, thanks for having me guys. >> Congratulations on a great show a lot of great buzz. >> Andy: Thank you. >> A lot of good stuff. Your Keynote was phenomenal. You get right into it, you giddy up right into it as you say, three hours, thirty announcements. You guys do a lot, but what I liked, the new addition, the last year and this year is the band; house band. They're pretty good. >> Andy: They're good right? >> They hit the queen notes, so that keeps it balanced. So we're going to work on getting a band for theCUBE. >> Awesome. >> So if I have to ask you, what's your walk up song, what would it be? >> There's so many choices, it depends on what kind of mood I'm in. But, uh, maybe Times Like These by the Foo Fighters. >> John: Alright. >> These are unusual times right now. >> Foo Fighters playing at the Amazon Intersect Show. >> Yes they are. >> Good plug Andy. >> Headlining. >> Very clever >> Always getting a good plug in there. >> My very favorite band. Well congratulations on the Intersect you got a lot going on. Intersect is a music festival, I'll get to that in a second But, I think the big news for me is two things, obviously we had a one-on-one exclusive interview and you laid out, essentially what looks like was going to be your Keynote, and it was. Transformation- >> Andy: Thank you for the practice. (Laughter) >> John: I'm glad to practice, use me anytime. >> Yeah. >> And I like to appreciate the comments on Jedi on the record, that was great. But I think the transformation story's a very real one, but the NFL news you guys just announced, to me, was so much fun and relevant. You had the Commissioner of NFL on stage with you talking about a strategic partnership. That is as top down, aggressive goal as you could get to have Rodger Goodell fly to a tech conference to sit with you and then bring his team talk about the deal. >> Well, ya know, we've been partners with the NFL for a while with the Next Gen Stats that they use on all their telecasts and one of the things I really like about Roger is that he's very curious and very interested in technology and the first couple times I spoke with him he asked me so many questions about ways the NFL might be able to use the Cloud and digital transformation to transform their various experiences and he's always said if you have a creative idea or something you think that could change the world for us, just call me he said or text me or email me and I'll call you back within 24 hours. And so, we've spent the better part of the last year talking about a lot of really interesting, strategic ways that they can evolve their experience both for fans, as well as their players and the Player Health and Safety Initiative, it's so important in sports and particularly important with the NFL given the nature of the sport and they've always had a focus on it, but what you can do with computer vision and machine learning algorithms and then building a digital athlete which is really like a digital twin of each athlete so you understand, what does it look like when they're healthy and compare that when it looks like they may not be healthy and be able to simulate all kinds of different combinations of player hits and angles and different plays so that you could try to predict injuries and predict the right equipment you need before there's a problem can be really transformational so we're super excited about it. >> Did you guys come up with the idea or was it a collaboration between them? >> It was really a collaboration. I mean they, look, they are very focused on players safety and health and it's a big deal for their- you know, they have two main constituents the players and fans and they care deeply about the players and it's a-it's a hard problem in a sport like Football, I mean, you watch it. >> Yeah, and I got to say it does point out the use cases of what you guys are promoting heavily at the show here of the SageMaker Studio, which was a big part of your Keynote, where they have all this data. >> Andy: Right. >> And they're data hoarders, they hoard data but the manual process of going through the data was a killer problem. This is consistent with a lot of the enterprises that are out there, they have more data than they even know. So this seems to be a big part of the strategy. How do you get the customers to actually wake up to the fact that they got all this data and how do you tie that together? >> I think in almost every company they know they have a lot of data. And there are always pockets of people who want to do something with it. But, when you're going to make these really big leaps forward; these transformations, the things like Volkswagen is doing where they're reinventing their factories and their manufacturing process or the NFL where they're going to radically transform how they do players uh, health and safety. It starts top down and if the senior leader isn't convicted about wanting to take that leap forward and trying something different and organizing the data differently and organizing the team differently and using machine learning and getting help from us and building algorithms and building some muscle inside the company it just doesn't happen because it's not in the normal machinery of what most companies do. And so it always, almost always, starts top down. Sometimes it can be the Commissioner or CEO sometimes it can be the CIO but it has to be senior level conviction or it doesn't get off the ground. >> And the business model impact has to be real. For NFL, they know concussions, hurting their youth pipe-lining, this is a huge issue for them. This is their business model. >> They lose even more players to lower extremity injuries. And so just the notion of trying to be able to predict injuries and, you know, the impact it can have on rules and the impact it can have on the equipment they use, it's a huge game changer when they look at the next 10 to 20 years. >> Alright, love geeking out on the NFL but Andy, you know- >> No more NFL talk? >> Off camera how about we talk? >> Nobody talks about the Giants being 2 and 10. >> Stu: We're both Patriots fans here. >> People bring up the undefeated season. >> So Andy- >> Everybody's a Patriot's fan now. (Laughter) >> It's fascinating to watch uh, you and your three hour uh, Keynote, uh Werner in his you know, architectural discussion, really showed how AWS is really extending its reach, you know, it's not just a place. For a few years people have been talking about you know, Cloud is an operational model its not a destination or a location but, I felt it really was laid out is you talked about Breadth and Depth and Werner really talked about you know, Architectural differentiation. People talk about Cloud, but there are very-there are a lot of differences between the vision for where things are going. Help us understand why, I mean, Amazon's vision is still a bit different from what other people talk about where this whole Cloud expansion, journey, put ever what tag or label you want on it but you know, the control plane and the technology that you're building and where you see that going. >> Well I think that, we've talked about this a couple times we have two macro types of customers. We have those that really want to get at the low level building blocks and stitch them together creatively however they see fit to create whatever's in their-in their heads. And then we have the second segment of customers that say look, I'm willing to give up some of that flexibility in exchange for getting 80% of the way there much faster. In an abstraction that's different from those low level building blocks. And both segments of builders we want to serve and serve well and so we've built very significant offerings in both areas. I think when you look at microservices um, you know, some of it has to do with the fact that we have this very strongly held belief born out of several years of Amazon where you know, the first 7 or 8 years of Amazon's consumer business we basically jumbled together all of the parts of our technology in moving really quickly and when we wanted to move quickly where you had to impact multiple internal development teams it was so long because it was this big ball, this big monolithic piece. And we got religion about that in trying to move faster in the consumer business and having to tease those pieces apart. And it really was a lot of impetus behind conceiving AWS where it was these low level, very flexible building blocks that6 don't try and make all the decisions for customers they get to make them themselves. And some of the microservices that you saw Werner talking about just, you know, for instance, what we-what we did with Nitro or even what we did with Firecracker those are very much about us relentlessly working to continue to uh, tease apart the different components. And even things that look like low level building blocks over time, you build more and more features and all of the sudden you realize they have a lot of things that are combined together that you wished weren't that slow you down and so, Nitro was a completely re imagining of our Hypervisor and Virtualization layer to allow us, both to let customers have better performance but also to let us move faster and have a better security story for our customers. >> I got to ask you the question around transformation because I think that all points, all the data points, you got all the references, Goldman Sachs on stage at the Keynote, Cerner, I mean healthcare just is an amazing example because I mean, that's demonstrating real value there there's no excuse. I talked to someone who wouldn't be named last night, in and around the area said, the CIA has a cost bar like this a cost-a budget like this but the demand for mission based apps is going up exponentially, so there's need for the Cloud. And so, you see more and more of that. What is your top down, aggressive goals to fill that solution base because you're also a very transformational thinker; what is your-what is your aggressive top down goals for your organization because you're serving a market with trillions of dollars of spend that's shifting, that's on the table. >> Yeah. >> A lot of competition now sees it too, they're going to go after it. But at the end of the day you have customers that have a demand for things, apps. >> Andy: Yeah. >> And not a lot of budget increase at the same time. This is a huge dynamic. >> Yeah. >> John: What's your goals? >> You know I think that at a high level our top down aggressive goals are that we want every single customer who uses our platform to have an outstanding customer experience. And we want that outstanding customer experience in part is that their operational performance and their security are outstanding, but also that it allows them to build, uh, build projects and initiatives that change their customer experience and allow them to be a sustainable successful business over a long period of time. And then, we also really want to be the technology infrastructure platform under all the applications that people build. And we're realistic, we know that you know, the market segments we address with infrastructure, software, hardware, and data center services globally are trillions of dollars in the long term and it won't only be us, but we have that goal of wanting to serve every application and that requires not just the security operational premise but also a lot of functionality and a lot of capability. We have by far the most amount of capability out there and yet I would tell you, we have 3 to 5 years of items on our roadmap that customers want us to add. And that's just what we know today. >> And Andy, underneath the covers you've been going through some transformation. When we talked a couple of years ago, about how serverless is impacting things I've heard that that's actually, in many ways, glue behind the two pizza teams to work between organizations. Talk about how the internal transformations are happening. How that impacts your discussions with customers that are going through that transformation. >> 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 too, we saw the need, you 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, 3 or 4 hundred milliseconds then we'd 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 Lambda people understandably said, well if we build Lambda and we build this serverless adventure in 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 that'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 going to spend less money, what really ends up happening is they spend less money per unit of compute but it allows them to do so much more that they ultimately, long term, end up being more significant customers. >> I mean, you are like beating the drum all the time. Customers, what they say, we encompass the roadmap, I got that you guys have that playbook down, that's been really successful for you. >> Andy: Yeah. >> Two years ago you told me machine learning was really important to you because your customers told you. What's the next traunch of importance for customers? What's on top of mind now, as you, look at- >> Andy: Yeah. >> This re:Invent kind of coming to a close, Replay's tonight, you had conversations, you're a tech athlete, you're running around, doing speeches, talking to customers. What's that next hill from if it's machine learning today- >> There's so much I mean, (weird background noise) >> It's not a soup question (Laughter) And I think we're still in the very early days of machine learning it's not like most companies have mastered it yet even though they're using it much more then they did in the past. But, you know, I think machine learning for sure I think the Edge for sure, I think that um, we're optimistic about Quantum Computing even though I think it'll be a few years before it's really broadly useful. We're very um, enthusiastic about robotics. I think the amount of functions that are going to be done by these- >> Yeah. >> robotic applications are much more expansive than people realize. It doesn't mean humans won't have jobs, they're just going to work on things that are more value added. We're believers in augmented virtual reality, we're big believers in what's going to happen with Voice. And I'm also uh, I think sometimes people get bored you know, I think you're even bored with machine learning already >> Not yet. >> People get bored with the things you've heard about but, I think just what we've done with the Chips you know, in terms of giving people 40% better price performance in the latest generation of X86 processors. It's pretty unbelievable in the difference in what people are going to be able to do. Or just look at big data I mean, big data, we haven't gotten through big data where people have totally solved it. The amount of data that companies want to store, process, analyze, is exponentially larger than it was a few years ago and it will, I think, exponentially increase again in the next few years. You need different tools and services. >> Well I think we're not bored with machine learning we're excited to get started because we have all this data from the video and you guys got SageMaker. >> Andy: Yeah. >> We call it the stairway to machine learning heaven. >> Andy: Yeah. >> You start with the data, move up, knock- >> You guys are very sophisticated with what you do with technology and machine learning and there's so much I mean, we're just kind of, again, in such early innings. And I think that, it was so- before SageMaker, it was so hard for everyday developers and data scientists to build models but the combination of SageMaker and what's happened with thousands of companies standardizing on it the last two years, plus now SageMaker studio, giant leap forward. >> Well, we hope to use the data to transform our experience with our audience. And we're on Amazon Cloud so we really appreciate that. >> Andy: Yeah. >> And appreciate your support- >> Andy: Yeah, of course. >> John: With Amazon and get that machine learning going a little faster for us, that would be better. >> If you have requests I'm interested, yeah. >> So Andy, you talked about that you've got the customers that are builders and the customers that need simplification. Traditionally when you get into the, you know, the heart of the majority of adoption of something you really need to simplify that environment. But when I think about the successful enterprise of the future, they need to be builders. how'l I normally would've said enterprise want to pay for solutions because they don't have the skill set but, if they're going to succeed in this new economy they need to go through that transformation >> Andy: Yeah. >> That you talk to, so, I mean, are we in just a total new era when we look back will this be different than some of these previous waves? >> It's a really good question Stu, and I don't think there's a simple answer to it. I think that a lot of enterprises in some ways, I think wish that they could just skip the low level building blocks and only operate at that higher level abstraction. That's why people were so excited by things like, SageMaker, or CodeGuru, or Kendra, or Contact Lens, these are all services that allow them to just send us data and then run it on our models and get back the answers. But I think one of the big trends that we see with enterprises is that they are taking more and more of their development in house and they are wanting to operate more and more like startups. I think that they admire what companies like AirBnB and Pintrest and Slack and Robinhood and a whole bunch of those companies, Stripe, have done and so when, you know, I think you go through these phases and eras where there are waves of success at different companies and then others want to follow that success and replicate it. And so, we see more and more enterprises saying we need to take back a lot of that development in house. And as they do that, and as they add more developers those developers in most cases like to deal with the building blocks. And they have a lot of ideas on how they can creatively stich them together. >> Yeah, on that point, I want to just quickly ask you on Amazon versus other Clouds because you made a comment to me in our interview about how hard it is to provide a service to other people. And it's hard to have a service that you're using yourself and turn that around and the most quoted line of my story was, the compression algorithm- there's no compression algorithm for experience. Which to me, is the diseconomies of scale for taking shortcuts. >> Andy: Yeah. And so I think this is a really interesting point, just add some color commentary because I think this is a fundamental difference between AWS and others because you guys have a trajectory over the years of serving, at scale, customers wherever they are, whatever they want to do, now you got microservices. >> Yeah. >> John: It's even more complex. That's hard. >> Yeah. >> John: Talk about that. >> I think there are a few elements to that notion of there's no compression algorithm for experience and I think the first thing to know about AWS which is different is, we just come from a different heritage and a different background. We ran a business for a long time that was our sole business that was a consumer retail business that was very low margin. And so, we had to operate at very large scale given how many people were using us but also, we had to run infrastructure services deep in the stack, compute storage and database, and reliable scalable data centers at very low cost and margins. And so, when you look at our business it actually, today, I mean its, its a higher margin business in our retail business, its a lower margin business in software companies but at real scale, it's a high volume, relatively low margin business. And the way that you have to operate to be successful with those businesses and the things you have to think about and that DNA come from the type of operators we have to be in our consumer retail business. And there's nobody else in our space that does that. So, you know, the way that we think about costs, the way we think about innovation in the data center, um, and I also think the way that we operate services and how long we've been operating services as a company its a very different mindset than operating package software. Then you look at when uh, you think about some of the uh, issues in very large scale Cloud, you can't learn some of those lessons until you get to different elbows of the curve and scale. And so what I was telling you is, its really different to run your own platform for your own users where you get to tell them exactly how its going to be done. But that's not the way the real world works. I mean, we have millions of external customers who use us from every imaginable country and location whenever they want, without any warning, for lots of different use cases, and they have lots of design patterns and we don't get to tell them what to do. And so operating a Cloud like that, at a scale that's several times larger than the next few providers combined is a very different endeavor and a very different operating rigor. >> Well you got to keep raising the bar you guys do a great job, really impressed again. Another tsunami of announcements. In fact, you had to spill the beans earlier with Quantum the day before the event. Tight schedule. I got to ask you about the musical festival because, I think this is a very cool innovation. It's the inaugural Intersect conference. >> Yes. >> John: Which is not part of Replay, >> Yes. >> John: Which is the concert tonight. Its a whole new thing, big music act, you're a big music buff, your daughter's an artist. Why did you do this? What's the purpose? What's your goal? >> Yeah, it's an experiment. I think that what's happened is that re:Invent has gotten so big, we have 65 thousand people here, that to do the party, which we do every year, its like a 35-40 thousand person concert now. Which means you have to have a location that has multiple stages and, you know, we thought about it last year and when we were watching it and we said, we're kind of throwing, like, a 4 hour music festival right now. There's multiple stages, and its quite expensive to set up that set for a party and we said well, maybe we don't have to spend all that money for 4 hours and then rip it apart because actually the rent to keep those locations for another two days is much smaller than the cost of actually building multiple stages and so we thought we would try it this year. We're very passionate about music as a business and I think we-I think our customers feel like we've thrown a pretty good music party the last few years and we thought we would try it at a larger scale as an experiment. And if you look at the economics- >> At the headliners real quick. >> The Foo Fighters are headlining on Saturday night, Anderson Paak and the Free Nationals, Brandi Carlile, Shawn Mullins, um, Willy Porter, its a good set. Friday night its Beck and Kacey Musgraves so it's a really great set of um, about thirty artists and we're hopeful that if we can build a great experience that people will want to attend that we can do it at scale and it might be something that both pays for itself and maybe, helps pay for re:Invent too overtime and you know, I think that we're also thinking about it as not just a music concert and festival the reason we named it Intersect is that we want an intersection of music genres and people and ethnicities and age groups and art and technology all there together and this will be the first year we try it, its an experiment and we're really excited about it. >> Well I'm gone, congratulations on all your success and I want to thank you we've been 7 years here at re:Invent we've been documenting the history. You got two sets now, one set upstairs. So appreciate you. >> theCUBE is part of re:Invent, you know, you guys really are apart of the event and we really appreciate your coming here and I know people appreciate the content you create as well. >> And we just launched CUBE365 on Amazon Marketplace built on AWS so thanks for letting us- >> Very cool >> John: Build on the platform. appreciate it. >> Thanks for having me guys, I appreciate it. >> Andy Jassy the CEO of AWS here inside theCUBE, it's our 7th year covering and documenting the thunderous innovation that Amazon's doing they're really doing amazing work building out the new technologies here in the Cloud computing world. I'm John Furrier, Stu Miniman, be right back with more after this short break. (Outro music)

>> Hi, my name is Andy Clemenko. I'm a Senior Solutions Engineer at StackRox. Thanks for joining us today for my talk on labels, labels, labels. Obviously, you can reach me at all the socials. Before we get started, I like to point you to my GitHub repo, you can go to andyc.info/dc20, and it'll take you to my GitHub page where I've got all of this documentation, I've got the Keynote file there. YAMLs, I've got Dockerfiles, Compose files, all that good stuff. If you want to follow along, great, if not go back and review later, kind of fun. So let me tell you a little bit about myself. I am a former DOD contractor. This is my seventh DockerCon. I've spoken, I had the pleasure to speak at a few of them, one even in Europe. I was even a Docker employee for quite a number of years, providing solutions to the federal government and customers around containers and all things Docker. So I've been doing this a little while. One of the things that I always found interesting was the lack of understanding around labels. So why labels, right? Well, as a former DOD contractor, I had built out a large registry. And the question I constantly got was, where did this image come from? How did you get it? What's in it? Where did it come from? How did it get here? And one of the things we did to kind of alleviate some of those questions was we established a baseline set of labels. Labels really are designed to provide as much metadata around the image as possible. I ask everyone in attendance, when was the last time you pulled an image and had 100% confidence, you knew what was inside it, where it was built, how it was built, when it was built, you probably didn't, right? The last thing we obviously want is a container fire, like our image on the screen. And one kind of interesting way we can kind of prevent that is through the use of labels. We can use labels to address security, address some of the simplicity on how to run these images. So think of it, kind of like self documenting, Think of it also as an audit trail, image provenance, things like that. These are some interesting concepts that we can definitely mandate as we move forward. What is a label, right? Specifically what is the Schema? It's just a key-value. All right? It's any key and pretty much any value. What if we could dump in all kinds of information? What if we could encode things and store it in there? And I've got a fun little demo to show you about that. Let's start off with some of the simple keys, right? Author, date, description, version. Some of the basic information around the image. That would be pretty useful, right? What about specific labels for CI? What about a, where's the version control? Where's the source, right? Whether it's Git, whether it's GitLab, whether it's GitHub, whether it's Gitosis, right? Even SPN, who cares? Where are the source files that built, where's the Docker file that built this image? What's the commit number? That might be interesting in terms of tracking the resulting image to a person or to a commit, hopefully then to a person. How is it built? What if you wanted to play with it and do a git clone of the repo and then build the Docker file on your own? Having a label specifically dedicated on how to build this image might be interesting for development work. Where it was built, and obviously what build number, right? These kind of all, not only talk about continuous integration, CI but also start to talk about security. Specifically what server built it. The version control number, the version number, the commit number, again, how it was built. What's the specific build number? What was that job number in, say, Jenkins or GitLab? What if we could take it a step further? What if we could actually apply policy enforcement in the build pipeline, looking specifically for some of these specific labels? I've got a good example of, in my demo of a policy enforcement. So let's look at some sample labels. Now originally, this idea came out of label-schema.org. And then it was a modified to opencontainers, org.opencontainers.image. There is a link in my GitHub page that links to the full reference. But these are some of the labels that I like to use, just as kind of like a standardization. So obviously, Author's, an email address, so now the image is attributable to a person, that's always kind of good for security and reliability. Where's the source? Where's the version control that has the source, the Docker file and all the assets? How it was built, build number, build server the commit, we talked about, when it was created, a simple description. A fun one I like adding in is the healthZendpoint. Now obviously, the health check directive should be in the Docker file. But if you've got other systems that want to ping your applications, why not declare it and make it queryable? Image version, obviously, that's simple declarative And then a title. And then I've got the two fun ones. Remember, I talked about what if we could encode some fun things? Hypothetically, what if we could encode the Compose file of how to build the stack in the first image itself? And conversely the Kubernetes? Well, actually, you can and I have a demo to show you how to kind of take advantage of that. So how do we create labels? And really creating labels as a function of build time okay? You can't really add labels to an image after the fact. The way you do add labels is either through the Docker file, which I'm a big fan of, because it's declarative. It's in version control. It's kind of irrefutable, especially if you're tracking that commit number in a label. You can extend it from being a static kind of declaration to more a dynamic with build arguments. And I can show you, I'll show you in a little while how you can use a build argument at build time to pass in that variable. And then obviously, if you did it by hand, you could do a docker build--label key equals value. I'm not a big fan of the third one, I love the first one and obviously the second one. Being dynamic we can take advantage of some of the variables coming out of version control. Or I should say, some of the variables coming out of our CI system. And that way, it self documents effectively at build time, which is kind of cool. How do we view labels? Well, there's two major ways to view labels. The first one is obviously a docker pull and docker inspect. You can pull the image locally, you can inspect it, you can obviously, it's going to output as JSON. So you going to use something like JQ to crack it open and look at the individual labels. Another one which I found recently was Skopeo from Red Hat. This allows you to actually query the registry server. So you don't even have to pull the image initially. This can be really useful if you're on a really small development workstation, and you're trying to talk to a Kubernetes cluster and wanting to deploy apps kind of in a very simple manner. Okay? And this was that use case, right? Using Kubernetes, the Kubernetes demo. One of the interesting things about this is that you can base64 encode almost anything, push it in as text into a label and then base64 decode it, and then use it. So in this case, in my demo, I'll show you how we can actually use a kubectl apply piped from the base64 decode from the label itself from skopeo talking to the registry. And what's interesting about this kind of technique is you don't need to store Helm charts. You don't need to learn another language for your declarative automation, right? You don't need all this extra levels of abstraction inherently, if you use it as a label with a kubectl apply, It's just built in. It's kind of like the kiss approach to a certain extent. It does require some encoding when you actually build the image, but to me, it doesn't seem that hard. Okay, let's take a look at a demo. And what I'm going to do for my demo, before we actually get started is here's my repo. Here's a, let me actually go to the actual full repo. So here's the repo, right? And I've got my Jenkins pipeline 'cause I'm using Jenkins for this demo. And in my demo flask, I've got the Docker file. I've got my compose and my Kubernetes YAML. So let's take a look at the Docker file, right? So it's a simple Alpine image. The org statements are the build time arguments that are passed in. Label, so again, I'm using the org.opencontainers.image.blank, for most of them. There's a typo there. Let's see if you can find it, I'll show you it later. My source, build date, build number, commit. Build number and get commit are derived from the Jenkins itself, which is nice. I can just take advantage of existing URLs. I don't have to create anything crazy. And again, I've got my actual Docker build command. Now this is just a label on how to build it. And then here's my simple Python, APK upgrade, remove the package manager, kind of some security stuff, health check getting Python through, okay? Let's take a look at the Jenkins pipeline real quick. So here is my Jenkins pipeline and I have four major stages, four stages, I have built. And here in build, what I do is I actually do the Git clone. And then I do my docker build. From there, I actually tell the Jenkins StackRox plugin. So that's what I'm using for my security scanning. So go ahead and scan, basically, I'm staging it to scan the image. I'm pushing it to Hub, okay? Where I can see the, basically I'm pushing the image up to Hub so such that my StackRox security scanner can go ahead and scan the image. I'm kicking off the scan itself. And then if everything's successful, I'm pushing it to prod. Now what I'm doing is I'm just using the same image with two tags, pre-prod and prod. This is not exactly ideal, in your environment, you probably want to use separate registries and non-prod and a production registry, but for demonstration purposes, I think this is okay. So let's go over to my Jenkins and I've got a deliberate failure. And I'll show you why there's a reason for that. And let's go down. Let's look at my, so I have a StackRox report. Let's look at my report. And it says image required, required image label alert, right? Request that the maintainer, add the required label to the image, so we're missing a label, okay? One of the things we can do is let's flip over, and let's look at Skopeo. Right? I'm going to do this just the easy way. So instead of looking at org.zdocker, opencontainers.image.authors. Okay, see here it says build signature? That was the typo, we didn't actually pass in. So if we go back to our repo, we didn't pass in the the build time argument, we just passed in the word. So let's fix that real quick. That's the Docker file. Let's go ahead and put our dollar sign in their. First day with the fingers you going to love it. And let's go ahead and commit that. Okay? So now that that's committed, we can go back to Jenkins, and we can actually do another build. And there's number 12. And as you can see, I've been playing with this for a little bit today. And while that's running, come on, we can go ahead and look at the Console output. Okay, so there's our image. And again, look at all the build arguments that we're passing into the build statement. So we're passing in the date and the date gets derived on the command line. With the build arguments, there's the base64 encoded of the Compose file. Here's the base64 encoding of the Kubernetes YAML. We do the build. And then let's go down to the bottom layer exists and successful. So here's where we can see no system policy violations profound marking stack regimes security plugin, build step as successful, okay? So we're actually able to do policy enforcement that that image exists, that that label sorry, exists in the image. And again, we can look at the security report and there's no policy violations and no vulnerabilities. So that's pretty good for security, right? We can now enforce and mandate use of certain labels within our images. And let's flip back over to Skopeo, and let's go ahead and look at it. So we're looking at the prod version again. And there's it is in my email address. And that validated that that was valid for that policy. So that's kind of cool. Now, let's take it a step further. What if, let's go ahead and take a look at all of the image, all the labels for a second, let me remove the dash org, make it pretty. Okay? So we have all of our image labels. Again, author's build, commit number, look at the commit number. It was built today build number 12. We saw that right? Delete, build 12. So that's kind of cool dynamic labels. Name, healthz, right? But what we're looking for is we're going to look at the org.zdockerketers label. So let's go look at the label real quick. Okay, well that doesn't really help us because it's encoded but let's base64 dash D, let's decode it. And I need to put the dash r in there 'cause it doesn't like, there we go. So there's my Kubernetes YAML. So why can't we simply kubectl apply dash f? Let's just apply it from standard end. So now we've actually used that label. From the image that we've queried with skopeo, from a remote registry to deploy locally to our Kubernetes cluster. So let's go ahead and look everything's up and running, perfect. So what does that look like, right? So luckily, I'm using traefik for Ingress 'cause I love it. And I've got an object in my Kubernetes YAML called flask.doctor.life. That's my Ingress object for traefik. I can go to flask.docker.life. And I can hit refresh. Obviously, I'm not a very good web designer 'cause the background image in the text. We can go ahead and refresh it a couple times we've got Redis storing a hit counter. We can see that our server name is roundrobing. Okay? That's kind of cool. So let's kind of recap a little bit about my demo environment. So my demo environment, I'm using DigitalOcean, Ubuntu 19.10 Vms. I'm using K3s instead of full Kubernetes either full Rancher, full Open Shift or Docker Enterprise. I think K3s has some really interesting advantages on the development side and it's kind of intended for IoT but it works really well and it deploys super easy. I'm using traefik for Ingress. I love traefik. I may or may not be a traefik ambassador. I'm using Jenkins for CI. And I'm using StackRox for image scanning and policy enforcement. One of the things to think about though, especially in terms of labels is none of this demo stack is required. You can be in any cloud, you can be in CentOs, you can be in any Kubernetes. You can even be in swarm, if you wanted to, or Docker compose. Any Ingress, any CI system, Jenkins, circle, GitLab, it doesn't matter. And pretty much any scanning. One of the things that I think is kind of nice about at least StackRox is that we do a lot more than just image scanning, right? With the policy enforcement things like that. I guess that's kind of a shameless plug. But again, any of this stack is completely replaceable, with any comparative product in that category. So I'd like to, again, point you guys to the andyc.infodc20, that's take you right to the GitHub repo. You can reach out to me at any of the socials @clemenko or andy@stackrox.com. And thank you for attending. I hope you learned something fun about labels. And hopefully you guys can standardize labels in your organization and really kind of take your images and the image provenance to a new level. Thanks for watching. (upbeat music)

(enlightening music) >> From theCUBE's studios in Palo Alto and Boston, connecting with thought leaders all around the world, this is a CUBE conversation. >> As we've been reporting, there's a new class of workloads emerging in the cloud. Early cloud was all about IaaS, spinning up storage, compute, and networking infrastructure to support startups, SaaS, easy experimentation, dev test, and increasingly moving business workloads into the cloud. Modern cloud workloads are combining data. They're infusing machine intelligence into application's AI. They're simplifying analytics and scaling with the cloud to deliver business insights in near real time. And at the center of this mega trend is a new class of data stores and analytic databases, what some called data warehouses, a term that I think is outdated really for today's speed of doing business. Welcome to this week's Wikibon CUBE Insights, powered by ETR. In this breaking analysis, we update our view of the emerging cloud native analytic database market. Today, we want to do three things. First, we'll update you on the basics of this market, what you really need to know in the space. The next thing we're going to do, take a look into the competitive environment, and as always, we'll dig into the ETR spending data to see which companies have the momentum in the market, and maybe, ahead of some of the others. Finally, we're going to close with some thoughts on how the competitive landscape is likely to evolve. And we want to answer the question will the cloud giants overwhelm the upstarts, or will the specialists continue to thrive? Let's take a look at some of the basics of this market. We're seeing the evolution of the enterprise data warehouse market space. It's an area that has been critical to supporting reporting and governance requirements for companies, especially post Sarbanes-Oxley, right? However, historically, as I've said many times, EDW has failed to deliver on its promises of a 360-degree view of the business and real-time customer insights. Classic enterprise data warehouses are too cumbersome, they're too complicated, they're too slow, and don't keep pace with the speed of the business. Now, EDW is about a $20 billion market, but the analytic database opportunity in the cloud, we think is much larger, why is that? It's because cloud computing unlocks the ability to rapidly combine multiple data sources, bring data science tooling into the mix, very quickly analyze data, and deliver insights to the business. More importantly, even more importantly, allow a line of business pros to access data in a self service mode. It's a new paradigm that uses the notion of DevOps as applied to the data pipeline, agile data or what we sometimes called DataOps. This is a highly competitive marketplace. In the early part of last decade, you saw Google bring BigQuery to market, Snowflake was founded, AWS did a one-time license deal to acquire the IP to ParAccel, an MPP database, on which it built Redshift. In the latter part of the decade, Microsoft threw his hat in the ring with SQL DW, which Microsoft has now evolved into Azure Synapse. They did so at the Build conference, a few weeks ago. There are other players as well like IBM. So you can see, there's a lot at stake here. The cloud vendors want your data, because they understand this is one of the key ingredients of the next decade of innovation. No longer is Moore's Law, the mainspring of growth. We've said this many times. Rather today, it's data driven, and AI to push insights and scale with the cloud. Here's the interesting dynamic that is emerging in the space. Snowflake is a cloud specialist in this field, having raised more than a billion dollars in venture, a billion four, a billion five. And it's up against the big cloud players, who are moving fast and often stealing moves from Snowflake and driving customers to their respective platforms. Here's an example that we reported on at last year's re:Invent. It's an article by Tony Baer. He wrote this on ZDNet talking about how AWS RA3 separates compute from storage, and of course, this was a founding architectural principle for Snowflake. Here's another example from the information. They were reporting on Microsoft here turning up the heat on Snowflake. And you can see the highlighted text, where the author talks about Microsoft trying to divert customers to its database. So you got this weird dynamic going on. Snowflake doesn't run on-prem, it only runs in the cloud. Runs on AWS, runs on Azure, runs on GCP. The cloud players again, they all want your data to go into their database. So they want you to put their data into their respective platforms. At the same time, they need SaaS ISVs to run in the cloud because it sells infrastructure services. So, is Snowflake, are they going to pivot to run on-prem to try to differentiate from the cloud giants? I asked Frank Slootman, Snowflake's CEO, about the on-prem opportunity, and his perspective earlier this year. Let's listen to what he said. >> Okay, we're not doing this endless hedging that people have done for 20 years, sort of keeping a leg in both worlds. Forget it, this will only work in the public cloud because this is how the utility model works, right? I think everybody is coming to this realization, right? I mean the excuses are running out at this point. We think that it'll, people will come to the public cloud a lot sooner than we will ever come to the private cloud. It's not that we can't run a private cloud, it just diminishes the potential and the value that we that we bring. >> Okay, so pretty definitive statements by Slootman. Now, the question I want to pose today is can Snowflake compete, given the conventional wisdom that we saw in the media articles that the cloud players are going to hurt Snowflake in this market. And if so, how will they compete? Well, let's see what the customers are saying and bring in some ETR survey data. This chart shows two of our favorite metrics from the ETR data set. That is Net Score, which is on the y-axis. Net Score, remember is a measure of spending momentum and market share, which is on the x-axis. Market share is a measure of pervasiveness in the data set. And what we show here are some of the key players in the EDW and cloud native analytic database market. I'll make a couple of points, and we'll dig into this a little bit further. First thing I want to share is you can see from this data, this is the April ETR survey, which was taken at the height of the US lockdown for the pandemic. The survey captured respondents from more than 1,200 CIOs and IT buyers, asking about their spending intentions for analytic databases for the companies that we show here on this kind of x-y chart. So the higher the company is on the vertical axis, the stronger the spending momentum relative to last year, and you could see Snowflake has a 77% Net Score. It leaves all players with AWS Redshift showing very strong, as well. Now in the box in the lower right, you see a chart. Those are the exact Net Scores for all the vendors in the Shared N. A Shared N is a number of citations for that vendor within the N of the 1,269. So you can see the N's are quite large, certainly large enough to feel comfortable with some of the conclusions that we're going to make today. Microsoft, they have a huge footprint. And they somewhat skew the data with its very high market share due to its volume. And you could see where Google sits, it's at good momentum, not as much presence in the marketplace. We've also added a couple of on-prem vendors, Teradata and Oracle primarily on-prem, just for context. They're two companies that compete, they obviously have some cloud offerings, but again, most of their base is on-prem. So what I want to do now is drill into this a little bit more by looking at Snowflake within the individual clouds. So let's look at Snowflake inside of AWS. That's what this next chart shows. So it's customer spending momentum Net Score inside of AWS accounts. And we cut the data to isolate those ETR survey respondents running AWS, so there's an N there of 672 that you can see. The bars show the Net Score granularity for Snowflake and Amazon Redshift. Now, note that we show 96 Shared N responses for Snowflake and 213 for Redshift within the overall N of 672 AWS accounts. The colors show 2020 spending intentions relative to 2019. So let's read left to right here. The replacements are red. And then, the bright red, then, you see spending less by 6% or more, that's the pinkish, and then, flat spending, the gray, increasing spending by more than 6%, that's the forest green, and then, adding to the platform new, that's the lime green. Now, remember Net Score is derived by subtracting the reds from the greens. And you can see that Snowflake has more spending momentum in the AWS cloud than Amazon Redshift, by a small margin, but look at, 80% of the AWS accounts plan to spend more on Snowflake with 35%, they're adding new. Very strong, 76% of AWS customers plan to spend more in 2020 relative to 2019 on Redshift with only 12% adding the platform new. But nonetheless, both are very, very strong, and you can see here, the key point is minimal red and pink, but not a lot of people leaving, not a lot of people spending less. It's going to be critical to see in the June ETR survey, which is in the field this month, if Snowflake is able to hold on to these new accounts that it's gained in the last couple of months. Now, let's look at how Snowflake is doing inside of Azure and compare it to Microsoft. So here's the data from the ETR survey, same view of the data here except we isolate on Azure accounts. The N there is 677 Azure accounts. And we show Snowflake and Microsoft cuts for analytic databases with 83 and 393 Shared N responses respectively. So again, enough I feel to draw some conclusions from this data. Now, note the Net Scores. Snowflake again, winning with 78% versus 51% from Microsoft. 51% is strong but 78% is there's a meaningful lead for Snowflake within the Microsoft base, very interesting. And once again, you see massive new ads, 41% for Snowflake, whereas Microsoft's Net Score is being powered really by growth from existing customers, that forest green. And again, very little red for both companies. So super positive there. Okay, let's take a look now at how Snowflake's doing inside of Google accounts, GCP, Google Cloud Platform. So here's the ETR data, same view of that data, but now, we isolate on GCP accounts. There are fewer, 298 running, then, you got those running Snowflake and Google Analytic databases, largely BigQuery, but could be some others in there but the Snowflake Shared N is 49, it's smaller than on the other clouds, because the company just announced support for GCP, just about a year ago. I think it was last June, but still large enough to draw conclusions from the data. I feel pretty comfortable with that. We're not slicing and dicing it too finely. And you could see Google Shared N at 147. Look at the story. I sound like a broken record. Snowflake is again winning by a meaningful margin if you measure this Net Score or spending momentum. So 77.6% Net Score versus Google at 54%, with Snowflake at 80% in the green. Both companies, very little red. So this is pretty impressive. Snowflake has greater spending momentum than the captive cloud providers in all three of the big US-based clouds. So the big question is can Snowflake hold serve, and continue to grow, and how are they going to to be able to do that? Look, as I said before, this is a very competitive market. We reported that how Snowflake is taking share from some of the legacy on-prem data warehouse players like Teradata and IBM, and from what our data suggests, Lumen and Oracle too. I've reported how IBM is stretched thin on its research and development budget, spends about $6 billion a year, but it's got to spend it across a lot of different lines. Oracle's got more targeted spending R&D. They can target more toward database and direct more of its free cash flow to database than IBM can. But Amazon, and Microsoft, and Google, they don't have that problem. They spend a ton of dough on R&D. And here's an example of the challenge that Snowflake faces. Take a look at this partial list that I drew together of recent innovations. And we show here a set of features that Snowflake has launched in 2020, and AWS since re:Invent last year. I don't have time to go into these, but we do know this that AWS is no slouch at adding features. Amazon, as a company, spends two x more on research and development than Snowflake is worth as a company. So why do I like Snowflake's chances. Well, there are several reasons. First, every dime that Snowflake spends on R&D, go-to market, and ecosystem, goes into making its databases better for its customers. Now, I asked Frank Slootman in the middle of the lockdown how he was allocating precious capital during the pandemic. Let's listen to his response. I've said, there's no layoffs on our radar, number one. Number two, we are hiring. And number three is, we have a higher level of scrutiny on the hires that we're making. And I am very transparent. In other words, I tell people, "Look, I prioritize the roles that are closest "to the drivetrain of the business." Right, it's kind of common sense. But I wanted to make sure that this is how we're thinking about this. There are some roles that are more postponable than others. I'm hiring in engineering, without any reservation because that is the long term, strategic interest of the company. >> But you know, that's only part of the story. And so I want to spend a moment here on some other differentiation, which is multi-cloud. Now, as many of you know, I've been sort of cynical of multi-cloud up until recently. I've said that multi-cloud is a symptom, more of a symptom of multi-vendor and largely, a bunch of vendor marketing hooey today. But that's beginning to change. I see multi-cloud as increasingly viable and important to organizations, not only because CIOs are being asked to clean up the crime scene, as I've often joked, but also because it's increasingly becoming a strategy, right cloud for the right workload. So first, let me reiterate what I said at the top. New workloads are emerging in the cloud, real-time AI, insights extraction, and real-time inferencing is going to be a competitive differentiator. It's all about the data. The new innovation cocktail stems from machine intelligence applied to that data with data science tooling and simplified interfaces that enable scaling with the cloud. You got to have simplicity if you're going to scale and cloud is the best way to scale. It's really the only way to scale globally. So as such, we see cross-cloud exploitation is a real differentiator for Snowflake and others that build high quality cloud native capabilities from multiple clouds, and I want to spend a minute on this topic generally and talk about what it means for Snowflake specifically. Now, we've been pounding the table lately saying that building capabilities natively for the cloud versus putting a wrapper around your stack and making it run in the cloud is key. It's a big difference, why is this? Because cloud native means taking advantage of the primitive capabilities within respective clouds to create the highest performance, the lowest latency, the most efficient services, for that cloud, and the most secure, really exploiting that cloud. And this is enabled only by natively building in the cloud, and that's why Slootman is so dogmatic on this issue. Multi-cloud can be a differentiator for Snowflake. We can think about data lives everywhere. And you want to keep data, where it lives ideally, you don't want to have to move it, whether it's on AWS, Azure, whatever cloud is holding that data. If the answer to your query requires tapping data that lives in multiple clouds across a data network, and the app needs fast answers, then, you need low latency access to that data. So here's what I think. I think Snowflake's game is to automate by extracting, abstracting, sorry, the complexity around the data location, of course, latency is a part of that, metadata, bandwidth concerns, the time to get to query and answers. All those factors that build complexity into the data pipeline and then optimizing that to get insights, irrespective of data location. So a differentiating formula is really to not only be the best analytic database but be cloud agnostic. AWS, for example, they got a cloud agenda, as do Azure and GCP. Their number one answer to multi-cloud is put everything on our cloud. Yeah, Microsoft and Google Anthos, they would argue against that but we know that behind the scenes, that's what they want. They got offerings across clouds but Snowflake is going to make this a top priority. They can lead with that, and they must be best at it. And if Snowflake can do this, it's going to have a very successful future, in our opinion. And by all accounts, and the data that we shared, Snowflake is executing well. All right, so that's a wrap for this week's CUBE Insights, powered by ETR. Don't forget, all these breaking analysis segments are available as podcasts, just Google breaking analysis with Dave Vellante. I publish every week on wikibon.com and siliconangle.com. Check out etr.plus. That's where all the survey data is and reach out to me, I'm @dvellante on Twitter, or you can hit me up on my LinkedIn posts, or email me at david.vellante@siliconangle.com. Thanks for watching, everyone. We'll see you next time. (enlightening music)

>> Announcer: From around the globe, it's theCUBE. With digital coverage of Dockercon live 2020. Brought to you by, Docker, and its ecosystem partners. >> Hey, welcome back everyone to the DockerCon 2020, #DockerCon20. This is The Cube virtual coverage with Docker on their event here. And we're in the studio in Palo Alto, I'm John Furrier your host of theCUBE, we're here with a great guest to talk about Docker Desktop, the Microsoft relationship, and the key news that's coming out. Ben De St Paer-Gotch is the product manager for Docker Desktop. Ben, great for coming on, thanks for spending the time with me. >> Thanks for having me, I really appreciate it. >> So obviously, this is a virtual conference, we wish we could be in person, but given the state of affairs we're going to do remotely, but the momentum Docker has is phenomenal, it's always been great with containers. It's the number one downloaded app around for developers. Microsoft just had their Build conference, which was again virtual as well, or digital, as they say, it's interchangeable. But clear momentum now with Docker as containers actually is the standard, you guys are doing great. What's the key news out of the Microsoft world for people who missed it last week with MS Build? >> Yeah, so last year at Build, Microsoft announced WSO2 to the Windows subsystem with Linux two. (mumbles) The mapping between the windows (mumbles) Which, went really well but it just didn't provide the same centered needed Linux experience. Last year, they announced Windows subsystem Linux two, (Provides an actual Linux one on windows machine, and we've been working hard with Microsoft over the last year to integrate proper desktop as a main desktop application for working with containers with WSO2. A build this year, Microsoft has gone on and announced that WSO2 is going to have a few new features, and it's going to have new features. (mumbles) Mention Linux graphical, Linux applications, you can access the file system, the installation is going to become a slicker which I guess I'm the most excited about that pitch. But the most exciting announcement is, they will be bringing GPU support to WSO2 which means that we will be able to provide and give you support through Docker desktop or container workloads that peoples are working on. And now we're launching Gray and Agua through containers and docks and desktops and Windows which is really cool because we haven't been able to do that before. >> So is this the first GPU support on Microsoft Windows for Docker, with Docker? >> It's, yeah, it's the first GPU Support for Docker Desktop or Mac or Windows. So, previously the hypervisor hasn't passed through the GPU, pretty much, which meant that we couldn't access it from Docker desktop. So Docker desktop isn't about a lightweight VM we sorts of plumb all that in for you. But we're limited about what we could get access to from the hypervisor, Microsoft putting this through and giving us access for the first time, we can actually, we can go. >> Not to go on a side tangent here, but you know, all these virtual events, and I was watching some of the build stuff as well, as well as us immediate streamers and doing stuff, you can see people's home rigs. And you talk to any Developer, video streamer, or anyone who is working remotely, if you don't have the best GPU's in there, I mean, this has just become, I mean, quite frankly, you need the GPU's. So this is important, it's not only from a vanity standpoint performance. Having that support, I'm going to want the best GPU's, I'm always going to be upgrading my machine for that extra power. What's the impact? What does it mean for me as a Developer? Does it increase stuff? What's the bottom line? >> As a Developer, it means you actually have access to it. So, especially when you're doing workloads on the CPU, you've got minimum amounts of power utilization you can do. When you're running workloads for an L Development, you have a lot of power up process you've got to log, to do your mobile training. So, in an element cycle, you're likely to have your application which you're going to use to produce a modeling, you're going to have training data. Taking that training data and producing a model requires lots of panel processing which is an enormous calculations in producing with finer waitings. Doing that on a CPU has to be done on a serial fashion rather than parallel, which is huge and intensive and takes a really long time. Whereas on a GPU, you can do all of that in parallel which massively reduces the amount of time it will take to run those training functions. Either just straight up in Linux or running them in a container, which as the more of people are looking at running container with workloads, it's how I first, the first team that I was on actually used Docker. I was working in Amazon Alexa, and my team picked up the opportunity to run our workload in container. And that was my first experience, so even though my team backed down, so I could see the system. >> Yeah, ML workloads automations could be critical of that performance. Okay, let's get into some of the momentum with Microsoft, you guys have obviously, builds over, we're here now at DockerCon, there's news. Could you share some of the tidbits for what's being talked about now with Docker and DockerCon. >> Yeah, absolutely, so, along with everything else we've been doing, we've been partnering with Microsoft trying to make the best experience generally with Docker desktop, and with WSO2 and with the VSCO. I've been working closely with Microsoft guys to actually try and improve our experience in Windows as it is today, and to improve some of those integrations with VSCO, and also working with the VSCO team on the Docker plugin for VSCO to give our feedback, and to hear feedback from those guys on the errors and issues they're seeing with Docker desktop and to really try to produce the best experience we can on Windows. End to end, from very front end running all the way through that first push, that first run on the cloud using Docker. >> So what is some of the new product management processes and customer support things that you guys are doing? This comes up a lot, obviously, we had a great conversation around shift left with security. That's great news there. You start to see a lot of this added value for Developers, wanted their support right? So how do I get things I need, and from a customer standpoint? It's kind of a moving train this world and it's only getting better and better from a Developer standpoint. But there's more complexity, it's got to be abstract the way you've got, you know, this new abstraction layers developing. You've got a lot of automation. How does the customer get the support they need in the same agile way that Developers are cranking out code? >> It's a really good question, it's something I think we're still working on as well. So, we're trying to working out and one of the big things I'm trying to work out is, how to make it easier for people to get started with Docker, and how do we also make sure with the things we build, we don't leave a cliff edge instead of a lining path. You don't get to a certain point in an easy process, and then the next step, takes you straight off a cliff, so that's not useful for anyone. So, producing those parts and those ways for people to learn and actually progress is something we're really trying to work out. How to make it natural from the first experience all the way through. From an actual support perspective, the other thing we're looking at, is we're trying to do more things in the open. We're really trying at Docker to bring as many of the new features and pieces we're developing which we have to do that in the open with community visibility, so that if people really want it fixed, they can open the PR and they can help us out. And then the last thing that my team really stood out was our Docker of having actions. As creators, someone already finished, could you do this? Someone else had a PR and emerged it. So, to a certain extent, you've got your one side which had you on board and this ever growth spiral and you keep learning. The other side is how'd you fix the board when you find an issue? In that one, we're really trying to work with the community, a lot more than we have in the last couple of years. >> Awesome, some folks watching, hit him up on Twitter, he's the Product Manager for Docker Desktop among other things. You guys are very transparent, you've got your Twitter handle on the lower third. People can chime in or just jump on the chat, we'll follow up and get you the info. Final question for you Ben, as you look at this reality we're in, there's kind of a holistic kind of moment now where people kind of realizing the new realities here. You're looking at the.. you get the keys to the kingdom with Docker Desktop, okay. You got some momentum with Microsoft, the developer role is moving fast and fast as the head room increases for capabilities with automation. And I know you mentioned a few of those things. GPU is now available. What's the future look like for these Developers? The next short, medium and long term? What's your view as you look out over the landscape because you've got to look at the product roadmap, your engagement with the community. Can you share some insight into how you're thinking about Docker Desktop going forward? >> Yeah, absolutely. So, I think what really interesting point as you say, which is that, if you look at sort of a lot of the Developer side of things that have sort of come out in the last like six months, six to eighteen months. The things I see, I see daily like you mention, things like orchestrating for containers gaining momentum. If you think about crossing the Kaizen model, we're just passed the early Dockers now. We're kind of into the early majority, but we're going to start to move over the next few years into the late majority. What that really means is that people here have been using one of two of these technologies. Maybe you've been using cloud, maybe you've been using Edge, maybe you've been using containers, maybe you've been using CICD, maybe you are using Expiration, maybe you're not. Maybe you've got a Microservice application, maybe it's a little bit of a mole rat. What we're really going to see is, you're going to start to see, all of these changes intersecting and overlapping. And people who have started to pick up model two of these will start to pick up all of them. And that's probably going to happen as we move into the majority of users. So from a what's coming instead of a lot of those thing that you see in best practice in the ideal Developer setup, so a beautiful CICD, a more of an orchestrated environment, Microservice architecture, we're going to see a lot more of that becoming the norm. But I think along with that, we'll also see a level of recognition coming along that a single Microservice alone doesn't provide value. And that's it's going to be some of those groups of services that will provide the user outcome. And that's where my focus is at the end which is you know, an authentication service is great but it doesn't provide value unless you give access to something as authentic. >> It's been issued that the new Docker is all about Developer experience. This is really the core mission. I mean, since the sale of the piece of morantis, Docker has retrenched and reinvented, but stayed core to its principles. Just share with the Developers who've been watching that are coming back into the ecosystem, what is this new Docker vibe? Share your thoughts. >> The new Docker vibe is about working in the open, and it's about solving problems for Developments. The original goal of Docker was to make it easy to pack and ship. It was to reduce Developer friction. As we move more into, sort of, the enterprise space, we worry more about Ops and DevOps. We're not trying to re-focus on Developer and if you sort of think there's two parts to the Developer life cycle, where you've got your work, where you're doing your creative work, where you're writing code. And then you've sort of got your part of the inner loop. And then you've got your part where you're trying to get that code out to production, you're trying to get your value to someone else. Instead of your outer loop, we're really trying to focus on the inner loop And sort of our mantra is that any bit for a Developer should spend as much as their time as possible creating new and exciting things and we're onto those holes that reduce those boring, Monday, repetitive tasks, that we're really trying to work out how we take those boring repetitive pieces and how do we make them just vanish like magic from new users or how do we reduce the friction for the experience from users? From both desktop and hub, we're really trying to bring those two together to achieve that. >> You know what's great about folks who have been in the class since day one. All of us have scar tissue experiences, you know the one thing that's constant is constant change. And one of the things that you guys have done at Docker, and hats off to the whole, you know, original team, is that brand of Docker has symbolized quality openness, and set the standard, I mean, if you look back and containers were really coming around, it's not a new concept. But Docker really set the industry on this path and it's been great to follow every DockerCon at TheCube coverage, but more importantly, as the demand for Developers to build these next wave of Cambrian explosion of applications. It's going to be more important than ever to have more of these abstractions, more of these tools in this real time, more Developers experience because there's more building going on. And it's not just one cloud, it's all clouds, it's all things. >> Yeah, I think it was like when IDC analyzed the future report a couple years ago, I think it was maybe the 2018 one. They said that maybe 2017. They said to date, we've built 500 millions applications worldwide and by 2023, we'll build another 500 million. The rate of creation is just insane, it's exponential growth of us producing more and more applications and connecting more and more devices to do them. The sheer volume of creation and the rate of new technology supporting, even with the rate of companies adopting, I guess more of a warm cloud. I think it's like 60 percent of companies are now more than one cloud provider. Maybe even more, maybe it's like 80 percent. It's ridiculous. >> I was just having this debate on Twitter about this multi-cloud. Someone tried to call us out saying, "Oh you guys were pooing on multi-cloud in 2016 and 18." I go "Look at, no one was Pooping on multi-cloud, it didn't exist." I had multiple clouds but there was no real use case. Now you're starting to see the use cases, where yeah, I had multiple clouds and I got Azure here, I got this over here. But no one wakes up and spreads their workloads wrong. This is going back a few years. Certainly the hybrid was developing, but I think now you're starting to see with networking and some of these inter-operable dynamics, you start to see innovation pockets in wide spaces in large market opportunities for start-ups and companies to thread the clouds together at the right place. So I think multi-cloud is becoming apparent from a use case stand point. Still a ton of work to do, I mean direct connects, got SLA's, I mean all kinds of stuff at the networking level but it is real. It's going to be one of those realities that everyone has, at least one or two, if not three. It could be optimization, this is what Developers do right? Solve problems. >> Yeah, absolutely, I mean if nothing else, I've encounter a couple of companies even just where redundancy is handled by multi-cloud strategy. If you want to achieve more nines and you're just balancing workloads between two clouds. >> I mean, the Zoom news was really a testament to that because everyone got into a twist over that. Oh Zoom moves off Amazon, no they didn't move off Amazon, they went to Oracle, they got Adge, they're everywhere. Why wouldn't they be? They need to pass it, they fail over, they need fall tolerance, I mean, these are basic distributing computing concepts that is one on one. You've got to have these co-locations. And optimization for those clouds and the apps on Microsoft as well, so why wouldn't you do it? >> Exactly. And that's that hybrid, that multi-cloud, compounding that some of which you said earlier, that over changes when you're looking at how you go to CICD, how you're bundling these applications, creating more applications than ever. Coming back, sort of, with more AI workloads, much like GPU and you combine that with, sort of, last in the growth of age devices as well. It sort of makes for a really interesting future. And Docker is sort of, that summation SOV, what we're using to frame how we're thinking about our product and what we should be building. >> Great, for the audience out there, hit him up on Twitter, Ben's available, they're out in the open, if you're interested in how Docker makes life easier on the Windows platform, with the GPU support, they've got security now built in, shifting left. Give these guys a call and of course, we love the mission, out in the open. It's theCUBE's mission as well and great to chat with you. Ben, thanks for spending the time with me today. >> Been an absolute pleasure, thank you for having me. >> Okay, just TheCube's coverage, the virtual Cube with DockerCon co-creating together out in the open. DockerCon20, #Docker20, I'm John Fer with TheCube, stay tuned for our next segment, and thanks for watching. (ambient music)

>> Narrator: From around the globe, it's theCUBE with digital coverage of DockerCon LIVE 2020, brought to you by Docker and its ecosystem partners. >> Hi, I'm Stu Miniman and this is theCUBE's coverage of DockerCon LIVE 2020. Happy to welcome back to the program one of our CUBE alumni, Deepak Singh. He's the vice president of compute services at Amazon Web Services. Deepak, great to see you. >> Likewise, hi, Stu. Nice to meet you again. >> All right, so for our audience that hasn't been in your previous times on theCUBE, give us a little bit about, you know, your role and your organization inside AWS? >> Yeah, so I'm, I've been part of the AWS compute services world from, for the last 12 years in various capacities. Today, I run a number of teams, all our container services, our Linux teams, I also happen to run a high performance computing organization, so it's a nice mix of all the computing that our customers do, especially some of the more new and large scale compute types that our customers are doing. >> All right, so Deepak, obviously, you know, the digital events, we understand what's happening with the global pandemic. DockerCon was actually always planned to be an online event but I want to understand, you know, your teams, how things are affecting, we know distributed is something that Amazon's done, but you have to cut up those two pizza and send them out to the additional groups or, you know, what advice are you giving the developers out there? >> Yeah, in many ways, obviously, how we operate has changed. We are at home, maybe I think with our families. DockerCon was always going to be virtual, but many other events like AWS Summits are now virtual so, you know, in some ways, the teams, the people that get most impacted are not necessarily the developers in our team but people who interact a lot with customers, who go to conferences and speak and they are finding new ways of being effective and being successful and they've been very creative at it. Our customers are getting very good at working with us virtually because we can always go to their site, they can always come to Seattle, or run of other sites for meeting. So we've all become very good at, and disciplined at how do you conduct really nice virtual meetings. But from a customer commitment side, from how we are operating, the things that we're doing, not that much has changed. We still run our projects the same way, the teams work together. My team tends to do a lot of happy things like Friday happy hours, they happen to be all virtual. I think last time we played, what word, bingo? I forget exactly what game we played. I know I got some point somewhere. But we do our best to maintain sort of our team chemistry or camaraderie but the mission doesn't change which is our customers expect us to keep operating their services, make sure that they're highly available, keep delivering new capabilities and I think in this environment, in some ways that's even more important than ever, as customer, as the consumer moves online and so much business is being done virtually so it keeps us on our toes but it's been an adjustment but I think we are all, not just us, I think the whole world is doing the best that they can under the circumstances. >> Yeah, absolutely, it definitely has humanized things quite a bit. From a technology standpoint, Deepak, you know, distributed systems has really been the challenge of you know, quite a long journey that people have been going on. Docker has played, you know, a really important role in a lot of these cloud native technologies. It's been just amazing to watch, you know, one of the things I point to in my career is, you know, watching from those very, very early days of Docker to the Cambrian explosion of what we've seen container based services, you know, you've been part of it for quite a number of years and AWS had many services out there. For people that are getting started, you know, what guidance do you give them? What do they understand about, you know, containerization in 2020? >> Yeah, containerization in 2020 is quite a bit different from when Docker started in 2013. I remember speaking at DockerCon, I forget, that's 2014, 2015, and it was a very different world. People are just trying to figure out what containers are that they could package code in deeper. Today, containers are mainstream, it is more customers or at least many customers and they are starting to build new applications, probably starting them either with containers or with some form of server technology. At least that's the default starting point but increasingly, we also seen customers with existing applications starting to think about how do they adapt? And containers are a means to an end. The end is how can we move faster? How can we deliver more quickly? How can our teams be more productive? And how can you do it more, less expensively, at lower cost? And containers are a big part, important and critical piece of that puzzle, both from how customers are operating their infrastructure, that there's a whole ecosystem of schedulers and orchestration and security tools and all the things that an enterprise need to deliver applications using containers that they have built up. Over the last few years, you know, we have multiple container services that meet those needs. And I think that's been the biggest change is that there's so much more. Which also means that when you're getting started, you're faced with many more options. When Docker started, it was this cute whale, Docker run, Docker build Docker push, it was pretty simple, you could get going really quickly. And today you have 500 different options. My guidance to customers really is, boils down to what are you trying to achieve? If you're an organization that's trying to corral infrastructure and trying to use an existing VM more effectively, for example, you probably do want to invest in becoming experts at schedulers and understanding orchestration technologies like ECS and EKS work but if you just want to run applications, you probably want to look at something like Fargate or more. I mean, you could go towards Lambda and just run code. But I think it all boils down to where you're starting your journey. And by the way, understanding Docker run, Docker build and Docker push is still a great idea. It helps you understand how things work. >> All right, so Deepak, you've already brought up a couple of AWS services of, you know, talk about the options out there, that you can either run on top of AWS, you have a lot of native services, you know, ECS, EKS, you mentioned, Fargate there, and very broad ecosystem in space. Could you just, you know, obviously, there are entire breakout sessions to talk about , the various AWS services, but you know, give us that one on one level as to what to understand for container service by AWS. >> Yeah, and these services evolved organically and we launched the Amazon Elastic Container Service or ECS in preview in November or whenever re:Invent was that year in 2014, which seems ages ago in the world of containers but in the end, our goal is to give our customers the most choice, so that they can solve problems the way they want to solve them. So Amazon ECS is our native container orchestration service, it's designed to work with and the rest of the AWS ecosystem. So it uses VPC for networking, it uses IAM identity, it uses ALB for load balancing, other than just good examples, some examples of how it works. But it became pretty clear over time that there was a lot of customers who were investing in communities, very often starting in their own data centers. And as they migrated onto the cloud, they wanted to continue using the same tool plane but they also wanted to not have to manage the complexity of communities control planes, upgrades. And they also wanted some of the same integrations that they were getting with ECS and so that's where the Amazon Elastic Kubernetes Service or EKS comes in, which is, okay, we will manage a control plane for you. We will manage upgrades and patches for you. You focus on building your applications in Kubernetes way, so it embraces Kubernetes. It has, invokes with all the Kubernetes tooling and gives you a Kubernetes native experience, but then also ties into the broad AWS ecosystem and allows us to take care of some of the muck that many customers quite frankly don't and shouldn't have to worry about. But then we took it one step further and actually launched the same time as EKS and that's, AWS Fargate, and Fargate was, came from the recognition that we had, actually, a long time ago, which is, one of the beauties of EC2 was that customers never had, had to stop, didn't have to worry about racking and stacking and where a server was running anymore. And the idea was, how can we apply that to the world of containers. And we also learned a little bit from what we had done with Lambda. And we took that and took the server layer and took it out of the way. Then from a customer standpoint, all you're launching is a pod or a task or a service and you're not worrying about which machines I need to get, what types of machines I need to get. And the operational simplicity that comes with it is quite remarkable and quite finding not that, surprisingly, our customers want us to keep pushing the boundary of the kind operational simplicity we can give them but Fargate serves a critical building block and part of that, and we're super excited because, you know, today by far when a new customer, when a customer comes and runs a container on AWS the first time they pick Fargate, we're usually using ECS because EKS and Fargate is much newer, but that is a default starting point for any new container customer on AWS which is great. >> All right, well, you know, Docker, the company really helped a lot with that democratization, container technologies, you know, all those services that you talked about from AWS. I'm curious now, the partnership with Docker here, you know, how do some of the AWS services, you know, fit in with Docker? I'm thinking Docker Desktop probably someplace that they're, you know, or some connection? >> Yeah, I think one of the things that Docker has always been really good at as a company, as a project, is understanding the developer and the fact that they start off on a laptop. That's where the original Docker experience that go well, and Docker Desktop since then and we see a ton of Docker Desktop customers have used AWS. We also learned very early on, because originally ECS CLI supported Docker Compose. That ecosystem is also very rich and people like building Docker files and post files and just being able to launch them. So we continue to learn from what Docker is doing with Docker Desktop. We continue working with them on making sure that customizing the Docker Compose and Docker Desktop can run all their services and application on AWS. And we'll continue working with Docker, the company, on how we make that a lot easier for our customers, they are our mutual customers, and how we can learn from their simplicity that Docker, the simplicity that Docker brings and the sort of ease of use the Docker bring for the developer and the developer experience. We learn from that for our own services and we love working with them to make sure that the customer that's starting with Docker Desktop or the Docker CLI has a great experience as they move towards a fully orchestrated experience in the cloud, for example. There's a couple of other areas where Docker has turned out to have had foresight and driven some of our thinking. So a few years ago, Docker released this thing called containerd, where they took out their container runtime from inside the bigger Docker engine. And containerd has become a very important project for us as well as, it's the underpinning of Fargate now and we see a lot of interest from customers that want to keep building on containerd as well. And it's going to be very interesting to see how we work with Docker going forward and how we can continue to give our customers a lot of value, starting from the laptop and then ending up with large scale services in the cloud. >> Very interesting stuff, you know, interesting. Anytime we have a conversation about Docker, there's Docker the technology and Docker the company and that leads us down the discussion of open-source technologies . You were just talking about, you know, containerd believe that connects us to Firecracker. What you and your team are involved in, what's your viewpoint is the, you know, what you're seeing from open-source, how does Amazon think of that? And what else can you share with the audience on this topic? >> Yeah, as you've probably seen over the last few years, both from our work in Kubernetes, with things like Firecracker and more recently Bottlerocket. AWS gets deeply involved with open-source in a number of ways. We are involved heavily with a number of CNCF projects, whether it be containerd, whether it be things like Kubernetes itself, projects in the Kubernetes ecosystem, the service mesh world with Envoy and with the containerd project. So where containerd fits in really well with AWS is in a project that we call firecracker-containerd. They're effectively for Fargate, firecracker-containerd as we move Fargate towards Firecracker becomes out of the container in which you run containerd. It's effectively the equivalent of runC in a traditional Docker engine world. And, you know, one of the first things we did when Firecracker got rolled out was open-source the firecracker-containerd project. It's a go project and the idea was it's a great way for people to build VM like isolation and then build sort of these serverless container architectures like we want to do with Fargate. And, you know, I think Firecracker itself has been a great success. You see customer, you know, companies like Libvirt integrating with Firecracker. I've seen a few other examples of, sometimes unbeknownst to us, of people picking a Firecracker and using it for very, very interesting use cases and not just on AWS in other places as well. And we learnt a lot from that that's kind of why Bottlerocket is, was released the way it was. It is both a product and a project. Bottlerocket, the operating system is an open-source project. It's on GitHub, it has all the building tooling, you can take it and do whatever you want with it. And then on the AWS side, we will build and publish Bottlerocket armies, Amazon machine images, we will support them on AWS and there it's a product. But then Bottlerocket the project is something that anybody in the world who wants to run a minimal operating system can choose to pick up. And I think we've learnt a lot from these experiences, how we deal with the community, how we work with other people who are interested in contributing. And you know, Docker is one of the, the Docker open-source pieces and Docker the company are both part of the growing open-source ecosystem that's coming from AWS, especially on the container world. So it's going to be very interesting. And I'll end with, containerization has started impacting other parts of AWS, as well as our other services are being built, very often through ECS and EKS, but they're also influencing how we think about what capabilities we need to build into the broader container ecosystem. >> Yeah, Deepak, you know, you mentioned that some of the learnings from Lambda has impacted the services you're doing on the containerization side. You know, we've been watching some of the blurring of the lines between another container world and the containerization world. You know, there's some open-source projects out there, the CNCS working on things, you know, what's the latest, as you see kind of containerization and serverless and you know, where do you see them going forward? >> This is that I say that crystal balls are not my strong suite. But we hear customers, customers often want the best of both world. What we see very often is that customers don't actually choose just Fargate or just Lambda, they'll choose both. Where for different pieces of their architecture, they may pick a different solution. And sometimes that's driven by what they know, sometimes driven by what fits into their need. Some of the lines blur but they're still quite different. Lambda, for example, as a very event driven architecture, it is one process at a time. It has all these event hooks into the rest of AWS that are hard to replicate. And if that's the world you want to live in or benefit from, you're going to use lambda. If you're running long running services or you want a particular size that you don't get in Lambda or you want to take a more traditional application and convert it into a more modern application, chances are you're starting on Fargate but it fits in really well you have an existing operational model that fits into it. So we see applications evolving very interestingly. It's one reason why when we build a service mesh, we thought forward instead. It is almost impossible that we will have a world that's 100% containers, 100% Lambda or 100% EC2. It's going to be some mix of all of these. We have to think about it that way. And it's something that we constantly think about is how can we do things in a way that companies aren't forced to pick one way to it and "Oh, I'm going to build on Fargate" and then months later, they're like, "Yeah, we should have probably done Lambda." And I think that is something we think a lot about, whether it's from a developer's experience side or if it's from service meshes, which allow you to move back and forth or make the mesh. And I think that is the area where you'll see us do a lot more going forward. >> Excellent, so last last question for you Deepak is just give us a little bit as to what, you know, industry watchers will be looking at the container services going forward, next kind of 12, 18 months? >> Yeah, so I think one of the great things of the last 18 months has been that type of application that we see customers running, I don't think there's any bound to it. We see everything from people running microservices, or whatever you want to call decoupled services these days, but are services in the end, people are running, most are doing a lot of batch processing, machine learning, artificial intelligence that work with containers. But I think where the biggest dangers are going to come is as companies mature, as companies make containers, not just things that they build greenfield applications but also start thinking about migrating legacy applications in much more volume. A few things are going to happen. I think we'll be, containers come with a lot of complexity right now. I think you've, if you've seen my last two talks at re:Invent along with David Richardson from the Lambda team. You'll hear that we talk a lot about the fact that we see, we've made customers think about more things than they used to in the pre container world. I think you'll see now that the early adopter techie part has done, cloud has adopted containers and the next wave of mainstream users is coming in, you'll see more attractions come on as well, you'll see more governance, I think service meshes have a huge role to play here. How identity works or this fits into things like control tower and more sort of enterprise focused tooling around how you put guardrails around your containerized applications. You'll see it two or three different directions, I think you'll see a lot more on the serverless side, just the fact that so many customers start with Fargate, they're going to make us do more. You'll see a lot more on the ease of use developer experience of production side because you started off with the folks who like to tinker and now you're getting more and more customers that just want to run. And then you'll see, and that's actually a place where Docker, the company and the project have a lot to offer, because that's always been different. And then on the other side, you have the governance guardrails, and how is going to be in a compliant environment, how am I going to migrate all these applications over so that work will keep going on and you'll more and more of that. So those are the three buckets I'll use, the world can surprise us and you might end up with something completely radically different but that seems like what we're hearing from our customers right now. >> Excellent, well, Deepak, always a pleasure to catch up with you. Thanks so much for joining us again on theCUBE. >> No, always a pleasure Stu and hopefully, we get to do this again someday in person. >> Absolutely, I'm Stu Miniman, thanks as always for watching theCUBE. >> Deepak: Yep, thank you. (gentle music)

>> Announcer: From around the globe, it's theCUBE with digital coverage of DockerCon Live 2020. Brought to you by Docker and its ecosystem partners. >> Okay Jenny, great to see you again. >> Good to see you. >> James Governor, nail on the Keynote there. Chat was phenomenal. That was pre-recorded but James is also in the chat stream. A lot of good conversations. That hit home for me that keynote. One, because memory lane was going down right into the 80s when it was a revolution. And we got him in the green room here. James Governor, welcome. >> James is here, hi James. >> Here we go. >> Fresh off the keynote. >> It's always a revolution. (John laughs) >> Well, in the 80s, I used to love your talk. A couple of key points I want to share and get your thoughts on was just to some highlights for the crowd is one, you walk through. Some of the key inflection points that I think were instrumental and probably some other ones depending on your perspective of where you were in the industry at that time. Whether you were a systems programmer or a networking guy, there was a proprietary world and it was a revolution back then. And UNIX was owned by AT&T if no one remembers. You couldn't even use the word. You had to trade market. So we actually had to call it XINU which is UNIX spelled backwards in all the text and whatnot. And even open source software freeware was kind of illegal. MIT did some work, Northeastern and Berkeley and other schools. It was radical back then so-- >> Yeah, we've come a long way for sure. I think that for me that was one of the things that I wanted to really point to in the keynote was that yes we have definitely come a long way and development culture is about open culture. >> I think the thing that I like to point out especially hate to sound like I'm old but I am. But I lived through that and the younger generation coming and have all these new tools. And I got to say not that I walked through to school in the snow with no shoes on but it's a pretty cool developer environment now. But remember things were proprietary back then. If you start to see the tea leaves now, I look at the world, you see these silos. You see silos that's kind of, they're not nestle proprietary but they might necessarily be open. So you kind of have a glimpse of open source on these projects and these companies. Whether they're tech companies, it feels open but it might not be. It could be walled garden. It could be data being hoarded. So as data opens up, this is interesting to me because I want to get your thoughts on this because in a way it feels proprietary but technically it's not proprietary. What's your thoughts on this? Because this is going to be the next 20 years of evolution. What's your thoughts? >> I think the productivity wins. Whoever packages technology in a way that makes it most productive for people. That's what wins. And open source, what's productive. It is very accessible. It enabled new waves. Get installed and you've got a package from... You got access to just a world of open-source. A world of software that was a big revolution. And I guess the cloud sort of came next and I think that's been one of the big shifts. You talk about proprietary. What matters is how easy you make things to people to do their work. And in that regard, obviously Amazon is in fact a bigger distribution network. Makes technology super consumable by so many people. I guess I would say that open is good and important but it's not the only thing. As you say, data is a lock-in and it's right and people are choosing services that make them productive. Nobody worries about whether Amazon Lambda is proprietary. They just know that they can build companies or businesses or business processes on it. >> You know it's interesting back in the day just to kind of segue with the next topic. We were fighting proprietary operating systems, UNIX and others. We're also fighting for proprietary Network protocol stacks. SNA was owned by IBM. DECnet was digital, the number one network. And then TCP/IP and OpenSan's interconnect came out. That's the OSI model for us old ones. That set the table. That changed the face of everything. It really enabled a lot. So when I see containers, what Docker did early on the pioneering phases of Docker containers, it unleashed a new reality of coolness and scale and capabilities. And then in comes Kubernetes and in comes micro services. So this path is showing some real strength for new kinds of capabilities. So how does a developer navigate all this because data lock-in does it a data plane seems to be a control point. What are we fighting now in your opinion? shouldn't say we're fighting but what are we trying to avoid if operating systems was for closing opportunities and network protocol stacks before closing in the past? What do you see as barriers that need to be broken down in the open source world around going down this great path of micro services, decomposed applications, highly cohesive architectures? >> Honestly there's enough work to be getting on with without like fighting someone in that regard. I mean we're fighting against technical debt. I just don't think that people are serrated about fighting against proprietary anymore. I think that's less than a concern. Open-source technology is great. It's how most work gets done in our industry today. So you mentioned Kubernetes and certainly Docker. Though we did a phenomenal job of packaging up and experience that map to see CICD. That map to the developer workplace people like do. Phenomenal job and I think that for me at least when I look at where we are as an industry, it's all about productivity. So there are plenty of interesting new platforms. I think in my keynote, that's my question. I'm less interested in microservices than I am in distributed work. I'm interested in one of the tools that are going to enable us to become more productive, solve more problems, build more applications and get better at building software. So I think that's my sort of focus. There will always be lock-in. And I think you will also have technologies mitigate against that. I mean clear messages today from Docker about supporting multiple clouds. For a while at least multiclouds seem like something only the kind waivers were interested in but increasingly we're seeing organizations where that is definitely part of how they're using the cloud. And again I think very often it's within specific areas. And so we see organizations that are using particular clouds for different things. And we'll see more of that. >> And the productivity. I love the passion, love that in the keynote. That was loud and clear. Two key points I want to get your reaction on that. You mentioned one was inclusion. Including more people, not seeing news. It's kind of imperative. And also virtual work environments, virtual events. You kind of made a highlight there. So again people are distributed remote first. It's an opportunity to be productive. Can you share your thoughts on those two points? One is, as we're distributed, that's going to open the aperture of more engagement. More people coming in. So code of conduct not as a file you must read or some rule. Culturally embracing a code of conduct. And then also, virtual events, virtual groups convening like we're doing here. >> Yeah I mean for me at least Allison McMillan from github and she just gave such a great demo at the recent sunlight event where she finished and she was like, it was all about, I want to be able to put the kids to bed for a nap and then go code. And I think that's sort of thinking people band around the phrase ruling this together but I mean certainly parenting is a team sport. But I think it's interesting we're not welcome. It was interesting that was looking at the chat, going through, I was being accused of being woke. I was being accused of being a social justice warrior. But look at the math. The graph is pretty clear. Women are not welcomed in tech. And that means we're wasting 50% of available resource to us. And we're treating people like shit. So I thought I underplayed that in the talk actually. Something like, "Oh, why is he complaining about Linus?" Well, the fact is that Linus himself admitted he needed to change his persona in order to just be more modern and welcoming in terms of building software and building communities. So look we've got people from around the world. Different cultural norms. All of the women I know who work in tech suffer so much from effectively daily harassment. Their bonafides are challenged. These are things that we need to change because women are brilliant. I'm not letting you signaling or maybe I am. The fact is that women are amazing at software and we do a terrible job of supporting them. So women of other nationalities, we're not going to be traveling as much. I think you can also grow. No we can't keep flying around as much. Make an industry where single parents can participate more effectively. Where we could take advantage of that. There're 200 million people in Nigeria. That hunger to engage. We won't even give them a visa and then we may not be treating them right. I just think we need an industry reset. I think from a we need to travel less. We need to do better work. And we need to be more welcoming in order that that could be the case. >> Yeah, there's no doubt a reset is here and you look at the COVID crisis is forcing that function there because one, people are resetting and reinventing and trying to figure out a growth strategy. Whether it's a business or teams. And what's interesting is new roles and new responsibilities is going to emerge and I think you're right about the women in tech. I completely agree and have evidence myself and reported on it ad nauseam. But the thing is data trumps opinion. And the data is clear on this issue. So if anyone will call you a social justice warrior I just say pound sand and tell them that go on their way. And just look at the data and clear. And also the field is getting wider. When I was in computer science major back in the day, it was male-dominated yes but it was very narrow. Wasn't as broad as it is now. You can do things so much more and in fact in Kelsey Hightower's talk, he talks to persona developers. The ones that love to learn and ones that don't want to learn anything. Just want to code and do their thing. And ones that care about just app development and ones that just want to get in and sling k-8 around like it's nobody's business or work with APIs, work with infrastructure. Some just want to write code. So there's more and more surface area in computer science and coding. Or not even computer science, it's just coding, developing. >> Well, I mean it's a bigger industry. We've got clearly all sorts of challenges that need to be solved. And the services that we've got available are incredible. I mean if you look at the work of companies like Netlify in terms of developer experience. You look at the emergence of JamStack and the productivity that we're seeing there, it's a really exciting time in the industry. >> No doubt about that. >> And as I say I mean it's an exciting time. It's a scary time. But I think that we're moving to a world of more distributed work. And that's my point about open source and working on code bases from different places and what the CapCloud can enable. We can work in a different way and we don't all need to be in San Francisco, London, or Berlin as I said in the Keynote. >> I love the vision there and the passion. I totally agree with it. I think that's a whole another distributed paradigm that's going to move up the stack if you will and software. I think it's going to be codified in cloud native and cloud scale creates new services. I mean it's the virtual world. You mentioned virtual events. Groups convening like the 67,000 people coming together virtually here at DockerCon. Large, small one-on-ones group dynamics are a piece of it. So share your thoughts on virtual events and certainly it's people are now just kicking the tires, learning. You do a zoom, you do a livestream. You do some chat. It's going to evolve and I think it's going to look more like a CICD pipeline and anything else. As you start to bring media together, we get 43 sessions here. Why not make it a hundred sessions? So I think this is going to be one of those learning environments where it's not linear, it's different. What's your vision of all this if you had to give advice for the folks out there? Not event plans, with people who want to gather groups and be productive. What's your thinking on this? >> Well, it sort of has to happen. I mean there are a lot of people doing good work in this regard. Patrick Dubois, founder of DevOps days. He's doing some brilliant work delineating. Just what are all the different platforms? What does the streaming platform look like that you can use? Obviously you've got one here with theCUBE. Yeah, I mean I think the numbers are pretty clear. I mean Microsoft Build had 245,000 registered attendees and I think something that might have been to begin. The patterns are slightly different. It's not like they're going to be there the whole time but the opportunity to meet people where they are, I think is something that we shouldn't ignore. Particularly in a world not everyone again has the privilege of being able to travel. You're in a different country or as I say perhaps your life circumstances mean you can't travel. From an accessibility perspective, clearly virtual events offer an opportunity that we haven't fully nailed. I think Microsoft performance in this regard has been super interesting. They were already moving that way and Kobe just slammed it up to another level. What they did with Build recently was actually, I mean they're a media company, right? But certainly developed a focused media company. So I think you'll be okay. You're about the business of software John. Don't worry Microsoft don't give you some space there. (John and James laughing) We're under the radar at theCUBE 365 for the folks who are watching this. This is our site that we built with our software. So we're open and Docker was instrumental and I think the Docker captains were also very instrumental and trying to help us figure out the best way to preserve the content value. I personally think we're in this early stage of, content and community are clearly go hand in hand and I think as you look at the chat, some of the names that are on there. Some of the comments, really there's a new flywheel of production and this to me is the ultimate collaboration when you have these distinct groups coming together. And I think it's going to just be a data dream where people aren't the product, they're actually a contributor. And I think this open source framework that you're talking about is going to be certainly just going to evolve rapidly. I think it's just not even scratching the surface. I just think this is going to be pretty massive. And services whatever you want to define that. It could be an API to anything. It's going to be essentially the scale point. I mean why have a monolith piece of software running something. Something Microsoft teams will work well here. Zoom will work well there but ultimately what's in it for me the person? This is the key question. Developers just want to develop. You're going to hear that throughout the day. Kelsey Hightower brings up some great points in his session and Amanda silver at Microsoft, she had a quote on one of her videos. She said, "App developers are the first responders "in this crisis." And that's the first time I've heard someone say that out loud and that hits home for me because it's true. And right now app developers are one of the front lines. They're providing the app support. They're providing to the practitioners in the field. This is something that's not really written about in the press. What's your reaction to app developers are the first responders in this crisis. >> Well I mean first I think it's important to pay tribute to people that actually are first responders. Writing code can make us responsive but let's not forget there are people that are lacking PPE and they are on the frontline. So not precise manner but I might frame it slightly differently. But certainly what the current situation has shown us is productivity is super important. Target has made huge investments in building out its own software development capabilities. So they used to be like 70% external 30% internal and they turn that round to like 80% internal 20 external. And they've been turning on a dime and well there's so much going on at the moment. I'm like talking about target then I'm remembering what's happening in Minneapolis today. But anyway we'll talk about that. But yeah organizations are responding quickly. Look at the numbers that Shopify is happening because all sorts of business is something like we need to be an online business. What's the quickest way to do that. And Shopify was able to package something up in a way that they they could respond to challenges. Huge social challenges. I'm a big believer the future's unwritten at this point and I think there's a lot of problems out there you point out and the first responders are there I agree. I'm just thinking that there's got to be a better path for all of us. And this brings up the whole new roles and responsibilities around this new environment and I know you're doing a lot of research. Can you share some thoughts on what you're kind of working on now James? That's important, I'll see what's trending here at DockerCon is. Compose the relationship with Microsoft, we've got security, Dockers now, multicloud approach, making it easier, that's their bread and butter. That's what they're known for. They kind of going back to that roots of why they pioneered in the first place. So as that continues ease-of-use, what's your focus area right now that you're researching that you could share with the audience? >> Well, I mean I'd say this year for me I've got probably three key areas. One is what's called GitOps. So it's the notion that you're using Git as a system of record. So that started off randomly making changes, you have an audit trail. You begin to have some sort of sense of compliance in software changes. I think the idea of everything has to be by a sort of a pull request. That automation model is super thing to me. So I've been looking at that. A lot of development teams are using those approaches. Observability is a huge trend. We're moving to the idea of testing and production. The kind of stuff that's been evangelized so successfully by charity majors honeycomb. It's super exciting to me and it's true because in effect, you're always testing in production, your dev environment. I mean we used to have this idea that you'd have a Dev and a Dev stage. You're have a staging environment. The only environment that really matters is where the rubber meets the road. And that is deployment. So I think that having having better tools for that is one of the areas I'm looking at. So how are tools innovating that area? And it won't be the thing that this is my own personal thing. I've been talking about progressive delivery which is asking a question about reducing risk by really understanding the blast radius of the service to be able to roll it out to specific use of populations first. Understanding who they are and enrolling it up so it's the idea that like maybe you brought something out to your employees first. Maybe you are in California and you roll something out in Tokyo knowing that not many people are using that service. It is a live environment but people are not going to be adversely affected if it happens. So Canary's Blue-Green deployments and also experimentation. This is sort of one of the areas I'm being sort of pulled towards. It's sort of product management and how that's really converging with software development. I feel like that's one of the things I haven't fully, I mean I think it's when they have research focused but you have to respond to new information. Anyhow, I'm spending a lot of time thinking about the world of product management. It's those companies to be most respect in terms of companies that are crushing it in the digital economy. They have such a strong product management focused. Everything is driven by product managers that understand technology and that's an exciting shift. The one that I'm paying greater attention. >> You do some great work and I love the focus on productivity software development. Getting those app developers out there and it's interesting. I just think that it's such an exciting time. It's almost intoxicating. Some people drinking on Twitter online and having beers because they're in different time zone. But if you look up and down the action that's going on, you got at the application developers side, all the things you were mentioning services. But when you look at the cloud side, you got almost this operating system reset. It's a systems architecture. So you have the hall and that's up and down. The middle of the stack to the bottom, you have this operating systems thinking and evolution. And then you got at the top, the pure software developers. And this is again to me the big aha moment. For the industry there's a true opportunity to scale that in unbelievable ways. And you don't have to pick a side. You can do a top of the stack bottom stack. So I think kubernetes and micro services really bring this whole enablement piece to the table. And that fascinates me and I think that's going to change what the apps will look like. It'll give more productivity and then making the internet programmable unit, that's new systems. So that seems to be the trend. You're a systems guy, your girl or you're a developer. How do you see that evolving? Do you get to that level? >> Developer experience is not necessarily the key value of Kubernetes. It's supremely flexible sort of system. It does offer you that portability. But I think what I'm seeing now is how people are taking Kubernetes and kind of thinking, so you've got VMware, acquires Heptio, brings Pivotal into the fold, starting about what that platform looks like. I think Pivotal with cloud foundry did a great job of thinking through operator experience. Operator experience is not the same as developer experience. I think we're going to see a bit more specialization of roles. Meanwhile at that point, you've got the cloud players all doing pretty awesome job supporting Kubernetes. But it gives that portability promise. So I think for me, one of the things is not expecting everyone to do everything. It's like Kelsey said, some people just want to come into work and do their job and they're super important. And so VMware I think a history of certification of application environments. So of them it's sort of quite--and certification of humans. It's quite natural that they would be somebody that would think about how do we make Kurbenetes more consumable and packaged in a way that more people take advantage of it. Docker was such a phenomenon and now seeing how that sort of evolving into that promise of portability is beginning to be realized. So I think the specialization, the pendulum is going to swing back just a little bit. >> I think it's just great timing and congratulations on all the work and thanks for taking the time for participating in DockerCon with the Keynote. Taking time out of your day and coming in and doing this live interview. The chat looks good. Hit some great, get some fans in there. It's a great opportunity and I think Docker as the pioneers, pivoting in a new direction, it's all about developer productivity and James you've been on it. @monkchips is his Twitter handle, follow him, hit him up. I'm John Furrier here in the studio for DockerCon 2020. Ginebra CEO and you got Brett Fisher on the captain's channel. If you go to the site, you'll see the calendar. Jump into any session you want. They'll be live on the time or on-demand instantly. TheCUBE track has a series of enemies. You've got Amazon, we got Microsoft, get some great guests, great practitioners that are literally having an impact on society. So thanks for watching. James, thanks for spending the time. >> Thank you very much John. >> Okay James Governor, founder of Monkchips, great firm, great person-- >> RedMonk, RedMonk is the company. Monkchips is the Twitter. >> Redmonk, Monkchips. RedMonk, RedMonk. >> RedMonk is the company. >> RedMonk, RedMonk. >> @monkchips is his Twitter handle and RedMonk is the firm, thank you for the correction. Okay more coverage DockerCon after this short break. Stay with us. The next segment is coming up. Stay with us here at theCUBE DockerCon. (gentle music)

>>from around the globe. It's the Cube with digital coverage of Red Hat. Summit 2020 Brought to you by Red Hat. >>Hi, I'm Stew Minimum And and this is the Cube's coverage of Red Hat Summit 2020 course Digital event This year. We're not together at Mosconi, but we are bringing together many of the speakers thought leaders, customers in this very important ecosystem. Really excited to welcome back to our program. Stephanie Cheers. Who's the vice president and general manager of the Red Hat Enterprise Linux business unit inside of Red Hat. Stephanie. So great to see you have to give you a virtual hug high five year, but you know, always great to see and have you on the program. >>Oh, thank you. So it's great to be here, and this is what together means today. But it's great to be together with you >>again. Here it's limit. >>Yeah, the discussion is you talk on it together apart for for a time we talk in tact. That change is one of the only constants that we have, and there are more changes than ever happening right now. So before we get into kind of your B you talk a little bit about, You know, some of the big changes. There's organizational changes, you know, I know we spoke to you about in 2019 at IBM Think and Red Hat Summit because you've worked for both sides of the equation here, Uh, give us kind of the latest from your standpoint. >>Yes, certainly the leadership changes which have been public now for a couple weeks. Those were a big change >>for for us. I think one of the things that has come through is IBM has really been respecting what red hat is. What? Um, what we do. But also how we do it is very important and valued. And we at red Hat >>believe in it so strongly. We're sticking to what Red Hat does best. Everything is open source. Everything is collaborative. And honestly, I have to say it. It >>feels great as a red Hatter to see Jim in the position he's in at IBM Um, Paul's passion, >>which clearly comes across in his keynotes and >>his passion for how we do have an open source development model. It's great to have them now take over the CEO role for Red hat. So it's it's really exciting times. I think. Last year when we spoke, it was, um it was a bit of a wait and see and see what happens. And I think now the recent announcements really solidify this sort of synergy and partnership that IBM and Red Hat have and what our intentions are in the market. But at Red Hat, we still stay red hat, and we're still driving things the way we always have. And that's great. Feels that >>that that's great. And thank you so much for the update. So when we talk about your business unit that the Red Hat Enterprise, Linux, of course, Rehl, um, you know, I've got a little too much history, you know. I go back when it was, whereas, you know, before well and kind of wash the growth of Linux sto become really, you know, the underlying fabric of so much of what we see out there today for all of businesses, so many companies could not exist if it wasn't for Linux. And in the seven years we've been having the Cube, of course, we've really watched that that moved from Lennox to not only be some of the foundations of what's happening in customer's environments, but also a major piece of cloud and cloud. Native S O. You know, give us that up date as to, you know, here in 2020. You know why? You know Linux has been around for quite a long time, but, you know, it's still is relevant. >>Yeah, so that's it. That's a >>great leader and ties exactly to how we look at well in the red hat sort of entire portfolio. Um, when you look at Lenox of how it evolved, it started out as being a bit of a cheaper alternative to units. But it quickly became, because of the open source way and collaborative way it's developed. It quickly became sort of this springboard for innovation because you have all these incredible innovators collaborating upstream. All of that has fed to a whole different view of what Linux is. Is cloud exists because of Linux is containers are just a different deployment mechanism or Lennox workloads, artificial intelligence. All those APS are built on Linux, so it's become this standardized foundation upon which innovation is done today, And for me, that's the most exciting thing, because it red hat and rail. Our goal is to one. Have it just work right? It has >>to be the standard. And, um well, sometimes that can be misinterpreted. It >>is boring or a commodity. It is anything but a commodity. It's probably one of the most strategic decisions that someone makes. Is which Raoul Distribution? Which Red Hat, which Lennox distribution did they use and that really take real pride that it's built for the enterprise? It's build for security. It's built for resiliency, and all of that build it once deploy anywhere, translates into also using all the innovation, all the container ization capabilities, using it across multiple public clouds. So it's really that combination of having it just work, be the foundation of where you build once and then being able to leverage all the innovation that's coming out of the open source world today. >>Yeah, really interesting points. Stephanie, I think back to when we talked for years about the consumer nation consumers, consumer ization. Excuse me of I t and people thought that therefore, there wouldn't be differentiation, you know, just by white box things and everything will be off the shelf. But if you look at how most companies build things, they really hyper optimize that. I need to build what I need. I need to use the tools that are available, and I need to be able to be agile. You know, I want one of my highlights last year talking to a lot of companies going through their digital transformation and a number of them at Red Hat Summit last year where they talked about both the organization and technology changes that they're making to move faster. And, of course, your portfolio is a big piece of helping them move forward. >>And that's one thing we're seeing that that ability to consume, innovation and get the >>most and extract the most out of what they're running today in their data center. As customers transform and take on this digital transformation, it's not just a technology statement. In most cases, it's an organizational statement as well. And how do you bridge both those and move it forward? It's one thing we focus a lot on right with the open innovation labs, with a lot of customers as well, because it's not just about the technology, it's about the way we work in the way we do things as well. >>Yeah. So, Stephanie, you know, every every year or so I hear it's like, Oh, well, we've got a new way to To the operating system. There was the Jeff just enough operating system for for a while when container ization came out, there was little company named core Os. That was like, Oh, we're going to make a thin version or core OS is now Ah, piece of red hat. Um, so still, with the cloud, there's always, you know, we're going to change the way the operating system it's done. Um, we just love your viewpoint as to, you know, Red Hat has, you know, a few options and kind of a spectrum of offerings. But how do your customers think about the OS these days? And you know, how should we be thinking about rail specifically in that overall spectrum? >>No, it's so that's a great question, too. And we look at >>it as Lennox and Rehl is be one thing that stays the same and helps you get the value out of all the work you've already put in all the development work you've already put in. And make sure that that translates to the future, where everything is changing, how you deploy where you deploy what you deploy. All of that may change, but if you want to get the value out of the work in the development that has been done yesterday, you need something to stay the same. In our view, that's real. We build it with um in mind for the enterprise along lifecycle security support. We build all of that into it so that when you build on a rail monorail kernel, you can take that. If you want to deploy it in a container, you can deploy on Rehl itself. Or if you need orchestration, you can deploy it on open shift. And that's part of the reason why you mentioned Core OS. So we now have a rail core. OS is within open shift 4.0, on beyond, of course. But what we did was we tailor down what is. In reality, it's the same packages. It's the same certification, security, all of that work that we put in. We take the core OS piece of it, what's essential and really optimized for open shift. We build that into an immutable image, and it goes out as part of open shift. It's not available separately because it's really tailored. What we pick the life cycle is all matching open shift, >>and what that does >>is provide you on open shift experience. That's easy to update fully across the board, all the way down to the kernel. But you know, it's the same Lennox that you have in rail, >>and it's that consistency >>of technology that we really strive for. Um, same thing in public Cloud. So when you build an image on Prem on REL, you can take that image up into the public cloud. And no, it's the same level of security and it just will work, you know, part of part of my team. And we take a lot of pride in the fact that it will just work on. And while that >>may not sound super exciting, particularly in days >>like like right now, being dependable and being reliable and knowing that it's secure, all of that is really important when you run your business that those those features or anything but commoditized >>Well, yeah, I think one of the real volumes that customers see with real specifically is there's so much change going on there, and you look at the Linux community, you look at what open shifts doing in the Kubernetes community. There's so much coaches going on red hat packages that make sure that you don't need to think about the almost chaos that's going out there in all of those communities. But you packaged those together. So Stephanie rarely was, of course, one of the highlights of last year's Red Hat Summit. So we'd love to hear you know, if you've got any good customer stories, really, the momentum of relate as you've seen it, you roll out around the world as and then we'll talk about the new updates. You have this. >>Yeah, great. So Rehl eight was a big deal for us last year, as you remember, and partly because not >>only all the features and functions, of course, which we put into it, but also because we really wanted to reposition what the value of an operating system is within a data center and within their innovation future. So we really focus all the features and functions into two buckets. One is about how do we help you with the operating system? Run your business better, more efficiently If the most out of the systems you have in the critical workloads that you run today and how do we use the operating system to help you bridge into the next level of innovation? What's coming down the pipeline? Things like containers. >>And we really wanted to >>make sure that, as we see you know, most customers are looking to how they digitally transform. But of course, no one has the freedom to throw away everything they've done in the past. They want to build upon that and get value out of it. So we really focused on balancing those two things now, as we look at. In fact, one of the commitments we made because we heard it from customers was they wanted a more predictable deployment of our minor releases and our major releases. And we committed, um, at the REHL eight launch that we would be delivery minor releases every six months, major releases every three years, and we have held to that. We delivered 816 months after we delivered eight. And now you saw last week we delivered eight dot too. Um, this is what it means for us to stand by our world and be dependable as an operating system. And the beauty of the subscription with well is that if you're a customer and you're running REL seven, particularly in times right now, it's It's not that easy to get into your data center, perhaps. And so if you don't choose to update to eight now, you can stay on seven until that time works. That's to me. That's part of the beauty and the flexibility of the subscription model. We have course want to continue to bring your new capabilities and new features. But the subscription Our goal is to have a value subscription that you can you can get the most value from No matter when you decide to upgrade or no forward with, uh, with a different releases, we have >>Well, you can go. And congratulations on keeping the releases going on schedule. One of the nice things about open source is we can see the roadmap out there. You've made this Ah, this promise and you're keeping to it. So ah is you said the announcements we made has been talked about in the keynote. So give us a couple of highlights. Says what people to be looking at and looking to learn more when they dig into a thought to >>Yeah, great. So we really wanted to stick with a few key >>messages with it, and they do really tie to How do we help you run your business? And how do we help you grow your business? It's one thing that we announced and what we pivoted to, um, with the eight dot io is we >>really moved to? How do we How do we >>deliver what we called an intelligent OS, which means an OS that helps you bridge the gap and brings more value to you in your data center than you got before? One of the key aspects to this was adding in the capability of red hat insights, and we added insights capability into every single rail subscription that is under current support. So whether or not you moved to relate whether you have real seven, if you have a supported version of real six, all of those had insights added to it, and what insights is is a as a service on cloud at red hat dot com and link up your servers, and >>it will give you insight >>into operational capability. Is it configured correctly is it could be optimized for better performance. Where are you on your C V E updates and what it does is take all that knowledge that Red Hat has from all the support cases and things that we're seeing what's happening in the industry, what we're seeing other customers have, and we can even proactively help customers. The feedback on this capability has been huge. In fact, you'll see in the announcement last week we've added a lot of new capabilities into this specifically For that reason we've had customers, you know, it's like having it's like having more ops people on my team because I'm getting this input in directly from Red Hat for things to look at. And so that, to me, was probably one of the key aspects that, as we look from going to eight into eight dot too, how do we build up that capability? And of course, last week you saw we added a lot to that, and I think now more than ever, we want to make sure that everyone who has a real subscription is getting the most value out of that and I think insights is one of the places where if you have a subscription and, um, you can value or you can get more value from operational help, insights is a place where we want to help you. Um, we everything we had prior we have now bucket sized into a capability and insights called advisor is really about performance, stability and security and doing an analysis for you. We've added a new capabilities around vulnerability, Right. How do you re mediate common vulnerabilities and exposures, compliance aspect, patch aspect policies and drift? Um, kind of all of those we've now bucket it in into that insights capability. So this friends a lot more value to something that we have already seen. Customers say, You know, we didn't expect to get this amount of input and continuous growth because we constantly add new new rules into that engine. And so you know what? What we what we knew yesterday will be what we know tomorrow, and we look forward to sharing with that with everyone >>who has a subscription. So this is >>a place where I think it's ah, it's an important place for folks to look, particularly now because operational efficiency is really key. And security is really we have a lot of capabilities in both. What? Yes, Please, >>please, please, go ahead. Now, >>one other aspect on that that I wanted to mention >>was we also added a capability called subscription watch and subscription Watch helps you get a very simple, clean view of all the subscriptions you have and where they're running. And that was one thing that we saw. Customers say there was friction. And how do I know where my entitlements are? How I'm using them across my entire enterprise Corruption watch can help with that. So, um, this sort of cloud dot red hat dot com capability that we can assist with and is already part of your subscription. These are the kinds of things that we really want to help augment this to make Really intelligent os for the enterprise. >>Yeah. Stuff Stephanie. The comment I was gonna make is there's certain shows that I go to that every year. You go to it, You say Okay, it's a little bit bigger. They announce something. They made some progress on it. What has impressed me most about going to the red Hat show year after year is really the the growth of the of the portfolio, if you will. So when I first started going to it, it was, you know, a lot of the people there were, you know, the hard core Linux people. Um And then, you know, there's some storage people, some networking people is cloud containers really grew. It really blossomed into this really robust ecosystem. Oh, and growth there. So would love just to get your viewpoint on, you know, the skill set because, you know, I'm sure there's plenty of companies out there that are like, Well, you know, I've got some people that are, you know, my limits people, and they do things that aren't there. But, you know, how do you see kind of the skill set and what what Red Hat's doing really permeating more and more of, of companies, day to day activity. >>I think one of the things that I'm >>most proud of is even since last year's all the deeper collaborations we have between the various product lines. Certainly we'll talk with Joe Fitzgerald, and he and I work together very closely. Capabilities like insights. How do we add answerable capabilities directly into real. And what that does is really help. I think in any customer today, skills is probably one of the biggest concerns that they have. How do they grow those skills? How do they help folks grow and learn more and progress into the innovation areas? But clearly they still need their their mission critical applications to run and how do they span that? And I think what we're really trying to do is be able to bring the strength of the portfolio together to help a customer have more flexibility in how they leverage their skills and how they grow their skills. >>Because I think coming back to >>that statement that that you made earlier it's not just about technology. It's about how, if >>you really want to be, have agile, it's about >>how a company has organized. And I think we're hoping that we bring together the strength of the portfolio so that a customer is able todo leverage their organization and leverage their skills and the best way possible. I think another place where we worked hard on eight dot too. Some similar lines of bridging the portfolio was, you know, we announced back in eight dot io. We were putting container ization tools directly in Terrell with build a pod made in scope e 08 dot too. We brought in the newest versions of Scope EO and Build Up. In fact, in tech preview, you get containerized versions of those, and so we're continuing to add. What we are seeing is the container ization is a journey for customers. Many customers just want to deploy a single container on a server. Or they were. They want to deploy a single container in a VM Um, they're not ready for orchestration. We wanted to put the tools in so that a customer could do that on REHL. Get started, get those containers deployed on REHL. Put those tools directly, and we added it to old protocol, which is a tool built for security. It brings that security of SC Lennox and brings that up and adds value at the container level. It's those kinds of things as you see the bridge from well into open shift. How do we help a customer rich? That skill journey as well along that path and I think right now in kubernetes and Containers skills is a is a big, big area of focus, so the more we can help ease that across the portfolio and bring those things together is really important. And I know we're working very closely with the chefs in the, um and the team there in order to help bridge that. >>Excellent. Stephanie, I just want to give you the last word. We talked a lot about the ongoing journey that customers are going through. So give us your final take away as to how customers should be thinking about red hat in general and role specifically as their journey goes forward. >>I think I think one of the things >>we're very proud of here at Red Hat is that we always, particularly in the open source communities with our customers, with our partners, we want to roll up our sleeves and help, and that's we want. So, developer, we wanna work upstream with you. It's one of the things we're very proud of, and now, particularly in this time it's We want to make sure that folks understand we're here to help, and we want to make sure that you're getting the most out of the subscriptions you have, Um, and we help. We help you on that journey both to get the most out of you can out of your data center today. But also be ready for the innovation that you want to consume going forward. And we're collectively working across red Hat in order to make that happen. But it's, um >>even though this is different and it's there the virtual Experience edition of Red Hat Summit. It's >>great to be together and be able to share the whole message. >>Well, Stephanie, the open source community is definitely used to collaborating remotely. So thank you so much for joining us. It's a pleasure to see you. And we would hope to talk again soon. >>Great to see you too. Thank you for the time. >>Alright. You're watching the Cube's coverage of Red Hat Summit 2020 digitally with remote guests from around the globe. Instrument a man and thank you for watching the Cube. >>Yeah, yeah, yeah.