Data from Computer Economics – Metrics for IT Managementhttp://www.computereconomics.com/article.cfm?id=1419
The Elastic Modeling Languages are a set of modular languages, defined in OWL v2, that express the end-to-end design requirements, control and operational specifications, and data centre resources & configurations required to enable automated application deployment & management.While the foundation of the modeling languages is in OWL and RDF, developers can interoperate with the Elastra Cloud Server through its RESTful interfaces; all functions available to the Elastra Workbench are available through this interface, which are based on Atom collections and serialized JSON, XML, or RDF (XML or Turtle) entries.The Elastic Modeling Languages provide a balance between enabling users to express declarative, machine-reasonable policy, and procedural know-how for configuration or provisioning.For More Information on the Modeling Languages please view the appendix section for more information on ECML, EDML, and EMML
The Elastra Plan Composer performs explicit reasoning and deliberation on behalf of system administrators. It chooses and organizes actions that the cloud control plane should take, by anticipating the expected outcomes of those actions.The Elastra Plan Composer enables administrators and change boards to synthesize a plan for execution. It analyzes the proposed application designs and infrastructure models, comparing them against a library of actions and outcomes. It then generates a plan guided by preferences or constraints in the models.Extensibility occurs through operational knowledge modules in the Plan Composer. These modules provide searchable, reusable process descriptions that encode the operational know-how for specific subject areas. For example, a “network knowledge module” can interpret and enact a network configuration; a “resource allocation knowledge module” knows how CPU, storage, and memory should be allocated to an application.
We enable customers to look at the total cost of running the complete application stack. From the software, to the servers, storage, bandwidth, and even down to electricity. We allow customers to integrate all of these cost components into an algorithm that optimizes the resources allocated to minimize the overall cost of ownership. Other organizations look at individual segments of an application stack and minimize those without taking into account the impact on the performance or functionality of the system.
Elastra’s philosophy is to integrate with existing chargeback mechanisms and cost accounting solutions wherever possible. In our architecture there are two components that allow us to integrate and report on application usage in your enterprise. The Elastra Resource Agent provides a gateway to the scarce resources in the Infrastructure plane, predominantly hardware such as Hosts, Network, and Storage. The Resource Agent serves as a plug-in layer for providers of cloud resources, virtualization platforms, and network or storage automation.Resource provisioning interfaces often are exposed through incompatible APIs that require integration. The resource requirements, expressed in an EDML document, are interpreted and matched against resource capabilities exposed by the Elastra Platform Provider Interface (PPI).The PPI provides a capability-based abstraction to the various resource providers that may be plugged-in to a resource agent.The Elastra Metering agent tracks metrics for deployments managed by the Elastra Cloud Server. These metrics can be used for governance purposes such as: license compliance, budget analysis, and chargeback generation.Most IT infrastructure involves a variety of vendors, service providers, licenses, pricing, and payment models that may change at different paces. Appraising the cost of an end-to-end service requires a metering agent capable of collecting and correlating data from distributed sources.The Elastra Metering agent collects metrics from various sources, such as resource agents, configuration agents, and usage sensors. It then filters, consolidates, and correlates this data with associated rules for rating the resources & components of a deployment. The aggregated metrics and rate information is then exported to an information stream and database schema for reporting and online analytics.
The structural view is the primary view to which other views correspond, usually by transforming or constraining the structure of the system.The structural view consists of:Components - Abstract units of software, configuration, and capability requirements, which expose interfaces for communication.Connectors - Abstract units of communication and/or mediation between components, which also may contain software, configuration, and capability requirements, which expose interfaces for binding to components.Components and Connectors can be assembled through interfaces that are described on declared slots.The lifecycle of the component or connector describes the various states available for that element, its transitions, and various requirements for a component or connector to be in that state.Finally, ECML’s extensible views capture higher-level policies such as:Resource Allocation The mapping of components to virtual hosts, storage & network resources.Scalability The policy of specifying components & connectors into tiers, where components and connector bindings are replicated depending on a scaling factor.
Resource elements model scarce infrastructure that must be provisioned and tracked in various pools or zones. Typically resources are data center resources, and EDML includes a virtual data center model to represent common entities such as Hosts, Storage, VLANs, Hypervisors, etc.Configuration elements model software packages or configuration metadata that make up the “bits” of a component or connector, and are installed and started on a set of resources.Categories provide a taxonomy of concepts to provide searchable descriptive metadata for elements in both EDML (Resources and Configuration elements) and ECML (Components, Connectors, etc.).Capabilities capture the features and functions that are available from an enterprise’s shared infrastructure, such as chip architecture, and storage or network capacity. Capabilities are grouped into bundles to expose standardized units of provisioning and configuration for applications to consume. Capabilities are extensible, and are not just decompositions of physical attributes. They can represent a variety of quantitative or qualitative (symbolic) measures
EMML provides elements to describe various configuration items in an IT management system, and their relationships, dependencies or states. Every element in ECML or EDML can be described as some kind of EMML design or resource item, and EMML introduces an independent “Deployed Item” to describe the state of a deployed application. EMML provides a CMDB-like interface for querying, analyzing, versioning, and archiving the configuration state of IT applications as they evolve over time.
Elastra Lean It
Solutions for Minimizing IT Operational Costs<br />Solutions for Lean IT<br />
Elastra’s Solution for Lean IT<br />Overview of Elastra’s Lean IT Approach<br />Why are Cost Controls Important?<br />How does Elastra Achieve this?<br />Why is Elastra’s Solution Different?<br />2<br />
Elastra’s Solution for Lean IT<br />Overview of Elastra’s Lean IT Approach<br />Why are Cost Controls Important?<br />How does Elastra Achieve this?<br />Why is Elastra’s Solution Different?<br />4<br />
Although Growth in Spending Will Return IT Should Expect Much Stricter Expectations<br />5<br />5% to 10% Growth in Spending in 2010<br />IT Spending to Reach 1.8%<br /> of Revenue in 2010<br />60% to 65% of Organizations<br /> will Increase Budgets in 2010<br />
Elastra’s Solution for Lean IT<br />Overview of Elastra’s Lean IT Approach<br />Why are Cost Controls Important?<br />How does Elastra Achieve this?<br />Why is Elastra’s Solution Different?<br />6<br />
Modeling Languages Describe Resources and Applications<br />7<br />
Plan-Composer Creates Plans Based on ECML and EDML<br />8<br />Plan Composer Architecture<br />Plan <br />Generation<br />ECML and <br />EDML<br />Structural<br />Analyzer<br />Plan Synthesizer<br />Knowledge Modules<br />Lifecycle and Action <br />Generation<br />Install and <br />Configuration<br />Resource <br />Allocation<br />
Modules for Minimizing Cost<br />9<br />Minimize Resource Cost<br />Assign a financial cost <br />to virtual <br />resources<br />During Plan Composition <br />the system evaluates all <br />virtual resources <br />available<br />Resources are <br />provisioned<br /> to minimize <br />financial cost<br />Minimize Total Cost of Ownership<br />Assign a financial cost<br />to all resources in <br />the stack<br />Assign a cost for how <br />resources <br />contribute to the metric<br />Resources are<br />provisioned to optimize <br />total cost of ownership<br />
Elastra’s Solution for Lean IT<br />Overview of Elastra’s Lean IT Approach<br />Why are Cost Controls Important?<br />How does Elastra Achieve this?<br />Why is Elastra’s Solution Different?<br />10<br />
We Look at the Total Cost of Ownership of the Complete Application Stack<br />11<br />Total Cost of Ownership<br />Cost of Running the Software<br />Cost of Running the Servers<br />Cost of Storage<br />Cost of Network Bandwidth<br />Cost of Electricity<br />
Integration with Chargeback Mechanisms to Streamline Cost Accounting and Reporting<br />12<br />Elastra Cloud Server Architecture<br />Cost <br />Accounting <br />System<br />Resource Agent<br />VMware Provider<br />Other Resource Provider<br />Metering Agent<br />Application Usage <br />Sensor<br />Resource Usage <br />Sensor<br />