>> From theCUBE studios in Palo Alto and Boston, bringing you data-driven insights from theCUBE and ETR. This is braking analysis with Dave Vellante. >> A new era of data is upon us, and we're in a state of transition. You know, even our language reflects that. We rarely use the phrase big data anymore, rather we talk about digital transformation or digital business, or data-driven companies. Many have come to the realization that data is a not the new oil, because unlike oil, the same data can be used over and over for different purposes. We still use terms like data as an asset. However, that same narrative, when it's put forth by the vendor and practitioner communities, includes further discussions about democratizing and sharing data. Let me ask you this, when was the last time you wanted to share your financial assets with your coworkers or your partners or your customers? Hello everyone, and welcome to this week's Wikibon Cube Insights powered by ETR. In this breaking analysis, we want to share our assessment of the state of the data business. We'll do so by looking at the data mesh concept and how a leading financial institution, JP Morgan Chase is practically applying these relatively new ideas to transform its data architecture. Let's start by looking at what is the data mesh. As we've previously reported many times, data mesh is a concept and set of principles that was introduced in 2018 by Zhamak Deghani who's director of technology at ThoughtWorks, it's a global consultancy and software development company. And she created this movement because her clients, who were some of the leading firms in the world had invested heavily in predominantly monolithic data architectures that had failed to deliver desired outcomes in ROI. So her work went deep into trying to understand that problem. And her main conclusion that came out of this effort was the world of data is distributed and shoving all the data into a single monolithic architecture is an approach that fundamentally limits agility and scale. Now a profound concept of data mesh is the idea that data architectures should be organized around business lines with domain context. That the highly technical and hyper specialized roles of a centralized cross functional team are a key blocker to achieving our data aspirations. This is the first of four high level principles of data mesh. So first again, that the business domain should own the data end-to-end, rather than have it go through a centralized big data technical team. Second, a self-service platform is fundamental to a successful architectural approach where data is discoverable and shareable across an organization and an ecosystem. Third, product thinking is central to the idea of data mesh. In other words, data products will power the next era of data success. And fourth data products must be built with governance and compliance that is automated and federated. Now there's lot more to this concept and there are tons of resources on the web to learn more, including an entire community that is formed around data mesh. But this should give you a basic idea. Now, the other point is that, in observing Zhamak Deghani's work, she is deliberately avoided discussions around specific tooling, which I think has frustrated some folks because we all like to have references that tie to products and tools and companies. So this has been a two-edged sword in that, on the one hand it's good, because data mesh is designed to be tool agnostic and technology agnostic. On the other hand, it's led some folks to take liberties with the term data mesh and claim mission accomplished when their solution, you know, maybe more marketing than reality. So let's look at JP Morgan Chase in their data mesh journey. Is why I got really excited when I saw this past week, a team from JPMC held a meet up to discuss what they called, data lake strategy via data mesh architecture. I saw that title, I thought, well, that's a weird title. And I wondered, are they just taking their legacy data lakes and claiming they're now transformed into a data mesh? But in listening to the presentation, which was over an hour long, the answer is a definitive no, not at all in my opinion. A gentleman named Scott Hollerman organized the session that comprised these three speakers here, James Reid, who's a divisional CIO at JPMC, Arup Nanda who is a technologist and architect and Serita Bakst who is an information architect, again, all from JPMC. This was the most detailed and practical discussion that I've seen to date about implementing a data mesh. And this is JP Morgan's their approach, and we know they're extremely savvy and technically sound. And they've invested, it has to be billions in the past decade on data architecture across their massive company. And rather than dwell on the downsides of their big data past, I was really pleased to see how they're evolving their approach and embracing new thinking around data mesh. So today, we're going to share some of the slides that they use and comment on how it dovetails into the concept of data mesh that Zhamak Deghani has been promoting, and at least as we understand it. And dig a bit into some of the tooling that is being used by JP Morgan, particularly around it's AWS cloud. So the first point is it's all about business value, JPMC, they're in the money business, and in that world, business value is everything. So Jr Reid, the CIO showed this slide and talked about their overall goals, which centered on a cloud first strategy to modernize the JPMC platform. I think it's simple and sensible, but there's three factors on which he focused, cut costs always short, you got to do that. Number two was about unlocking new opportunities, or accelerating time to value. But I was really happy to see number three, data reuse. That's a fundamental value ingredient in the slide that he's presenting here. And his commentary was all about aligning with the domains and maximizing data reuse, i.e. data is not like oil and making sure there's appropriate governance around that. Now don't get caught up in the term data lake, I think it's just how JP Morgan communicates internally. It's invested in the data lake concept, so they use water analogies. They use things like data puddles, for example, which are single project data marts or data ponds, which comprise multiple data puddles. And these can feed in to data lakes. And as we'll see, JPMC doesn't strive to have a single version of the truth from a data standpoint that resides in a monolithic data lake, rather it enables the business lines to create and own their own data lakes that comprise fit for purpose data products. And they do have a single truth of metadata. Okay, we'll get to that. But generally speaking, each of the domains will own end-to-end their own data and be responsible for those data products, we'll talk about that more. Now the genesis of this was sort of a cloud first platform, JPMC is leaning into public cloud, which is ironic since the early days, in the early days of cloud, all the financial institutions were like never. Anyway, JPMC is going hard after it, they're adopting agile methods and microservices architectures, and it sees cloud as a fundamental enabler, but it recognizes that on-prem data must be part of the data mesh equation. Here's a slide that starts to get into some of that generic tooling, and then we'll go deeper. And I want to make a couple of points here that tie back to Zhamak Deghani's original concept. The first is that unlike many data architectures, this puts data as products right in the fat middle of the chart. The data products live in the business domains and are at the heart of the architecture. The databases, the Hadoop clusters, the files and APIs on the left-hand side, they serve the data product builders. The specialized roles on the right hand side, the DBA's, the data engineers, the data scientists, the data analysts, we could have put in quality engineers, et cetera, they serve the data products. Because the data products are owned by the business, they inherently have the context that is the middle of this diagram. And you can see at the bottom of the slide, the key principles include domain thinking, an end-to-end ownership of the data products. They build it, they own it, they run it, they manage it. At the same time, the goal is to democratize data with a self-service as a platform. One of the biggest points of contention of data mesh is governance. And as Serita Bakst said on the Meetup, metadata is your friend, and she kind of made a joke, she said, "This sounds kind of geeky, but it's important to have a metadata catalog to understand where data resides and the data lineage in overall change management. So to me, this really past the data mesh stink test pretty well. Let's look at data as products. CIO Reid said the most difficult thing for JPMC was getting their heads around data product, and they spent a lot of time getting this concept to work. Here's the slide they use to describe their data products as it related to their specific industry. They set a common language and taxonomy is very important, and you can imagine how difficult that was. He said, for example, it took a lot of discussion and debate to define what a transaction was. But you can see at a high level, these three product groups around wholesale, credit risk, party, and trade and position data as products, and each of these can have sub products, like, party, we'll have to know your customer, KYC for example. So a key for JPMC was to start at a high level and iterate to get more granular over time. So lots of decisions had to be made around who owns the products and the sub-products. The product owners interestingly had to defend why that product should even exist, what boundaries should be in place and what data sets do and don't belong in the various products. And this was a collaborative discussion, I'm sure there was contention around that between the lines of business. And which sub products should be part of these circles? They didn't say this, but tying it back to data mesh, each of these products, whether in a data lake or a data hub or a data pond or data warehouse, data puddle, each of these is a node in the global data mesh that is discoverable and governed. And supporting this notion, Serita said that, "This should not be infrastructure-bound, logically, any of these data products, whether on-prem or in the cloud can connect via the data mesh." So again, I felt like this really stayed true to the data mesh concept. Well, let's look at some of the key technical considerations that JPM discussed in quite some detail. This chart here shows a diagram of how JP Morgan thinks about the problem, and some of the challenges they had to consider were how to write to various data stores, can you and how can you move data from one data store to another? How can data be transformed? Where's the data located? Can the data be trusted? How can it be easily accessed? Who has the right to access that data? These are all problems that technology can help solve. And to address these issues, Arup Nanda explained that the heart of this slide is the data in ingestor instead of ETL. All data producers and contributors, they send their data to the ingestor and the ingestor then registers the data so it's in the data catalog. It does a data quality check and it tracks the lineage. Then, data is sent to the router, which persists the data in the data store based on the best destination as informed by the registration. This is designed to be a flexible system. In other words, the data store for a data product is not fixed, it's determined at the point of inventory, and that allows changes to be easily made in one place. The router simply reads that optimal location and sends it to the appropriate data store. Nowadays you see the schema infer there is used when there is no clear schema on right. In this case, the data product is not allowed to be consumed until the schema is inferred, and then the data goes into a raw area, and the inferer determines the schema and then updates the inventory system so that the data can be routed to the proper location and properly tracked. So that's some of the detail of how the sausage factory works in this particular use case, it was very interesting and informative. Now let's take a look at the specific implementation on AWS and dig into some of the tooling. As described in some detail by Arup Nanda, this diagram shows the reference architecture used by this group within JP Morgan, and it shows all the various AWS services and components that support their data mesh approach. So start with the authorization block right there underneath Kinesis. The lake formation is the single point of entitlement and has a number of buckets including, you can see there the raw area that we just talked about, a trusted bucket, a refined bucket, et cetera. Depending on the data characteristics at the data catalog registration block where you see the glue catalog, that determines in which bucket the router puts the data. And you can see the many AWS services in use here, identity, the EMR, the elastic MapReduce cluster from the legacy Hadoop work done over the years, the Redshift Spectrum and Athena, JPMC uses Athena for single threaded workloads and Redshift Spectrum for nested types so they can be queried independent of each other. Now remember very importantly, in this use case, there is not a single lake formation, rather than multiple lines of business will be authorized to create their own lakes, and that creates a challenge. So how can that be done in a flexible and automated manner? And that's where the data mesh comes into play. So JPMC came up with this federated lake formation accounts idea, and each line of business can create as many data producer or consumer accounts as they desire and roll them up into their master line of business lake formation account. And they cross-connect these data products in a federated model. And these all roll up into a master glue catalog so that any authorized user can find out where a specific data element is located. So this is like a super set catalog that comprises multiple sources and syncs up across the data mesh. So again to me, this was a very well thought out and practical application of database. Yes, it includes some notion of centralized management, but much of that responsibility has been passed down to the lines of business. It does roll up to a master catalog, but that's a metadata management effort that seems compulsory to ensure federated and automated governance. As well at JPMC, the office of the chief data officer is responsible for ensuring governance and compliance throughout the federation. All right, so let's take a look at some of the suspects in this world of data mesh and bring in the ETR data. Now, of course, ETR doesn't have a data mesh category, there's no such thing as that data mesh vendor, you build a data mesh, you don't buy it. So, what we did is we use the ETR dataset to select and filter on some of the culprits that we thought might contribute to the data mesh to see how they're performing. This chart depicts a popular view that we often like to share. It's a two dimensional graphic with net score or spending momentum on the vertical axis and market share or pervasiveness in the data set on the horizontal axis. And we filtered the data on sectors such as analytics, data warehouse, and the adjacencies to things that might fit into data mesh. And we think that these pretty well reflect participation that data mesh is certainly not all compassing. And it's a subset obviously, of all the vendors who could play in the space. Let's make a few observations. Now as is often the case, Azure and AWS, they're almost literally off the charts with very high spending velocity and large presence in the market. Oracle you can see also stands out because much of the world's data lives inside of Oracle databases. It doesn't have the spending momentum or growth, but the company remains prominent. And you can see Google Cloud doesn't have nearly the presence in the dataset, but it's momentum is highly elevated. Remember that red dotted line there, that 40% line, anything over that indicates elevated spending momentum. Let's go to Snowflake. Snowflake is consistently shown to be the gold standard in net score in the ETR dataset. It continues to maintain highly elevated spending velocity in the data. And in many ways, Snowflake with its data marketplace and its data cloud vision and data sharing approach, fit nicely into the data mesh concept. Now, a caution, Snowflake has used the term data mesh in it's marketing, but in our view, it lacks clarity, and we feel like they're still trying to figure out how to communicate what that really is. But is really, we think a lot of potential there to that vision. Databricks is also interesting because the firm has momentum and we expect further elevated levels in the vertical axis in upcoming surveys, especially as it readies for its IPO. The firm has a strong product and managed service, and is really one to watch. Now we included a number of other database companies for obvious reasons like Redis and Mongo, MariaDB, Couchbase and Terradata. SAP as well is in there, but that's not all database, but SAP is prominent so we included them. As is IBM more of a database, traditional database player also with the big presence. Cloudera includes Hortonworks and HPE Ezmeral comprises the MapR business that HPE acquired. So these guys got the big data movement started, between Cloudera, Hortonworks which is born out of Yahoo, which was the early big data, sorry early Hadoop innovator, kind of MapR when it's kind of owned course, and now that's all kind of come together in various forms. And of course, we've got Talend and Informatica are there, they are two data integration companies that are worth noting. We also included some of the AI and ML specialists and data science players in the mix like DataRobot who just did a monster $250 million round. Dataiku, H2O.ai and ThoughtSpot, which is all about democratizing data and injecting AI, and I think fits well into the data mesh concept. And you know we put VMware Cloud in there for reference because it really is the predominant on-prem infrastructure platform. All right, let's wrap with some final thoughts here, first, thanks a lot to the JP Morgan team for sharing this data. I really want to encourage practitioners and technologists, go to watch the YouTube of that meetup, we'll include it in the link of this session. And thank you to Zhamak Deghani and the entire data mesh community for the outstanding work that you're doing, challenging the established conventions of monolithic data architectures. The JPM presentation, it gives you real credibility, it takes Data Mesh well beyond concept, it demonstrates how it can be and is being done. And you know, this is not a perfect world, you're going to start somewhere and there's going to be some failures, the key is to recognize that shoving everything into a monolithic data architecture won't support massive scale and agility that you're after. It's maybe fine for smaller use cases in smaller firms, but if you're building a global platform in a data business, it's time to rethink data architecture. Now much of this is enabled by the cloud, but cloud first doesn't mean cloud only, doesn't mean you'll leave your on-prem data behind, on the contrary, you have to include non-public cloud data in your Data Mesh vision just as JPMC has done. You've got to get some quick wins, that's crucial so you can gain credibility within the organization and grow. And one of the key takeaways from the JP Morgan team is, there is a place for dogma, like organizing around data products and domains and getting that right. On the other hand, you have to remain flexible because technologies is going to come, technology is going to go, so you got to be flexible in that regard. And look, if you're going to embrace the metaphor of water like puddles and ponds and lakes, we suggest maybe a little tongue in cheek, but still we believe in this, that you expand your scope to include data ocean, something John Furry and I have talked about and laughed about extensively in theCUBE. Data oceans, it's huge. It's the new data lake, go transcend data lake, think oceans. And think about this, just as we're evolving our language, we should be evolving our metrics. Much the last the decade of big data was around just getting the stuff to work, getting it up and running, standing up infrastructure and managing massive, how much data you got? Massive amounts of data. And there were many KPIs built around, again, standing up that infrastructure, ingesting data, a lot of technical KPIs. This decade is not just about enabling better insights, it's a more than that. Data mesh points us to a new era of data value, and that requires the new metrics around monetizing data products, like how long does it take to go from data product conception to monetization? And how does that compare to what it is today? And what is the time to quality if the business owns the data, and the business has the context? the quality that comes out of them, out of the shoot should be at a basic level, pretty good, and at a higher mark than out of a big data team with no business context. Automation, AI, and very importantly, organizational restructuring of our data teams will heavily contribute to success in the coming years. So we encourage you, learn, lean in and create your data future. Okay, that's it for now, remember these episodes, they're all available as podcasts wherever you listen, all you got to do is search, breaking analysis podcast, and please subscribe. Check out ETR's website at etr.plus for all the data and all the survey information. We publish a full report every week on wikibon.com and siliconangle.com. And you can get in touch with us, email me david.vellante@siliconangle.com, you can DM me @dvellante, or you can comment on my LinkedIn posts. This is Dave Vellante for theCUBE insights powered by ETR. Have a great week everybody, stay safe, be well, and we'll see you next time. (upbeat music)

>> Announcer: From Copenhagen, Denmark, it's theCUBE. Covering KubeCon and CloudNativeCon Europe 2018. Brought to you by the Cloud Native Computing Foundation and its ecosystem partners. >> Hello and welcome back to the live CUBE coverage here in Copenhagen, Denmark, for KubeCon 2018, Kubernetes European conference. This is theCUBE, I'm John Furrier, my co-host Lauren Cooney here with Adrian Cockcroft who is the Vice President of Cloud Architecture and Strategy for Amazon Web Services, AWS. CUBE alumni, great to see you, a legend in the industry, great to have you on board today. Thanks for coming on. >> Thanks very much. >> Quick update, Amazon, we were at AWS Summit recently, I was at re:Invent last year, it gets bigger and bigger just continue to grow. Congratulations on successful great earnings. You guys posted last week, just continuing to show the scale and leverage that the cloud has. So, again, nothing really new here, cloud is winning and the model of choice. So you guys are doing a great job, so congratulations. Open source, you're handling a lot of that now. This community here, is all about driving cloud standards. >> Adrian: Yeah. >> Your guys position on that is? Standards are great, you do what customers want, as Andy Jassy always says, what's the update? I mean, what's new since Austin last year? >> Yeah, well, it's been great to be back on had a great video of us talking at Austin, it's been very helpful to get the message out of what we're doing in containers and what the open source team that I lead has been up to. It's been very nice. Since then we've done quite a lot. We were talking about doing things then, which we've now actually done and delivered on. We're getting closer to getting our Kubernetes service out, EKS. We hired Bob Wise, he started with us in January, he's the general manager of EKS. Some of you may know Bob has been working with Kubernetes since the early days. He was on the CNCF board before he joined us. He's working very hard, they have a team cranking away on all the things we need to do to get the EKS service out. So that's been major focus, just get it out. We have a lot of people signed up for the preview. Huge interest, we're onboarding a lot of people every week, and we're getting good feedback from people. We have demos of it in the booth here this week. >> So you guys are very customer-centric, following you guys closely as you know. What's the feedback that you're hearing and what are you guys ingesting from an intelligence standpoint from the field. Obviously, a new constituent, not new, but a major constituent is open source communities, as well as paying enterprise customers? What's the feedback? What are you hearing? I would say beyond tire kicking, there's general interest in what Kubernetes has enabled. What's Amazon's view of that? >> Yeah, well, open source in general is always getting a larger slice of what people want to do. Generally, people are trying to get off of their enterprise solutions and evolving into an open source space and then you kind of evolve from that into buying it as a service. So that's kind of the evolution from one trend, custom or enterprise software, to open source to as a service. And we're standing up all of these tools as a service to make them easier to consume for people. Just, everybody's happy to do that. What I'm hearing from customers is that that's what they're looking for. They want it to be easy to use, they want it to scale, they want it to be reliable and work, and that's what we're good at doing. And then they want to track the latest moves in the industry and run with the latest technologies and that's what Kubernetes and the CNCF is doing, gathering together a lot of technologies. Building the community around it, just able to move faster than we'd move on our own. We're leveraging all of those things into what we're doing. >> And the status of EKS right now is in preview? And the estimated timetable for GA? >> In the next few months. >> Next few months. >> You know, get it out then right now it's running in Oregon, in our Oregon data center, so the previews are all happening there. That gets us our initial thing and then everyone go okay, we want to in our other regions, so we have to do that. So another service we have is Fargate, which is basically say just here's a container, I want to run it, you don't have to declare a node or an instance to run it first. We launched that at re:Invent, that's already in production obviously, we just rolled that out to four regions. That's in Virginia, Oregon, Dublin and Ohio right now. A huge interest in Fargate, it lets you simplify your deployments a little bit. We just posted a new blog post that we have an open source blog, you can find if you want to keep up with what's going on with the open source team at AWS. Just another post this morning and it's a first pass at getting Fargate to work with Kubernetes using Virtual Kubelet which is a project that was kicked off by, it's an experimental project, not part of the core Kubernetes system. But it's running on the side. It's something that Microsoft came up with a little while ago. So we now have, we're working with them. We did a pull request, they accepted it, so that team and AWS and a few other customers and other people in the community, working together to provide you a way to start up Fargate as the underlying layer for provisioning containers underneath Kubernetes as the API for doing you know the management of that. >> So who do you work with mostly when you're working in open source? Who do you partner with? What communities are you engaging with in particular? >> It's all over. >> All over? >> Wherever the communities are we're engaging with them. >> Lauren: Okay, any particular ones that stand out? >> Other than CNCF, we have a lot of engagement with Apache Hadoop ecosystem. A lot of work in data science, there's many, many projects in that space. In AI and machine learning, we've sponsored, we've spend a lot of time working with Apache MXNet, we were also working off with TensorFlow by Torch and Caffe and there's a lot, those are all open source frameworks so there's lots of contributions there. In the serverless arena, we have our own SAM service application model. We've been open sourcing more of that recently ourselves and we're working with various other people. Across these different groups there's different conferences you go to, there's different things we do. We just sponsored Rails Conference. My team sponsors and manages most of the open source conference events we go to now. We just did RAILCON, we're doing a Rust conference, soon I think, there's Python conferences. I forget when all these are. There's a massive calendar of conferences that we're supporting. >> Make sure you email us that that list, we're interested actually in looking at what the news and action is. >> So the language ones, AltCon's our flagship one, we'll be top-level sponsor there. When we get to the U.S., CubeCon in Seattle, it's right there, it's two weeks after re:Invent. It's going to be much easier to manage. When we go to re:Invent it's like everyone just wants to take that week off, right. We got a week for everyone to recover and then it's in the hometown. >> You still have that look in your eyes when we interviewed you in Austin you came down, we both were pretty exhausted after re:Invent. >> Yeah, so we announced a bunch of things on Wednesday and Thursday and I had to turn it into a keynote by Tuesday and get everyone to agree. That's what was going on, that was very compressed. We have more time and all of the engineering teams that really want to be at an event like this, were right in the hometown for a lot. >> What's it like workin' at Amazon, I got to ask you it since you brought it up. I mean and you guys run hard at Amazon, you're releasing stuff with a pace that's unbelievable. I mean, I get blown away every year. Almost seems like, inhuman that that you guys can run at that pace. And earnings, obviously, the business results speak for themselves, what's it like there? I mean, you put your running shoes on, you run a marathon every day. >> It's lots of small teams working relatively independently and that scales and that's something other engineering organizations have trouble with. They build hierarchies that slow down. We have a really good engineering culture where every time you start a new team, it runs at its own speed. We've shown that as we add more and more resources, more teams, they are just executing. In fact, their accelerated, they're building on top of other things. We get to build higher and higher level abstractions to layer into. Just getting easier and easier to build things. We're accelerating our pace of innovation there's no slowing down. >> I was telling Jassy they're going to write a Harvard Business School case study on a lot of the management practices, but certainly the impact on the business side with the model that you guys do. But I got to ask you, on the momentum side, super impressed with SageMaker. I predicted on theCUBE at AWS Summit that that will be the fastest growing service. It will overtake Aurora, I think that is currently on stage, presented as the fastest growing service. SageMaker is really popular. Updates there, its role in the community. Obviously, Kubernete's a good fit for orchestrating things. We heard about CubeFlow, is an interesting model. What's going on with SageMaker how is it interplaying with Kubernetes? >> People that want to run, if you're running on-premise, cluster of GPU enabled machines then CubeFlow is a great way of doing that. You're on TensorFlow, that manages your cluster, you run CubeFlow on top. SageMaker is running at very low scale and like a lot of things we do at AWS, what you need to run an individual cluster for any one customer is different from running a multi-tenant service. SageMaker sits on top of ECS and it's now one of the largest generators of traffic to ECS which is Amazon's horizontally scaled, multi-tenant, cluster management system, which is now doing hundreds of millions of container launches a week. That is continuing to grow. We see Kubernetes as it's a more portable abstraction. It has some more, different layers of API's and a big community around it. But for the heavy lifting of running tens of thousands of containers in for a single application, we're still at the level where ECS does that every day and Kubernetes that's kind of the extreme case, where a few people are pushing it. It'll gradually grow scale. >> It's evolution. >> There's an evolution here. But the interesting things are, we're starting to get some convergence on some of the interfaces. Like the interfacing at CNA, CNA is the way you do networking on containers and there is one way of doing that, that is shared by everybody through CNA. EKS uses it, BCS uses it and Kubernetes uses it. >> And the impact of customers is what for that? What's the impact? >> It means the networking structures you want to set up will be the same. And the capabilities and the interfaces. But what happens on AWS is because it has a direct plug-in, you can hook it up to our accelerated networking infrastructure. So, AWS's instances right now, we've offloaded most of the network traffic processing. You're running 25 gigabits of traffic, that's quite a lot of work even for a big CPU, but it's handled by the the Nitro plug-in architecture we have, this in our latest instance type. So if you talked a bit about that at re:Invent but what you're getting is enormous, complete hypervisor offload at the core machine level. You get to use that accelerated networking. You're plugging into that interface. But that, if you want to have a huge number of containers on a machine and you're not really trying to drive very high throughput, then you can use Calico and we support that as well. So, multiple different ways but all through the same thing, the same plug-ins on both. >> System portability. You mentioned some stats, what's the numbers you mentioned? How many containers you're launching a week, hundreds of thousands? On ECS, our container platform that's been out for a few years, so hundreds of millions a week. It's really growing very fast. The containers are taking off everywhere. >> Microservices growth is, again that's the architecture. As architecture is a big part of the conversation what's your dialogue with customers? Because the modern software architecture in cloud, looks a lot different than what it was in the three layered approach that used to be the web stack. >> Yeah, and I think to add to that, you know we were just talking to folks about how in large enterprise organizations, you're still finding groups that do waterfall development. How are you working to kind of bring these customers and these developers into the future, per se? >> Yeah, that's actually, I spend about half my time managing the open source team and recruiting. The other half is talking to customers about this topic. I spend my time traveling around the world, talking at summits and events like this and meeting with customers. There's lots of different problems slowing people down. I think you see three phases of adoption of cloud, in general. One is just speed. I want to get something done quickly, I have a business need, I want to do it. I want machines in minutes instead of months, right, and that speeds everything up so you get something done quickly. The second phase is where you're starting to do stuff at scale and that's where you need cloud native. You really need to have elastic services, you can scale down as well as up, otherwise, you just end up with a lot of idle machines that cost you too much and it's not giving you the flexibility. The third phase we're getting into is complete data center shutdown. If you look at investing in a new data center or data center refresh or just opening an AWS account, it really doesn't make sense nowadays. We're seeing lots of large enterprises either considering it or well into it. Some are a long way into this. When you shut down the data center all of the backend core infrastructure starts coming out. So we're starting to see sort of mainframe replacement and the really critical business systems being replaced. Those are the interesting conversations, that's one of the areas that I'm particularly interested in right now and it's leading into this other buzzword, if you like, called chaos engineering. Which is sort of the, think of it as the availability model for cloud native and microservices. We're just starting a working group at CNCF around chaos engineering, is being started this week. So you can get a bit involved in how we can build some standards. >> That's going to be at Stanford? >> It's here, I mean it's a working group. >> Okay, online. >> The CNCF working group, they are wherever the people are, right. >> So, what is that conversation when you talk about that mainframe kind of conversation or shut down data centers to the cloud. What is the key thing that you promote, up front, that needs to get done by the by the customer? I mean, obviously you have the pillars, the key pillars, but you think about microservices it's a global platform, it's not a lift and shift situation, kind of is, it shut down, but I mean not at that scale. But, security, identity, authentication, there's no perimeter so you know microservices, potentially going to scale. What are the things that you promote upfront, that they have to do up front. What are the up front, table stake decisions? >> For management level, the real problem is people problems. And it's a technology problem somewhere down in the weeds. Really, if you don't get the people structures right then you'll spend forever going through these migrations. So if you sort of bite the bullet and do the reorganization that's needed first and get the right people in the right place, then you move much faster through it. I say a lot of the time, we're way upstream of picking a technology, it's much more about understanding the sort of DevOps, Agile and the organizational structures for these more cellular based organizations, you know, AWS is a great example of that. Netflix are another good example of that. Capital One is becoming a good example of that too. In banking, they're going much faster because they've already gone through that. >> So they're taking the Amazon model, small teams. Is that your general recommendation? What's your general recommendation? >> Well, this is the whole point of microservices, is that they're built by these small teams. It's called Conway's law, which says that the code will end up looking like the team, the org structure that built it. So, if you set up a lots of small teams, you will end up with microservices. That's just the way it works, right. If you try to take your existing siloed architecture with your long waterfall things, it's very hard not to build a monolith. Getting the org structure done first is right. Then we get into kind of the landing zone thing. You could spend years just debating what your architecture should be and some people have and then every year they come back, and it's changing faster than they can decide what to do. That's another kind of like analysis paralysis mode you see some larger enterprises in. I always think just do it. What's the standard best practice, layout my accounts like this, my networks like this, my structures we call it landing zone. We get somebody up to speed incredibly quickly and it's the beaten path. We're starting to build automation around these on boarding things, we're just getting stuff going. >> That's great. >> Yeah, and then going back to the sort of chaos engineering kind of idea, one of the first things I should think you should put into this infrastructure is the disaster recovery automation. Because if that gets there before the apps do, then the apps learn to live with the chaos monkeys and things like that. Really, one of the first apps we installed at Netflix was Chaos Monkey. It wasn't added later, it was there when you arrived. Your app had to survive the chaos that was in the system. So, think of that as, it used to be disaster recovery was incredibly expensive, hard to build, custom and very difficult to test. People very rarely run through their disaster recovery testing data center fail over, but if you build it in on day one, you can build it automated. I think Kubernetes is particularly interesting because the API's to do that automation are there. So we're looking at automating injecting failure at the Kubernetes level and also injecting into the underlying machines that are running Good Maze, like attacking the control plane to make sure that the control plane recovery works. I think there's a lot we can do there to automate it and make it into a low-cost, productized, safe, reliable thing, that you do a lot. Rather than being something that everyone's scared of doing that. >> Or they bolted on after they make decisions and the retrofit, pre-existing conditions into a disaster recovery. Which is chaotic in and of itself. >> So, get the org chart right and then actually get the disaster recovery patterns. If you need something highly available, do that first, before the apps turn up. >> Adrian, thanks for coming on, chaos engineering, congratulations and again, we know you know a little about Netflix, you know that environment, and been big Amazon customer. Congratulations on your success, looking forward to keeping in touch. Thanks for coming on and sharing the AWS perspective on theCUBE. I'm John Furrier, Lauren Cooney live in Denmark for KubeCon 2018 part of the CNC at the Cloud Native Compute Foundation. We'll back with more live coverage, stay with us. We'll be right back. (upbeat music)

(upbeat music) >> Announcer: Live from Las Vegas it's The Cube, covering IBM Think 2018. Brought to you by IBM. >> We're back at IBM Think 2018. This is The Cube, the leader in live tech coverage. My name is Dave Vellante. I'm here with my co-host Peter Burris, Moe Abdulla is here. He's the vice president of Cloud Garage and Solution Architecture Hybrid Cloud for IBM and Tim Davis is here, Data Analytics and Cloud Architecture Group and Services Center of Excellence IBM. Gentlemen, welcome to The Cube. >> Glad to be here. >> Thanks for having us. >> Moe, Garage, Cloud Garage, I'm picturing drills and wrenches, what's the story with Garage? Bring that home for us. >> (laughs) I wish it was that type of a garage. My bill would go down for sure. No, the garage is playing on the theme of the start-up, the idea of how do you bring new ideas and innovate on them, but for the enterprises. So what two people can do with pizza and innovate, how do you bring that to a larger concept. That's what The Garage is really about. >> Alright and Tim, talk about your role. >> Yeah, I lead the data and analytics field team and so we're really focused on helping companies do digital transformation and really drive digital and analytics, data, into their businesses to get better business value, accelerate time to value. >> Awesome, so we're going to get into it. You guys both have written books. We're going to get into the Field Guide and we're going to get into the Cloud Adoption Playbook, but Peter I want you to jump in here because I know you got to run, so get your questions in and then I'll take over. >> Sure I think so obvious question number one is, one of the biggest challenges we've had in analytics over the past couple of years is we had to get really good at the infrastructure and really good at the software and really good at this and really good at that and there were a lot of pilot failures because if you succeeded at one you might not have succeeded at the other. The Garage sounds like it's time to value based. Is that the right way to think about this? And what are you guys together doing to drive time to value, facilitate adoption, and get to the changes, the outcomes that the business really wants? >> So Tim you want to start? >> Yeah I can start because Moe leads the overall Garage and within the Garage we have something called the Data First Methodology where we're really driving a direct engagement with the clients where we help them develop a data strategy because most clients when they do digital transformation or really go after data, they're taking kind of a legacy approach. They're building these big monolithic data warehouses, they're doing big master data management programs and what we're really trying to do is change the paradigm and so we connect with the Data First Methodology through the Garage to get to a data strategy that's connected to the business outcome because it's what data and analytics do you need to successfully achieve what you're trying to do as a business. A lot of this is digital transformation which means you're not only changing what you're doing from a data warehouse to a data lake, but you're also accelerating the data because now we have to get into the time domain of a customer, or your customer where they may be consuming things digitally and so they're at a website, they're moving into a bank branch, they go into a social media site, maybe they're being contacted by a fintech. You've got to retain an maintain a digital relationship and that's the key. >> And The Garage itself is really playing on the same core value of it's not the big beating the small anymore, it's the fast beating the slow and so when you think of the fast beating the slow, how do you achieve fast? You really do that by three ways. So The Garage says the first way to achieve fast is to break down the problem into smaller chunks, also known as MVPs or minimum viable product. So you take a very complex problem that people are talking and over-talking and over engineering, and you really bring it down to something that has a client value, user-centered. So bring the discipline from the business side, the operation side, the developers, and we mush them together to center that. That's one way to do fast. The second way-- >> By the way, I did, worked with a client. They started calling it minimum viable outcomes. >> Yes, minimum viable outcomes means what product and there's a lot of types of these minimum viable to achieve, we're talking about four weeks, six weeks, and so on and so forth. The story of American Airlines was taking all of their kiosk systems for example and really changing them both in terms of the types of services they can deliver, so now you can recheck your flights, et cetera, within six week periods and you really, that's fast, and doing it in one terminal and then moving to others. The second way you do fast is by understanding that the change is not just technology. The change is culture, process, and so on. So when you come to The Garage, it's not like the mechanic style garage where you are sitting in the waiting room and the mechanic is fixing your car. Not at all. You really have some sort of mechanical skills and you're in there with me. That's called pair programming. That's called test-driven, these types of techniques and methodologies are proven in the industry. So Tim will sit right next to me and we'll code together. By the time Tim goes back to his company, he's now an expert on how to do it. So fast is achieving the cultural transformation as well as this minimum viable aspect. >> Hands on, and you guys are actually learning from each in that experience, aren't you? >> Absolutely. >> Oh yeah. >> And then sharing, yeah. >> I would also say I would think that there's one more thing for both of you guys and that is increasingly as business acknowledges that data is an asset unlike traditional systems approaches where we built a siloed application, this server, that database manager, this data model, that application and then we do some integration at some point in time, when you start with this garage approach, data-centric approach, figure out how that works, now you have an asset that can be reused in a lot of new and interesting ways. Does that also factor into this from a speed aspect? >> Yeah it does. And this is a key part. We have something called data science experience now and we're really driving pilots through The Garage, through the data first method to get that rapid engagement and the goal is to do sprints, to do 12 to 20 week kind of sprints where we actually produce a business outcome that you show to the business and then you put it into production and we're actually developing algorithms and other things as we go that are part of the analytic result and that's kind of the key and behind that, you know the analytic result is really the, kind of the icing on the cake and the business value where you connect, but there's a whole foundation underneath that of data and that's why we do a data topology and the data topology has kind of replaced the data lake, replaces all that modeling because now we can have a data topology that spans on premise, private cloud, and public cloud and we can drive an integrated strategy with the governance program over that to actually support the data analytics that you're trying to drive and that's how we get at that. >> But that topology's got to tie back to the attributes of the data, right? Not the infrastructure that's associated with it. >> It does and the idea of the topology is you may have an existing warehouse. That becomes a zone in the topology, so we aren't really ripping and replacing, we're augmenting, you know, so we may augment an on premise warehouse that may sit in a relational database technology with a Hadoop environment that we can spin up in the cloud very rapidly and then the data science applications and so we can have a discovery zone as well as the traditional structured reporting and the level of data quality can be mixed. You may do analytic discovery against raw data versus where you have highly processed data where we have extreme data quality for regulatory reporting. >> Compared to a god box where everything goes through some pipe into that box. >> And you put in on later. >> Yes. >> Well and this is the, when Hadoop came out, right, people thought they were going to dump all their data into Hadoop and something beautiful was going to happen right? And what happened is everybody created a lot of data swamps out there. >> Something really ugly happened. >> Right, right, it's just a pile of data. >> Well they ended up with a cheaper data warehouse. >> But it's not because that data warehouse was structured, it has-- >> Dave: Yeah and data quality. >> All the data modeling, but all that stuff took massive amounts of time. When you just dump it into a Hadoop environment you have no structure, you have to discover the structures so we're really doing all the things we used to do with data warehousing only we're doing it in incremental, agile, faster method where you can also get access to the data all the way through it. >> Yeah that makes sense. >> You know it's not like we will serve new wine before its time, you know you can. >> Yeah, yeah, yeah, yeah. >> You know, now you can eat the grapes, you can drink the wine as it's fermenting, and you can-- >> No wrong or right, just throw it in and figure it out. >> There's an image that Tim chose that the idea of a data lake is this organized library with books, but the reality is a library with all the books dumped in the middle and go find the book that you want. >> Peter: And no Dewey Decimal. >> And, exactly. And if you want to pick on the idea that you had earlier, when you look at that type of a solution, the squad structure is changing. To solve that particular problem you no longer just have your data people on one side. You have a data person, you have the business person that's trying to distill it, you have the developer, you have the operator, so the concept of DevOps to try and synchronize between these two players is now really evolved and this is the first time you're hearing it, right at The Cube. It's the Biz Data DevOps. That's the new way we actually start to tell this. >> Dave: Explain that, explain that to us. >> Very simple. It starts with business requirements. So the business reflects the user and the consumer and they come with not just generics, they come with very specific requirements that then automatically and immediately says what are the most valuable data sources I need either from my enterprise or externally? Because the minute I understand those requirements and the persistence of those requirements, I'm now shaping the way the solution has to be implemented. Data first, not data as an afterthought. That's why we call it the data first method. The developers then, when they're building the cloud infrastructure, they really understand the type of resilience, the type of compliance, the type of meshing that you need to do and they're doing it from the outside. And because of the fact that they're dealing with data, the operation people automatically understand that they have to deal with the right to recovery and so on and so forth. So now we're having this. >> Makes sense. You're not throwing it over the wall. >> Exactly. >> That's where the DevOps piece comes in. >> And you're also understanding the velocity of data, through the enterprise as well as the gaps that you have as an enterprise because you're, when you go into a digital world you have to accumulate a lot more data and then you have to be able to match that and you have to be able to do identity resolution to get to a customer to understand all the dimensions of it. >> Well in the digital world, data is the core, so and it's interesting what you were saying Moe about essentially the line of business identifying the data sources because they're the ones who know how data affects monetization. >> Yes. >> Inder Paul Mendari, when he took over as IBM Chief Data Officer, said you must from partnerships with the line of business in order to understand how to monetize, how data contributes to the monetization and your DevOps metaphor is very important because everybody is sort of on the same page is the idea right? >> That's right. >> And there's a transformation here because we're working very close with Inder Paul's team and the emergence of a Chief Data Officer in many enterprises and we actually kind of had a program that we still have going from last year which is kind of the Chief Data Officer success program where you can help get at this because the classic IT structure has kind of started to fail because it's not data oriented, it's technology oriented, so by getting to a data oriented organization and having a elevated Chief Data Officer, you can get aligned with the line of business, really get your hands on the data and we prescribe the data topology, which is actually the back cover of that book, shows an example of one, because that's the new center of the universe. The technologies can change, this data can live on premise or in the cloud, but the topology should only change when your business changes-- (drowned out) >> This is hugely important so I want to pick up on something Ginny Rometti was talking about yesterday was incumbent disruptors. And when I heard that I'm like, come on no way. You know, instant skeptic. >> Tim: And that's what, that's what it is. >> Right and so then I started-- >> Moe: Wait, wait, discover. >> To think about it and you guys, what you're describing is how you take somebody, a company, who's been organized around human expertise and other physical assets for years, decades, maybe hundreds of years and transform them into a data oriented company-- >> Tim: Exactly. >> Where data is the core asset and human expertise is surrounding that data and learn to say look, it's not an, most data's in silos. You're busting down those silos. >> Exactly. >> And giving the prescription to do that. >> Exactly, yeah exactly. >> I think that's what Tim actually said this very, you heard us use the word re-prescriptive. You heard us use the word methodology, data first method or The Garage method and what we're really starting to see is these patterns from enterprises. You know, what works for a startup does not necessarily translate easily for an enterprise. You have to make it work in the context of the existing baggage, the existing processes, the existing culture. >> Customer expectations. >> Expectations, the scale, all of those type dimensions. So this particular notion of a prescription is we're taking the experiences from Hertz, Marriott, American Airlines, RVs, all of these clients that really have made that leap and got the value and essentially started to put it in the simple framework, seven elements to those frameworks, and that's in the adoption, yeah. >> You're talking this, right? >> Yeah. >> So we got two documents here, the Cloud Adoption Playbook, which Moe you authored, co-authored. >> Moe: With Tim's help. >> Tim as well and then this Field Guide, the IBM Data and Analytic Strategy Field Guide that Tim you also contributed to this right? >> Yeah, I wrote some of it yeah. >> Which augments the book, so I'll give you the description of it too. >> Well I love the hybrid cloud data topology in the back. >> That's an example of a topology on the back. >> So that's kind of cool. But go ahead, let's talk about these. >> So if you look at the cover of that book and piece of art, very well drawn. That's right. You will see that there are seven elements. You start to see architecture, you start to see culture and organization, you start to see methodology, you start to see all of these different components. >> Dave: Governance, management, security, emerging tech. >> That's right, that really are important in any type of transformation. And then when you look at the data piece, that's a way of taking that data and applying all of these dimensions, so when a client comes forward and says, "Look, I'm having a data challenge "in the sense of how do I transform access, "how do I share data, how to I monetize?," we start to take them through all of these dimensions and what we've been able to do is to go back to our starting comment, accelerate the transformation, sorry. >> And the real engagement that we're getting pulled into now in many cases and getting pulled right up the executive chains at these companies is data strategy because this is kind of the core, you've got to, so many companies have a business strategy, very good business strategies, but then you ask for their data strategy, they show you some kind of block diagram architecture or they show you a bunch of servers and the data center. You know, that's not a strategy. The data strategy really gets at the sources and consumption, velocity of data, and gaps in the data that you need to achieve your business outcome. And so by developing a data strategy, this opens up the patterns and the things that we talk to. So now we look at data security, we look at data management, we look at governance, we look at all the aspects of it to actually lay this out. And another thought here, the other transformation is in data warehousing, we've been doing this for the past, some of us longer than others, 20 or 30 years, right? And our whole thing then was we're going to align the silos by dumping all the data into this big data warehouse. That is really not the path to go because these things became like giant dinosaurs, big monolithic difficult to change. The data lake concept is you leave the data where it is and you establish a governance and management process over top of it and then you augment it with things like cloud, like Hadoop, like other things where we can rapidly spin up and we're taking advantage of things like object stores and advanced infrastructures and this is really where Moe and I connect with our IBM Club private platforms, with our data capabilities, because we can now put together managed solutions for some of these major enterprises and even show them the road map and that's really that road map. >> It's critical in that transformation. Last word, Moe. >> Yeah, so to me I think the exciting thing about this year, versus when we spoke last year, is the maturity curve. You asked me this last year, you said, "Moe where are we on the maturity curve of adoption?" And I think the fact that we're talking today about data strategies and so on is a reflection of how people have matured. >> Making progress. >> Earlier on, they really start to think about experimenting with ideas. We're now starting to see them access detailed deep information about approaches and methodologies to do it and the key word for us this year was not about experimentation or trial, it's about acceleration. >> Exactly. >> Because they've proven it in that garage fashion in small places, now I want to do it in the American Airlines scale, I want to do it at the global scale. >> Exactly. >> And I want, so acceleration is the key theme of what we're trying to do here. >> What a change from 15, 20 years ago when the deep data warehouse was the single version of the truth. It was like snake swallowing a basketball. >> Tim: Yeah exactly, that's a good analogy. >> And you had a handful of people who actually knew how to get in there and you had this huge asynchronous process to get insights out. Now you guys have a very important, in a year you've made a ton of progress, yea >> It's democratization of data. Everyone should, yeah. >> So guys, really exciting, I love the enthusiasm. Congratulations. A lot more work to do, a lot more companies to affect, so we'll be watching. Thank you. >> Thank you so much. >> Thank you very much. >> And make sure you read our book. (Tim laughs) >> Yeah definitely, read these books. >> They'll be a quiz after. >> Cloud Adoption Playbook and IBM Data and Analytic Strategy Field Guide. Where can you get these? I presume on your website? >> On Amazon, you can get these on Amazon. >> Oh you get them on Amazon, great. Okay, good. >> Thank you very much. >> Thanks guys, appreciate it. >> Alright, thank you. >> Keep it right there everybody, this is The Cube. We're live from IBM Think 2018 and we'll be right back. (upbeat electronic music)

>> Announcer: Live from Austin, Texas, It's The Cube. Covering KubeCon 2017 and CloudNativeCon 2017. Brought to you by Red Hat, The Lennox Foundation, and The Cube's ecosystem partners. >> Okay, welcome back everyone. Live here in Austin, Texas, this is The Cube's exclusive coverage of the CNCF CloudNativeCon which was yesterday, and today is KubeCon, for Kubernetes conference, and a little bit tomorrow as well, some sessions. Our next guest is Adrian Cockcroft, VP of Cloud Architecture Strategy at AWS, Amazon Web Services, and my co-host Stu Miniman. Obviously, Adrian, an industry legend on Twitter and the industry, formerly with Netflix, knows a lot about AWS, now VP of Cloud Architecture, thanks for joining us. Appreciate it. >> Thanks very much. >> This is your first time as an AWS employee on The Cube. You've been verified. >> I've been on The Cube before. >> Many times. You've been verified. What's going on now with you guys, obviously coming off a hugely successful reinvent, there's a ton of video of me ranting and raving about how you guys are winning, and there's no second place, in the rear-view mirror, certainly Amazon's doing great. But CloudNative's got the formula, here. This is a cultural shift. What is going on here that's similar to what you guys are doing architecturally, why are you guys here, are you evangelizing, are you recruiting, are you proposing anything? What's the story? >> Yeah, it's really all of those things. We've been doing CloudNative for a long time, and the key thing with AWS, we always listen to our customers, and go wherever they take us. That's a big piece of the way we've always managed to keep on top of everything. And in this case, the whole container industry, there's a whole whole market there, there's a lot of different pieces, we've been working on that for a long time, and we found more and more people interested in CNCF and Kubernetes, and really started to engage. Part of my role is to host the open source team that does outbound engagement with all the different open source communities. So I've hired a few people, I hired Arun Gupta, who's very active in CNCF earlier this year, and internally we were looking at, we need to join CNCF at some point. We got to do that eventually and venture in, let's go make it happen. So last summer we just did all the internal paperwork, and running around talking to people and got everyone on the same page. And then in August we announced, hey, we're joining. So we got that done. I'm on the board of CNCF, Arun's my alternate for the board and technical, running around, and really deeply involved in as much of the technology and everything. And then that was largely so that we could kind of get our contributions from engineering on a clear footing. We were starting to contribute to Kupernetes, like as an outsider to the whole thing. So that's why we're, what's going on here? So getting that in place was like the basis for getting the contributions in place, we start hiring, we get the teams in place, and then getting our ducks in a row, if you like. And then last week at Reinvent, we announced EKS, the EC2 Kubernete's Service. And this week, we all had to be here. Like last week after Reinvent, everyone at AWS wants to go and sleep for a week. But no, we're going to go to Austin, we're going to do this. So we have about 20 people here, we came in, I did a little keynote yesterday. I could talk through the different topics, there, but fundamentally we wanted to be here where we've got the engineering teams here, we've got the engineering managers, they're in full-on hiring mode, because we've got the basic teams in place, but there's a lot more we want to do, and we're just going out and engaging, really getting to know the customers in detail. So that's really what drives it. Customer interactions, little bit of hiring, and just being present in this community. >> Adrian, you're very well known in the open source community, everything that you've done. Netflix, when you were on the VC side, you evangelized a bunch of it, if I can use the term. Amazon, many of us from the outside looked and, trying to understand. Obviously Amazon used lots of open source, Amazon's participated in a number of open source. MXNet got a lot of attention, joining the CNCF is something, I know this community, it's been very positively received, everybody's been waiting for it. What can you tell us about how Amazon, how do they think about open source? Is that something that fits into the strategy, or is it a tactic? Obviously, you're building out your teams, that sends certain signals to market, but can you help clarify for those of us that are watching what Amazon thinks about when it comes to this space? >> I think we've been, so, we didn't really have a team focused on outbound communication of what we were doing in open source until I started building this team a year ago. I think that was the missing link. We were actually doing a lot more than most people realized. I'd summarize it as saying, we were doing more than most people expected, but less than we probably could have been given the scale of what we are, the scale that AWS is at. So part of what we're doing is unlocking some internal demand where engineering teams were going. We'd like to open source something, we don't know how to engage with the communities. We're trying to build trust with these communities, and I've hired a team, I've got several people now, who are mostly from the open source community, we were also was kind of interviewing people like crazy. That was our sourcing for this team. So we get these people in and then we kind of say, all right, we have somebody that understands how to build these communities, how to respond, how to engage with the open source community. It's a little different to a standard customer, enterprise, start up, those are different entities that you'd want to relate to. But from a customer point of view, being customer-obsessed as AWS is, how do we get AWS to listen to an open source community and work with them, and meet all their concerns. So we've been, I think, doing a better job of that now we've pretty much got the team in place. >> That's your point, is customer focus is the ethos there. The communities are your customers in this case. So you're formalizing, you're formalizing that for Amazon, which has been so busy building out, and contributing here and there, so it sounds like there was a lot of activity going on within AWS, it was just kind of like contributing, but so much work on building out cloud ... >> Well there's a lot going on, but if no one was out there telling the story, you didn't know about it. Actually one of the best analogies we have for the EKS is actually our EMR, our Hadoop service, which launched 2010 or something, 2009, we've had it forever. But from the first few years when we did EMR, it was actually in a fork. We kept just sort of building our own version of it to do things, but about three or four years ago, we started upstreaming everything, and it's a completely clean, upstreamed version of all the Hadoop and all the related projects. But you make one API call, a cluster appears. Hey, give me a Hadoop cluster. Voom, and I want Spark and I want all these other things on it. And we're basically taking Kubernetes, it's very similar, we're going to reduce that to a single API call, a cluster appears, and it's a fully upstreamed experience. So that's, in terms of an engineering relationship to open source, we've already got a pretty good success story that nobody really knew about. And we're following a very similar path. >> Adrian, can you help us kind of unpack the Amazon Kubernetes stack a little bit? One of the announcements had a lot of attention, definitely got our attention, Fargate, kind of sits underneath what Kubernetes is doing, my understanding. Where are you sitting with the service measures, kind of bring us through the Amazon stack. What does Amazon do on its own versus the open source, and how those all fit together. >> Yeah, so everyone knows Amazon is a place where you can get virtual machines. It's easy to get me a virtual machine from ten years ago, everyone gets that, right? And then about three years ago, I think it was three years ago, we announced Lambda - was that two or three years ago? I lose track of how many reinvents ago it was. But with Lambda it's like, well, just give me a function. But as a first class entity, there's a, give me a function, here's the code I want you to run. We've now added two new ways that you can deploy to, two things you can deploy to. One of them's bare metal, which is already announced, one of the many, many, many announcements last week that might have slipped by without you noticing, but Bare Metal is a service. People go, 'those machines are really big'. Yes, of course they're really big! You get the whole machine and you can be able to bring your own virtualization or run whatever you want. But you could launch, you could run Kubernetes on that if you wanted, but we don't really care what you run it on. So we had Bare Metal, and then we have container. So Fargate is container as a first class entity that you deploy to. So here's my container registry, point you at it, and run one of these for me. And you don't have to think about deploying the underlying machines it's running on, you don't have to think about what version of Lennox it is, you have to build an AMI, all of the agents and fussing around, and you can get it in much smaller chunks. So you can say you get a CPU and half a gig of ram, and have that as just a small container. So it becomes much more granular, and you can get a broader range of mixes. A lot of our instances are sort of powers of two of a ratio of CPU to memory, and with Fargate you can ask for a much broader ratio. So you can have more CPU, less memory, and go back the other way, as well. 'Cause we can mix it up more easily at the container level. So it gives you a lot more flexibility, and if you buy into this, basically you'll get to do a lot of cost reduction for the sort of smaller scale things that you're running. Maybe test environments, you could shrink them down to just the containers and not have a lot of wasted space where you're trying to, you have too many instances running that you want to put it in. So it's partly the finer grain giving you more ability to say -- >> John: Or consumption choice. >> Yeah, and the other thing that we did recently was move to per-second billing, after the first minute, it's per-second. So the granularity of Cloud is now getting to be extremely fine-grained, and Lambda is per hundred millisecond, so it's just a little bit -- >> $4.03 for your bill, I mean this is the key thing. You guys have simplified the consumption experience. Bare Metal, VM's, containers, and functions. I mean pick one. >> Or pick all of them, it's fine. And when you look at the way Fargate's deployed in ECS it's a mixture. It's not all one or all the other, you deploy a number of instances with your containers on them, plus Fargate to deploy some additional containers that maybe didn't fit those instances. Maybe you've got a fleet of GPU enhanced machines, but you want to run a bit of Logic around it, some other containers in the same execution environment, but these don't need to be on the GPU. That kind of thing, you can mix it up. The other part of the question was, so how does this play into Kubernetes, and the discussions are just that we had to release the thing first, and then we can start talking, okay, how does this fit. Parts of the model fit into Kubernetes, parts don't. So we have to expose some more functionality in Fargate for this to make sense, 'cause we've got a really minimal initial release right now, we're going to expose it and add some more features. And then we possibly have to look at ways that we mutate Kubernetes a little bit for it to fit. So the initial EKS release won't include Fargate, because we're just trying to get it out based on what everyone knows today, we'd rather get that out earlier. But we'll be doing development work in the meantime, so a subsequent release we'll have done the integration work, which will all happen in public, in discussion with the community, and we'll have a debate about, okay, this is the features Fargate needs to properly integrate into Kubernetes, and there are other similar services from other top providers that want to integrate to the same API. So it's all going to be done as a public development, how we architect this. >> I saw a tweet here, I want to hear your comments on, it's from your keynote, someone retweeted, "managing over 100,000 clusters on ACS, hashtag Fargate," integrated into ECS, your hashtag, open, ADM's open. What is that hundred thousand number. Is that the total number, is that an example? On elastic container service, what does that mean? >> So ECS is a very large scale, multi-tenant container operation service that we've had for several years. It's in production, if you compare it to Kubernetes it's running much larger clusters, and it's been running at production-grade for longer. So it's a little bit more robust and secure and all those kinds of things. So I think it's missing some Kubernetes features, and there's a few places where we want to bring in capabilities from Kubernetes and make ECS a better experience for people. Think of Kubernetes as some what optimized for the developer experience, and ECS for more the operations experience, and we're trying to bring all this together. It is operating over a hundred thousand clusters of containers, over a hundred thousand clusters. And I think the other number was hundreds of millions of new containers are launched every week, or something like that. I think it was hundreds of millions a week. So, it's a very large scale system that is already deployed, and we're running some extremely large customers on, like Expedia and Macbook. Macbook ... Mac Box. Some of these people are running tens of thousands of containers in production as a single, we have single clusters in the tens of thousands range. So it's a different beast, right? And it meets a certain need, and we're going to evolve it forwards, and Kubernetes is serving a very different purpose. If you look at our data science space, if you want exactly the same Hadoop thing, you can get that on prem, you can run EMR. But we have Athena and Red Shift and all these other ways that are more native to the way we think, where we can go iterate and build something very specific to AWS, so you blend these two together and it depends on what you're trying to achieve. >> Well Adrian, congratulations on a great opportunity, I think the world is excited to have you in your role, if you could clarify and just put the narrative around, what's actually happening in AWS, what's been happening, and what you guys are going to do forward. I'll give you the last minute to let folks know what your job is, what your objective is, what you're looking for to hire, and your philosophy in the open source for AWS. >> I think there's a couple of other projects, and we've talked, this is really all about containers. The other two key project areas that we've been looking at are deep learning frameworks, since all of the deep learning frameworks are open source. A lot of Kubernetes people are using it to run GPUs and do that kind of stuff. So Apache MXNet is another focus on my team. It went into the incubation phase last January, we're walking it through, helping it on its way. It's something where we're 30, 40% of that project is AWS contribution. So we're not dominating it, but we're one of its main sponsors, and we're working with other companies. There's joint work with, it's lots of open source projects around here. We're working with Microsoft on Gluon, we're working with Facebook and Microsoft on Onyx which is an open URL network exchange. There's a whole lot of things going on here. And I have somebody on my team who hasn't started yet, can't tell you who it is, but they're starting pretty soon, who's going to be focusing on that open source, deep learning AI space. And the final area I think is interesting is IOT, serverless, Edge, that whole space. One announcement recently is free AltOS. So again, we sort of acquired the founder of this thing, this free real-time operating system. Everything you have, you probably personally own hundreds of instances of this without knowing it, it's in everything. Just about every little thing that sits there, that runs itself, every light bulb, probably, in your house that has a processor in it, those are all free AltOS. So it's incredibly pervasive, and we did an open source announcement last week where we switched its license to be a pure MIT license, to be more friendly for the community, and announced an Amazon version of it with better Amazon integration, but also some upgrades to the open source version. So, again, we're pushing an open source platform, strategy, in the embedded and IOT space as well. >> And enabling people to build great software, take the software engineering hassles out for the application developers, while giving the software engineers more engineering opportunities to create some good stuff. Thanks for coming on The Cube and congratulations on your continued success, and looking forward to following up on the Amazon Web Services open source collaboration, contribution, and of course, innovation. The Cube doing it's part here with its open source content, three days of coverage of CloudNativeCon and KubeCon. It's our second day, I'm John Furrier, Stu Miniman, we'll be back with more live coverage in Austin, Texas, after this short break. >> Offscreen: Thank you.

>> live from the Mandalay Bay Convention Center in Las Vegas. It's the cues covering via World 2016 brought to you by IBM Wear and its ecosystem sponsors. Now here you're Hope's Stool Minimum and John Walls. And welcome back to Las Vegas. Here on the cubicle, tear our coverage. Of'em world here. Mandalay Bay along with minimum. I'm John Woes. Thanks for joining us here for our coverage throughout the next three days. All that's happened in Vienna World. Almost 25,000 attendees to pretty good crowd. Well, I hadn't heard the number, so that would be the largest bm world ever. If we believe the numbers, so no reason not to With John Gill Martin, Who is the vice president? General manager of the integrated assistant business at VM. Where, John. Thanks for being with us once again. It's always a pleasure. Thanks for having me. You know, like you bet I am at this point. Yeah. Tell us about the vibe of the show. First off, day one things underway. A lot of excitement, I would think. Yeah, it's fantastic. You know, I think this is my 11 PM world in a row s so I've got to see a huge evolution in this program is amazing to see how much has changed over the years. Going back, you know, it used to be a server virtualization. What is this thing and where we are today? It's so different. There's a lot of excitement. People trying to figure out how to manage and deal with all the change happen in the industry right now. So, John, one of the things we're all coming into this week looking at is kind of the the cloud management suite, which is right in your area. Can you help us unpack? We looked at kind of V cloud sweet, and then there was some STD see stuff, and now it's cloud foundations. How did these things relate? Is it rebranding, Renaming, repackaging? Help us understand, Actually. So with that foundation, that's one of the key announcements we made today. The objective. There is what I think. How do we take what we have been talking about? Whats offered by Data Center and just make it easy? I don't make it easy for our customers to deploy easy for them to architect easy that even offer as a service from public cloud. That's kind of a key concept. So we are taking and integrating together the key components of softer, defined compute storage and network. There are wrapping some new capabilities to automate deployment autumn E provisioning. And so some ways is an extension, but also in evolution of what we've been doing previously. Okay, but this is still a software offering. Correct is what >> one of the components inside of that >> s O. There's four key components inside of my foundation. There's peace here, virtual sand NSX that gives you that software defined across all three domains and >> then a new component >> that we call STD. See, Manager. So what the SEC Manager does is sort of the glue that brings it all together to bring that integrated experience. It takes all the work that our customers do around you. How do I think about design? How does architect how to deploy? How'd I manage patches and upgrades over time and just automates all that inside of software so they can go from air medal systems deployed cloud infrastructure very, very quickly. So So what was the gap? You know what? What do you dress in here in terms of improvement in terms of change. You're talking about doing something a little bit differently for customers. Use a visa. What have you, But we're trying to get done it. So the key thing, just like the two key new things in this that are really different one is that just making it really easy on the private cloud side. But then we also take exactly that same sort of technologies and also work with our partners to offer it as a service. That's also the really new thing that we're doing today. So we had an announcement today with IBM as part of their IBM cloud. They're offering Cloud Foundation as a service, which >> means customers and go to a >> portal and provisioned out capacity based upon 100% consistent infrastructure. >> That means, you know, if I need some more capacity, as you have it inside my data center provisioned it out inside IBM Cloud. And now I have seen management tools, the same operations, everything I do in my data center. I can now do inside of this cloud environment. We'll extend that after other partners in the future. We'll send that out into the crowd air next quarter. This is really a great way for customers to start extending our migrating into the cloud. But do it based upon without having the architect. The applications are fundamentally change how they operate. >> Eso We've been arguing. We've been trying to figure out this hybrid cloud thing to the last few years, and there's many companies that are saying Okay, here's the software sack. You can put it in your own data center, or you can put it in some kind of public cloud environment. We see IBM does that sum. We see Oracle do that. Microsoft, of course, has azure and azure stacks coming some diamond next year. Is this The em wears answer to say OK in the data center where you know and love these fear, this is a full set, and then you can put it in IBM Soft Layer or a bunch of other writers. >> Yes, it is that concept of a consistent stack, yet a seem stacked inside the day's center, exactly the same stack outside the data center. So it is 100% consistent, right? That's part of what's really attractive about that. And then his customers think about well, what are the management tools or the cloud management platform, but I won't run on top of that. That can extend very seamlessly now across multiple environments. >> Okay, what about the interconnection between different locations? How does that >> work? So interconnections. You can take advantage of NSX and what it does around stretching, stretching, networking across environments like it's a very powerful capability to really think about it, really, as it's seamless extension of the data center. That's one of the unique capabilities and obviously with IBM has a first partner. They have almost having 50 data centers around the world, so it becomes very easy to collate. Locate your applications close to your private data center, which >> is important. So IBM is the first partner. How does this fit into, like the V Cloud their network, then, where you have thousands of >> partners already? Yeah, so they're the first Qatar network partner to offer a service, and then we expect that are working with other because our network partners to do the same offer Cloud Foundation as a service and, you know, kind of underlying that technology is this s CDC manager, which makes it easy for them as well. They go provision out these infrastructures very quickly and easily. >> Yeah, when you're about customers, what are the pain points that you were hearing from them that you were dressing? Because we take about the sophistication of technology, these of use efficiencies, high performance, all this stuff. It couldn't be any better, but obviously could have been better. So what we're hearing from them that led you to develop the new product. >> Well, the big thing is his customers were trying to think about how to the leverage public cloud is part of their architectures. You can kind of, It's pretty clear, that kind of result they want. They want to able to have an environment where their application owners and the developers sort of don't even know where things are running. They wanted to be a little bit transparent, kind of seamless. At the same time, they want to be able to have the ability to maintain control, maintain security policies, maintain operational control over the environment, have good insight into it. And so I sort of challenge that we're walking into, and your traditional infrastructure still very much stands in the way people trying to support the developers, people enterprise has spent too much time hugging components together trying to make things work together. And that's just not value added activity. It's not differentiating. It doesn't help them compete in the marketplace. And so we saw is what happened. We help them get out of that business and focus more on the things they want to do above the infrastructure layer. That's sort of the whole rationale for building a foundation was, Just take everything that they do today That's on value, out of activity. Put that in software, automated public empire the cloud and they can focus on what there is value out of business on. >> One of the challenges we've been facing in this transformation is kind of the go to market. If I think about traditionally the sphere, you know Veum. He's got a great channel partnership Lotto, EMS in the early days, and now, I mean just a huge amount of channel parts that know how to sell it, know how to make money. Cloud is a big shift for them. There's only a small percent of the channel that kind of understands this with IBM, kind of as a first partner. How do you see this playing out with kind of official panic Channel partners, service providers and the whole go to market. >> As you point out, it's clearly an evolving story. Right and different partners were kind of thinking about it in different ways. You know, there's still, you know, definitely in on premise opportunity that they're going after. But clearly having a good crowd strategy is going to be important for every reseller out there in every partner. And some of that is gonna be thinking about what are the kind of service is that you can offer your customers to help them make that transition. Yeah, if you think about you know, if I want to extend my data center, I need to migrate workloads or re architect workloads. Those types of service is I think they're going to be critical to become experts in and help customers. We think about their long term strategy. The fact is, the customers are gonna move warm or the workloads into clouds of some type over the next few years, and they're gonna need help in your advice and guidance and migration surfaces to get there. So there's a real business to go be built around those kinds of opportunities. >> Okay. Can you give us a little bit of what should we be looking for? Going forward, You know, if their customers that are running this stack already before it was called this And how do we How could we benchmark to say whether or not you're successful by the time we come back next year? >> Yeah, that's a good question. >> Tough questions, >> A challenge. So now it's a great question. So this software is gonna be available later this week, so it's actually generally available on September 1st. So it's just coming in the marketplace now. And so we've been working with Summerlee Beta customers on this over the last couple a couple of months, get great feedback and really help this steer perfectly towards this public cloud opportunity S O. I would expect as we come back in a few months, we'd be able to talk about our kind of initial lighthouse customers and how they're doing. But we see just huge interest in this right now, right? Customers want to move, and companies want to move away from kind of plugging things together. They want away from individuals, components. They really are looking to buy Seymour integrated ways. This is kind of a key enabling technology to help him do that. And we could do that also with our partners. >> Yeah, Um, one of the big challenges we've had is everybody is always like, okay, but my needs are a little bit different. So we understand that if we can eliminate diversity of the environments in the homogeneity is good, I can repeat it. I understand it. But everybody, all that you know, that's the problem with ideas. They always want to tweak it. So what do you do when they say, Oh, you know, the sand's great. But, you know, you've got all these ecosystem part partners in storage. I kind of want this storage. And it's ex. I understand some pieces. Maybe I want over. Yes, but I wanted till some other pieces. What do you do for customers that want to kind of go outside of this initial package? What kind of choice and options that they have? >> Yeah. Yeah, it's, uh so just like this year, you know, these here is sort of been the universal platform for running virtual machines and has a lot of those connections into different things, so foundation fundamentally is based on the sphere. So for the take storage, for example, no keys here can connect to external storage. We can connect national storage and on a road map for the automation software inside. We'll look at how we can take advantage of external storage and some of these things as well, so as new as we talk to customers. And we, as we learned those areas that are consistent across many, we can start to bring some of those things in tow the equation as well. This gives us a very powerful starting point, and we can look at what are the right connections out system? >> And do you still have folks who are trying to hang on to say I understand what you're doing understands the new service of a new opportunity here, But I'm not ready to cut the Courtauld away. And how do you bring them along to showing them? There are new efficiencies here and there is a better bottom line benefit to you. >> I think you know the history of I t is a history of things remaining right. So you still have a I actually feel mainframes. Eso this transition will take time. This is not gonna be on overnight time type of changes. We moved to these types of architectures that are fully suffered a find, but we made a huge amount of progress thus far. We have over 5000 customers on virtual sand. Your NSX is going incredibly fast. Both of these approved points that these are the architecture's customers are trying to move to the end of the same time. Though we have to find the right the right starting points. What is the right project to start with? This doesn't have to be a wholesale change. The data center it could be. Let's take a virtual desktop project and run now on top of that foundation must take a new invite. New server applications, unemployed run that on foundation. And just like the sphere kind of started with these use cases that expanded over time. Same thing of foundation. We could start with a project and then and that shows success to move into other projects. >> John, you've been with the, um where for quite a few years you've done two stints of the company as you hear the outside world talking about, you know, cloud and where things were going. What do you think people don't understand about bm Worse position in the cloud marketplace going forward. >> You know the one thing you know, I've talked a lot right now about Cloud Foundation, which was one of our announcements. I think the other thing that is really unique that we talked about this week is, uh, something called across Cloud Architecture and said across Cloud service Is that in addition foundation and what we're recognizing is just like with server virtualization, we were able to abstract multiple types of servers and provide consistent layer we're going to do the same. Thing is we were across multiple clouds. Even non GM were based clouds, right, working with Amazon Azure Google. And I think that's one thing that is maybe even surprising, folks. And it's very different than kind of the company strategy going back 10 years ago. So we are fully embracing that these will be part of our customer strategy in the future. We do expect to see them, but we see a unique opportunity for us to go help them when it comes to managing applications across the networking security where we have really unique assets we can help with. And also data management. Government. >> Well, John, I know you said it takes time. Transition state time. >> Still gave you a year. >> Yeah. So next year at the world will come back and the update you on the progress that we've made, >> we look forward to it. Thank you for joining us and the best left down the road. We'll see a year from now. >> Fantastic. Thank you very much. >> You bet John Gill Martin from VM where we'll be back with more from Veum World here in Vegas. Right after this, You're watching the Cube.

>>On the ground presented by the cube. Here's your host, John furrier. >>Hello everyone. Welcome to the cube on the ground here in Seattle, Washington, the IBM open compute architecture. Some of the day after Docker con. I'm John furrier, the host of the cube. We're here with Renee foster, who's the vice president of technical cloud at IBM. So the customer journey. What is the customer journey because there are many paths to the cloud, certainly open source collaboration, kicking the tires. How is the engagement with customers now changed? What is, what's it like? Take us through an example. >>Okay, well first I want to say it all starts with where the customer is coming into as you said, into the journey. And we have at IBM a cloud capability maturity model and what we do is we actually work with our clients and see do they know anything about a cloud today? And if they do then we go on that path with them in order to explain the technology, understand their use case scenarios. Right? Because you want to come from a solution perspective and not from a product or technology perspective where they are. What their problems are and then all the way to the end of the spectrum where customers have been on the cloud journey for some time and now what they would like to do is they have a multicloud environment. How can they bring that all together in an integrated and our operable, >>so the bigger customers, more advanced have multiple clouds, but the early ones can need to understand the use cases that fit for their business, the application environment. That's cool. Now I've got to ask this kind of a different question. Kind of going back to the client server days, it used to be a very simple formula. You do an audit, you get, you get paid for that, you do a strategy session, you do a POC, and then you go to production over months, maybe a year, depending on how big it is, not the cloud. They want stuff fast. Is it the same concept, that process or is there happening differently, faster? >>Absolutely. It's different and the reason why it's different back to your point is we're now more in an agile environment. Back to your point that customers are leveraging methodologies like scrum and what they would like to do is, you know, back to understanding the use case scenario, be able to come to the market faster. You've heard the terminology disruptive innovation, right? So they want to be able to create new markets or serve markets that they don't currently serve today, so they can't do it the way we've been doing it in the past. But what we found out is design is key. And so what we have done at IBM is we have a Bloomex garage where we have a design methodology and the customers can come in and actually bring in their applications, their ideas, and then we helped them develop that. >>I'm got to ask you, is it, is it, is it chaotic for customers? Because I can only imagine the industry is chaotic. Cloud technology fabric is changing rapidly. The industry formation is changing rapidly. What are some of the patterns that you're seeing that are common amongst all customers? I mean, is it chaotic? Is it much more of their learning? Is it more advanced? What? Can you share any anecdotal color around the patterns that you're seeing in the customer environment? >>Right. I would say that customers are now learning, the lessons learned are now coming now, right? Because they've actually evolved. They're not at the exculpatory, it's exploit exploratory kind of a phase in cloud anymore. So now what they're doing is they're saying, what are the lessons learned that we have? And what we find out is that customers, the sand security infrastructure networking infrastructure, they are just as important as the cloud use cases that designed this. >>We just were at DockerCon for two days and we interviewed for two straight days, wall to wall coverage. And one of the most interesting comments that I heard was from Scott Johnson, the COO of Docker. And I'm like, Oh, this application craze and dev ops has gone mainstream. That's so amazing. Now that we have to operate it now. So now dev ops success has changed it operations, right? And he goes, well, what's your thoughts? He goes, well, certainly no one's going to change their service level agreements. So you see ops now accepting the dev ops ethos, but yet the standards are so high for security and operational, SLS and running the business. Do you see that area? What's your thoughts on this? Because this seems to be a common thread that we're hearing. Okay, I'm sold on dev ops agile and now I've got to run it. What are the customers doing in this area? >>Well, what customers are really doing is they're looking for frameworks and they want to make sure that we look at security, if you will, from, you know, doing everything on the glass, right? Making sure that we have single sign on capabilities all the way to um, identify and grow vulnerabilities within a cloud environment. What are some of the risks and threats? And so they truly come into IBM and saying, let's share with you our concerns. And then we know you have a framework that you can address that. And back to your point, from a dev ops perspective, I mean, it looks at the entire application life cycle and that's why operations now is so entrenched in understanding that we are here to remove the right waste, make it more secure, and have governance around it. >>So final question. What do think about this open cloud architecture summit? What's this all about? Customers like it, they embracing it. Are they interested? >>Yes, yes, yes. All of the above. And I would say because, and back to your point at the beginning with some multicloud environment and customers want to know, I don't want them to lock in. They want to make sure that they remain open open standards and they want to make sure that they have like cloud brokerage. Uh, they want to make sure that as they develop their architectures that you know, they can actually have a platform, uh, you know, environments where they can, um, have that interoperability and it's going to be become more and more better and more and more efficient over time. Open winds, as we say, open source mainstream. Renee, thank you for sharing your insight. I'm John. We here on the ground in Seattle, Washington at the IBM open cloud architecture summit. Thanks for watching.