>> Announcer: From around the globe, it's theCUBE with digital coverage of Ansible Fest 2020, brought to you by Red Hat. >> Everyone welcome back to theCUBEs, virtual coverage of Ansible Fest 2020. I'm John Furrier, host of theCUBE, we're here virtual, we're not face to face obviously because of COVID. So we're doing a virtual event Ansible Fest coverage. We have Mary Johnston Turner, research Vice President of Cloud Management at IDC international data Corp. Mary great to see you, thanks for coming on for Ansible Fest 2020. >> Thanks for inviting me. >> So obviously Cloud Management, everything's Cloud native we're seeing that at VM world, we've got Re-invent coming up, Azure has got growth. The enterprises have gotten some religion on Cloud Native, COVID certainly is forcing that. What are you seeing from your research at IDC around the convergence of Cloud strategies. What's the data tell you, what's the research show? >> Well, obviously with COVID a lot of folks have pivoted or accelerated their move to the Cloud in many ways. And I think what's happening is that we're seeing many, many organizations recognizing they continue to have need for On-prem resources. They're building out edge, they've got remote work from home, they've got traditional VM workloads, They've got modern Cloud Native container-based workloads running On-Prem and in public Clouds and public Cloud services. So it's really kind of a striking world of connected Clouds is how I'm talking about it increasingly. And I think what that means from an operational perspective is that it's getting more and more challenging for organizations to maintain consistent configuration, stable APIs, security, compliance and conformance. And they're really starting to look at Automation as the way to deal with the increasing scale and velocity of change because that's one of the things that's happening. And I think COVID accelerated that is we've seen organizations stand up applications they never thought they were going to have to stand up and they not only stood them up very quickly, but then they continue to update them with great frequency often multiple times a day or a week. And and the infrastructure has had to pivot and the workloads have had to migrate. So it's really been a very challenging time for many organizations. And I think those that are coping the best with it are the ones who have been investing in Automation particularly Automation in CICD pipeline and code based environment. >> Yeah, you know, you're seeing the releases, obviously Automation has helped on the agile side, VMs and containers have been a great way to automate, how are customers looking at this? Because it seems to be Automation is like the first step towards everything as a service, right? So it's XAAS as it's says, as it's called in the industry. Services is ultimately the holy grail in all this because you get, when the Automation and services used to be Automation, Automation, Automation. Now you're hearing as a service, as a service, as a service as the top three priorities. So it seems to be a trajectory. How are customers getting first of all... Do you agree with that? And then how do customers think about this? Cause sometimes we're ahead of the customers. Automation is the first step. What's your take on this, and what are customers planning when it comes to Automation? Are they thinking as a service? What'd you hearing from the customers? >> Let's talk a little bit about what we mean by as a service. Cause that's a really interesting concept, right? And I've been hearing this conversation with folks as a service started a decade or more ago, taking things that particularly software that ran On-prem infrastructure or software. And putting it into share Data Centers where we could run Multi tenant Environments we could scale it, and each Cloud provider basically got that scale by investing in their own set of infrastructure Automation. So whether it was Azure or VMware or whoever, they build a whole repeatable, scalable environment that they could control. What's happening now is that we're seeing these control planes get stretched back to On-prem resources. And I think what's really happening is that the line about where does the thing physically have to run? Becomes more of a discussion around the physics of the matter, Latency, Data Volumes, transaction processing cost of installed equipment. And every organization is making its own choice about what's the right mix, in terms of where physically do things have to run, and how they want to manage them. But I think that we're starting to see a abstraction layer coming in between that. And a lot of that abstraction is Automation that's portable that can be applied across all these environments. And that can be used to standardize configurations, to maintain standard APIs, to deploy at very fast speed and consistency across all these different resources. And so Automation and the related management layer to me is that new abstraction layer that actually is going to allow most enterprises to stop worrying quite so much about (chuckles) what kind of as a service am I buying? And focus more on the economics and the performance and the physics of the infrastructure, and then maintain consistency with highly Automated, Repeatable, Programmable Style Environments that are consistent across all these different platforms. >> Yeah, that's a great point. It's great insight, I love that. It's almost, as you can almost visualize the boardroom. We need to change our business model as a service. Go do it, climb that hill, get it done, what are you talking about? What you're trying to manage workloads inside our enterprise and outside as they started looking at the workload aspect of it, it's not trivial to just say it, right? So your containers has barely filled the void here. How are customers and how are people getting started with this initial building block of saying okay, do we just containerize it? Cause that's another hand waving activity which has a lot of traction. Also you put some containers has got some goodness to it, are many people getting started with solving this problem? And what are some of the roadblocks of just managing these workloads inside and outside the enterprise? >> Well, again I think, yeah many organizations are still in the early stages of working with containers. Right now I think our research shows that maybe five to 10% of applications have been containerized. And that's a mix of lift and shift of traditional workloads as well as net new Cloud Native. Over the next couple of years almost enterprise has tell us to think a third of their workloads could be containerized. So it's ramping very, very quickly. Again, I think that the goal for many organizations is certainly containers allow for faster development, very supportive microservices, but increasingly it's also about portability. I talk to many organizations that say, yeah, one of the reasons I'm moving, even traditional workloads into containers is so that I have that flexibility. And again, they're trying to get away from the tight coupling of workloads to physical resources and saying I'm going to make those choices, but they might change over time or I might need to go what happens. I have to scale much faster than I ever thought. I'm never going to be able to do that my own data center, I'm going to go to the Cloud. So I think that we're seeing increasing investments in, Kubernetes and containers to promote more rapid scaling and increased business agility. And again, I think that means that organizations are looking for those workloads to run across a whole set of environments, geographies, physical locations, edge. And so they're investing in platforms and they count on Automation to help them do that. >> So your point here is that in five, 10% that's a lot of growth opportunity. So containers is actually happening now so you starting to see that progression. So that's great insight. So I've got to ask you on the COVID impact, that's certainly changed some orientation because hey, this project let's double down on this is a tailwind for us, work from home this new environment and these projects, maybe we want to wait on those, how do we come out of COVID? Some people have been saying, some spending in some areas are increasing, some are not, how are customers spending money on infrastructure with COVID impact? What are you seeing from the numbers? >> Well, that's a great question, and I do see one of the major things we do is track IT markets and spending and purchasing around the world. And as you might expect, if you go back to the early part of the year, there was a very rapid shift to Cloud, particularly to support work from home. And obviously there was a lot of investment in virtual desktops and remote work kinds of and collaboration very early on. But now that we're sort of maturing a little bit and moving into more of ongoing recovery resiliency sort of phase, we continue to see very strong spending on Cloud. I think overall it's accelerated this move to more connected environments. Many of the new initiatives are being built and deployed in Cloud environments. But again, we're not seeing a Whole Hog exit from On-prem resources. The other thing is Edge. We're seeing a lot of growth on Edge, both again there's sort of work from home, but also more remote monitoring, more support for all kinds of IOT and remote work environments, whether it's Lab Testing or Data Analysis or Contact Tracing. I mean, there's just so many different use cases. >> I'm going to ask you about Ansible and Red Hat. I see you've been following Ansible since the acquisition by Red Hat. How do you think they're doing Visa Vie the market, their competitors that have also been acquired? What's your take on their performance, their transition, their transformation? >> Well, this infrastructure is code or Automation is code market has really matured a lot over the last 10 or more years. And I think the Ansible acquisition was about five years ago now. I think we've moved from just focusing on trying to build elegant Automation languages, which certainly was an early initiative. Ansible offered one of the earlier human readable Python based approaches as opposed to more challenging programming languages that some of the earlier solutions had. But I think what's been really interesting to me over the last couple years with Red Hat is just what a great job they've done in promoting the community and building out that ecosystem, because at the end of the day the value of any of these infrastructures code solutions is how much they promote the connectivity across networks, Clouds, servers, security, and do that in a consistent, scalable way. And I think that's what really is going to matter going forward. And then that's probably why you've seen a range of acquisitions in this market over the last couple of years, is that as a standalone entity, it's hard to build those really robust ecosystems, and to do the analytics and the curation and the support at large scale. So it kind of makes sense as these things mature that they become fun homes with larger organizations that can put all that value around it. >> That's great commentary on the infrastructure as code, I totally agree. You can't go wrong by building abstraction layers and making things more agile. I want to get your take on some announcements that are going on here and get your thoughts on your perspective. Obviously they released with the private Automation hub and a bunch of other great stuff. I mean, bringing Automation, Kubernetes, and series of new features to the platform together, obviously continuation of their mission. But one of the things when I talked to the engineers is I say, what's the top three things, Ansible Fest, legal collections, collections, collections, so you start to see this movement around collections and the platform. The other thing is, it's a tool market and everyone's got tools we need a platform. So it's a classic tools. As you saw that in big data other areas where need start getting into platform, and you need management and orchestration you need Automation, services. What's your perspective on these announcements? Have they been investing aggressively? What does it mean? What's your take? And what does it mean? >> Yeah, I would agree that Red Hat has continued to invest very aggressively in Red Hat and in Ansible over the last few years. What's really interesting is if you go back a couple years, we had ASML engine, which included periodic, maybe every quarter or even longer than that distributions that pretty much all Ansible code got shipped on. And then we had tower which provided an API and a way to do some audit and logging and integration with source control. And that was great, but it didn't move fast enough. And we just got done talking about how everything's accelerated and everything's now connected Clouds. And I think a lot of what the Red Hat has done is really, approach the architecture for scale and ecosystem for scale. And so the collections have been really important because they provide a framework to not only validate and curate content but also to help customers navigate it and can quickly find the best content for their use cases. And also for the partners to engage, there's I think it's 50 plus collections now that are focused on partner content. And so it's I think it's really provided an environment where the ecosystem can grow, where customers can get the support that they need. And then with the Automation hub and the ability to support really robust source control and distribution. And again, it's promoting this idea of an Automation environment that can scale not only within a data center, but really across these connected environments. >> Great stuff. I want to get your thoughts cause I want to define and understand what Red Hat and Ansible, when they talk about curated content, which includes support for open shifts, versus pulling content from the community. I hear content I'm like, oh, content is that a video? Is that like, what is content? So can you explain what they mean when they say they're currently building out, aggressively building curated content and this idea of what does content mean? Is it content, is it code? >> Yeah, I think any of these Automation as code environments. You really have a set of building blocks that in the Ansible framework would be be modules and playbooks and roles. And those are relatively small stable pieces of code, much of it is actually written by third parties or folks in the community to do a very specific task. And then what the Ansible platform is really great at is integrating those modules and playbooks and roles to create much more robust Automations and to give folks a starting point, and ability to do, rather than having to code everything from scratch to really kind of pull together things that have been validated have been tested, get security updates when they need it that kind of thing. And so the customers can focus on essentially changing these things together and customizing them for their own environment as opposed to having to write all the code from step one. >> So content means what, in this context, what does content mean for them? >> It's Automation building blocks. It's code, it's small amounts of code that do very specific things (chuckles) and in a collections environment, it's tagged, it's tested, it's supported. >> It's not a research report like of a Cube video, it's like code, it's not content. >> Yeah, I know. But again, this is Automation as code, right? So it it's pieces of code that rather than needing an expert who understands everything about how a particular device or system works, you've got reusable pieces of code that can be integrated together, customized and run on a repeatable, scalable basis. And if they need to be updated cause an API changes or something, there's a chain that goes back to the the vendors who, again are part of the ecosystem and then there's a validation and testing. So that by the time it goes back into the collections, the customers can have some confidence that when they pull it down, it's not going to break their whole environment. Whereas in a pure community supported model, the contents made by the community, may be beautiful, but you don't know, and you could have five submissions that kind of do the same thing. How do you know what's going to work and what's going to be stable? So it's a lot of helping organizations get Automation faster in a more stable environment. >> We can certainly follow up on this train cause one of things I've been digging into is this idea of, open source and contribution, integrations are huge. The collections to me is super important because when we start thinking about integration that's one of Cloud native, supposedly strength is to be horizontally scalable, integrated, building abstraction layers as you had pointed out. So I've got to ask you with respect to open source. I was just talking with a bunch of founders yesterday here in Silicon Valley around as Cloud scales and certainly you seeing snowflake build on top of AWS. I mean, that's an amazing success story. You're starting to see these new innovations where the Cloud scale providers are providing great value propositions and the role open source is trying to keep pace. And so I got to ask you is still open source, let me say I believe it's important, but how does open source maintain its relevance as Cloud scale goes on? Because that's going to force Automation to go faster. Okay, and you got the major Cloud vendors promoting their own Cloud platforms. Yet you got the innovation of startups and companies. Your enterprises are starting to act like startups as container starts to get through this lift and shift phase. You'll see innovation coming from enterprises as well as startups. So you start to see this notion bring real value on top of these Clouds. What's your take on all this? >> Well, I think open source and the communities continue to be very, very important, particularly at the infrastructure layer, because to get all this innovation that you're talking about, you act, if you believe you've got a connected environment where folks are going to have different footprints and, and probably, you know, more than one public Cloud set of resources, it's only going to, the value is only going to be delivered if the workloads are portable, they're stable, they can be integrated, they can be secure. And so I think that the open source communities have become, you know, continue to be an incredibly important as a way to get industry alignment and shared innovation on the, on the platform and infrastructure and operational levels. And I think that that's, you know, going to be, be something that we're going to see for a long time. >> Well Mary, I really appreciate your insights, I got one final question, but I'll just give you a plug for the folks watching, check out Mary's work at IDC, really cutting edge and super important as Cloud management really is at the heart of all the, whether it's multicloud, on-premise hybrid or full Cloud lift and shift or Cloud native, management plays a huge important role right now. That's where the action is. You looking at the container growth as Mary you pointed out is great. So I have to ask you what comes next. What do you think management will do relative to Cloud management, as it evolves in these priority environments around Cloud, around on-premise as the operations start to move along, containers are critical. You talked about the growth is only five, 10%, a lot of headroom there. How is management going to evolve? >> Well, again, I think a lot of it is going to be is everything has to move faster. And that means that Automation actually becomes more and more important, but we're going to have to move from Automation at human speed to Automation at container and Cloud speed. And that means a lot is going to have to be driven by AI and ML analytics that can and observability solutions. So I think that that's going to be the next way is taking these, you know, very diverse sources of, of log and metrics and application traces and performance and end user experience and all these different things that tell us, how is the application actually running and how is the infrastructure behaving? And then putting together an analytics and Automation layer that can be a very autonomous. We have at IDC for doing a lot of research on the future of digital infrastructure. And this is a really fundamental tenant of what we believe is that autonomous operations is the future for a Cloud and IT. >> Final point for our friends out there and your friends out there watching who some are on the cutting edge, riding the big wave of Cloud native, they're at Cube calm, they're digging in, they're at service meshes, Kubernetes containers, you name it. And for the folks who have just been kind of grinding it out, an it operations, holding down the Fort, running the networks, running all the apps. What advice do you give the IT skillset friends out there that are watching. What should they be doing? What's your advice to them, Mary? >> Well, you know, we're going to continue to see the convergence of, of virtualized and container based infrastructure operations. So I think anyone out there that is in those sorts of roles really needs to be getting comfortable with programmatic code driven Automation and, and figuring out how to think about operations from more of a policy and scale scalability, point of view. Increasingly, you know, if you believe what I just said about the role of analytics driving Automation, it's going to have to be based on something, right? There's going to have to be rules. There's going to have to be policies is going to have to be, you know, configuration standards. And so kind of making that shift to not thinking so much about, you know, the one off lovingly handcrafted, handcrafted environment, thinking about how do we scale, how do we program it and starting to get comfort with, with some of these tools, like an Ansible, which is designed to be pretty accessible by folks with a large range of skillsets, it's human readable, it's Python based. You don't have to be a computer science major to be able to get started with it. So I think that that's what many folks have to do is start to think about expanding their skill sets to operate at even greater scale and speed. >> Mary, thanks so much for your time. Mary Johnston Turner, Vice President of Research at Cloud for Cloud management at IDC for the Ansible Fest virtual. I'm John Ferrier with theCUBE for cube coverage, cube virtual coverage of Ansible Fest, 2020 virtual. Thanks for watching.

>> Welcome back to AnsibleFest. I'm Matthew Jones, I'm the architect of the Ansible Automation Platform. And today I want to talk to you a little bit about what we've got coming in 2021, and some of the things that we're working on for the future. Today, I really want to cover some of the work that we're doing on scale and flexibility, and how we're going to focus on that for the next year. I also want to talk about how we're going to help you grow and manage and use your content on the Automation platform. And then finally, I want to look a little bit beyond the automation platform itself. So, last year we introduced Ansible Content Collections. Earlier this year, we introduced the Ansible Automation Hub on Red Hat Cloud. And yesterday you heard Richard mentioned on private automation hub that's coming later this year. And automation hub, Ansible tower, this is really what the automation platform means for us. It's bringing together that content, with the ability to execute and run and manage that content, that's really important. And so what we really want to do, is we want to help you bring Red Hat and partner content that you trust together with community content from galaxy that you may need, and bring this together with content that you develop for yourself, your roles, your collections, the automation that you actually do. And we want to give you control over that content and help you curate that content and build a community around your automation. We want to focus on a seamless experience with this automation from Ansible Tower and from Automation Hub for the automation platform itself, and make it accessible to the automation and infrastructure that you're managing. Now that we've talked about content a little bit, I want to talk about how you run Ansible. Today an Ansible Tower, use virtual environments to manage the actual execution of Ansible, and virtual environments are okay, but they have some drawbacks. Primarily they're not very portable. It's difficult to manage dependencies and the version of Ansible. Sometimes those dependencies conflict with the other systems that are on the infrastructure itself, even Ansible Tower. So what we've done is created a new system that we call execution environments. Execution environments are container-based. And what we're doing is bringing the flexibility and portability of containers to these Ansible execution environments. And the goal really is portability. And we want to be able to leverage the tools that the community develops as well as the tools that Red Hat provides to be able to produce these container images and use them effectively. At Ansible we've developed a tool called Ansible Builder. Ansible builder will let you bring content collections together with the version of Ansible and Red Hats base container image so that you can put together your own images for execution environments. And you'll be able to host these on your own private registry infrastructure. If you don't already have a container registry solution, Automation Hub itself provides that registry. The idea here is that, unlike today where your virtual environments and your production execution environments diverge a little bit from what your developers, your content developers and your automation developers experience, we want to give you the same experience between your production environments and your development environments, all the way through your test and validation workloads. Red Hat's also going to provide some prebuilt execution environments. We want to have some continuity between the experience that you have today on the Ansible tower and what you'll have next year, once we bring execution environments into production. We want you to be able to trust the Ansible, the version of Ansible that's running on your execution environments, and that you have the content that you expect. At the same time, we're going to provide a version of the execution environment, that's just the base execution environment. All it has is Ansible. This will let you take those using Ansible builder, take the collections that you've developed, that you need in your automation and combine them without having to bring in things that you don't need, or that you don't want in your automation and build them together into a very opinionated, container image. If you're interested in execution environments and you want to know how these are built and how you'll use them, we actually have them available for you to use today. Shane McDonald and Adam Miller are giving a talk later with a walk through how to build execution environments and how you'll use them. You can use this to make sure that you're ready for execution environments coming to the automation platform next year. Now that we've talked about how we build execution environments, I want to talk about how execution runs in your infrastructure. So today when you deploy Ansible tower, you're deploying a monolithic web application. Your execution capability is tied up into how you actually deploy Ansible tower. This makes scaling Ansible tower and your automation workloads difficult, and everything has to be co-located together in the same data center. Isolated nodes solve this a little bit, but they bring about their own sort of opinionated challenges in setting up SSH and having direct connectivity between the control nodes and the execution nodes themselves. We want to make this more flexible and easier to use. And so one of the things that we've created over the last year and that we've been working on over the last year is something that we call receptor. Receptor is an overlay network that's an Automation Mesh. And the goal here is to separate the execution capability of your Ansible content from the control plane capability, where you manage the web infrastructure, the users, the role-based access control. We want to draw a line between those. We want you to be able to deploy execution environments anywhere. Chris Wright earlier today mentioned Edge. Well Edge Cloud, we want you to be able to manage data centers anywhere in the world, and you can do this with the Automation Mesh,. The Automation Mesh connects your control plane with those execution nodes, anywhere in the world. Another thing that the Automation Mesh brings is, we're going to be able to draw the lines between the control plane themselves and each Automation Mesh node. This means that if you have an outage or a problem on your network and on your infrastructure, if you can draw a line between the control plane itself and the node that needs to execute, the sensible work, the Automation Mesh can route around problems. The Automation Mesh in the way it's deployed, also allows this to fit closer with ingress and egress policies that you have between your infrastructure. It doesn't matter which direction the Automation Mesh itself connects in. Once the connection is established, automation will be able to flow from the control systems to the execution nodes and get responses back. Now, this all works together with automation of the content collections that we mentioned earlier, the execution environments that we were just talking about and your container registries. All of these work together with these Automation Mesh nodes. They're very lightweight and very simple systems. This means you can scale up and scale down execution capacity as your needs increase or decrease. You don't need to keep around a lot of extra capacity just in case you automate more, just because you're not sure when your execution capacity needs will increase and decrease. This fits into an automated system for scaling your infrastructure and scaling your execution capacity. Now that we've talked about the content that you use to manage, and how that execution is performed and where that execution is performed. I want to look a little bit beyond the actual automation platform itself. And specifically, I want to talk about how the automation platform works with OpenShift and Kubernetes. Now we have an existing installer for Ansible tower that we'll deploy to OpenShift Kubernetes, and we support OpenShift and Kubernetes as a first-class system for deploying Ansible tower. But I mentioned automation hub and Ansible tower as this is what the automation platform is for us. So we want to take that installer and replace it with an operator-based full life cycle approach to deploying and managing the automation platform on OpenShift. This operator will be available in OperatorHub. So there's no need to manage complex YAML files that represent the deployment. Since it's available in OperatorHub, you have one place that you can go to manage deployments, upgrades, backup and restore. And all of this work seamlessly with the container groups feature that we introduced last year. But I want to take this a little bit beyond just deploying and upgrading the automation platform from the operator. We want to look at what other capabilities that we can get out of those operators. So beyond just deploying and upgrading, we're also creating a resource operators and CRDs that will allow other systems running in OpenShift or Kubernetes to directly manage resources within the automation platform. Anything from triggering jobs and getting the status of jobs back, we want to enable that capability if you're using OpenShift and Kubernetes. The first place we're starting with this, is Red Hats Advanced Cluster Management system. Advanced Cluster Management brings together the ability to manage OpenShift and Kubernetes clusters to install them and manage them, as well as applications and products in managing the life cycle of those across your clusters. So what we really want to do, is give you the ability to connect traditional and container-based workloads together. You're already using the Ansible automation platform to manage workloads with Ansible. When using Advanced Cluster Management and OpenShift and Kubernetes, now you have a full system. You can manage across clouds across clusters, anywhere in the world. And this sort of brings me back to one of the areas of focuses for us. Our goal is complete end-to-end automation. We want to connect your people, your domains and the processes. We want to help you deliver for you and your customers by expanding the capabilities of the Ansible automation platform. And we want to make this a seamless experience to both curate content, control the content for your organization, and run the content and run Ansible itself using the full suite of the Ansible automation platform. So the Advanced Cluster management team is giving a talk later where you'll actually be able to see Advanced cluster Management and the Ansible automation platform working together. Don't forget to check out Adam and Shane's talk on execution environments, how those are built and how you can use those. Thank you for coming to AnsibleFest, and we'll see you next time.

>>live from Atlanta, Georgia. It's the Q covering Answerable Fest 2019. Brought to you by Red Hat. >>Welcome back. This is the Cubes Live coverage of anti professed 2019 here in Atlanta. Georgia Instrument in my co host is John Ferrier and happy to welcome to the program the first time guest pile sing. Who's a principal solutions engineer with F five? Of course. Five's a partner of Anti Bowl In the keynote this morning when they were laying out You know how to use all of these pieces? Oh, I need a load balancer. Great. Here. Here's five to the rescue. So tell us a little bit about you know your role inside F five and kind of fights activities here at the show. >>Sure. Sure. Uh, so thank you for the introduction. Yeah, My name is our piloting principal solution. Ngo S O. I work a lot with different alliance partners and answerable being one of them. Of course, s O. I develop technical integrated joint solutions with answerable. You know, we've had a great, great working relationship with the answerable. They've been absolutely wonderful to work with on at this summit. We have various activities We had a workshop at the contributor summit. We had a session yesterday. We have another workshop on Thursday. So we're really busy, you know, the boots being flowing. And so far, it's been an awesome experience. >>The other people of the show here, they really dig into what they're doing. Ah, you know, even on the bus ride to the party last night, people are talking about their configurations at lunchtime. Everybody is talking about it. Bring us inside a little bit, you know? So is the new collections what people are asking you about? Are there other deployment ways? You know, what are some of the things that are bringing people to talk to >>people That kind of talking, you know, on a broad spectrum, you know, there's some people are just starting out with answerable. They just want to know, you know, how do I write a play book with their 500? Get it running? Others are a little more advanced, you know, Let's get into rules, you know? What are we doing with rules? And then now collections is coming on top of mine. You know how you guys doing with collections, So of course we are in lockstep. You know, we have the first collections out. We're gonna bundle playbooks and a lot of work flows and rules that gonna be someone. It's gonna be easy for customers to just download used these work clothes out of the box and get started with that five. But we've had, you know, different use cases, different questions around Day zero deployment was his data management. Bliss is monitoring was back of resource. All sorts of questions >>in one of the things that's come up is, you know, hit the low hanging fruit and then go to the ant, worked close in tow and is more of a kind of the bigger opportunities. But, you know, we've been talking about Dev Ops two for 10 years, and this to me has always been like the area that's been ripe for Dev ops, configuration management, a lot of the plumbing. But now that it's 10 years later starting to see this glue layer, this integration layer come out and the ecosystem of partners is growing very rapidly for answerable. And so there's been a very nice evolution. This is kind of a nice add on to great community great customers for these guys. What's the integration like as you work with answerable? Because as more people come on and share and connect in, what's it take? What are some of the challenges? What some of the things that you guys need to do our partners need to do with danceable, >>Right? So contributing is, you know, it's been a little slow, I would say, because firstly, they got a kind of lawn answerable and they gotta learn. You know what sensible galaxy. How can I walk around it? And then there's the networking piece, right? How do I now make it work with F five? You know, is this role good enough? Should I be contributing or not? So we're working closely with, you know, Ned, ops engineers as well as the world changes to kind of say, you know, whatever you think is a good work, so is good enough to go there. So, you know, get your role uploaded on galaxy and, you know, show us what you're doing. It doesn't have to be the best, but just get it out there so way have a lot of workshops. You know, we also have this training on F. I called Super Netapp, which is kind of targeting that walked in that office. Engineers. So we're trying to educate people so that everybody is on board with with us. >>One of the conversation we've been having a lot this week has been about the collaboration between teams and historically that's been a challenge for networking. It's alright. Networking going to sit in the corner, tell me what you need. Oh, wait, You need those things changes. Nope, I'm not gonna do it for you are, you know. Okay, wait, get me a budget in 12 months and we'll get back to you. So, uh, how are things changing? Are they changing enough in your customers environments? >>That's a good question. So it is changing, but it's changing slowly. There's still a lot of silos like nettles. Guys are doing their stuff there. Watch guys are doing their self. But with automation is it's kind of hang in together because, you know, the network's engineers have their domain expertise, develops have tails. But, you know, we were able to get them in the same room because we don't get five and then we don't automation and and then they connect. They're like, Oh, you guys are doing what we've already done So it's happening, But it's so, but it's definitely drops that develops. You don't think this is >>the chairman? We've been covered. A lot of we've had a lot of events. We've talked about programmable infrastructure. Infrastructures code is kind of in the butt when you start getting into the networking side, because very interesting when you can program things, this is a nice future. Head room for Enterprises As their app start to think about micro service is what you're taking on the program ability of networking. How do you guys see that? What's your view? >>So program ability In the networking space, it's it's catching up like just five. As a company, we started with just rest a P. I called. Now we're going to moving to answerable to F eyes. Also coming out with this AP I call declared a baby I we have this F ai automation tow chain where we're kind of abstracting more and more off how much user needs to know about the device but be able to configure it really easily. So we're definitely moving towards that and I see other other networking when there's also kind off moving towards that program ability for sure. >>Did you have any specific customer stories you might be able to share? Understand. You might not be able to give the name of the company, but it's always helps to illustrate. >>Yeah, sure, definitely. So we had one customer who, you know, they had an older or not told a different load balancer. And they want to know my great order, the Air five. So they had a lot of firewall rules and, you know, a lot of policies that they wanted to move over. So they used to have these maintenance windows and move on application at a time, eh? So they started, came across sensible, started using answerable, and they were able to migrate like 5 to 10 applications for maintenance window. And they will, you know, they loved it. They've been using answerable. They've been great providence. Or what goes into our modules, you know, really helping us guiding us as well as to what they need. So they were a great, you know, customer story. Another customer we had was you know, we get a lot of use cases for if I that we want to be able to change an application or the network without incurring any downtime, you know, fail overs, it could be as simple as as broader Sze between data centers or, you know, something simple. But what this company did want to shift between fellow between data centers, they got into answerable, they were able to do it in minutes was his hours and, you know they loved it. >>I got to ask you about a Zen engineer. You think about the data center cloud we get that that's been around that workings been great, getting better as five G and I o. T Edge kind of comes into the picture how routing and networking works with compute and edge devices start to be an opportunity for these kinds of automation. How do you guys view that's future state of EJ and and as the surface area of the network gets larger and the edges really part of the equation now his need for automation great need for seeing observe abilities. Super hot area with micro service is now you got automation kind of Ah, nice area. Expand on. What's your thoughts on beyond the data center >>so beyond the data center. So f five is indifferent clouds right to donate ws as your g c p It's out there. We also have like you know, we've recently collaborated with not collaborated. You know, engine ex has become a part of their five. So, you know, we're out there on definitely with I od and you know, no one date us and the specific that there is a boom off applications and you know, we wantto not be a hindrance to anyone who's trying to automate applications anywhere. So ah, goal is also at five is everywhere and anywhere and securing abs, making them available >>and securities 200 big driver of automation. >>I'm glad you brought up in genetic. So you know, we've been very familiar seeing Engine X at a lot of the cloud shows how Zenger next kind of changing the conversation you're having with customers. >>So having a lot of conversations with develops engineers about an genetics, you know, some of them are already using it in the day to day activity, and, you know, they don't want to see how a five and engine excite gonna gonna come together And you know what kind of solutions we can offer. So if I were working on that strategy, But you know, definitely that there is a link between us and engine aches, and customers are happy to know that. You know, we're kind of now on the same pot, So if they're in the cloud on from, you know, they can choose which one they want, but they're going to get the same support and backing off. Five. >>Great. We're getting towards the end of answerable fests. Give us what you want. Kind of some of the key takeaways. People tohave about five here at the show. >>Sure. You know, if you haven't started automating at five Invincible. My key takeaways, you know, get started. It's really simple. We have sessions now. We have a workshop on those. They look that up a great resource for us. It's just answerable dot com slash five. We have great resources. Um, are answerable. Models are supported, were certified by that had answerable. So, you know, just dive in and start automating >>pale, saying Thank you so much for the update. Really appreciate it. And congratulations on the progress. >>Thank you so much. >>for John, for your arms to minimum, getting towards the end of two days water wall coverage here. Thanks, as always for watching the Cube.

(upbeat music) >> Welcome back to London everybody, this is Dave Vellante with The Cube, the leader in tech coverage, and we're here at AWS. We wanted to cover deeper the public sector activity. We've been covering this segment for quite some time, with the public sector summit in DC, went to Bahrain last year, and we wanted to extend that to London. We're doing a special coverage here with a number of public sector folks. Anjenesh Babu is here, he's a network manager at Oxford GLAM. Thanks very much for coming on The Cube, it's good to see you. >> Thank you.], thanks. >> GLAM, I love it. Gardens, libraries and museums, you even get the A in there, which everybody always leaves out. So tell us about Oxford GLAM. >> So we are part of the heritage collection side of the University. And I'm here representing the gardens and museums. In the divisions we've got world renown collections, which has been held for 400 years or more. It comprises of four different museums and the Oxford University Botanic Gardens and Arboretum. So in total, we're looking at five different divisions, spread across probably sixteen different sites, physical sites. And the main focus of the division is to bring out collections to the world, through digital outreach, engagement and being fun, bringing fun into the whole system. Sustainment is big, because we are basically custodians of our collections and it has to be here almost forever, in a sense. And we can only display about 1% of our collections at any one point and we've got about 8.5 million objects. So as you can imagine, the majority of that is in storage. So one way to bring this out to the wider world is to digitize them, curate them and present them, either online or in another form. So that is what we do. >> In your role as the network manager is to makes sure everything connects and works and stays up? Or maybe describe that a little more. >> So, I'm a systems architect and network manager for gardens and museums, so in my role, my primary focus is to bridge the gap between technical and the non-technical functions, within the department. And I also look after network and infrastructure sites, so there's two parts to the role, one is a BAU business as usual function where we keep the networks all going and keep the lights on, basically. The second part is bringing together designs, it's not just solving technical problems, so if I'm looking at a technical problem I step out and almost zoom out to see, what else are we looking at which could be connected, and solve the problem. For example, we could be looking at a web design solution in one part of the project, but it's not relevant just to that project. If you step out and say, we could do this in another part of the program, and we may be operating in silence and we want to breakdown those, that's part of my role as well. >> Okay, so you're technical but you also speak the language of the organization and business. We put it in quotes because you're not a business per say. Okay, so you're digitizing all these artifacts and then making them available 24/7, is that the idea? What are some of the challenges there? >> So the first challenge is only 3% of objects are actually digitized. So we have 1% on display, 3% is actually digitized, it's a huge effort, it's not just scanning or taking photographs, you've got cataloging, accessions and a whole raft of databases that goes behind. And museums historically have got their own separate database collection which is individually held different collection systems, but as public, you don't care, we don't care, we just need to look at the object. You don't want to see, that belongs to the Ashmolean Museum or the picture does. You just want to see, and see what the characteristics are. For that we are bringing together a layer, which integrates different museums, it sort of reflects what we're doing in out SIT. The museums are culturally diverse institutions and we want to keep them that way, because each has got its history, a kind of personality to it. Under the hood, the foundational architecture, systems remain the same, so we can make them modular, expandable and address the same problems. So that's how we are supporting this and making it more sustainable at the same time. >> So you have huge volume, quality is an issue because people want to see beautiful images. You got all this meta data that you're collecting, you have a classification challenge. So how are you architecting this system and what role does the Cloud play in there? >> So, in the first instance we are looking at a lot of collections were on premises in the past. We are moving as a SaaS solution at the first step. A lot of it requires cleansing of data, almost, this is the state of the images we aren't migrating, we sort of stop here let's cleanse it, create new data streams and then bring it to the Cloud. That's one option we are looking at and that is the most important one. But during all this process in the last three years with the GLAM digital program there's been huge amount of changes. To have a static sort of golden image has been really crucial. And to do that if we are going down rate of on premise and trying to build out, scale out infrastructures, it would have a huge cost. The first thing that I looked at was, explore the Cloud options and I was interested in solutions like Snowball and the Storage Gateway. Straightforward, loads up the data and it's on the Cloud, and then I can fill out the infrastructure as much as I want, because we can all rest easy, the main, day one data is in the Cloud, and it's safe, and we can start working on the rest of it. So it's almost like a transition mechanism where we start working on the data before it goes to the Cloud anyway. And I'm also looking at a Cloud clearing house, because there's a lot of data exchanges that are going to come up in the future, vendor to vendor, vendor to us and us to the public. So it sort of presents itself a kind of junction, who is going to fill the junction? I think the obvious answer is here. >> So Snowball or Gateway, basically you either Snowball or Gateway the assets into the Cloud and you decide which one to use based on the size and the cost associated with doing that, is that right? >> Yes, and convenience. I was saying this the other day at another presentation, it's addictive because it's so simple and straight forward to use, and you just go back and say it's taken me three days to transfer 30 terabytes into a Snowball appliance and on the fourth day, it appears in in my packets, so what are we missing? Nothing. Let's do it again next week. So you got the Snowball for 10 days, bring it in transfer, so it's much more straightforward than transferring it over the network, and you got to keep and eye on things. Not that it's not hard, so for example, the first workloads we transferred over to the file gateway, but there's a particular server which had problems getting things across the network, because of out dated OS on it. So we got the Snowball in and in a matter of three days the data was on the Cloud, so to effect every two weeks up on the Snowball, bring it in two weeks, in three days it goes up back on the Cloud. So there's huge, it doesn't cost us any more to keep it there, so the matter of deletions are no longer there. So just keep it on the Cloud shifting using lifecycle policies, and it's straight forward and simple. That's pretty much it. >> Well you understand physics and the fastest way to get from here to there is a truck sometimes, right? >> Well, literally it is one of the most efficient ways I've seen, and continues to be so. >> Yeah, simple in concept and it works. How much are you able to automate the end-to-end, the process that you're describing? >> At this point we have a few proof of concept of different things that we can automate, but largely because a lot of data is held across bespoke systems, so we've got 30 terabytes spread across sixteen hard disks, that's another use case in offices. We've got 22 terabytes, which I've just described, it's on a single server. We have 20 terabytes on another Windows server, so it's quite disparate, it's quite difficult to find common ground to automate it. As we move forward automation is going to come in, because we are looking at common interface like API Gateways and how they define that, and for that we are doing a lot of work with, we have been inspired a lot by the GDS API designs, and we are just calling this off and it works. That is a road we are looking at, but at the moment we don't have much in the way of automation. >> Can you talk a bit more about sustainability, you've mentioned that a couple of times, double click on that, what's the relevance, how are you achieving sustainability? Maybe you could give some examples. >> So in the past sustainability means that you buy a system and you over provision it, so you're looking for 20 terabytes over three years, lets go 50 terabytes. And something that's supposed to be here for three years gets kept going for five, and when it breaks the money comes in. So that was the kind of very brief way of sustaining things. That clearly wasn't enough, so in a way we are looking for sustainability from a new function say, we don't need to look at long-term service contracts we need to look at robust contracts, and having in place mechanisms to make sure that whatever data goes in, comes out as well. So that was the main driver and plus with the Cloud we are looking at the least model. We've got an annual expenditure set aside and that keeps it, sustainability is a lot about internal financial planning and based on skill sets. With the Cloud skill sets are really straightforward to find and we have engaged with quite a few vendors who are partnering with us, and they work with us to deliver work packages, so in a way even though we are getting there with the skills, in terms of training our team we don't need to worry about complex deployments, because we can outsource that in sprints. >> So you have shipped it from a CAPX to an OPX model, is that right? >> Yes >> So what was that like, I mean, was that life changing, was it exhilarating? >> It was exhilarating, it was phenomenally life changing, because it set up a new direction within the university, because we were the first division to go with the public Cloud and set up a contract. Again thanks to the G-Cloud 9 framework, and a brilliant account management team from AWS. So we shifted from the CAPX model to the OPX model with an understanding that all this would be considered as a leased service. In the past you would buy an asset, it depreciates, it's no longer the case, this is a leased model. The data belongs to us and it's straight forward. >> Amazon continues to innovate and you take advantage of those innovations, prices come down. How about performance in the cloud, what are you seeing there relative to your past experiences? >> I wouldn't say it's any different, perhaps slightly better, because the new SDS got the benefit of super fast bandwidth to the internet, so we've got 20 gigs as a whole and we use about 2 gigs at the moment, we had 10 gig. We had to downgrade it because, we didn't use that much. So from a bandwidth perspective that was the main thing. And a performance perspective what goes in the Cloud you frankly find no different, perhaps if anything they are probably better. >> Talk about security for a moment, how early on in the Cloud people were concerned about security, it seems to have attenuated, but security in the Cloud is different, is it not, and so talk about your security journey and what's your impression and share with our audience what you've learned. >> So we've had similar challenges with security, from security I would say there's two pots, one's the contractual security and one is the technical security. The contractual security, if we had spun up our own separate legal agreement with AWS or any other Cloud vendor, it would have taken us ages, but again we went to the digital marketplace, used the G-Cloud 9 framework and it was no brainer. Within a week we had things turned around, and we were actually the first institution to go live with and account with AWS. That is the taken care of. SDS is a third party security assessment template, which we require all our vendors to sign. As soon as we went through that it far exceeds what the SDS requires, and it's just a tick box exercise. And things like data encryption at rest, in transit it actually makes it more secure than what we are running on premise. So in a way technically it's far more secure than what we could ever have achieved that's on premise, and it's all taken care of, straight forward. >> So you've a small fraction of your artifacts today that are digitized. What's the vision, where do you want to take this? >> We're looking at, I'm speaking on behalf of gardens, this is not me, per say, I'm speaking on behalf of my team, basically we are looking at a huge amount of digitization. The collection should be democratized, that's the whole aspect, bringing it out to the people and perhaps making them curators in some form. We may not be the experts for a massive collection from say North America or the Middle East, there are people who are better than us. So we give them the freedom to make sure they can curate it in a secure, scalable manner and that's where the Cloud comes in. And we backend it using authentication that works with us, logs that works with us and roll-back mechanisms that works with us. So that's were we are looking at in the next few years. >> How would you do this without the Cloud? >> Oh. If you're doing it without the Cloud-- >> Could you do it? >> Yes, but we would be wholly and solely dependent on the University network, the University infrastructure and a single point. So when you're looking at the bandwidth it's shared by students using it network out of the university and our collection visitors coming into the university. And the whole thing, the DS infrastructure, everything's inside the university. It's not bad in its present state but we need to look at a global audience, how do you scale it out, how do you balance it? And that's what we're looking at and it would've been almost impossible to meet the goals that we have, and the aspirations, and not to mention the cost. >> Okay so you're going to be at the summit, the Excel Center tomorrow right? What are you looking forward to there for us from a customer standpoint? >> I'm looking at service management, because a lot of our work, we've got a fantastic service desk and a fantastic team. So a lot of that is looking at service management, how to deliver effectively. As you rightly say Amazon is huge on innovation and things keep changing constantly so we need to keep track of how we deliver services, how do we make ourselves more nimble and more agile to deliver the services and add value. If you look at the OS stack, that's my favorite example, so you look at the OS stack you've got seven layers going up from physical then all the way to the application. You can almost read an organization in a similar way, so you got a physical level where you've got cabling and all the way to the people and presentation layer. So right now what we are doing is we are making sure we are focusing on the top level, focusing on the strategies, creating strategies, delivering that, rather than looking out for things that break. Looking out for things that operationally perhaps add value in another place. So that's where we would like to go. >> Anjenesh, thanks so much for coming on The Cube. >> Thank you >> It was a pleasure to have you. All right and thank you for watching, keep right there we'll be back with our next guest right after this short break. You're watching The Cube, from London at Amazon HQ, I call it HQ, we're here. Right back. (upbeat music)