>> Announcer: Live from the Moscone center it's theCUBE covering AWS Summits San Francisco 2018. Brought to you by Amazon Web Services. >> Welcome back, this is theCUBE's coverage of AWS Summit San Francisco. Here at the Moscone Center West. I'm Stu Miniman, happy to have a distinguished panel of guests on the program. Starting down of the fair side, Steven Jones whose the Director of Solution Architecture with AWS, helping us talk about how AWS gets to market is Chris Wegmann, Manager and Director of Accenture, and then super excited to have a customer on the program Chad Anderson is the IT Director of Operations at Del Monte Foods. Gentleman, thank you so much for joining us. >> Thanks for having us. >> Alright Chad, we're going to start with you, talk to us a little bit about your role inside Del Monte and really the journey of the cloud, something we've been talking about for years, but Del Monte has an interesting story. I want to kind of understand your role in that. Start us off. >> Ya so I oversaw the project for us to migrate everything to AWS. We started off with just needing to really understand if were missing something here. Like, shouldn't we be moving to the cloud and that ended up in a study where we just kind of went threw the numbers, we looked at what the benefits were going to be and it kind of just turned into a obvious choice for us to do it. >> Back us up for a second, give us you know your organization Del Monte Foods and your technology group is this global and scope kind of how many end user do you have? How many sites? Can you give us a little bit of the speeds and feeds of what what was being considered, was it everything or some pieces, what was the impetus for the journey of the cloud? >> Ya, so we have about a thousand users, globally we are mostly in Manila, for our global share services our business back office work is done there and then most of it is U.S. footprint of plants and distribution centers and headquarters, et cetera operations. >> Alright so Chris, the SI partner for this cloud journey. So bring us a little bit of insight, bring us back to you know, kind of what was the business challenge and what was your teams role in helping along those journeys? >> The business challenge was getting Del Monte, getting the heart of their organization SAP to AWS quickly. Alright, there was a short time frame, I learned a lot about fruit packing during the project, but it was about how quickly could we get there? So, when we actually started, we started looking at taking seven months to do the migration of their environment. We really got into it and really got focused on what needed to be done. We looked at a lot of automation, put a lot of automation on the process, a very diligent approach, and we were able to do it, we thought we could do it in four months, and we did in three and a half months so very rapid, and I think as Chad will tell you we really kind of focused on building the right architecture, putting a lot of automation, and then also getting it in there with the right performance and then being able to tune things down, because you can you can move so quickly between engine sizes and memory and it was a really really exciting process to go through. >> Ya, so you said it originally we thought it was seven months, and it was good and done in half that time. That's not my experience with Enterprise Software roll outs. So, what was the delta there? How was the team able to move so fast? >> A lot of it was obviously AWS, being able to spin up the infrastructure, being able to automate a lot of the tasks that had to be done. Alright we did it threw three different environment sets. So we started diligent, moved to test, then went to production, and in each step we automated more and more of the process so we were able to condense the speed of the technical work that had to take place in a really short amount of time. >> We had to treat it also, like a mission critical thing across it wasn't just a infrastructure move it really the application guys were focused on this, we stopped all development of other activities going on. We really just kind of turned everybody and say "Let's get this done as soon as possible "and not be competing with each other." >> When you say stop everything, but of course the business didn't stop, but was transition pretty seamless. >> I mean other projects. >> Ya, ya, ya I understand, but I mean from the cut over and from your users stand point, did it go pretty smoothly? >> Oh definitely, these guys did an amazing job of putting together a plan that was really ready to be executed against. It took some, it took a lot of, I mean on my part it was really just to negotiate the extended maintenance window, but as far as the best compliment I ever got was people were like what did you do? Like I didn't even know that you guys did anything. From day one they took it and ran with it and we were stable. I mean it was pretty awesome. >> A black box, magic happens here and all of a sudden everything is running faster, scaling easier, cost is better, some of those types of thing? >> Ya, cocktails and beach time. >> Steve cocktails? I didn't realize that when I moved my enterprise application to cloud cocktails were involved. >> A few cocktails are involved. >> I mean look, I remember a few years ago where it was like well it's your development will do in the cloud, but I mean SAP has really raised cloud full boar and you know very strong partner, but bring us up to how does AWS help customers make sure that, this is critical things running the business, that it runs so smoothly. What have you learned along the way? What is different in 2018, then say it was even a year or two ago? >> A lot of great questions in there Stu, I would say this is become the new normal. Right? It use to be full disclosure, dev test, training type work loads in the early days but over the course of years we have taking a lot of learning with partners like Accenture and customers like Del Monte and we've taking those learnings and put them back into the platforms, so what you see today is a platform that a partner like Accenture could come in build a lot of automation tooling around, to reduce time frame from seven months down to three and a half. I think it was around two hundred servers, 50 of those were SAP related, and 25 terabytes of data that were moved in a short amount of time. So it's a combination of years worth of effort to build a platform that is scalable, resilient, and flexible. As well as the work that we have done directly with SAP that has gone right back into the platform. >> Chad bring us inside kind of operations on your team. What is the before and after? What's it look like? Was there change in personal or roles or skills? >> We transition services with our migration. So the Accenture team has taking over the long term operational activities as well as helping us through the migration efforts. We had a lot of preparation that was going on besides the server migration that was happening and I think what is really unique about them is because they can deliver these capabilities of the migration they have got a lot of the tooling and the automation is built into the operational mana services model as well. So it's been a much easier kind of hand over from those teams because we are working with the same vendor. >> Most of the time its not just that I've migrated from my environment to the cloud, but how does that enable the new services either Accenture from AWS from the marketplace. What has changed as to how you look at your SAP environment and kind of capability wise? >> It's just incredibly flexible now. It's just one of those situations where we can start small and we can scale so rapidly and it's like I feel like its kind of like walking into a fast food restaurant and just like oh, I'll take one of these, one of these, and one of these. You wait there and the food comes out, it just happens automatically. So, it's a great thing. >> Chris, I remember I interviewed a CEO a few years ago, and he said use to give me a million dollars in 18 months and I'll build you the Taj Mahal from my applications. Today I need to move faster and it's not a one time migration, but there's ongoing I've heard it a time and again there, so where does Accenture, it's not just the planning, where's Accenture involved? What is kind of the ongoing engagement? >> We go end to end. Right? So, we start out with strategy, we start out with a migration. The migration takes planning and execution, but really we focus on the run area as well using our Accenture platform and tooling that we have built. We really focus on how do you continue to optimize? How do you continue to improve performance? How do you govern? How do you do things like quota and security management and that type of stuff. I do think that a lot of our customers start with cloud think I can spin this stuff up, I can run it just like I ran my on premise data center and it's not the same. You go from a capacity planning person to a cost management person. You need to have a cloud architect understanding how you build your applications to be Cloud ready and AWS ready. There are a lot of great services, but if your not taking advantages of those services you can't auto scale, you can't do that stuff. So, we really help our clients go threw that entire process and make sure their getting the most value out of AWS all the way through the run for many years after they have done the migration. >> Chad, do you have any discussion of how are you reporting back to the business as to what were the hero numbers or success factors that said hey this was actually the right thing to do? >> Ya I mean we're a canned food company, so people are very interested in making sure that we are keeping our cost low. Most people from a business prospect want to talk to me about the efficiencies that their seeing and how's that going to show up a reduction in SG and A. We have seen it, I mean when you move to a group of people that can manage a larger set of infrastructure with a smaller group of people and the underline services can be turned on and off, so you only utilize what you really absolutely have. Those numbers show up on our bottom line. >> Steve, any other similar, what do you hear from customers when it comes to SAP, and what is the main driver, and what are the big hero things? >> So in the early days, it was all about cost right, driving cost out of the system. Now it's the flexibility, the ability to move quicker. Chad was relating earlier how you would spend a lot of time sizing environment and now there actually able to right size their environments using purpose built equipment the AWS has built for SAP. It's enabled them to actually reduce cost and move quicker. That's what we are hearing is common theme now these days. It's okay to move faster, to maybe not worry about sizing as much as we use to. >> Ya for future initiatives, I mean it's, there's all these windows of time that are just gone for us to stand up new services whether it's traditional application that needs servers and computer, whether it's SAP services, we are kind of all on that platform now where we can just click and plug in items much easier. >> Chad, what do things like digital transformation and innervation mean to a canned food company? >> We are desperately trying to get in touch of our consumer. So, whether were figuring out how to get improve kind of how we are managing our digital assets, how were managing, our pages on Amazon, or our pages on Walmart.com. We need to be much more in touch and much more consumer focused and a lot of these newer technologies, et cetera there built to run on AWS and we ready to kind of integrate that into our existing enterprise environment. >> Innervation has been a big part of our customers reason for moving to cloud. I'd say 18 months ago, we saw a big transition in our enterprise customers a lot of them were starting off with cost savings, for operational savings, just overall improvement of their operations, and then we seen about 18 months ago we saw a big shift of people very much focused on innervation and using AWS platform as that catalyst renovation. So, the businesses asking for Alexa apps, they're asking for the integration. Well, the SAP data has to be there to support that stuff. Right, and your enterprise tech has to be there, so by doing that it's enabled a lot of innervation in our processors. >> Chad, last question when you talk about innovation, are there certain areas that your team's investing in is it AI, is it IOT, you know what are some of the areas that you think will be the most promising and how do Accenture and AWS fit into those from your planning? >> Ya, I mean IOT is definitely an interesting area for us, and getting to a point where we can measure our effectiveness and our manufacturing processes, those are all really initiatives now that we're starting to focus on, now that we kind of gotten some of the infrastructure related stuff and were ready to kind of build out those platforms. We're talking about scaling out our OE software and our infrastructure its just such an easier conversation to kind of plan for those activities. We turned a three month sizing exercise as to how much IOT did and we think were going to have to process through these engines into a hey let's go with this and if it doesn't work then we'll take it out and increase the size. It really helps us deliver capabilities new capabilities and new types of ways of measuring or helping our business run in a much more effective and efficient way. >> Anything that you've learned along the way that you've turned to peers and say "Here's something I did, maybe do it faster or do it a little bit different way?" >> I think Accenture has been an amazing partner. I think a lot of people are skeptical about running their entire enterprise across the network and once you kind of bring them in and you really let them look under the cover of what you have. One of the reasons we went with them was just the trust and confidence that they had that we could do this. Once I kind of saw that it was like well I mean let's trust the process here. I mean these guys are the experts and so so that's been a big thing is just reach out learn about what people are doing. There's no reason why you can't do this. >> Well Chad, Chris, and Steve thank you both so much for highlighting the story of a customer's journey to the cloud. We will be back with lots more coverage here at AWS Summit in San Francisco. I'm Stu Miniman. You're watching theCUBE. (upbeat music)

>> Narrator: Live from the Moscone Center, it's theCube, covering AWS Summit San Francisco 2018 brought to you by Amazon Web Services. (upbeat music) >> We're back I'm Stu Miniman and we're here with theCube's exclusive coverage of AWS Summit San Francisco here in the Moscone Center West. Happy to welcome to the program two gentlemen from DynaTrace, we've got Andy Grabner, who's a DevOps specialist and Dave Anderson, vice president of marketing. Gentlemen, thanks so much for joining us. >> Thanks for having us. >> Alright so Dave we'll start, since you've got the marketing title, give us a little bit your role there and for our audience that might not be familiar with DynaTrace, I'm sure everybody knows 'em, but give us a little bit of the background. >> So essentially what DynaTrace does is, the world needs software to work perfectly. What we do is we help customers build and manage their software in their cloud environments on premise to help deliver a fantastic customer experiences because we know that it all needs to work. We've been in the market for the Magic Quadrant leader for the last eight years in the APM space, but we're expanding out beyond that now as the customer demands. >> Excellent, well one of my favorite lines you say you have to make software work, is they said hardware will eventually fail and software will eventually work. So Andy you've given a session here at the show tell us what your role is at DynaTrace, what are you doing here at the show? >> So I've been with the company for 10 years and I've been through a similar transformation that I believe most of the people here want to go through from quote unquote old-fashion, on premise, legacy, monolithic applications to using containers, microservices, and eventually serverless. So my session was all about fearless from monolith to serverless. I gave them some ideas on what we went through, how we as a company transformed, but also how our product transformed from, before we did on premise monitoring, built for the monolithic apps, and now we basically do full cloud-scale, in the cloud, but still covering all the enterprise technology because everybody that wants to build the cool, new stuff that they are selling here, you still have legacy applications that you integrate with and still carry around. So it's all about enterprise cloud technology that we cover. >> So Dave I hear all this I'm sure DynaTrace has more than 10 years of server-less and 12 factor authentication experience, right? >> Dave: Yes. >> Okay so you're the hipster you know, a cloud native company, you were doing all of it before any of us knew about exists. Tell us a little bit, historically, how did DynaTrace start before and move into this space? >> Yeah, so we've been in the space for around 10 years. We've been a leader in the space, but what we really did four or five years ago is we predicted on the future we were going to have serverless environments, we're going to have microservices, customers are going to have multiple cloud environments, they're going to need that software to work and they're going to need automation. So what we did is we took our 50 best engineers and we said go and re-invent the future and that's exactly what they've done. Our CTO has a vision, fully automated IT, so our whole product philosophy is around making it really simple for our customers to be able to see within this really complex digital environment, exactly what's going on, how is the software performing, how are the users adopting it and how do we role out better features and better functions to the customer base. >> All right, I love the re-invent pun, but this is the Summit, ReInvent's in November. Andy, we were talking to Sandy Carter, in the last segment, talking about customers and customers have so many applications that it's great to say this is the future and serverless and micro-architectures distributed is great and everything, but some of your stuff's going to be lift and shift, some of the stuff's probably got to stay where it is for a while, how do customers manage that portfolio and a few years ago it was like, we're going to do a bi-model world, we were not onboard with that, but there's a spectrum and there's lots of applications and it's really complicated, so what is the advice, how do you help customers kind of squint through that, and work through that? >> So I think essentially people want to update the critical apps, be more innovative, they want to go and invest in the new enterprise clouds tech, I would say, right? So we basically help them, first of all, figure out which of the applications that they have right now are easier to migrate, whether it's lift and shift or re-platform because we actually give them full visibility into the current tech, tell them where are the most dependent and least dependent services, which ones are easier to extract and harder to extract, depending on the dependencies and the traffic take us over into criticalities. So we help them first of all figure out their cloud migration plan, what to migrate first. We talked about T-shirt sizing your migration, small, medium, and large, and then not only do we help them to migrate things over but to break the big monoliths apart put stuff on top of it, right? So this is also happening, so we really help them to figure out which application, which service to tackle first, to migrate over. We do it in a safe way because we not only help them to later on monitor their new system, but we help them along the way. So we talked about DevOps earlier. I mean we had our little prep call. We actually think that monitoring, the space we are, is not just something to keep the lights on in production, but it's something that has to be checked along the delivery pipeline. That's why we are part of the development process, we are apart of your CICD, when a code change goes in, an architectural change goes in, when they move over, we monitor all these changes and we give you early warning signals that this change is going to be good one or not a good one. And that's how we solve them. >> Well so much things in the cloud, it's never a one time thing, it's got to be an ongoing process, it's iterative and if I hear right though, you're not just only an AWS, it's my on premises stuff, multi-cloud, you play with all of those environments. >> Yes. Yes exactly so I mean you name it. I'm not sure if I'm allowed to name all the other vendors in this space here at AWS. >> Look we're independent media, we cover all of those shows, and I think your customers are using all them, so you can say, they're all in an AWS, but they might also use GCP and Azure and other stuff. >> I think the stats were like 98 or 90% of customers are hybrid enterprise, multi-cloud, and that's why we designed the product to be able to do just that. They're going to have applications running in the cloud that are making calls back to things on premise. You want to be able to see that entire delivery chain. So absolutely we provide that single visibility across all of their cloud environments and on premise. >> What are you seeing as some of the biggest challenges your customers are facing, Dave? >> The shear, the complexity, the pressures which they face, which is they've got to shift to the cloud faster. They've got their CEO going, we need to provide better digital experience. They're going to build out these new cloud platforms. They're just struggling for time to deploy these things. They need to move faster. There's threats of competition, all the buzzwords that come, but they're all real for IT people. And then all we're doing is giving them that visibility because the environments have become so complex, microservice, serverless, multi-cloud, on-premise, and just to be able to help them challenge the visibility into where is everything, how is it performing, is it working and then give them the confidence to release faster as Andy talks about. >> So Andy, one of the things that people look at sometimes is okay it's a multi-cloud environment, but okay if I go down the container environment, can I do that multi-cloud? If I go down the path of say something like Fargate, that's only with Amazon, so are your customers concerned about that, how deep down do they go? I should say, how far up the stack are they willing to go with Amazon or are they holding back and trying to use services that are more easy to be able to be migrated if need be? >> I want to give you two answers to this. >> Yeah. >> First of all, the developers don't care. >> Okay. >> I don't care where it runs. >> No, I understand. I've got a software development team. When they port it over to any of us, they're like autoscaling's awesome, it's great, I don't want to have to port somewhere else, and if it works, I go back to, it was like, standards and proprietary versus that if you solve my business need, I'm needed. So I agree, but, what's your other answer? >> Yeah so but it is clear that people, what we hear at least, what I hear, people want to figure out, how can they define their next platform and make sure that at least they're not doing a complete vendor lock in, a cloud lock in, so they definitely think and invest in, how can we deliver something, a platform to our developers so that they can just worry about writing code and we make sure that, if we decide Amazon today, maybe something else later, it's not going to be too hard and so I think we see the people try, I think still a lot of people are in the early stages. So they start primarily with one vendor, with one platform, with one technology, but they always make sure that they keep their options open to eventually move over and they're constantly look, that's why they're constantly bringing in new technology, which is also a challenge for every vendor that is here on the floor to make sure we're coping with this technology disruption that is constantly happening, not only for the users, the consumers of the technology, but those of us as vendors and I think that's what we try to keep up with, yeah? >> Yeah, so how we doing as industry and how are customers doing at keeping up with all this change? >> It is, I think, constant dedication, constantly looking what's new. We, as Dave mentioned, we until only a couple of years ago figured out something new is coming, so we actually broke out our own team, our innovation team, that figure out what's the next big thing, I think we see this also with our customers. You constantly have to disrupt yourself, you constantly have to redefine yourself and that's what we did with monitoring. We redefined monitoring because we saw five years ago that a new wave of technology's coming and we don't stop now, we keep innovating and everybody else is doing it as well. You always have to keep up with what's coming and experiment and figure out what makes sense for you and what maybe does not make sense for you. You don't have to be part of every hype. >> And we do that in two ways, we sort of do that also in that a lot of the features that we put into the product actually come from our customer base. So we have a really strong connection with our customers, we listen to the customers, and we say, what do you need, what challenges are you suffering, what would you like to have, and then we build them into our product roadmap. So it's kind of a hybrid model of making sure you're able to listen to the customer and take their needs in, but also sometimes they don't know what's coming, so we'd work with an AWS, to understand what they're building out, and other technology partners to make sure that our product is future proof. >> So when you built that innovation team and everything, is it serverless underneath now for some of your products? >> It's a set of technologies, right? It's all of what you basically see here on the floor and others. I think the nice thing, what I heard actually today on the floor, they said you don't only talk about DevOps and CICD and innovation, you actually live it and what they mean with this, he said, if I look at how often DynaTrace produces new features, we deploy new feature releases twice a month, we deploy daily new updates, and then they said, if you look at other vendors in this space they also claim to be living what they expect from you, but they deploy twice a year still or maybe every other month. So I think we redefined monitoring, but also redefined and live what we actually expect our customers to do. >> Yeah, if you say you're a DevOps company, you better be embracing CICD and publish now and often. All right, Andy and Dave, thank you so much for giving us the updates. Congrats on the progress, we look forward to catching with you up more in the future. We'll be back with lots more coverage here from AWS Summit San Francisco, I'm Stu Miniman. You're watching theCube. (upbeat music)

>> Announcer: Live from San Francisco, it's theCUBE. covering Spark Summit 2017, brought to you by Databricks. (techno music) >> Welcome to theCUBE, at Spark Summit here at San Francisco, at the Moscone Center West, and we're going to be competing with all the excitement happening behind us. They're going to be going off with raffles, and I don't know what all. But we'll just have to talk above them, right? >> Clarke: Well at least we didn't get to win. >> Our next guest here on the show is Clarke Patterson from Confluent. You're the Senior Director of Product Marketing, is that correct? >> Yeah, you got it. >> All right, well it's exciting -- >> Clarke: Pleasure to be here >> To have you on the show. >> Clarke: It's my first time here. >> David: First time on theCUBE? >> I feel like one of those radio people, first time caller, here I am. Yup, first time on theCUBE. >> Well, long time listener too, I hope. >> Clarke: Yes, I am. >> And so, have you announced anything new that you want to talk about from Confluent? >> Yeah, I mean not particularly at this show per se, but most recently, we've done a lot of stuff to enable customers to adopt Confluent in the Cloud. So we came up with a Confluent Cloud offering, which is a managed service of our Confluent platform a couple weeks ago, at our event around Kafka. So we're really excited about that. It really fits that need where Cloud First or operation-starved organizations are really wanting to do things with storing platforms based on Kafka, but they just don't have the means to make it happen. And so, we're now standing this up as a managed service center that allows them to get their hands on this great set of capabilities with us as the back stop to do things with it. >> And you said, Kafka is not just a publish and subscribe engine, right? >> Yeah, I'm glad that you asked that. So, that one of the big misconceptions, I think, of Kafka. You know, it's made its way into a lot of organizations from the early use case of publish and subscribe for data. But, over the last 12 to 18 months, in particular, there's been a lot of interesting advancements. Two things in particular: One is the ability to connect, which is called a Connect API in Kafka. And it essentially simplifies how you integrate large amounts of producers and consumers of data as information flows through. So, a modernization of ETL, if you will. The second thing is stream processing. So there's a Kafka streams API that's built-in now as well that allows you to do the lightweight transformations of data as it flows from point A to point B, and you could publish out new topics if you need to manipulate things. And it expands the overall capabilities of what Kafka can do. >> Okay, and I'm going to ask George here to dive in, if you could. >> And I was just going to ask you. >> David: I can feel it. (laughing) >> So, this is interesting. But if we want to frame this in terms of what people understand from, I don't want to say prehistoric eras, but earlier approaches to similar problems. So, let's say, in days gone by, you had an ETL solution. >> Clarke: Yup. >> So now, let's put Connect together with stream processing, and how does that change the whole architecture of integrating your systems? >> Yeah, I mean I think the easiest way to think about this is if you think about some of the different market segments that have existed over the last 10 to 20 years. So data integration was all about how do I get a lot of different systems to integrate a bunch of data and transform it in some manner, and ship it off to some other place in my business. And it was really good at building these end-to-end workflows, moving big quantities of data. But it was generally kind of batch-oriented. And so we've been fixated on, how do we make this process faster? To some degree, and the other segment is application integration which said, hey, you know when I want applications to talk to one another, it doesn't have the scale of information exchange, but it needs to happen a whole lot faster. So these real-time integration systems, ESBs, and things like that came along and it was able to serve that particular need. But as we move forward into this world that we're in now, where there's just all sorts of information, companies want to become advanced-centric. You need to be able to get the best of both of those worlds. And this is really where Kafka is starting to sit. It's saying, hey let's take massive amounts of data producers that need to connect to massive amounts of data consumers, be able to ship a super-granular level of information, transform it as you need, and do that in real-time so that everything can get served out very, very fast. >> But now that you, I mean that's a wonderful and kind of pithy kind of way to distill it. But now that we have this new way of thinking of app integration, data integration, best of both worlds, that has sort of second order consequences in terms of how we build applications and connect them. So what does that look like? What do applications look like in the old world and now what enables them to be sort of re-factored? Or for new apps, how do you build them differently? >> Yeah, I mean we see a lot of people that are going into microservices oriented architecture. So moving away from one big monolithic app that takes this inordinate amount of effort to change in some capacity. And quite frankly, it happens very, very slow. And so they look to microservices to be able to split those up into very small, functional components that they can integrate a whole lot faster, decouple engineering teams so we're not dependent on one another, and just make things happen a whole lot quicker than we could before. But obviously when you do that, you need something that can connect all those pieces, and Kafka's a great thing to sit in there as a way to exchange state across all these things. So that's a massive use case for us and for Kafka specifically in terms of what we're seeing people do. >> You've said something in there at the end that I want to key off, which is, "To exchange state." So in the old world, we used a massive shared database to share state for a monolithic app or sometimes between monolithic apps. So what sort of state-of-the-art way that that's done now with microservices, if there's more than one, how does that work? >> Yeah, I mean so this is kind of rooted in the way we do stream processing. So there's this concept of topics, which effectively could align to individual microservices. And you're able to make sure that the most recent state of any particular one is stored in the central repository of Kafka. But then given that we take an API approach to stream processing, it's easy to embed those types of capabilities in any of the end-points. And so some of the activity can happen on that particular front, then it all gets synchronized down into the centralized hub. >> Okay, let me unpack that a little bit. Because you take an API approach, that means that if you're manipulating a topic, you're processing a microservice and that has state in it? Is that the right way to think about it? >> I think that's the easiest way to think about it, yeah. >> Okay. So where are we? Is this a 10 year migration, or is it a, some certain class of apps will lend themselves well to microservices, legacy apps will stay monolithic, and some new apps, some new Greenfield apps, will still be database-centric? How do you, or how should customers think about that mix? >> Yeah that's a great question. I don't know that I have the answer to it. The best gauge I can have is just the amount of interest and conversations that we have on this particular topic. I will say that from one of the topics that we do engage with, it's easily one of the most popular that people are interested in. So if that's a data point, it's definitely a lot of interested people trying to figure out how to do this stuff very, very fast. >> How to do the microservices? >> Yeah and I think if you look at some of the more notable tech companies of late, they're architected this way from the start. And so everyone's kind of looking at the Netflix of the world, and the Ubers of the world saying, I want to be like those guys, how do I do that? And it's driving them down this path. So competitive pressure, I think, will help force people's hands. The more that your competitors are getting in front of you and are able to deliver a better customer experience through some sort of mobile app or something like that, then it's going to force people to have to make these changes quicker. But how long that takes it'll be interesting to see. >> Great! Great stuff. Switch gears just a little bit. Talk about maybe why you're using Databricks and what some of the key value you've gotten out of that. >> Yeah, so I wouldn't say that we're using Databricks per se, but we integrate directly with Spark. So if you look at a lot of the use cases that people use Spark for, they need to obviously get data to where it is. And some of the principles that I said before about Kafka generally, it's a very flexible, very dynamic mechanism for taking lots of sources of information, culling all that down into one centralized place and then distributing it to places such as Spark. So we see a lot of people using the technologies together to get the data from point A to point B, do some transformation as they so need, and then obviously do some amazing computing horsepower and whatnot in Spark itself. >> David: All right. >> I'm processing this, and it's tough because you can go in so many different directions, especially like the question about Spark. I guess, give us some of the scenarios where Spark would fit. Would it be like doing microservices that require more advanced analytics, and then they feed other topics, or feed consumers? And then where might you stick with a shared database that a couple services might communicate with, rather than maintaining the state within the microservice? >> I think, let me see if I can kind of unpack that myself a little bit. >> George: I know it was packed pretty hard. (laughing) >> Got a lot packed in there. When folks want to do things like, I guess when you think about it like an overall business process. If you think about something like an order to cash business process these days, it has a whole bunch of different systems that hang off it. It's got your order processing. You've got an inventory management. Maybe you've got some real-time pricing. You've got some shipments. Things, like that all just kind of hang off of the flow of data across there. Now with any given system that you use for addressing any answers to each of those problems could be vastly different. It could be Spark. It could be a relational database. It could be a whole bunch of different things. Where the centralization of data comes in for us is to be able to just kind of make sure that all those components can be communicating with each other based on the last thing that happened within each of them individually. And so their ability to embed transformation, data transformations and data processing in themselves and then publish back out any change that they had into the shared cluster subsequently makes that state available to everybody else. So that if necessary, they can react to it. So in a lot of ways, we're kind of agnostic to the type of processing that happens on the end-points. It's more just the free movement of all the data to all those things. And then if they have any relevant updates that need to make it back to any of the other components hanging on that process flow, they should have the ability to publish that back down it. >> And so one thing that Jay Kreps, Founder and CEO, talks about is that Kafka may ultimately, or in his language, will ultimately grow into something that rivals the relational database. Tell us what that world would look like. >> It would be controversial (laughing). >> George: That's okay. >> You want me to be the bad guy? So it's interesting because we did Kafka Summit about a month ago, and there's a lot of people, a lot of companies I should say, that are actually using and calling Kafka an enterprise data hub, a central hub for data, a data distribution network. And they are literally storing all sorts (raffle announcements beginning on loudspeaker) of different links of data. So one interesting example was the New York Times. So they used Kafka and literally stored every piece of content that has ever been generated at that publisher since the beginning of time in Kafka. So all the way back to 1851, they've obviously digitized everything. And it sits in there, and then they disposition that back out to various forms of the business. So that's -- >> They replay it, they pull it. They replay and pull, wow, okay. >> So that has some very interesting implications. So you can replay data. If you run some analytics on something and you didn't get the result that you wanted, and you wanted to redo it, it makes it really easy and really fast to be able to do that. If you want to bring on a new system that has some new functionality, you can do that really quickly because you have the full pedigree of everything that sits in there. And then imagine this world where you could actually start to ask questions on it directly. That's where it starts to get very, very profound, and it will be interesting to see where that goes. >> Two things then: First, it sounds, like a database takes updates, so you don't have a perfect historical record. You have a snapshot of current values. Like whereas in a log, like Kafka, or log-structured data structure you have every event that ever happened. >> Clarke: Correct. >> Now, what's the impact on performance if you want to pull, you know -- >> Clarke: That much data? >> Yeah. >> Yeah, I mean so it all comes down to managing the environment on which you run it. So obviously the more data you're going to store in here, and the more type of things you're going to try to connect to it, you're going to have to take that into account. >> And you mentioned just a moment ago about directly asking about the data contained in the hub, in the data hub. >> Clarke: Correct. >> How would that work? >> Not quite sure today, to be honest with you. And I think this is where that question, I think, is a pretty provocative one. Like what does it mean to have this entire view of all granular event streams, not in some aggregated form over time? I think the key will be some mechanism to come onto an environment like this to make it more consumable for more business types users. And that's probably one of the areas we'll want to watch to see how that's (background noise drowns out speaker). >> Okay, only one unanswered question. But you answered all the other ones really well. So we're going to wrap it up here. We're up against a loud break right now. I want to think Clarke Patterson from Confluent for joining us. Thank you so much for being on the show. >> Clarke: Thank you for having me. >> Appreciate it so much. And thank you for watching theCUBE. We'll be back after the raffle in just a few minutes. We have one more guest. Stay with us, thank you. (techno music)