 Hello everyone. Good evening. I'm Sanjay Mishra. I'm with Taligent Corporation, and I'm here to talk to you about Open Book, which is a rating and billing solution for OpenStack environments. I'm just going to walk through the product itself just to give you a sense of what the product does and what we're aiming to do. For those of you who might have attended the Solometer presentation yesterday, if you saw the three-part slide that talked about what Solometer does and then what follows beyond Solometer, metering is what Solometer does. We sit behind metering, and we aim to provide the rating and the billing component behind that. In talking to folks here, in talking to folks prior to this event as we were developing the product, we heard a lot of feedback about the gory, murky process that happens in between having metrics on the one hand and generating a bill that goes to the customer on the other hand, and that's the part that we aim to solve. We would like to be able to provide a solution that takes metric data, lets you apply cost to it, and then generate a bill that then you can present to a customer. Our typical deployment is as an on-premise solution. We're a Java application running on Tomcat with a Cassandra database sitting underneath it. Let me just dive in. I'll log in. I'll walk you through what some of the key features of the product are. Thank you for coming. I should announce, I've been asked to announce that at the end of this, we have a drawing for an Apple TV, so stick around till the end. If you stop by our booth earlier and put your business card in the jar there, then that's what we're going to be drawing from. My main focus is going to be in talking about our OpenStack integration. We integrate with VMware as well, and we have a Hyper B integration in the works, but clearly at OpenStack today we're talking about OpenStack. One of the things that we provide in an OpenStack environment is the ability to define a rich, multi-layered, anterior organizational structure and then to take the OpenStack clusters or the infrastructure and map it into that. As you look over here on the left, BNCC Corporation is just a test environment that we created. Within this, you have the ability to define multiple layers. Whether it's by geography, whether it's by business unit, whether it's by application group, you can define what we call resource groups. Then when you come over on the OpenStack side and you import an OpenStack tenant into the environment, then you can either bring them in as an individual customer or you can take these tenants and import them in as resource groups within an existing customer. This is just the cloud admin view. This is the view for somebody who has visibility into all the tenants in the environment. We have a full role-based security model. As you set up a tenant, you can define tenant admins for individual tenants and their view as they come into this portal is restricted to that one tenant. Then you can further refine what they can or cannot do by granting them permissions. Anyway, the dashboard is just giving you a sense of system activity. Switching over to the administration side, give you a sense of what it takes to actually integrate with an OpenStack environment. This is about the extent of what we ask for. Server name or the host name, the API endpoint that, say, the Horizon dashboard would connect to, and then the credentials that you would use to log in through Horizon to look at the entire environment. User ID, password, the default domain, and so on. At that point, we're connected. Once we're connected, we pull the metrics that are available through Solometer. Our current integration is with Solometer version 1, and we're working on moving that over to version 2 because of the significant differences and improvements that have happened between version 1 and version 2. So through Solometer, we're getting all the data on changes to the infrastructure. So as managed entities, meaning instances or networks or port submits, as they get created, destroyed, changed, we pick up that data, and at the same time, we're also picking up the utilization and the consumption data. So measuring how much CPU is utilized, measuring how many bytes of network traffic are being generated from an endpoint. So this is the list of metrics that's being collected in this environment. We're collecting all of them. You have the ability to fine-tune that and restrict that to an error set if you so choose. That's one set of data. Once you have that, you also define what we call billable features. And billable features are just the things that are either provisioned to a customer or the resources that are being consumed by a customer and that you want to bill on. So in this case, we have the OpenStack entity set up as provisioned features. On the other hand, you also have the actual utilization data that you can measure on. So we have two classes of entities that you're billing on, just either managed entities, infrastructure elements, services, or the actual utilization data. So in setting up one of these, I'm just going to use a VMware example just because it's a demo environment and the OpenStack stuff is not exactly good working in this case. But so you choose a metric, you define what frequency you want to measure that metric and how you want to charge for it. So in this case, you're still setting up the environment and you're setting the defaults that you want to charge users for. So say for CPU utilization, in every five-minute interval, you take a measurement and you define what you want to charge. And so this is the initial setup. You've configured what you want to charge. And then as the final step, you define what we call a rate plan. And the rate plan just sort of brings everything together in terms of your charges and then lets you assign those to customers. So one of the key things that we did not want to do in our implementation was to lock you into a particular way of billing for the infrastructure. So the system supports multiple rate plans. You can have rate plans that either vary by geography or vary by the type of billing that you want to do. You can assign rate plans across different levels in the organizational hierarchy. So you can have one rate plan for one customer, a different rate plan for a different customer. You can even vary rate plans within the tenant itself. So there's a particular rate plan for one business unit and a different rate plan for a different business unit. So just some of the key elements of a rate plan. This is what I like to call the hygiene section in that this is all the stuff that you kind of have to do, sort of like brushing your teeth. I mean, so we support discounting. We support currency and being able to vary currency across tenants. The way we don't do currency conversion in our implementation, what we do with currency information is match the currency that's defined for a rate plan against the currency that's defined for a tenant. So if you have a tenant who expects to receive a bill in U.S. dollars, then we verify that a rate plan that's assigned to them also is a U.S. dollar rate plan. Pro-eration. So you may have charges that you bill at different intervals. You have a monthly charge for a VM, say, and then how do you want to treat a partial billing period? So a VM gets added in the middle of the month. Do you pro-erate that charge on a daily basis, on an hourly basis, whatever? You have the option of doing that. And then how do we how do you want to handle partial billing? So do you just do actual pro-eration or do you just do full scale rounding up to the entire period? In defining assignees, as I mentioned earlier, you can choose to assign a rate plan at any level in the hierarchy. So if I within BNCC Corporation, if I want to test rate plan here, but I wanted a different rate plan for Asia, I have the ability to do that. Rate plans are effective for periods of time. So you can stack up rate plans. You can have this rate plan active for this particular period of time. You know that a change is coming, so you can go ahead and define the change and have it have it active from some point in the future. Brings me to an important aspect of the solution as well in that everything is time-stamped for compliance and tracking purposes. Any change that happens is time-stamped. Nothing ever really gets deleted. It just sort of gets expired and says it's no longer valid. In assembling the elements that you're billing on, so this is what I showed you earlier in terms of setting up a billable feature, when I choose a provisioned entity that I want to bill on, I choose my entity. I'd previously defined what my default costs are for particular billing periods. And when I actually assign it to a rate plan, I can choose to override those. So I previously said my default cost for a firewall is $1.50 per day. But in this case, if I want to charge $2, then I can do that. Feature attribute-based costs are the more fine-grained billing based on what the actual characteristics of an entity are. So the use case would be something like I want to charge $10 a month for a VM, but if the VM is running Windows, then I want to charge $5 more per month. And so when we pull data from Salam, or when we get data from OpenStack, not only are we getting the list of managed entities, but we're pulling the attributes that are with those entities as well. And so you can take any of those attributes and you can attach cost associated with that. So just another level of detail that we can bill on. And then finally, the usage-based costs. In setting up usage-based costs, you'd find the frequency at which you want to calculate the cost. So this particular metric is available to me in five-minute intervals, hourly intervals, daily intervals. And so I can choose, say, once per hour. And then I can choose either a simple or a tiered billing mechanism. So the simple billing mechanism is just, you know, here's my measurement. I'm going to multiply it by a number and that's it. The tiered billing mechanism, the best example I can think of is the way that I get my water bill, where for the first 2,000 gallons, I pay 20 cents a gallon. For the next 2,000 gallons, I pay 40 cents a gallon and so on. And so you have the ability to define multiple tiers and charge differently. And then you can either charge, you can only bill, you can bill either only at the tier that matches or you have the ability to roll that all up and collect data. So that's setting up the billing mechanism. I'm going to close with, this is what I was, maybe I can switch my screen resolution so that shows up a little bit better here. And so what I'm doing here is I'm taking this rate plan and I'm taking this particular tenant. And this actually, here's the risk with doing a live demo. There's something that's gone wonky with our demo environment where not all the detail that should be showing up here is actually showing up, but I can at least show you the utilization-based cost as it's being generated here. So in this case, this is a very simple use case that we picked. I have, the tenant has one VM and we're showing the usage-based costs for this particular VM. And so in this case, we metered CPU and network outgoing bytes. This is the number of metrics that we collected and this is the cost that we calculated based on this rate plan. So in this case, I generated this live. It lets you do some basic level of modeling and some what-if kind of analysis. So it lets you tweak parameters of a rate plan and actually apply those to an actual environment and see what you might end up with. I'll just close with, I'll close with the security model. As I was mentioning earlier, we have a full role-based model. This same UI can also be exposed to the tenant and the tenant admin can log in and see what's happening within the environment through the same interface. That's it. Thank you. Thank you for coming.