 Live from Las Vegas, it's theCUBE, covering AWS re-invent 2017, presented by AWS, Intel, and our ecosystem of partners. Can you hear that? That's the sound of a happy conference right now. 40,000 plus here gathered. We are live here in Las Vegas here at re-invent. AWS putting on its three-day event with great success, we might add, along with Justin Warren, I'm John Walls, we're now joined with a couple of folks who are from the Red Hat side of the fence. Let's start with Tim App now, who's a Senior Principal Product Manager at OpenShift. Tim, nice to have you here. Oh, with Ansible. Yeah, or Ansible. OpenShift, all right, all right. He's on the OpenShift side of the family. All right, so I knew I was going to get that confused. First, let's talk about OpenShift a little bit though, Eric, you had an announcement just about a week ago, getting a little more in line with AWS. Obviously, you're here with that announcement a week ago, but tell us a little bit more about that. Yeah, certainly. So what we've actually done is we've had a long partnership with Amazon or AWS, and we're enabling the AWS services natively on OpenShift. So what that really means is you can go right from the, what we call as a service catalog, the user interface, and developers really don't need to know where their services are running. What they're able to do now is go into that service catalog, order AWS services alongside of their applications, and they really can deploy hybrid workloads. And really, it couldn't be any easier. You don't have to switch between consoles, you don't have to go to outside of OpenShift, it can all be done on the platform. And what was that response to? Because I'm sure you talk to customers, right? You hear what the workloads that they're trying to handle, they like the cloud environment, they like AWS, like what's going on there. But what were you trying to do for them? Yes. That solved the problem solving. Yeah, we're definitely listening to our customers and we have a lot of customers who run hybrid workloads. And really the goal of this was to make it easier, right? You know, we heard loud and clear, hybrid workloads are important. They're a part of most companies' business and they wanted a way that was really seamless and easy to reduce the overhead and complication on the developers. And by being able to pull those services into the user interface, it really makes it a lot easier to deploy all the popular services on AWS, again, right from the platform without having to ever leave that environment. So it makes it a lot more easier and comfortable for the developers and makes them a lot more efficient. Yeah. What are some of the services that you're hearing developers demand that you, like what are the ones that they really want to use on OpenShift? Yeah, yeah, there's quite a few. So we've enabled 10 initially, I'm not going to go through all 10, but things like RDS, right? So they're a relational database service, SQS, some queuing service, SNS, Athena, Route 53. I mean, the list goes on and on. So, you know, there's definitely a lot of services we have today, but what we're really doing is we're taking a lot of that feedback now that we've actually enabled this. We made it available as public and get the code today. And then we're starting to getting feedback and as we get that feedback, we're enabling more services. And the nice part about this is it's automatic. When you put a new service out there, their environment can immediately consume it, right? It doesn't have to do any special changes or enablements or reconfigurations. It's really just up to the administrator to decide which services they want to expose to their users. Yeah. So what is it about putting those services in an OpenShift that really amplifies the way that you develop with OpenShift? Because developing software on OpenShift is quite different from other forms of software development which is without that kind of platform. So what is it about putting these services that amplifies the ability of what you can do as a developer in OpenShift? Yeah. So that's kind of a multi-part question. Let me see if I can do it some justice. I think one of the nice things is we're based on Kubernetes. And Kubernetes is one of the de facto standards today for orchestrating workloads. So not only do a lot of these workloads, again, are hybrid-based, right? So they're both on-premise and in the cloud. But it pretty much adds that layer of flexibility there that you really don't have to kind of pick, right? You don't have to have it all in, you know, Amazon's AWS environment, EC2 environment, or on-prem, right? You can run it full. And the nice part about this enablement that we did, which makes it really flexible, is in an on-prem environment, you can actually enable the services there to be able to take advantage of deploying AWS services natively from on-premise. Yeah, I mean, obviously, all those services still run in the cloud, but you can actually run them, run the software to enable it locally. Likewise, if you have an instance of OpenShift where you're doing development in the cloud, EC2, you can actually have it run it there and you still have access to it. So it's really flexible in how you want to do that. It's not just confined to, you know, in the cloud, it's also available on-prem. Yeah, it provides you with that flexibility without it being too complicated and having to go into the weeds and figure out exactly how you do it in 900 different ways. You can say, well, actually, we just standardize on this one OpenShift approach, but you get the access and the choice that developers really, really like. Yeah, it's one of the things that we're, again, we're based on the Kubernetes standard, so we have something called the OpenShift Service Catalog, and that's the Kubernetes upstream project. And what that is is that standardized interface and it's really meant to automate, to make things more efficient. Normally, you'd have a ticket queuing system, your order of service, you know, a number of days it takes IT operations person some time to get that implemented, and then you get the credentials, you get an endpoint, and then you could finally tie that into your service, right, and that stays wasted. With the service catalog, that really sort of enables self-service, right, for developers, so they can go in, not only that, all those services that they create, and they put in that catalog that they can deploy, again, that's sort of married with all the services that they may need for their Harvard workloads, so all the AWS services. So it really makes it a simple, easy way to deploy your workloads, deploy your applications without a lot of work. I don't know one of the ways that you're exposing those services is using the Ansible. The Ansible Service Broker, is that what it's called? Yes, yeah, it's, we're using Ansible, the OpenShift team has used Ansible Automation to make creating these services more easy to develop and deploy into their platform. So it's one of the ways that, you know, the flexibility of the Ansible tool in adapting. Tell us a bit more about how developers are using that Ansible, so I think, particularly around that service brokerage idea, but more around, Ansible is available as open source, Red Hat is famous for being really open and knowing that. Yes it is. But it also has enterprise capabilities. So could you walk us through a bit more about that, how are developers using this to access services and then what are some of the enterprise capabilities that they can get with Ansible? Well, specific to what the OpenShift team launched, they're able to develop these services and use the entire suite of Ansible bundle modules that are bundled together and then brought in as services so they're able to mount and provision different types of services, only knowing Ansible Automation, they don't need to know like Golang or some type of other sophisticated things, so it's bringing something more powerful in a more simple way to the OpenShift platform. More specifically or more broadly, I should say, Ansible's always been a highly flexible tool that can adapt to different workflows, different environments, whether that's on-prem legacy environments or pure cloud or hybrid cloud environments. So this is just one way that it's been used differently but we're seeing it used throughout the Red Hat portfolio and it's always been a strength with Amazon that we've always had a strong Amazon web services community within Ansible. Whether it's just traditional compute or even doing things in the serverless space, Lambda and moving beyond that, we're able to do that complete automation from end to end for them. As a Python guy, I've got a special place in my heart for Ansible, I quite like that thing. And I like being able to do things in a Python-y kind of way. So yeah, Golang, I hear people really like it but I like my Python. Yeah, but we try to keep that where users don't have to really know Python but that is what Ansible is underneath the hood and it is when you want to extend Ansible what you would use, but the vast majority of users don't really need programming skills. They're working with very human readable, declarative forms of defining the state they want their servers and their computing resources to be in. Yeah, Ansible is sort of historically is used for things like it's more of an infrastructure configuration tool but we've got service configuration now as well and something like OpenShift is much more application developer centric. So I'm seeing a real blending of those two kinds of people who are doing development. They're kind of two different forms of developers but now they're basically blending themselves together and becoming one team of like, do you see that as where development is going that pretty much everyone becomes a software developer? Well, I know from the Ansible standpoint we're continuing to explore and bringing that simplicity and power to all these different ways that we can adapt that and since we've joined the Red Hat family we're exploring all these different ways that we can work together and bring that type of value to its end users, to its customers, so. And what do you think at the end of the day when you say, we talked about customers and trying to meet demands and what have you, if you had to look down the road and say for the next six, nine months that this is what we're going to try to address or this is what we're hearing from our customers that they need attended to that you could provide help for, what would that be? Like what headache are people bringing to you right now to say to them? The headache? Give me a hand. Generally, the headache is a lot of people just trying to automate and make sense of all this legacy things that they've had and the issues where they've done things manually or before you had cloud native applications and how do they move it to a cloud native architecture like an open shift? So that's a lot of our focus. So it's, how do I wrestle some of these private clouds? How do I wrestle windows? How do I bring things into AWS? How do I do multi-cloud? Things of that nature. So it's how do I manage things that are when they're moving so fast and there's so many moving parts? And we give them that a single language that they can use for their automation. So you've got all this legacy work that's been done. You're trying to get them into the 21st or not even the 2018. And there's a lot of retroactivity that needs to be done there, right? But you've got to fix a lot of problems. The legacy hasn't gone away. They still need to automate and manage it. So we're very much a Swiss Army knife and it can cover a lot of ground in a lot of different environments. That's good to be handy. Yes. Nothing wrong with that. All right, gentlemen, from OpenShift, no, from OpenShift and from Ansible. Again, thanks for joining us. We appreciate the time. Thank you. Good guys, good having you here. We'll be back with more here from Reinvent, AWS, live in Las Vegas in just a moment here on theCUBE.