If you are new to Teevity Cloud Costs Analytics, we provide a SaaS based, multi-provider (AWS, Azure, Google GCE/AppEngine), cloud cost analytics service which built on top of an improved, multi-cloud version of Netflix Ice.

We also provide a standalone Netflix Ice as-a-Service solution. The Teevity API can be used as a Netflix Ice API and can even act as a cache in front of a deployment of Ice that would not be running full-time.

This works whether Ice is hosted by us (our as-a-Service solution), hosted by you through the AWS Marketplace or through on another Cloud provider (DigitalOcean, OVH, ...). And it can even work for a Netflix Ice deployment running on a local machine.

This page gives an overview of the features our API provides for:

• Cloud user : easy access to your cloud spending data, powerful "in-context" analysis of it and easy executing of cost cutting actions
• Service provider : tools to provide detailed cost info to your customers (for generic Cloud monitoring services, Managed Service Providers, IT departments, ...) and tools to build your chargeback and billing systems
• Cloud provider : ways of integrating your service with Teevity to let your users get a deep understanding of their spending.

This API reflects what we have learnt through 2012 and 2013 by interacting with many users of our cloud spending analytics service and by meeting many companies using Cloud and VDC services, either for their own needs or to provide services to others.

Some of what we've also learnt is that there seem to be five main categories of people interested in Cloud spending analytics and monitoring, each of them with their specific needs.

• Team managers or team leaders who want to track how Cloud spending evolves over time.
• Product line managers who need to build 'Cost models' (for their new SaaS service for instance) and to ensure reality goes by the model
• Finance departments who need simple ways to integrate Cloud spending inside their finance systems (full ERPs or Excel/Google spreadsheets)
• Cloud architects and developers which are increasingly becoming aware of Cost Driven Design and that they need cloud cost debugging tools
• Devops people who need to ensure actions are conducted at the infrastructure level to optimize the spend/quality of service ration

What we've also learned from companies around the world is that, when it comes to Cloud spending analytics:

• Monitoring absolute amounts is of limited value. Value comes with "in-context" analysis (cost per transaction, per tenant ...)
• Not everybody loves SaaS for Cloud spending analytics, mainly for confidentiality reasons (go ask Netflix how much they spend :-))
• Reducing IT spend is only one of the reasons companies are going Cloud (not the reason at all for some). They still need cost control and analytics.
• Most tech teams have very little knowledge of the impact of their design/technical choices on Cloud costs
• Cloud spending recommendations have little value unless they are easy to put to reality (yes, you already know you should be autoscaling that component ...).

The API has been designed with these use cases and feedbacks in mind.

We are well aware that most APIs are used beyond the initial intended use cases, so we've taken great care, when building this API, as to design it in a way that will reduce chances of it breaking under the un-expected use cases. We'll see how it goes :-)

There are 4 main areas covered by our API and so there also 4 main sections in this page

• Cost monitoring to get access to high-level and detailed cloud cost and usage data
• Cost analytics to make business or technical sense of your cost and usage data (isolate specific parts of your costs, understand the cost impact of technical choices you've made, help build and validate your cost-of-sales model, ...)
• Cloud automation because monitoring is not enough to cut your cloud spending ! Automate the start/stop of instances on predefined schedules, destroy untagged resources, automate AWS Spot bidding for instances, ....
• Partner integration for a simple integration between your SaaS service and ours

A few technical considerations on this API

• The API itself runs on Google AppEngine and is thus very scalable. The systems behind this API are running both on the AWS and GCE clouds.
• It is mostly RESTful and supports JSON and XML for all operations
• Version management is done through an API version number included in the endpoint URL. Header based version negotiation might also be supported in the future.
• Accesses are through HTTPS and access protection is done through an AccessKey and optional VerificationCode only required for some operations. The key can be passed as a header of your requests or as a request parameter.

This API is multi-cloud by design and builds on top of a generic cost and usage data model, which is why it doesn't use Cloud provider specific terms but generic ones. You can find on our blog a mapping between the Teevity API generic terms and the Cloud provider specific ones

Due to the differences between Cloud providers, the API provides different level of cost and usage details depending on the Cloud provider. But a significant subset of the API is common to all providers.

The "basic" cost monitoring API allows you to request cost and usage data for a whole cloud service (aka cloud account). The data returned can be a single value or can be further detailed as to how this cost/usage data is divided among sub-services or sub-sub-subservices inside that cloud account.

Dates can be expressed in yyyy-mm-dd:hh-mm or epoch format or using an eventRef (see below in the 'cost analytics' section)

Remark : The aggregation period defines the minimum time precision of your requests (ie 'monthly aggregation' force time boundaries to be at the month level)

There are several ways to get access to detailed billing information about a Cloud service or a set of Cloud services.

• By making a direct reference to the 'teevity id' of the CloudService (you fetch data for the entire account)
• By making a reference to a CostAllocationGroupe ID defined within Teevity (you fetch data for a dynamically defined subset of cloud resources)
• By making a reference to an ApplicationGroup ID manually defined in Teevity Detailed Analytics user intereface (or an ApplicationGroup defined in Ice)

Information for Netflix Ice users: You can use the Teevity API to make programmatic calls to Netflix/Ice or Teevity/Ice and make some direct references to CostAllocationGroups/ApplicationGroup you have defined in Ice.

With the Teevity API, you can define dynamic set of Cloud resources using generic criteria. These criteria are

• Based on Tags provided at the Cloud provider level (AWS tags, GCE tags, ...)
• Can express generic conditions on the tag names
• Can express generic conditions on the tags values

The Teevity API enable business oriented cloud spending computations. You can for instance compute your cost per transaction, cost per request, cost per tenant, ... More to come on this later.

The Teevity API allows you to make easy correlations between events/actions happening on your account and the changes in your Cloud spending. You can discover correlations graphically, and you can also use the Teevity API to ask for price data between two events.

Exemple API query: Give me all the AWS EBS PIOPS spend that occured during our latest load test.

Events can include

• the "release of a new version of your software",
• a "public price change by a provider",
• the start and end of a "load test",
• the start and end of a "test of the latest AWS instances",
• or anything else that helps means make correlations and measurements

You can push events to the timeline through a simple wget/curl call to our API. And Teevity can also auto-generate some events (cloud price changes for instance).

You can push events to the Teevity cost timeline. This is usefull to track various events (devops action, public price change, buying strategy change, addition of a new account to the monitoring, ...) and enable an easy correlation between the occurence of these events and the impact they have on Cloud spending.

You can search for events in the timeline, the main use case being to use the event date as a time parameter in another call

You can use eventReferences everywhere you can pass-in date parameters. The timeDate of the event will be used as the date value.

If you use an event lookup function and no event is found, the cost monitoring request will return an error.

The Programmatic Cloud Switch service will let you turn resources on/off on planned schedules (office time is only 2/7 of the total time of a week; there is a huge saving potential here). And our Netflix Janitor Monkey as a Service will help you clean unused resources.

More info coming soon.

More info coming soon

More info coming soon

More info coming soon

More info coming soon