 Hello everyone good afternoon, Sanjay Mishra with Taligent and I'll take about 15 minutes to go through our product open book Leave five minutes at the end for questions One housekeeping item. We're giving away a hat at the end of this presentation So put your business card in the hat will have a drawing afterwards and you get to win very nice Stetson at the end of this So Taligent open book We're focused on show back charge back billing and Capacity reporting for open stack clouds our primary focuses on open stack We also acknowledge that this is primarily still a hybrid cloud environment and so from that perspective We also integrate with VMware and are able to collect usage data from vCenter servers as well as with AWS so We can collect AWS usage data, and then we have a mapping scheme within our product that lets you take AWS usage VMware usage open stack usage and roll it up under a customer and project hierarchy and produce a Consolidated bill of cloud usage across those different flavors of infrastructure So I'm going to focus primarily on our administrator interface. We have two views into the product The admin interface is targeted towards the cloud operator the financial user So the the team the individuals setting up the integration into open stack setting up the integration into VMware into AWS Defining rate plans and products Setting up customers setting up the billing scheme for customers the customer to rate plan assignment Looking at invoices distributing invoices or reports and so on and then obviously a reporting function and an Analytics function there is another interface for the product that's targeted towards the customer or the project user showing usage by customer and project Given the Short period of the short amount of time that we have I'm not going to spend a lot of time on that if you'd like detail on that Please follow up. We have a booth towards that entrance and welcome to stop by and dig deeper into the detail So there's a dashboard view that gives you an overall view of spend and consumption across your cloud Looking at your current on bill charges the system calculates on bill charges continuously And so at any point in time you can come in and get a view of Unbuilt charges across the entire cloud by category by customer by tenant invoice history 12 month totals In getting into the details of the the billing the rating the the reporting Let me start with what the end product of the the the entire Function within the software is so this is a sample invoice. It's generated for a customer called marketing and I wanted to talk about just the the ability to take multiple open stack projects roll them up under a customer So in our view a customer is who receives a bill for usage And then projects obviously are the the container within open stack resources within which open stack resources are being consumed So within open book open book manages customers open stack manages projects within open book You can create a one-to-many hierarchy of customers and projects And and consolidate billing and usage across across multiple projects So in this example, I have I have usage broken out by open stack region This customer has project admin Cloud Foundry and trial rolled up under them and then within those projects We're keeping track of usage across pretty much anything that can be provisioned or consumed with an open stack So any open stack service can be translated into a product. We have a metadata based Billing model where you can take attributes for service instances as they've been created and define products based on that I'll go into that in a little bit more detail, but just to Talk about the things that we can bill for and how we bill for them So floating IPs. I'm billing based on a five. I'm charging five dollars a month per floating IP So we're keeping track of the floating IPs provision and how long they were in existence Images billing based on a gigabyte month basis instances billing on instance hour This can be quite a bit more fine grained in that you can define small instances medium instances and so on and as we talk about products I'll talk about that in more detail load balancer rips again billing five dollars per month Volumes. I'm billing based on a gigabyte month metric. So again as part of our integration with open stack we're keeping track of Resources being provisioned resources being reconfigured And and then applying the rate to that to produce the the final invoice We we produce invoices the default behavior is to produce invoices on a monthly cycle So on the first of the month invoices slash reports depending on the context that you're in Get generated and and they they span across a month period Before I leave this let me also throw up an example of what a consolidated invoice would look like or a consolidated bill would look like if you Were combining usage from within your open stack cloud as well as usage from AWS So this is a customer that is That has projects in both environments. So my AWS usage again is shown by region. So here's my AWS US West region multiple projects within this within this customer. So in open book you can take AWS accounts and Tag names and tag values and use those in any combination to define a customer and and tenant or a customer and project mapping or roll up within within open book So for our example, we just these these are tenants that are defined within open book We're taking AWS data and and recategorizing it this way in this context. We're obviously we're not providing a rating function We're taking data charges as they're precalculated by AWS and presenting that single pane of glass that consolidated view Across all your your different environments. And so here my AWS usage is broken out again by category of spend multiple projects within here and Similarly if I scroll down, here's my open stack usage now. This is an open stack project and I'm billing for floating IPs within open stack So what what does it take to get this going and set up? The first the first step once open book is installed is to configure the integration into open stack So let me pull this up Service managers are our term for the wrapper around a data source. So an open stack a set of open stack API is an AWS Bucket VMware vCenter Server all of those represent service managers. They're sources of data basically within the system Couple of points to note one installation of open book can connect into multiple open stack clouds You can connect into multiple vCenter servers. You can collect connect into multiple AWS endpoints So there's a multi-tenancy built built built into the product in that way So for our data collection We have a Very low impact lightweight integration into open stack all the data that we use for our billing and reporting functions We collect through the open stack APIs. So we we ask for access to the Keystone admin port Keystone admin user a member of the admin project And then beyond that we we discovered the rest of the service catalog and can connect into the service API Is if salameter is available in the in the environment we can collect data from salameter in the absence of salameter We can still support 90% of the use cases that we typically encounter for from a showback charge back perspective so billing for Services as their provisioned as they get reconfigured as they get deprovisioned all of that is available in either scenario without salameter Some of the metric based billing so things like billing for bandwidth or billing for CPU hours Those the the units as they're as they're provided by salameter metrics those obviously have a dependency on the on the metering API There's also an option to push metrics directly into open books. So you can define custom metrics. We have a rest API Rich rest API. I'll touch on that very briefly You can push metric samples directly into open book build a billing model around that So bandwidth for example is a common thing if the neutron metering agent is deployed and salameter is available Then we can we can consume those metrics If not if you're collecting bandwidth metrics elsewhere, you can push them directly into open book and and bill based on that So beyond that the integration we support keystone version three So in a keystone version three context you can scope the data collection down to a particular domain If you have multiple domains that you want to collect data from you set up multiple service managers and span across the environment that way and then Anything for the most part that can be provisioned in open stack can be reconciled into open book and can be built for These are the services that I'm collecting data for in this context if open stack I mean again if salameter is available. I can I can collect metrics as well We have a rich set of metrics that we can pull over from salameter any of these is available simply for a reporting function If that's what you you want to look at metric aggregates by tenant over time And obviously for billing as well And then here's the option where you configure how you want usage to get rolled up into into customers and tenants So you have the option of either having open book automatically create customers for tenants as they're discovered in open Stack or you can you can do a Mapping within the product to define the roll-up and I'll talk about that in just a second and then how do you want to? Collect data from open stack. Do you want to collect it from the metering API or directly through the service APIs? Having done that the next thing you might want to do is define a project to customer mapping So customers again as I mentioned earlier are owned by open book. They're an open they're an open book Construct these are the open-stack projects and I've just defined a mapping So I'm rolling up all of these projects under the customer sales and I'm rolling up these two projects under the customer IT You can change this at any time When you if you change this during a billing cycle then the usage Over partial periods get out gets allocated appropriately depending on when the change was made So I've set up my customers. I've set up my my integration to open stack I'm collecting usage data the next step that I would typically do is to define my products So products layer on top of either services or metrics and as I mentioned earlier We have a metadata based billing model So you take services and and metadata values and define products around them, right? So in the most I got the most interesting example might be billing for compute So we see multiple models out there billing for instances by flavor and image tends to be the most common And so here's an example where I've defined Products corresponding to the different flavors. So I've got medium and small open-stack Instances and the way that these are configured they build upon the base open-stack instance service And I've defined a filter that looks at the flavor metadata attribute and classifies it appropriately depending upon the value so medium flavor medium equals a medium open-stack instance and then similarly right that should say Flavor small would correspond to to small instances another model that we commonly encounter is Splitting apart these configuration values and billing for them individually So we have some customers who want to bill for CPU RAM disk and image as Individual attributes and so in this context I have products based on those billable attributes And the way that this gets configured is I choose one of those Numeric values as a billable attribute. So in this scenario, I have vCPU setup as a billable attribute I'm counting up the number of vCPUs. I'm keeping track of CPUs of Instances being resized up or down and updating this value appropriately and then the end of the month There's a charge per vCPU for the month, and that's the that's the billable metric similarly for Storage billing by gigabyte month and so on and so configuring products depending on what the what the appropriate Combinations are for metadata attributes and then the final step is defining a rate plan So with an open book you can have multiple rate plans the elements by which rate plans vary are Whether they apply to a customer or reseller we support a reseller model where you can have another level of Another layer in the hierarchy where resellers have subsets of customers under them subsets of projects They can set their own rates. They can define their own products. They can manage their own customers so For in billing for resellers We aggregate up the customer usage and generate a bill based on that for customers the other Factor by which rate plans vary is currency so we support multiple currencies within the application and the way that we handle that is by matching customer currency to The rate plan currency so customers onboarded they have a currency associated with them when it comes time to calculate charges We either look for a default rate plan that that matches the customer currency or an Explicitly assigned rate plan so you can actually set up individual rate plans by customer if appropriate and Very the rates that you're charging customers based on the rate plan that's assigned to them so in setting up the rate plan You're basically pulling products in you're choosing what state you want it you want to bill for so Everything other than compute has the state of just being in existence volume has been provisioned it existed for a certain amount of time I'm billing for that compute can have the additional state of being powered on or being in use And so you have the ability to to be a little bit more granular in that context and only billing for Compute instances when they're powered on Beyond that you can vary rates by region so US West you have one set of rates US East you have a different set of rates London Singapore you have different rates And so you can you can decide how how you vary your rates by by region and then my rate And so when it's all said and done you end up with something that looks Looks similar to this. I'm I'm tracking usage. I'm applying the rate and I'm calculating a charge Let me briefly touch on the API So everything that that I can do through the UI obviously is available through arrest API. We take an API first approach As it currently stands the API is actually richer than the API and then the UI so just as an example This API documentation is built into the application if you navigate to slash open book slash API doc It's all here and and you can actually exercise the API directly through here So if I click on invoices and I want to get my invoice detail one thing that we see commonly is Open book does the rating and the invoice generation, but something else does the invoice presentation Maybe you're in a context where there's there's a whole set of services that Beyond open stack that's being consumed and so we can provide the rating function We can provide the invoice generation function But the actual invoice invoice presentation the payment processing and so on maybe happening elsewhere And so this API supports that kind of that kind of integration So if I wanted to pull all the invoices for the marketing customer, I can run this call through here Here's what it would look like if you Invoke the this API endpoint through curl. Here's what it looked like in terms of the actual URL And then here's the detail. It's Jason And I've got invoice header information. I've got invoice detail So you could take this and and and render this in whatever way you chose You could also use this to drive dashboards within other applications that you have or even Integrated into horizon and have a billing panel that's showing usage by customer by tenant by region, etc Full set of functions pretty much anything like I said I mean everything that's available through the application is available through the API So we we think of the API as a product in and of itself and and pay a lot of attention to Its functionality and its its usability Down to three months, let me Just quickly skim through some of the capacity Reporting capabilities that we added recently so our view is the the complete history of activity within the cloud that we're Collecting to drive the billing function is also very interesting from a from a usage and consumption and trend perspective And so think of the the capacity reporting that that we that we provide as another view into the same data set So looking at your overall compute capacity either across your your full environment or by by by cloud in region The legends here if this is visible so the blue line is showing me what my usage is the orange the dotted orange line shows me the the actual CPU or RAM on the machine and then the red line is my my hard limit right from a scheduler's perspective That's taking the over allocation ratio into account and that's showing you what the what the total available capacity is looking at it another way by host so Drilling down an individual host level seeing where things are standing in terms of CPU RAM and disk Looking at how the scheduler is doing his job. So how are VMs being allocated across hosts? This is it's a small data sets a You know, obviously it would be a richer view with with additional hosts in there But these are individual hosts at the the gray area is the available capacity The smaller boxes are the individual VMs and if I drill down I can see this in a little bit more detail So individual VMs on the host how much CPU or how much RAM depending on which metric I'm slicing this up by Is is being allocated and what's available? I can play with this I can do some degree of simulation and forecasting. What if I change my allocation ratio on RAM to 1 to 1? What does my available to? To used capacity look like What if I played with it in the other direction? What if I allocated my RAM 1 to 2? What does it do to the the usage and and and consumption across the environment and same thing like let's say I I Change my CPU allocation to 1 to 10, you know, get really aggressive with it service consumption trends give you an overall view of consumption across time so My current snapshots across open stack services and then we by default maintain a year's worth of trend data So looking at what my consumption trends have been over time And and seeing what's growing. What's what what might be shrinking and then finally orphaned infrastructure gives you solves kind of a source of annoyance with an open stack you could delete a project if you haven't deleted the resources within the project they kind of live out there as orphans and Most folks have some process for dealing with that in case you don't This is a view that shows you everything that exists within open stack that doesn't have a tenant associated with it There's some additional filters that we apply to it ports by default don't have tenant ID associated them So we drill down a little bit deeper But the idea is everything that's not owned by a tenant and is most likely a candidate for cleanup and deletion Last thing I want to touch on in the 30 seconds. I have remaining is it's just the customizability and the configuration within the application the application lends itself well to white labeling and branding so setting your company information The logo the application name that you want to display here We support payment processing we can we can integrate with PayPal Stripe, etc Customizing currency codes we have a customer who to avoid the politics of dollars and cents They have their own currency unit and that's what they charge customers for in a private cloud context So you can define your own currency unit and and charge people for those Country codes customizing the emails that gets sent from the system Changing the templates and so on so at the end of the month an email gets sent to customers with their invoice You can change what that looks like and so on Wow right on time. Thank you