 Yeah, so I'm just going to throw out a few statistics here and things that I thought were very interesting About the just the adoption of the container space and and Kubernetes So first off just Docker con. I got struck by the numbers of applications that were Containerized today and the number of things that were happening Just such an active space and data dog Actually had a an article where they talked about the adoption over this past just the past one year and the increase in the number of Docker images that were being used in production and Right scale very much the same and I like this metric because I felt like this targeted very directly an enterprise space so But then the one that really really impressed me was From the CNCF survey where it looked like with just just native adoption of Kubernetes about 63% of those workloads were ending up on AWS. So looking at that information and and a Strong effort that we've had over quite a long time now with red hat. We were working on putting together more of a picture for what OpenShift looked like and Kubernetes was Getting this wider adoption across not just enterprise business, but a lot of mid-market business and a Lot of it a lot of strong enterprise businesses So we knew that OpenShift was being adopted and there were a lot of customers that We were hearing about and the customers that we knew talking to like Amadeus and then we saw, you know Hybrid environment strategies like the one inch skipple and adoption by groups at Samsung For OpenShift so What sets the AWS environment apart we think that's the security model just the number of services that are available for integration and The experience we have millions of active customers every month The global footprint being able to deploy and go global in just minutes the integration of New tools and new technologies like artificial intelligence just right there a growing ecosystem specifically with partners partners that are already collaborating with red hat as well so working over the past Year or so This was announced at summit that we were working on an integration of the The open service broker API through our collaboration with red hat and In our joint work we put together a group of Services that were natively available to Red Hat OpenShift customers Through the the OpenShift console That work is built around the OpenShift Ansible service broker and The collaboration work we did there was that cloud formation templates were created and then In the framework of the OpenShift Ansible service broker those are deployed on behalf of the developer so You've heard Paul Maury talk about this right so so we wanted the the the conversation to change Normally a developer would have to ask an operations person to retrieve specific products or services for their use and they're in their Organization or their product their project and and We wanted to make sure that This was a seamless practice built or Seamless integration that was built on the best practices in those cloud formation templates so that we were using Ansible and cloud formation in tandem to provide a way to not only stand up those resources, but then to Cleanly remove them when that resource was no longer necessary So that was the focus of the work that we did here in Our collaboration anybody can stand up an s3 bucket, right? But but can you make sure that when when you're finished with it you remove it? Does it feel like it's native in your OpenShift environment? So a lot of that work went into Building a Immediate user experience so that Not knowing everything about the command line You might be able to use those service brokers immediately from the console so I'm proud of this photo because it shows that a lot of this work was done Using OpenShift origin to so there were 10 services that we focused on so if you'd heard Any of the Open Service Broker API discussions early on they talked about one of the first surfaces for attack was The database so RDS or our relate the Amazon relational database service was one of our first first projects for adoption so Early examples of the Open Service Broker in in action show the RDS MySQL being used but then other analytic services like Athena Amazon EMR and Amazon Redshift all have become part of our first grouping of tools available they're exposed today through the service broker API So We're all the rest That's what you want to know Well, we want to we do want to eventually you know in the fullness of time We would like to see all those services in the Open Service Broker But we would really like to work on them in the order that is most Efficient for your your use so we're looking forward to getting feedback on What should be next in the adoption line? So we think this offers you incredible agility inside of the of the the infrastructure So we'd like to see how you use this and Get more go get more detail. You may have noticed that I had just a few statistics The reason I don't have any statistics that show open shift is because I need to hear more Information from the users. I can't see what you're deploying. I can only see that it's been deployed. I Know there are millions of containers out there millions of images that are being deployed and I'm sure there There is a very large number of open shift deployments out there And I'd love to hear more and more feedback from you about how you're using Red Hat open shift or open shift origin in the environment. You have a global footprint. You can deploy pretty much anywhere We feel like we have a great shared security model so From the from the instance up from the host up We know you're using open shift and you're using your own tools to Secure your environment and we're handling that from the instance down with multiple industry certifications and Best practices for security there and again this partner ecosystem that we have includes basically everything that's in the The Red Hat suite, but also we have thousands of partners who are there both technology partners who are Adding Software and machine image Products and services inside of AWS, but we also have consultancy partners who are adding value on top of services like open shift And I'm sure there's some consultancy partners here in the room who can who can deploy open shift as well But one of the things that we wanted to do for new users is to find a way for them to without having to be an expert in Amazon Web Services you remember I remember tell us saying gentlemen from tell us saying that they had only a few people inside of their organization who? Were AWS experts? I'm sure they only had a few people who were open shift experts as well But we want to make sure that we're empowering people in organizations where they have neither or one of those expertise in a very quick way, so Inside of Amazon we have The AWS quick start team and the quick start team is built it or it's made up of partner solutions architects similar to myself, but Also a whole host of people out from the community who integrate and collaborate on those Those quick starts so that they can understand better how they run and make sure that they run in the best possible way and we wanted to make sure that Customers could quickly and efficiently deploy an open shift environment of their choice for experimentation and then with a single click and in the cloud formation console Roll back the entire implementation So this this work this represents basically the architecture that gets deployed This architecture is based upon the Red Hat reference architecture and we worked pretty closely with Scott Collier and his associates from the Red Hat reference architecture team and they in turn worked in tandem with the OpenShift online team to find best practices for deploying OpenShift in AWS and that included some interesting things like leveraging the elastic the elastic load balancer as a way to Balance load for the application nodes and also to provide a front end for applications that are deployed as within your projects So You'll see on here that we used serverless functions We use the serverless function to ensure that we were getting the SSH credentials across to each one of these individual nodes And and we generate auto generated those credentials and the reason we use that serverless function outside of of the OpenShift environment was because that gave us an opportunity to do the full cleanup So we're deploying that stack that stack is fully functional, but then the wrapper around that is native functionality So with this you can stand up your own environment So we've iterated over several versions of OpenShift right within the Kubernetes family and and we started with 3.2. We went to 3.3 We were using a partner to do some of that work and at 3.3 we made the decision that the collaboration work the collaborative work that we did in with the Red Hat directly with the Red Hat OpenShift team the Red Hat Ansible team and The Red Hat reference architecture team was much more valuable so In the OpenShift 3.6 version we released that together and and that became our standard So that's still around today So looking forward Our hybrid team is going to carry this our partner hybrid team is going to carry this into the OpenShift 3.7 where we'll incorporate the AWS service broker some native logging and metrics and Changed some things about the way that that that we use Route 53 for DNS and One more thing that I'm really excited about which is We have a best practice for scaling out nodes that was put together by the quick start team. So I Say quick start team, but really this is one of the great things about the scaling model This is for scaling nodes. So we're we're not just scaling The the application knows we're actually scaling the master nodes So if necessary we can do both in in a self-healing kind of fashion Just can't lose that CD The the other thing about this work is that this this commit I've pointed to on the or the pull pull request that I've Pointed to you on the slide. This was done by Andrew Glenn who is one of our support engineers So not only is the quick start team collaborating with members of support But support has also built a community of practice around OpenShift and is getting a much better understanding of how to how to work with it so the the Community of practice is starting to extend out into into the organization as a whole and that is I think very exemplary of a strong commitment We've made over the past year to ensure that we have better red hat support all the way around so Working with with all these teams and with the services around this in the cloud formation templates I think we're building better practices the OpenShift Team we work with we work. We typically commit to to repositories and GitHub And we have very much a social experience where we're talking about what it is that we're doing we're We're passing back and forth communications around What we think are the best best next steps and And then we're we're passing a lot of that information over in front of the Ansible teams and letting people like Ryan Brown Give us their suggestions so that we can meet some of the demands. So some of the interesting demands we we found in in building the auto scaling models Were that with our life cycle hooks We had about four minutes to finish our job and that didn't necessarily always jail with the time Necessary for the Ansible scripts to to play out so In using those Ansible scripts we are in improving those Ansible scripts We worked with the Ansible team the red hat Ansible team To provide their feedback and improve those OpenShift Ansible scripts We're using cloud formation templates as a basis for the quick start we're using identity and access management to to do fine-grained security around those specific specific elements of the of the environment so that we can You know maintain the least privilege We're using the virtual private cloud to ensure that the end the the deployments that we're doing are As localized as possible and non-routable where necessary But routable where where you require your applications to be exposed Specifically through the ELB And then we're using serverless functions. They are native for serverless functions to support the deployments so If you're really interested now, I'm going to pay the bills for a minute If you're really interested in doing a proof of concept for this We would like to have to help you with that to participate in in our POC program We're doing this jointly with the the red hat team and the AWS North America solutions architects are full first point of contact so if you can if you're interested in In in doing a deployment for yourself Let us know and we will work with you to ensure that you have everything that you need to get started credits for your deployment and temporary entitlements and with that that's All I have to say