 Good afternoon, everyone. Thank you for coming. Sanjay Mishra with Taligent. I'm going to walk through our product open book. That's me. Thank you for coming. This often ends up being the last slide. I want to have it up front and center just to say thanks for taking your time and coming here. A couple of highlights about open book and Taligent. Taligent is a software company headquartered in Austin, Texas. We have been focused on show back, charge back, capacity management solution for OpenStack since about 2013 with the Grizzly release. And recently, we've also added support for public clouds. And that's the main area that I want to focus on in this presentation. We have, I believe, the strongest and deepest support for OpenStack. And with our support for AWS and GCP, we're acknowledging that OpenStack typically doesn't deploy in a vacuum. It deploys within an organization where there's a mix of infrastructure that's being consumed. And so being able to provide that across the board single pane of glass view to that consumption is important. And that's been our goal with version three of our product. And then we're going to continue to extend that as we go forward. The key areas that we focus on. So self-service, OpenStack, there's a variety of ways in which OpenStack can be consumed. There's just a straight up API integration. There may be a pass type of interaction where OpenStack is the infrastructure layer. And then there's Cloud Foundry or something else as a platform layer. Or there may be a self-service experience that maybe needs to mirror more a digital cloud-like experience rather than AWS experience. And so from that last perspective, we support a self-service function that lets new users sign up for access to the cloud. And then once they have access, consume applications and databases and virtual machines through a more streamlined interface than, say, Horizon or something else. Spend management, obviously, that's our core. So a couple of aspects to this in a private cloud context. Collecting the raw usage data, applying rate to it, generating a bill or a report from it, versus a public cloud use case where that rating and billing and invoice generation is already done. But there's a need to pull that data over the calculated charges and then be able to represent them across an organization. So one of the other key things you can do through OpenBook is represent a structure that mirrors your organization and then roll up charges across those different types of infrastructure into that consistent view. So modeling business units, modeling applications, creating virtual tenants. So in AWS, for example, you've got a couple of different mechanisms that you can use to categorize charges. Either accounts and subaccounts in a master or subaccount billing scenario are tags. And through OpenBook, you can combine all of those and create virtual tenants. So you can create your own groupings or how those charges should be allocated. And then place them alongside your OpenStack charges. You can place them alongside your VMware charges and create a consistent view. Hybrid cloud support, obviously that's what we've been talking about. And then cloud operation, there's a rich management function that OpenBook supports as well. So from a capacity reporting perspective, from tracking trends of consumption, who are my top consumers? Which are my most highly utilized services? So as you can imagine, the usage data that we collect that feeds into the billing reporting also is very interesting and useful from a capacity perspective. And so looking at that consumption and that usage over a period of time provides useful insights from a management and operations perspective. So without further ado, let me jump over into the demo itself. So our product is OpenBook. There are two interfaces into OpenBook. This is the administrator view. It provides an overall visibility across the OpenStack cloud, across the public cloud integrations that you have. There's also a customer view. So through the customer view, you're looking at usage at your individual customer level or collection of projects. In this demo, I'm going to focus mostly on the administrator view and talk about that overall spend. So this is a dashboard. Dashboard gives you a mix of visibility into both capacity and spend. And so looking at these aggregates across the top consumers of CPU, RAM, and disk, but then also looking at your top spenders and your spend over time. So in OpenBook, we support, as I was saying earlier, a one-to-many hierarchy in who the consumer is. So the consumer being the tenant, or the account, or the project, and then the person or the entity that receives the bill, so the customer. So there's a one-to-many association that you can set up to roll up those charges. And that's how these get reported here. So these are customers who have OpenStack infrastructure. Here are customers that have AWS infrastructure, and then it breaks out those charges by that. Let me actually, I'm going to stay relatively technical in this and talk about what the integration looks like. So briefly, let me talk about connecting into OpenStack. We collect usage data from OpenStack from either the metering API if available, or if it's not, then we can collect that data directly from the service APIs. So the integration is lightweight, low impact. We don't install anything into the OpenStack cloud. So don't install agents, collectors, et cetera. Everything we do is through the external API. And we support pretty much any flavor of OpenStack that's out there. We currently, all the major vendor packages, Marantus, Red Hat, Canonical, Platform 9, Susa, Trunk. And then we validated up to Metaka. So there's support for Keystone version 2, Keystone version 3. The integration requires access to the Keystone Admin endpoint. So that's one consideration as you think about deploying this. OpenBook can deploy either on a set of virtual machines or on a set of bare metal or equivalent machines within the OpenStack cloud itself. And wherever you deploy it, this issue of being able to provide access to the Keystone Admin port is an important consideration, sometimes from a networking perspective that may or may not be available from the tenant cloud. So just something to keep in mind. That access is what gives us visibility across all projects within the cloud. And then, excuse me, beyond that, pretty much any service that's commonly consumed in OpenStack is available for reconciliation. And our view of this, we have a metadata-based billing model. So as we reconcile these service instances from OpenStack, we also bring over a collection of metadata associated with it. And that metadata lets you define products around it and set up a billing scenario. We also support metric-based billing. So these are salameter metrics, things like bandwidth or certain types of storage. Or I don't know, you want to build people for power usage. There's a salameter metric for that. And you can take that and build a billing model around that. In addition to that, we also generate a set of metrics within OpenBook itself. So quota metrics, what we typically see in OpenStack is there are multiple levels of granularity or resolution that people may want to bill for. So one scenario is, I just want to bill for quota. I want to bill for what's been allocated to a project or a tenant. Don't care about what the actual consumption is when I've allocated quota to someone. They're consuming a set of resources and they want to bill for that. So that's a set of metrics that we collect and generate internally within OpenBook. On an hourly basis, we see what the quotas are for projects. And there's a set of synthetic or OpenBook-generated metrics that represent quota items across compute and storage. Beyond that, the most common billing scenario is billing for, say, compute by flavor and billing for storage by storage type and then billing for floating IPs and load balancer and so on on a monthly basis. So that's based on the services itself. And then there's the billing for metrics. So one of our customers actually bills for CPU hours. And so there's the CPU nanosecond metric that Solometer provides, taking that, rolling it up into an hourly value and then billing based on that. And then these stats control what the capacity views look like, and I'll talk about that in just a second. So that's the OpenStack integration. On the AWS side, if you've worked with AWS, this will look familiar to you. So AWS provides a mechanism to export the cost data to an S3 bucket, and that's what we connect into. So there are a couple of steps, the documentation is on our website, to set up that export to the S3 bucket and then you point us to that. And then this is the interesting part down here where you can take any combination of account ID or tag and define a virtual tenant structure based on that. So obviously those are the two common scenarios that exist for tracking costs within AWS. Either there's a master account with sub accounts or there's one account with tags in it, or a combination of both. So you can set up a fairly granular and tiered hierarchy based on those combinations of values. And so what I've done here, in this case, I have a master sub account scenario and I've taken these account IDs and I've mapped them to a customer within OpenBook and then I've created these virtual tenants. So Eric and Sanjay are labels that I've applied for these accounts within OpenBook and that's how charges show up. And then finally, GCP integration. So this is, again, a lot of JSON there, but that's the integration mechanism that GCP provides and in GCP it's similar to the master and sub account. And so they're projects within GCP. You can create a multi-level hierarchy within GCP itself and then we can pull that over and then map that over to OpenBook. So what's the end product of all of that? Let me see if I can pull up a sample of what this report looks like. So here's an example of a bill or a report that shows both OpenStack and GCP charges side by side. So in OpenStack, I'm billing for compute based on flavor and I'll take a second and walk you through what it takes to set up that OpenStack instance small example. So I'm billing for floating IPs for I'm billing $5 a month per floating IP. I'm billing for instances on an hourly basis, 25 cents per hour, this is an expensive cloud. And then on the GCP side, I've pulled over the raw usage and as I showed you in my example, there's a virtual project or a tenant that I've created called Eric and then if I scroll down, there's Sanjay and then whatever the usage is in GCP network and compute, we're pulling that over and categorizing it. So there's a set of mappings that OpenBook does automatically based on these charges from the public cloud environments. You have the ability to tweak that. It's a rule-based approach and so flexibility in categorizing and mapping those is one of the strong features in OpenBook. Let me see if I can pull up, yeah, similar thing. So let me jump over to what it takes to set that up. So as I was saying earlier, in OpenBook, we support a metadata-based billing model and so let me pull up the OpenStack instance small that I was just looking at. And the way the flow of the process or the data is through our integration with OpenStack, we get the raw usage data. So instances being created, modified, deleted, that is brought over automatically through a reconciliation process and then when an instance is created on our side, there's a set of metadata that we bring over with it and any of those metadata attributes are available either for classification or for billing. So there are a couple of examples that I've got here. In this case, I'm just saying bill for an instance based on hours and existence or you have the option of billing for it based on hours powered on or hours in use and then I'm classifying this as a small instance based on the flavor attribute. I can add additional metadata attributes here and I could say if this is, if image contains, say rel, then this is a OpenStack instance rel small and so combining these attributes and being more granular lets you bill for, so rel and windows where you might have a license charge versus CentOS or Ubuntu where you don't or I mean, regardless, it lets you classify those and be more granular with that. So this is taking your services, classifying them into products and then the next step in being able to bill and generate an invoice is to define a rate plan and rate plans are collections of products with charges associated with them applied to certain types of instances. OpenBook supports two types of billable entities. So customers and resellers, there's a reseller model within the product as well. So when you define a rate plan, you have to, you say whom applies to, does it apply to a customer or a reseller, which currency does this apply to? Customers have currency or resellers have currency associated with them. So you can have multiple rate plans within the product. Those rate plans can be differentiated by whether they're the default rate plan, you can create individual rate plans for customers and assign them directly to a particular customer and you can vary rate plans by currency. So with several customers that bill in their home geography and the local currency and then everybody else in US dollars, for example, and then there's a rule-based approach that can assign that to customers and pick a default currency and a default rate for them. And so this is the final step in setting this up. I've selected my products. There's both a billing based on hour and month flat rate and then there's a tiered billing scenario that OpenBook can support as well. So for example, with bandwidth where the first 10 gigabytes might be free, 10 to 100 is at a particular rate and then more than 100 is at a different rate. That's an example here where I've got this configured to bill on a tiered model. See, hot word. And then everything else, I've added the product. Let me select this. So being able to vary the rates by region, being able to vary them by state and obviously depending on how the product is configured, being able to vary it based on time granularity. So hours or minutes. Before I close, let me also touch on the other aspect of the product that I talked about earlier, capacity reporting. So in reporting on capacity, primary focus is on OpenStack Compute in this release and so there are multiple levels at which you can look at available capacity and usage. So this is an overall view across either all your clouds or drilling down into a region or a cloud. And so this view is showing me my overall availability and usage by CPU, RAM and disk. Explanation for these charts. So the blue line shows me the actual usage by day. There's years worth of data that we maintain within OpenBook by default. That value is configurable physically as much disk as you want to throw at it. You can keep as much history as you want. The blue line shows actual consumption. The dotted yellow line is the available resources at a physical level. So what's the actual number of cores or the actual amount of memory across my host? And then the red line shows you what your hard limit is based on your over-commit ratios. So if you remember earlier when I set up my integrated, when I created my service manager to connect into OpenStack, one of the options that I have is I can configure the allocation ratios across those different clouds and so that value is used to display that chart here. Drilling down to another level of detail. So this is showing the usage and capacity at an individual host level. So these are the hosts in my environment. Anything that's green is less than 60% utilized. Yellow is 60 to 80 and then anything more than 80% is red. Any of this data can be easily exported. So if I just click on the Excel button here, here's this raw data and if the presentation or the reporting that's available in OpenBook is not sufficient, you can easily export this and do more with it outside of here. It's a small demo environment so not a whole lot of data but this view shows me my allocation by host at a VM, at a physical machine level. So this is showing me how my CPU and RAM is allocated across the hosts. Let's see if I've got more data, same thing here. So this is an individual host in the environment. If I drill down into it, here are the VMs that are installed on that host and this is the available capacity on that host. So this view is in terms of CPU. This other view is in terms of RAM. I'm clearly, I've got a little bit of a disconnect here in terms of how my CPU and RAM are being allocated. I'm over committed on RAM. Got plenty of headroom on CPU so maybe something I wanna tweak. This service consumption trends across OpenStack services, it shows you what the usage has been over time. So these metrics and these aggregates that are displayed here are configurable. The amount of time for which you use this data is configurable as well. So showing you usage across the OpenStack services over time and then another way in which this is useful to look at is to look at the usage and aggregation across projects and tenants over time. This is a popular report that tends to get distributed within the organization. So here by cloud, by region and then by customer within that region and then by project, I'm looking at my consumption over a six month, three month period and looking at these services and what the trend has been. And again, this is also easy to export. So if I drop this out, here's the view, it's a little cramped there but these numbers are easy to share and distribute within the organization. Last thing I wanna do, am I out of time? So OpenBook has a rich and complete REST API around it and the specifics of the API are documented within the product itself. You can navigate to slash open book slash API doc and so if I, several of the details that I was looking at, so if I wanna look at my invoice history, I can just run this here and this is the, let's see. Okay, sorry, just very quickly, I'm gonna throw this up here. Demo gods have decided to stop smiling on me but anyway, this is the REST API, all the details on invoking the API, output, et cetera, all available through the product. Makes for a very easy integration beyond say the exports to Excel and so on. Thank you very much.