(upbeat music) >> Welcome back to Supercloud22, #Supercloud22, this is Dave Vellante. In 2019, Oracle and Microsoft announced a collaboration to bring interoperability between OCI, Oracle Cloud Infrastructure and Azure clouds. It was Oracle's initial foray into so-called multi-cloud and we're joined by Karan Batta, who's the vice president for product management at OCI, and Kris Rice, is the vice president of software development at Oracle database. And we're going to talk about how this technology's evolving and whether it fits our view of what we call, Supercloud. Welcome, gentlemen. Thank you. >> Thanks for having us. >> Thanks for having us. >> So you recently just last month announced the new service. It extends on the initial partnership with Microsoft Oracle Interconnect with Azure, and you refer to this as a secure private link between the two clouds across 11 regions around the world. Under two milliseconds data transmission, sounds pretty cool. It enables customers to run Microsoft applications against data stored in Oracle databases without any loss in efficiency or presumably performance. So we use this term Supercloud to describe a service or sets of services built on hyperscale infrastructure that leverages the core primitives and APIs of an individual cloud platform, but abstracts that underlying complexity to create a continuous experience across more than one cloud. Is that what you've done? >> Absolutely. I think, you know, it starts at the, you know, at the top layer in terms of, you know, just making things very simple for the customer, right. I think at the end of the day we want to enable true workloads running across two different clouds, where you're potentially running maybe the app layer in one and the database layer or the back in another, and the integration I think, starts with, you know, making it ease of use. Right? So you can start with things like, okay can you log into your second or your third cloud with the first cloud provider's credentials? Can you make calls against another cloud using another cloud's APIs? Can you peer the networks together? Can you make it seamless? I think those are all the components that are sort of, they're kind of the ingredients to making a multi-cloud or Supercloud experience successful. >> Oh, thank you for that, Karan. So, I guess as a question for Kris is trying to understand what you're really solving for, what specific customer problems are you focused on? What's the service optimized for presumably its database but maybe you could double click on that. >> Sure. So, I mean, of course it's database so it's a super fast network so that we can split the workload across two different clouds leveraging the best from both, but above the networking, what we had to do is we had to think about what a true multi-cloud or what you're calling Supercloud experience would be. It's more than just making the network bytes flow. So what we did is, we took a look as Karan hinted at, right? Is where is my identity? Where is my observability? How do I connect these things across how it feels native to that other cloud? >> So what kind of engineering do you have to do to make that work? It's not just plugging stuff together. Maybe you could explain in a little bit more detail, the resources that you had to bring to bear and the technology behind the architecture? >> Sure. >> I think, you know, it starts with actually, you know, what our goal was, right? Our goal was to actually provide customers with a fully managed experience. What that means is we had to basically create a brand new service. So, you know, we have obviously an Azure like portal and an experience that allows customers to do this but under the covers, we actually have a fully managed service that manages the networking layer that the physical infrastructure, and it actually calls APIs on both sides of the fence. It actually manages your Azure resources, creates them, but it also interacts with OCI at the same time. And under the covers this service actually takes Azure primitives as inputs, and then it sort of like essentially translates them to OCI action. So, so we actually truly integrated this as a service that's essentially built as a PaaS layer on top of these two clouds. >> So, so the customer doesn't really care, or know, maybe they know, coz they might be coming through, you know, an Azure experience, but you can run work on either Azure and or OCI, and it's a common experience across those clouds, is that correct? >> That's correct. So, like you said, the customer does know that they know there is a relationship with both clouds but thanks to all the things we built there's this thing we invented, we created called a multi-cloud control plane. This control plane does operate against both clouds at the same time to make it as seamless as possible so that maybe they don't notice, you know, the power of the interconnect is extremely fast networking, as fast as what we could see inside a single cloud, if you think about how big a data center might be from edge to edge in that cloud. Going across the interconnect makes it so that that workload is not important that it's spanning two clouds anymore. >> So you say extremely fast networking. I remember I used to, I wrote a piece a long time ago. Hey, Larry Ellison loves InfiniBand. I presume we've moved on from them, but maybe not. What is that interconnect? >> Yeah, so it's funny, you mentioned interconnect, you know, my previous history comes from HPC where we actually inside inside OCI today, we've moved from, you know, InfiniBand as its part of Exadata's core, to what we call RoCEv2. So that's just another RDMA network. We actually use it very successfully, not just for Exadata but we use it for our standard computers, you know, that we provide to, you know, high performance computing customers. >> And the multi-cloud control plane, runs... Where does that live? Does it live on OCI? Does it live on Azure? Yes? >> So it does. It lives on our side. >> Yeah. >> Our side of the house, and it is part of our Oracle OCI control plane. And it is the veneer that makes these two clouds possible so that we can wire them together. So it knows how to take those Azure primitives and the OCI primitives and wire them at the appropriate levels together. >> Now I want to talk about this PaaS layer. Part of Supercloud, we said, to actually make it work you're going to have to have a super PaaS. I know, we're taking this term a little far but it's still, it's instructive in that, what we, what we surmised was, you're probably not going to just use off the shelf, plain old vanilla PaaS, you're actually going to have a purpose built PaaS to solve for the specific problem. So, as an example, if you're solving for ultra low latency, which I think you're doing, you're probably, no offense to my friends at Red Hat, but you're probably not going to develop this on OpenShift, but tell us about that, that PaaS layer or what we call the super PaaS layer. >> Go ahead, Kris. >> Well, so you're right. We weren't going to build it out on OpenShift. So we have Oracle OCI, you know, the standard is Terraform. So the back end of everything we do is based around Terraform. Today, what we've done, is we built that control plane and it will be API drivable. It'll be drivable from the UI and it will let people operate and create primitives across both sides. So you can, you, you mentioned developers developers love automation, right? Because it makes our lives easy. We will be able to automate a multi-cloud workload, from ground up, Config is code these days. So we can Config an entire multi-cloud experience from one place. >> So, double click Kris on that developer experience, you know, what is that like? They're using the same tool set irrespective of, you know, which cloud we're running on is, is it and it's specific to this service or is it more generic across other Oracle services? >> There's two parts to that. So one is the, we've only onboarded a portion. So the database portfolio and other services will be coming into this multi-cloud. For the majority of Oracle cloud the automation, the Config layer is based on Terraform. So using Terraform, anyone can configure everything from a mid tier to an Exadata, all the way soup to nuts from smallest thing possible to the largest. What we've not done yet is is integrated truly with the Azure API, from command line drivable, that is coming in the future. It will be, it is on the roadmap. It is coming, then they could get into one tool but right now they would have half their automation for the multi-cloud Config on the Azure tool set and half on the OCI tool set. >> But we're not crazy saying from a roadmap standpoint that will provide some benefit to developers and is a reasonable direction for the industry generally but Oracle and, and, and Microsoft specifically? >> Absolutely. I'm a developer at heart. And so one of the things we want to make sure is that developers' lives are as easy as possible. >> And, and is there a Metadata management layer or intelligence that you've built in to optimize for performance or low latency or cost across the, the respective clouds? >> Yeah, definitely. I think, you know, latency's going to be an important factor. You know, the, the service that we've initially built isn't going to serve, you know, the sort of the tens of microseconds but most applications that are sort of in, you know, running on top of, the enterprise applications that are running on top of the database are in the several millisecond range. And we've actually done a lot of work on the networking pairing side to make sure that when we launch, when we launch these resources across the two clouds we actually pick the right trial site, we pick the right region, we pick the right availability zone or domain. So we actually do the due diligence under the cover, so the customer doesn't have to do the trial and error and try to find the right latency range, you know, and this is actually one of the big reasons why we only launched this service on the interconnect regions. Even though we have close to, I think, close to 40 regions at this point in OCI, this, this, this service is only built for the regions that we have an interconnect relationship with with Microsoft. >> Okay. So, so you've, you started with Microsoft in 2019 you're going deeper now in that relationship, is there is there any reason that you couldn't, I mean technically what would you have to do to go to other clouds? Would you just, you talked about understanding the primitives and leveraging the primitives of Azure. Presumably if you wanted to do this with AWS or Google or Alibaba, you would have to do similar engineering work, is that correct? Or does what you've developed just kind of pour it over to any cloud? >> Yeah, that's, that's absolutely correct, Dave, I think, you know, Kris talked a lot about kind of the multi-cloud control plane, right? That's essentially the, the, the control plane that goes and does stuff on other clouds. We would have to essentially go and build that level of integration into the other clouds. And I think, you know, as we get more popularity and as as more products come online through these services I think we'll listen to what customers want, whether it's you know, maybe it's the other way around too, Dave maybe it's the fact that they want to use Oracle cloud but they want to use other complimentary services within Oracle cloud. So I think it can go both ways. I think, you know, kind of the market and the customer base will dictate that. >> Yeah. So if I understand that correctly, somebody from another cloud Google cloud could say, "Hey, we actually want to run this service on OCI coz we want to expand our market and..." >> Right. >> And if TK gets together with his old friends and figures that out but we're just, you know, hypothesizing here, but but like you said, it can, can go both ways. And then, and I have another question related to that. So you multi-clouds. Okay, great. Supercloud. How about the edge? Do you ever see a day where that becomes part of the equation? Certainly the, the near edge would, you know, a a home Depot or a Lowe's store or a bank, but what about like the far edge, the tiny edge. Do, do you, can you talk about the edge and and where that fits in your vision? >> Yeah, absolutely. I think edge is a interestingly, it's a, it's a it's getting fuzzier and fuzzier day by day. I think there's the term, you know, we, obviously every cloud has their own sort of philosophy in what edge is, right? We have our own, you know, it starts from, you know, if you if you do want to do far edge, you know, we have devices like red devices, which is our ruggedized servers that that talk back to our, our control plane in OCI you could deploy those things in like, you know, into war zones and things like that underground. But then we also have things like Cloud@Customer where customers can actually deploy components of our infrastructure, like Compute or Exadata into a facility where they only need that certain capability. And then a few years ago we launched, you know, what's now called Dedicated Region. And that actually is a, is a different take on edge in some sense where you get the entire capability of our public commercial region, but within your facility. So imagine if, if, if a customer was to essentially point to, you know, point to, point a finger on a commercial map and say, "Hey, look, that region is just mine." Essentially, that's the capability that we're providing to our customers, where if you have a white space if you have a facility if you're exiting out of your data center space you could essentially place an OCI region within your confines behind your firewall. And then you could interconnect that to a cloud provider if you wanted to. and get the same multi-cloud capability that you get in a commercial region. So we have all the spectrums of possibilities there. >> Guys, super interesting discussion. It's very clear to us that the next 10 years of cloud ain't going to be like the last 10. There's a whole new layer developing. Data is a big key to that. We see industries getting involved. We obviously didn't, didn't get into the Oracle Cerner acquisitions a little too early for that but we we've actually predicted that companies like Cerner and you've seen it with Goldman Sachs and Capital One, they're actually building services on the cloud. So this is a really exciting new area and I really appreciate you guys coming on the Supercloud22 event and sharing your insights. Thanks for your time. >> Thank very much. >> Thank very much. >> Okay. Keep it right there. #Supercloud22. We'll be right back with more great content right after this short break. (upbeat music)

>> Narrator: From around the globe, it's theCUBE with digital coverage of AWS re:Invent 2020 sponsored by Intel, AWS and our community partners. >> Hello, welcome back to theCUBE's Virtual Coverage of AWS re:Invent 2020 virtual. Normally we're in person. This year because of the pandemic, we're doing it remote. We're Cube Virtual covering AWS re:Invent Virtual. I'm John for your host. We are theCUBE Virtual, two great guests here Linda Tong a general manager, AppDynamics and Dave McCann vice-president of AWS migration, marketplace and control services. Welcome to theCUBE. >> Thanks so much for having us. >> Good to see you again John. >> Linda we were talking to some AppDynamics folks and some of your customers, obviously we've been following the growth of the marketplace for many years. The confluence of the tailwinds of the innovation going on with COVID and post COVID strategies is about helping customers where they are and they're not in the office anymore. They got to get the job done. This is really important on this cloud migration of getting software in the hands of people to write these modern apps. It's a big theme. What's your perspective on this right now, because you guys are partnered with Amazon, share your vision. >> Yeah, absolutely. And you nailed it. It's with COVID-19 our customers like IT organizations are finding this need to accelerate their migration to the cloud. And what's more important is they're finding that more and more of their customers are engaging through digital experiences and with the influx of people leaning on those digital experiences during COVID, performance issues are becoming more and more apparent. And so we're helping our customers as they migrate to the cloud. And specifically to AWS, it's a big partnership for us because we need to understand how our customers and how they manage performance through these transitions can stay flawless so that they can manage those experiences for their end users. >> Yeah, Dave, I've been watching this discovery observation space, observability, service meshes, Kubernetes, cloud native higher level services have really gotten popularity have gone mainstream. So there's more and more demand for I won't call it point products. That's an old term, but in the cloud, these are just higher level services that people are adopting more of. You're seeing huge pickup in the marketplace of companies who are selling through there and engaging but it's not just selling, you're integrating. What's your vision for all of this? >> So, John, you're absolutely right. Our customers as they migrate more and more applications to the cloud and in some regulated industries they still have applications running on premise. They're really actually standing up a new operating model where they not only want observability of what's going on but I feel what we would call service management framework or a set of tools to manage the application portfolio. And companies around the world are putting together new common instance of AWS native services, such as CloudWatch CloudTrail, Service Catalog, AWS Config, Control Tower with best in class vendors like Cisco AppDynamics. And each company is building their own collection of tools into management framework that allows them to optimally modernize and manage their application portfolio. And it's a rising topic around the world. >> Linda, I want to get back to you on AppDynamics you're the leader of the team as general manager, congratulations. You know a little bit about software in the cloud and CloudScale and your career going back to Google now at AppDynamics you've seen a lot of the changes. What specifically value do you see AppDynamics and Amazon bringing to the market today? Because the world's changed. It's still large scale, there's faster speed but you can't just buy things like anymore, I've got to go in send a ticket request, go to procurement, developers want to integrate immediately. They need to integrate when they see a problem they got to integrate technology. This seems to be a trend. What's your, where is AppDynamics bringing the value of AWS to the market? >> Absolutely I think it's threefold. One it's for a lot of these developers, as they start to migrate their applications and modernize them with AWS and all the great services that are available we can partner to help them with that modernization effort while giving them visibility into the performance of those applications to make sure that they don't miss a beat as they deploy those on these new sets of services over AWS. The second thing is, for those customers that are leveraging AWS for that migration, we have a seamless integration between AppDynamics and AWS. So you can buy our service directly through AWS marketplace. So that becomes a really easy procurement. And then on top of that, as, a lot of developers have to manage hybrid employments, so new modern applications has done AWS as well as some of their traditional applications that are talking to each other. They can get that full end to end visibility leveraging AppDynamics so that they can understand what's going on across the entirety of their business as they start to lead these transformations across our organization. >> Dave, just comment on if you can, 'cause I know a little bit about some of the things you put in place, the enterprise I forget development or sales program where at the prices can be more friendly. I think this is kind of a use case where this is proving enterprises can get what they need in the marketplace that not only is it successful but you have traction with this. What's you take on... >> There's a number of motions that we're doing there John, to help large companies around the world who may have, dozens, hundreds and in comes cases with fortune 100 they're thousands of applications. And so you actually have to solve multiple challenges that the company has. On the procurement side, we're obviously working with AppDynamics to publish as a service right in AWS marketplace. And we have over 300,000 customers worldwide only AWS marketplace who are subscribing to software and provisioning out to hundreds and thousands of developers, all of whom are using their own AWS accounts. So on that provisioning and subscription experience we work deeply with the AppDynamics team to meet that a really seamless experience from discovery to provision to meter and billing. On the interoperability front, as Linda mentioned, our customers want these best in class tools like AppDynamics to work well with the other AWS services so that they can really have a very modern DevOps pipeline for those applications that are moving to more of a CICD model. And for people who are still running in a bit more of an Intel, ITSM model, they've still got to manage and monitor applications that haven't quite got there in the full modernization stack. So this is actually happening not just with the customer, the enterprise or with the ISV AppDynamics, this transitions' also working with all the consulting firms. And a lot of the large software resellers around the world, the computer centers of Europe the right spaces, the presidios of North America. The DXEs of Asia Pacific. These consulting partners are also using tools such as AppDynamics so to become a managed service provider. And in some cases on that journey to the cloud no join the customer saying I'm really busy I'm modernizing applications. Hey consulting partner, can you manage some part of my infrastructure, some part of my stack? And tools like AppDynamics and Kubernetes and AWS become really central tool kits to the new emerging managed service providers that are all around the world. >> Yeah, and I talked about this years ago with Andy Jassy and I think we were riffing on this run this new set of category creations of services and companies. Linda this appears to be one of those cases where, there's a category with existing spend and existing customers. So what he just said is interesting. And I want to get your thoughts because these are these points of these new areas where AppDynamics can potentially help enterprises. What are some of the areas that you see AppDynamics helping enterprises in their cloud adoption journey 'cause they want some cloud native we see Hybrid and all the announcements, Outpost, now Edge it's a distributed computer. You need to have software at every piece of the puzzle. So what's your, what areas can you share specifically? >> Absolutely and so, like Dave was just saying it's, as these organizations start to make these major cloud migrations, one, their applications are getting actually significantly more complex than they've ever been. And they're now spanning a much broader ecosystem than they've ever spanned before. So that the kind of coverage that IT organizations and DevOps needs to cover not only is seeing this explosion of data but it's also now spanning areas of control that some of these folks have never had to think about before. And so the value of AppDynamics is our ability to be able to ingest data from your cloud native applications your traditional applications, all different sources of domain data that you want to get including things like security data. So we can start to correlate that in a meaningful way and then tie that back to business insights. And so the way that AppDynamics is actually bringing value to the table is not only helping our customers get visibility across the entire stack, but actually only surfacing the most meaningful insights to help them act on that those performance issues that they might see and more meaningfully manage their businesses. >> Linda I think you guys are onto something really big not just on the wave and just the positioning but one of the trends that we're reporting and we're going to be teasing out all week three weeks here is automation is great but that's just baseline. Everything is a service really speaks to some of the things that you guys have to put in place 'cause the mandate is everything should be a service. Now, I mean, I'm overgeneralizing but that's generally the ivory tower C suite message. Make it as a service cloud scale is beautiful, but then you when you pass it down to the teams, that's like that's not easy boss. It's not easy to do. That's really kind of what you're getting at here. It's not just automation and DevOps. It's the business model. >> Absolutely it's the intelligence it's once you create thousands and thousands of services, how do you manage them effectively and know what matters and what doesn't? >> Dave your final word here on on this point is when you think about that if you believe that to be true, then I'm just going to be downloading services whenever I need them. So it's almost like quasi self service managed services kind of coming together in real time or with my off base there. What's your take on that? >> No, we're actually working together with that dynamic and so all these kinds of things. So as we proliferate services, John and, AWS has got over 175 services and application is made up of many components. So how do you actually correlate an associate all the resources that make up that application? And if you think about dynamics name is the application and dynamics what's going on with the application. So we actually just launched today service catalog application registry, which is a new API surface for the AWS service catalog that allows you to define NGS on all the AWS resources from a cloud formation stack set all the way down into an easy to instance and associate that's an application known. And so the higher level of abstraction is what we talked about is management of the application. And what customers want to do, CIO's want to manage the application all the resources associated through the application whether the application is running well, is it secure? Is it on budget? Whether it's actually running? So application management is kind of where people are going even though their application is made up of dozens of associated services. So this is the next frontier. >> Well you guys are just great to have on world-class partnership two leaders, AppDynamics, story history they continue to do well. And even now with the world going on, Dave congratulations on your success. Final question for both of you is, where's the partnership go from here? I think it's a great success story. What's in the store for the future? >> Linda. >> Yeah to the moon. It's look AWS is an amazing partner. And Dave is a great guy to work with and where we are going is to help our customers build world-class applications and be able to manage them and modernize those effectively. And there's no way we could do that without partners at AWS. So it's a, there's a long-term relationship here. >> Well, congratulations, Linda Tong general manager AppDynamics. Thanks for coming on, and virtually at least we'll see you on the Interwebs during the next couple of weeks here, Virtual re:Invent Dave McCann. Of course, we'll see you again and great to watch you continue to grow. Is there any new title is going to add to your thing marketplace now it's migration, control services come on. >> With innovation culture we keep innovating. >> Great to have you guys on. Thanks for, thanks for sharing, appreciate it. >> John, Linda thank you very much. >> Thanks. >> Thanks for that great insight. Really appreciate it. I'm John from theCUBE you're watching coverage of re:Invent 2020. This is theCUBE virtual. (upbeat music)

>> (soft upbeat music) >> Announcer: From around the globe, it's the cube with digital coverage of Ansible Fest 2020, brought to you by RedHat. >> Hello, welcome to the cubes coverage of Ansible Fest 2020. We're not in person, we're virtual. I'm John Furrier , your host of theCube. We've got a great power panel here of RedHat engineers. We have Brad Thorton, Senior Principle Software Engineer for Ansible networking. Adam Miller, Senior Principle Software Engineer for Security and Jill Rouleau, who's the Senior Software Engineer for Ansible Cloud. Thanks for joining me today. Appreciate it. Thanks for coming on. >> Thanks. >> Good to be here. >> We're not in person this year because of COVID, a lot going on but still a lot of great news coming out of Ansible Fest this year. Last year, you guys launched a lot since last year. It's been awesome. Launched the new platform. The automation platform, grown the collections, certified collections community from five supported platforms to over 50, launched a lot of automation services catalog. Brad let's start with you. Why are customers successful with Ansible in networking? >> Why are customers successful with Ansible in networking? Well, let's take a step back to a bit of classic network engineering, right? Lots of CLI interaction with the terminal, a real opportunity for human error there. Managing thousands of devices from the CLI becomes very difficult. I think one of the reasons why Ansible has done well in the networking space and why a lot of network engineers find it very easy to use is because you can still see an attack at the CLI. But what we have the ability to do is pull information from the same COI that you were using manually, and showed that as structured data and then let you return that structured data and push it back to the configuration. So what you get when you're using Ansible is a way to programmatically interface and do configuration management across your entire fleet. It brings consistency and stability, and speed really to network configuration management. >> You know, one of the big hottest areas is, you know, I always ask the folks in the cloud what's next after cloud and pretty much unanimously it's edge, and edge is super important around automation, Brad. What's your thoughts on, as people start thinking about, okay, I need to have edge devices. How does automation play into that? And cause networking, edge it's kind of hand in hand there. So what's your thought on that? >> Yeah, for sure. It really depends on what infrastructure you have at the edge. You might be deploying servers at the edge. You may be administering IOT devices and really how you're directing that traffic either into edge compute or back to your data center. I think one of the places Ansible is going to be really critical is administering the network devices along that path from the edge, from IOT back to the data center, or to the cloud. >> Jill, when you have a Cloud, what's your thoughts on that? Because when you think about Cloud and Multicloud, that's coming around the horizon, you're looking at kind of the operational model. We talked about this a lot last year around having Cloud ops on premises and in the Cloud. What should customers think about when they look at the engineering challenges and the development challenges around Cloud? >> So cloud gets used for a lot of different things, right? But if we step back Cloud just means any sort of distributed applications, whether it's on prem in your own data center, on the edge, in a public hosted environment, and automation is critical for making those things work, when you have these complex applications that are distributed across, whether it's a rack, a data center or globally. You need a tool that can help you make sense of all of that. You've got to... We can't manage things just with, Oh, everything is on one box anymore. Cloud really just means that things have been exploded out and broken up into a bunch of different pieces. And there's now a lot more architectural complexity, no matter where you're running that. And so I think if you step back and look at it from that perspective, you can actually apply a lot of the same approaches and philosophies to these new challenges as they come up without having to reinvent the wheel of how you think about these applications. Just because you're putting them in a new environment, like at the edge or in a public Cloud or on a new, private on premise solution. >> It's interesting, you know, I've been really loving the cloud native action lately, especially with COVID, we're seeing a lot of more modern apps come out of that. If I could follow up there, how do you guys look at tools like Terraform and how does Ansible compare to that? Because you guys are very popular in the cloud configuration, you look at cloud native, Jill, your thoughts. >> Yeah. So Terraform and tools like that. Things like cloud formation or heat in the OpenStack world, they do really, really great at things like deploying your apps and setting up your stack and getting them out there. And they're really focused on that problem space, which is a hard problem space that they do a fantastic job with where Ansible tends to come in and a tool like Ansible is what do you do on day two with that application? How do you run an update? How do you manage it in the longterm of something like 60% of the workloads or cloud spend at least on AWS is still just EC2 instances. What do you do with all of those EC2 instances once you've deployed them, once they're in a stack, whether you're managing it, whatever tool you're managing it with, Ansible is a phenomenal way of getting in there and saying, okay, I have these instances, I know about them, but maybe I just need to connect out and run an update or add a package or reconfigure a service that's running on there. And I think you can glue these things together and use Ansible with these other stack deployment based tools really, really effectively. >> Real quick, just a quick followup on that. what's the big pain point for developers right now when they're looking at these tools? Because they see the path, what are some of the pain points that they're living right now that they're trying to overcome? >> I think one of the problems kind of coincidentally is we have so many tools. We're in kind of a tool explosion in the cloud space, right now. You could piece together as as many tools to manage your stack, as you have components in your stack and just making sense of what that landscape looks like right now and figuring out what are the right tools for the job I'm trying to do, that can be flexible and that are not going to box me into having to spend half of my engineering time, just managing my tools and making sense of all of that is a significant effort and job on its own. >> Yes, too many may add, would choke in years ago in the big data search, the tools, the tool train, one we call the tool shed, after a while, you don't know what's in the back, what you're using every day. People get comfortable with the right tools, but the platform becomes a big part of that thinking holistically as a system. And Adam, this comes back to security. There's more tools in the security space than ever before. Talking about tool challenges, security is the biggest tool shed everyone's got tools they'd buy everything, but you got to look at, what a platform looks like and developers just want to have the truth. And when you look at the configuration management piece of it, security is critical. What's your thoughts on the source of truth when it comes into play for these security appliances? >> So these are... Source of truth piece is kind of an interesting one because this is going to be very dependent on the organization. What type of brownfield environment they've developed, what type of things that they rely on, and what types of data they store there. So we have the ability for various sources of truth to come in for your inventory source and the types of information you store with that. This could be tagged information on a series of cloud instances or series about resources. This could be something you store in a network management tool or a CMDB. This could even be something that you put into a privilege access management system, such as, CyberArk or hashivault. Like those are the things and because of Ansible flexibility and because of the way that everything is put together in a pluggable nature, we have the capability to actually bring in all of these components from anywhere in a brownfield environment, in a preexisting infrastructure, as well as new decisions that are being made for the enterprise as I move forward. And, and we can bring all that together and be that infrastructure glue, be that automation component that can tie all these disjoint loosely coupled, or complete disc couple pieces, together. And that's kind of part of that, that security posture, remediation various levels of introspection into your environment, these types of things, as we go forward, and that's kind of what we're focusing on doing with this. >> What kind of data is stored in the source of truth? >> I mean... So what type of data? This could be credential. It could be single use credential access. This could be your inventory data for your systems, what target systems you're trying to do. It could be, various attributes of different systems to be able to classify them ,and codify them in different ways. It's kind of kind of depending, be configuration data. You know, we have the ability with some of the work that Brad and his team are doing to actually take unstructured data, make it structured, bullet into whatever your chosen source of truth is, store it, and then utilize that to, kind of decompose it into different vendors, specific syntax representations and those types of things. So we have a lot of different capability there as well. >> Brad, you were mentioned, do you have a talk on parsing, can you elaborate on that? And why should network operators care about that? >> Yeah, welcome to 2020. We're still parsing network configuration and operational state. This is an interesting one. If you had asked me years ago, did I think that we would be investing development time into parsing with Ansible network configurations? I would have said, "Well, I certainly hope not. "I hope programmability of network devices and the vendors "really have their API's in order." But I think what we're seeing is network containers are still comfortable with the command line. They're still very familiar with the command line and when it comes time to do operational state assessment and health assessment of your network, engineers are comfortable going to the command line and running show commands. So really what we're trying to do in the parsing space is not author brand new parking and parsing engine ourselves, but really leverage a lot of the open source tools that are already out there bringing them into Ansible, so network engineers can now harvest the critical information from usher operational state commands on their network devices. And then once they've gotten to the structure data, things get really interesting because now you can do entrance criteria checks prior to doing configuration changes, right? So if you want to ensure a network device has a very particular operational state, all the BGP neighbors are, for example before pushing configuration changes, what we have the ability to do now is actually parse the command that you would have run from the command line. Use that within a decision tree in your Ansible playbook, and only move forward when the configuration changes. If the box is healthy. And then once the configuration changes are made at the end, you run those same health checks to ensure that you're in a speck can do a steady state and are production ready. So parsing is the mechanism. It's the data that you get from the parsing that's so critical. >> If I had to ask you real quick, just while it's on my mind. You know, people want to know about automation. It's top of mind use case. What are some of these things around automation and configuration parsing, whether it's parsing to other configuration manager, what are the big challenges around automation? Because it's the Holy grail. Everyone wants it now. What are the couches? where's the hotspots that needs to be jumped on and managed carefully? Or the easiest low hanging fruit? >> Well, there's really two pieces to it, right? There's the technology. And then there's the culture. And, and we talk really about a culture of automation, bringing the team with you as you move into automation, ensuring that everybody has the tools and they're familiar with how automation is going to work and how their day job is going to change because of automation. So I think once the organization embraces automation and the culture is in place. On the technology side, low hanging fruit automation can be as simple as just using Ansible to push the commands that you would have previously pushed to the device. And then as your organization matures, and you mature along this kind of path of network automation, you're dealing with larger pieces, larger sections of the configuration. And I think over time, network engineers will become data managers, right? Because they become less concerned about the network, the vendors specific configuration, and they're really managing the data that makes up the configuration. And I think once you hit that part, you've won at automation because you can move forward with Ansible resource modules. You're well positioned to do NETCONF for RESTCONF or... Right once you've kind of grown to that it's the data that we need to be concerned about and it could fit (indistinct) and the operational state management piece, you're going to go through a transformation on the networking side. >> So you mentioned-- >> And one thing to note there, if I may, I feel like a piece of this too, is you're able to actually bridge teams because of the capability of Ansible, the breadth of technologies that we've had integrations with and our ability to actually bridge that gap between different technologies, different teams. Once you have that culture of automation, you can start to realize these DevOps and DevSecOps workflow styles that are top of everybody's mind these days. And that's something that I think is very powerful. And I like to try to preach when I have the opportunity to talk to folks about what we can do, and the fact that we have so much capability and so many integrations across the entire industry. >> That's a great point. DevSecOps is totally a hop on. When you have software and hardware, it becomes interesting. There's a variety of different equipment, on the security automation. What kind of security appliances can you guys automate? >> As of today, we are able to do endpoint management systems, enterprise firewalls, security information, and event management systems. We're able to do security orchestration, automation, remediation systems, privileged access management systems. We're doing some threat intelligence platforms. And we've recently added to the I'm sorry, did I say intrusion detection? We have intrusion detection and prevention, and we recently added endpoint security management. >> Huge, huge value there. And I think everyone's wants that. Jill, I've got to ask you about the Cloud because the modules came up. What use cases do you see the Ansible modules in for the public cloud? Because you got a lot of cloud native folks in public cloud, you've got enterprises lifting and shifting, there's a hybrid and multicloud horizon here. What's some of the use cases where you see those Ansible modules fitting well with public level. >> The modules that we have in public cloud can work across all of those things, you know. In our public clouds, we have support for Amazon web services, Azure GCP, and they all support your main services. You can spin up a Lambda, you can deploy ECS clusters, build AMI, all of those things. And then once you get all of that up there, especially looking at AWS, which is where I spend the most time, you get all your EC2 instances up, you can now pull that back down into Ansible, build an inventory from that. And seamlessly then use Ansible to manage those instances, whether they're running Linux or windows or whatever distro you might have them running, we can go straight from having deployed all of those services and resources to managing them and going between your instances in your traditional operating system management or those instances and your cloud services. And if you've got multiple clouds or if you still have on prem, or if you need to, for some reason, add those remote cloud instances into some sort of on-prem hardware load balancer, security endpoint, we can go between all of those things and glue everything together, fairly seamlessly. You can put all of that into tower and have one kind of view of your cloud and your hardware and your on-prem and being able to move things between them. >> Just put some color commentary on what that means for the customer in terms of, is it pain reduction, time savings? How would you classify their value? >> I mean, both. Instead of having to go between a number of different tools and say, "Oh, well for my on-prem, I have to use this. "But as soon as I shift over to a cloud, "I have to use these tools. "And, Oh, I can't manage my Linux instances with this tool "that only knows how to speak to, the EC2 to API." You can use one tool for all of these things. So like we were saying, bring all of your different teams together, give them one tool and one view for managing everything end to end. I think that's, that's pretty killer. >> All right. Now I get to the fun part. I want you guys to weigh in on the Kubernetes. Adam, if you can start with you, we'll start with you go in and tell us why is Kubernetes more important now? What does it mean? A lot of hype continues to be out there. What's the real meet around Kubernetes what's going on? >> I think the big thing is the modernization of the application development delivery. When you talk about Kubernetes and OpenShift and the capabilities we have there, and you talk about the architecture, you can build a lot of the tooling that you used to have to maintain, to be able to deliver sophisticated resilient architectures in your application stack, are now baked into the actual platform, so the container platform itself takes care of that for you and removes that complexity from your operations team, from your development team. And then they can actually start to use these primitives and kind of achieve what the cloud native compute foundation keeps calling cloud native applications and the ability to develop and do this in a way that you are able to take yourself out of some of the components you used to have to babysit a lot. And that becomes in also with the OpenShift operator framework that came out of originally Coral S, and if you go to operator hub, you're able to see these full lifecycle management stacks of infrastructure components that you don't... You no longer have to actually, maintain a large portion of what you start to do. And so the operator SDK itself, are actually developing these operators. Ansible is one of the automation capabilities. So there's currently three supported there's Ansible, there's one that you just have full access to the Golang API and then helm charts. So Ansible's specifically obviously being where we focus. We have our collection content for the... carries that core, and then also ReHat to OpenShift certified collection's coming out in, I think, a month or so. Don't hold me to the timeline. I'm shoving in trouble for that one, but we have those things going to come out. Those will be baked into the operator's decay that we fully supported by our customer base. And then we can actually start utilizing the Ansible expertise of your operations team to container native of the infrastructure components that you want to put into this new platform. And then Ansible itself is able to build that capability of automating the entire Kubernetes or OpenShift cluster in a way that allows you to go into a brownfield environment and automate your existing infrastructure, along with your more container native, futuristic next generation, net structure. >> Jill this brings up the question. Why don't you just use native public cloud resources versus Kubernetes and Ansible? What's the... What should people know about where you use that, those resources? >> Well, and it's kind of what Adam was saying with all of those brownfield deployments and to the same point, how many workloads are still running just in EC2 instances or VMs on the cloud. There's still a lot of tech out there that is not ready to be made fully cloud native or containerized or broken up. And with OpenShift, it's one more layer that lets you put everything into a kind of single environment instead of having to break things up and say, "Oh, well, this application has to go here. "And this application has to be in this environment.' You can do that across a public cloud and use a little of this component and a little of that component. But if you can bring everything together in OpenShift and manage it all with the same tools on the same platform, it simplifies the landscape of, I need to care about all of these things and look at all of these different things and keep track of these and are my tools all going to work together and are my tools secure? Anytime you can simplify that part of your infrastructure, I think is a big win. >> John: You know, I think about-- >> The one thing, if I may, Jill spoke to this, I think in the way that a architectural, infrastructure person would, but I want to try to really quick take the business analyst component of it as the hybrid component. If you're trying to address multiple footprints, both on prem, off prem, multiple public clouds, if you're running OpenShift across all of them, you have that single, consistent deployment and development footprint for everywhere. So I don't disagree with anything they said, I just wanted to focus specifically on... That piece is something that I find personally unique, as that was a problem for me in a past life. And that kind of speaks to me. >> Well, speaking of past lives-- >> Having me as an infrastructure person, thank you. >> Yeah. >> Well, speaking of past lives, OpenStack, you look at Jill with OpenStack, we've been covering the Cuba thing when OpenStack was rolling out back in the day, but you can also have private cloud. Where you used to... There's a lot of private cloud out there. How do you talk about that? How do people understand using public cloud versus the private cloud aspect of Ansible? >> Yeah, and I think there is still a lot of private cloud out there and I don't think that's a bad thing. I've kind of moved over onto the public cloud side of things, but there are still a lot of use cases that a lot of different industries and companies have that don't make sense for putting into public cloud. So you still have a lot of these on-prem open shift and on-prem OpenStack deployments that make a ton of sense and that are solving a bunch of problems for these folks. And I think they can all work together. We have Ansible that can support both of those. If you're a telco, you're not going to put your network function, virtualization on USC as to one in spot instances, right? When you call nine one one, you don't want that going through the public cloud. You want that to be on dedicated infrastructure, that's reliable and well-managed and engineered for that use case. So I think we're going to see a lot of ongoing OpenStack and on-prem OpenShift, especially with edge, enabling those types of use cases for a long time. And I think that's great. >> I totally agree with you. I think private cloud is not a bad thing at all. Things that are only going to accelerate my opinion. You look at the VM world, they talked about the telco cloud and you mentioned edge when five G comes out, you're going to have basically have private clouds everywhere, I guess, in my opinion. But anyway, speaking of VMware, could you talk about the Ansible VMware module real quick? >> Yeah, so we have a new collection that we'll be debuting at Ansible Fest this year bore the VMware REST API. So the existing VMware modules that we have usually SOAP API for VMware, and they rely on an external Python library that VMware provides, but with these fare 6.0 and especially in vSphere 6.5, VMware has stepped up with a REST API end point that we find is a lot more performance and offers a lot of options. So we built a new collection of VMware modules that will take advantage of that. That's brand new, it's a lighter way. It's much faster, we'll get better performance out of it. You know, reduced external requirements. You can install it and get started faster. And especially with these sphere seven, continuing to build on this REST API, we're going to see more and more interfaces being exposed so that we can take advantage. We plan to expand it as new interfaces are being exposed in that API, it's compatible with all of the existing modules. You can go back and forth, use your existing playbooks and start introducing these. But I think especially on the performance side, and especially as we get these larger clouds and more cloud deployments, edge clouds, where you have these private clouds and lots and lots of different places, the performance benefits of this new collection that we're trying to build is going to be really, really powerful for a lot of folks. >> Awesome. Brad, we didn't forget about you. We're going to bring you back in. Network automation has moved towards the resource modules. Why should people care about them? >> Yeah. Resource modules, excuse me. Probably I think having been a network engineer for so long, I think some of the most exciting work that has gone into Ansible network over the past year and a half, what the resource modules really do for you is they will reach out to network devices. They will pull back that network native, that vendor native configuration. While the resource module actually does the parsing for you. So there's none of that with the resource modules. And we returned structured data back to the user that represents the configuration. Going back to your question about source of truth. You can take that structure data, maybe for your interface CONFIG, your OSPF CONFIG, your access list CONFIG, and you can store that data in your source of truth under source of truth. And then where you are moving forward, is you really spend time as every engineer managing the data that makes up the configuration, and you can share that data across different platforms. So if you were to look at a lot of the resource modules, the data model that they support, it's fairly consistent between vendors. As an example, I can pull OSPF configuration from one vendor and with very small changes, push that OSPF configuration to a different vendor's platform. So really what we've tried to do with the resource modules is normalize the data model across vendors. It'll never be a hundred percent because there's functionality that exists in one platform that doesn't exist and that's exposed through the configuration, but where we could, we have normalized the data model. So I think it's really introducing the concept of network configuration management through data management and not through CLI commands anymore. >> Yeah, that's a great point. It just expands the network automation vision. And one of the things that's interesting here in this panel is you're talking about, cloud holistically, public multicloud, private hybrid security network automation as a platform, not just a tool, we're still going to have all kind of tools out there. And then the importance of automating the edge. I mean, that's a network game Brad. I mean, it's a data problem, right? I mean, we all know about networking, moving packets from here to there, but automating the data is critical and you give have bad data and you don't have... If you have misinformation, it sounds like our current politics, but you know, bad information is bad automation. I mean, what's your thoughts? How do you share that concept to developers out there? What should they be thinking about in terms of the data quality? >> I think that's the next thing we have to tackle as network engineers. It's not, do I have access to the data? You can get the data now for resource modules, you can get the data from NETCONF, from RESTCONF, you can get it from OpenConfig, you can get it from parsing. The question really is, how do you ensure the integrity and the quality of the data that is making up your configurations and the consistency of the data that you're using to look at operational state. And I think this is where the source of truth really becomes important. If you look at Git as a viable source of truth, you've got all the tools and the mechanisms within Git to use that as your source of truth for network configuration. So network engineers are actually becoming developers in the sense that they're using Git ops to worklow to manage configuration moving forward. It's just really exciting to see that transformation happen. >> Great panel. Thanks for everyone coming on, I appreciate it. We'll just end this by saying, if you guys could just quickly summarize Ansible fast 2020 virtual, what should people walk away with? What should your customers walk away with this year? What's the key points. Jill, we'll start with you. >> Hopefully folks will walk away with the idea that the Ansible community includes so many different folks from all over, solving lots of different, interesting problems, and that we can all come together and work together to solve those problems in a way that is much more effective than if we were all trying to solve them individually ourselves, by bringing those problems out into the open and working together, we get a lot done. >> Awesome, Brad? >> I'm going to go with collections, collections, collections. We introduced in last year. This year, they are real. Ansible2.10 that just came out is made up of collections. We've got certified collections on automation. We've got cloud collections, network collections. So they are here. They're the real thing. And I think it just gets better and deeper and more content moving forward. All right, Adam? >> Going last is difficult. Especially following these two. They covered a lot of ground and I don't really know that I have much to add beyond the fact that when you think about Ansible, don't think about it in a single context. It is a complete automation solution. The capability that we have is very extensible. It's very pluggable, which has a standing ovation to the collections and the solutions that we can come up with collectively. Thanks to ourselves. Everybody in the community is almost infinite. A few years ago, one of the core engineers did a keynote speech using Ansible to automate Philips hue light bulbs. Like this is what we're capable of. We can automate the fortune 500 data centers and telco networks. And then we can also automate random IOT devices around your house. Like we have a lot of capability here and what we can do with the platform is very unique and something special. And it's very much thanks to the community, the team, the open source development way. I just, yeah-- >> (Indistinct) the open source of truth, being collaborative all is what it makes up and DevOps and Sec all happening together. Thanks for the insight. Appreciate the time. Thank you. >> Thank you. I'm John Furrier, you're watching theCube here for Ansible Fest, 2020 virtual. Thanks for watching. (soft upbeat music)