 All right, perfect. How's the sound? Testing one, two, three, testing one, two, three. Awesome, perfect. All right, so I'm here to talk about pulsing governments for Hybrid Cloud. So hopefully those of you that are in the audience are interested in that, if not too bad. I'm still gonna talk. So let's get started. So a little bit about myself. My name's Sebastian Stadel. I'm the founder of an open source project called Scaler. We have a booth over there in the back, if you want to know more at the end of the talk. And I'm also, I sit on the advisory boards, both at Google and Microsoft. And so I have, from the Scaler open source project, as well as from Microsoft Azure and Google Compute Engine, I have a fairly good visibility into what's going on in the cloud world. And a lot of the customers we have at Scaler are deploying cloud in a hybrid model. So I have really good visibility in what types of, what are the things and the problems that people are running into when they're doing Hybrid Cloud. So this is really a talk about that. And so let's get started. All right, so first of all, I'd like to start with some of the problems that we run into in the Hybrid Cloud environment. And the first is that when you start having, when you start deploying applications and you start having workloads that are across public and private clouds or maybe across availability zones, et cetera, you run into a problem where you don't have any centralized visibility into what workloads are running where, whether they're development or production, et cetera. And so what you have is you don't have central IT that has centralized control or visibility. That's a problem already if you're on a single cloud. It just multiplies when you start having components and tiers running in different clouds. So that's the first fundamental problem that we see. The second problem we see is that when you give your developers self-service access to cloud, when it's already a problem when you're 10 developers using cloud, but when you get to 100 or 1,000 developers that are all doing their own thing on OpenStack, on Azure, you start having a ton of discrepancy between what everybody's doing. Some people might be leaving VMs running on and some people might not be tagging everything properly. Some people might be opening up security groups to the world. And you, as the IT manager, you don't have like very good visibility over all that. So what happens to you, it just looks like a huge mess. And that means that if you're using public cloud, it's very expensive to keep stuff running all the time. It might be a security risk. It's really hard to manage all that. So that's the second problem. And the third problem that we run into in hybrid cloud environments is that you have to duplicate all the automation you're doing across cloud. If you have like a Jenkins pipeline, if you're building a Cassandra cluster, or if you're building like a Kubernetes, set of Kubernetes clusters, what happens is you're gonna have to build automation that deploys that to Azure, and you have to log into the Azure portal to do that. You have to do the same thing for OpenStack, same thing for all the different clouds you're using. So you end up having a lot of duplicate code. And that's a huge problem as well. So the Scalar Open Source Project tackles this in a couple of manners. First, Scalar offers a multi-cloud abstraction. We offer high-level declarative primitives that then map to all the cloud-specific workflows and cloud-specific objects. So you write against the Scalar API once, and then Scalar is in charge of translating those provision workflows to all of the different clouds you have. So all of the automation you're building for a specific cloud gets reusable and portable from one cloud to another. The second problem we tackle is when you've got a mess in an environment, you oftentimes wanna create rules to be able to put some order into all that. So Scalar has a very comprehensive policy framework which allows you to basically define by what rules your developers are gonna use the cloud. You might define some PCI environments that are audited in a certain manner. You might want to have some assistive stuff. And we'll get into that in more detail after. And the last thing is we tackle this with a very unique architecture which kinda looks like this. So this is the Scalar, everything here in red is the Scalar architecture, and it kinda shows you how all the pieces work together. So your end users, they talk to the Scalar Control Plane and they talk to that through the user interface or through a high level declarative API. When your end users hit the Scalar Control Plane, then what happens is we check that call those credentials against whatever identity framework you have such as Active Directory or Open LDAP or whatever you have that speaks to LDAP protocol. Once that authentication and authorization is done, then it goes to the second layer, which is the policy layer. So we'll check the user's requests against what policies you have set up in the system to be able to determine if yes, no, they're allowed to do that or if that request needs to be amended in some manner. After that, there's a whole bunch of other components of Scalar like building, provisioning, orchestration. There's also a desired state engine. All those are part of the Scalar Control Plane. Once that request comes in through the end user, then Scalar translates those to the cloud specific API calls to say public clouds like Azure or Amazon or to private clouds like CloudStack, but we're at the OpenStack seven, so OpenStack. Once those API calls are done, then that's used to be able to provision the infrastructure to run your applications. Now, larger organizations also want to integrate with third parties. So Scalar's got a very flexible framework based off of webhooks. So anytime there's a lifecycle event that happens in your infrastructure, we'll post a webhook. You can build your own handler, receive the payload from that webhook, and then integrate into HPCMDB, integrate into ServiceNow, integrate into all your stuff. You can pipe stuff into your finance systems, et cetera. So that's the architecture. So with Scalar, you get a beautiful user interface and a high level declarative API in this case here. This is an example of the Scalar dashboard, entirely JavaScript driven, it's very responsive. And when you can see here is at the top right, you can see that when your developers are provisioning stuff through the user interface, we'll surface the costs to them. So you're making sure your developers are always aware that whatever they're doing on public clouds or whatever resources they're using are actually incurring costs and just basically to empower them to make better financial decisions. You can also create a service catalog. And so it's kind of like Murano that was explained and introduced earlier today, except it's done in a multi-cloud manner. So anything that you define in the Scalar service catalog will be able to run on any cloud. And again, that's kind of ties into what I was talking about earlier, which is the portability of all the automation you're building. So in this case here, the service catalog that you can see has got some very popular open source software. There's lots of categories for your databases and load balancers. And you can create your own and extend that service catalog with your own stuff. All right, so let's talk about policies and governance a little bit. So what's unique in Scalar's policy model is that it's based on an inheritance model. So just like in the US federal government, you have federal law that applies to every state. You have state law that applies to every city and then you have municipal law that applies to everyone in that city. The Scalar inheritance model works the same way. You can define policies at the scalar scope that apply to everything below. Then inside of the scalar scope, you have multiple accounts and you can define policies at the account level that then apply to everything below that. And inside of accounts, you have environments in which you can set up policies that then trickle down. So you have this hierarchical policy system where if you're, for example, a big corporate entity, you can define policies at the scalar scope that will apply to everybody below you, but all your different lines of businesses might want to inherit, they will inherit your policies at the corporate level plus be able to add their own policies that are specific to that line of business. So that's one of the things that's unique to the Scalar policy framework. Another thing that's kind of like the Congress project from OpenStack, except in a multi-cloud manner, Scalar has reactive, assistive and preventative policies. I'll give a few examples of each. A reactive policy is when you want to allow your users to do whatever they want, so you want to be lenient with them, but you don't want to be careless. So you want to allow them to go out and provision whatever infrastructure you want, but maybe after a certain period of time of running some infrastructure, you might want to say, hey, well, do you still need that infrastructure to run? Because if not, we'll shut it down for you or we'll do that garbage collection. That's an example of a reactive policy where you're pruning out, you're kind of doing that garbage collection. So again, you're allowing your users to do whatever they want, but you're not being careless. An assistive policy is when you help your developers do the right thing, kind of setting up guardrails, if that makes sense. That's when, for example, you want your developers to always tag stuff. You don't want to have, now you don't want to carry around your whip and kind of like beat them into submission to never forget about the five mandatory corporate tags. So an assistive policy will, for example, tell Scaler that anytime some infrastructure is provisioned on OpenStack, it needs to have some metadata that specifies who provisioned this particular resource, what business unit he's part of, is this development or production, what project was he working on, just like that you as the central admin, when you're looking at how your cloud's being used, you have a really good picture of how everything's being used. So an assistive policy is really like that when you want to help your users do the right thing, and in that case, it's by automatically tagging stuff. The third category of policy that we have are preventative policies. And if you're in a very highly regulated industry, like if PCI compliance matters to you, if HIPAA compliance matters to you, that's when you want to be able to set up preventative policies that outright prevent a user from doing something. For example, you might want to ensure that you might want to create a workload placement rule that forces deployment of something into a specific OpenStack network. So you'd be able to create a Scaler environment that has only access to OpenStack in a certain network so that by default, all the infrastructure provisioning always goes in that network. So again, work workload placement policies. If you're building an application for the German market, you might want to make sure that you only have ADLs Frankfurt and your local OpenStack. So those are the types of preventative policies that you can create with Scaler. And the last type of policies that's very unique to Scaler is that you can set up policies that are either intra-VM or extra-VM. Intra-VM means policies that apply to stuff that's inside the virtual machine. So let's say in a production environment, you might want to mandate that there's some intrusion detection system installed on it. Or you might want to mandate that it's monitored with new relic or something like that. Those are things that you want to have installed on the system inside the virtual machine. So Scaler allows you to define intra-VM policies. There's also extra-VM policies, which allows you, like the webhooks I was talking about earlier, which allows you to integrate the stuff your developers are doing with external systems. So if you're using like a CMDB from ServiceNow, you can use the webhooks to create a policy that will automatically populate your ServiceNow database with all the infrastructure you're using, your users are provisioning. So that's an example of policies going inside the VM and now kind of outside the VM with third-party services. All right, so this is what the user interface looks like when you want to set up an assisted policy. You can see here where we have Rackspace, we're using Rackspace as a public open stack. We clicked on the metadata policy that allows us on the right side to be able to specify some mandatory tags. So in this case here, like every resource that's provisioned through Scaler will be tagged with the environment, the owner, so the person, that provision, that workload. Like what tier it is. And we can extend that with any key values, name values that you want. So you can extend that with the line of business, et cetera. And the idea here is you really want to empower your developers while establishing governance. All right, so to kind of wrap this up, I wanna repeat that Scaler's license under the Apache 2.0 license. It's all on GitHub. If you go to github.com.scaler, you'll get the full source code there. We have a booth right over there, booth S3 ironically, like the Amazon project. And we'll be happy to give you an in depth demo and kind of show you how, answer any questions you might have. So it'll give you any demos, et cetera. And the very last thing I wanna talk about is if you saw the keynote this morning, Jonathan Chang came in to talk about what NASA JPL is doing on OpenStack. Jonathan will be giving an in depth talk on their usage of Scaler, OpenStack, Azure, and Amazon. So NASA has this hybrid cloud deployed and NASA is giving a talk tomorrow, Wednesday, right before noon about how they've done hybrid cloud and how they've integrated with Scaler and SaltStack and all the other technologies that they have internally. So with that before I get kicked out, I'd like to thank you all for your time. And if there's any questions, I'll step off right here and be able to take them. But if there's any questions right now, just raise your hand. Good, all right, so I'll just step off and do that. Thank you so much for your time. Thank you.