Elastra connects the power use in the data center to the application architects and deployment decision makers.

Plan Composer function lets customers set their own policies based on application needs and specific power metrics (such as wattage, PUE, number of cores, etc.). Therefore, if an application requires 4GB of RAM and two cores for optimal performance, and if the customer is concerned with straight wattage, Elastra’s product will automatically route it to the lowest-power 4GB, dual-core virtual machine available.

Amazon.com, Inc.

(NASDAQ:AMZN), a Fortune 500 company based in Seattle, opened on the World Wide Web in July 1995 and today offers Earth's Biggest Selection. Amazon.com, Inc. seeks to be Earth's most customer-centric company, where customers can find and discover anything they might want to buy online, and endeavors to offer its customers the lowest possible prices. Amazon.com and other sellers offer millions of unique new, refurbished and used items in categories such as books, movies, music & games, digital downloads, electronics & computers, home & garden, toys, kids & baby, grocery, apparel, shoes & jewelry, health & beauty, sports & outdoors, and tools, auto & industrial.

Back to his PDF. Much of the information in the pdf is on the Elastra technology site, but I found it easier to read the PDF to understand Stu’s thinking.

The introduction targets the use of Elastra for the architect, stating the problems.

Reference Architecture Introduction

In today’s age of on-demand access to applications, compute, storage, and networks, modern IT applications and service management has many complications:

Applications can be deployed across organizationally & geographically distributed data centers. The technology in these data centers, from virtualization platforms, to host, storage, and network infrastructure, is typically heterogeneous, and not necessarily managed with uniform policies and interfaces.

The performance, scalability, and availability characteristics of an application are due to a complex combination of design and operational decisions. The greatest impacts on these factors are due to decisions in the architecture and development of the application, before configuring the data center infrastructure.

Application and infrastructure management is complex and inter-disciplinary. It’s unlikely a system can be diagnosed and maintained by one person to keeping the system design & configuration in their head. Application design, administration, and management typically is a collaborative activity across specialists; there is no “one-size fits all” design tool, management tool or application platform.

The design goals are right on.

Three design goals for an end-to-end cloud design approach include:

Separated Applications from Infrastructure, through modeling the application in terms of its architecture and infrastructure requirements, without tying the application to a specific set of underlying infrastructure

Enabling Computer-Assisted Modeling and Control Automation, provided by a set of control agents and user-guided by graphical design tools. This could help IT architects and operators determine design constraints on the application, match the design to the underlying infrastructure, and enable goal-driven automation to deploy, scale, or recover their IT systems on demand.

Explicit Collaboration To Enact Changes, through models that codify, relate and analyze the constraints and preferences that are appropriate to stakeholders across enterprise IT: from architects and developers, through operators, administrators, and managers.

The document has many great ideas including the use of models.

Declarative models are useful ways to drive complexity out of IT application design and configuration, in favor of more concise statements of intent. Given a declaration of preferences or constraints, an IT management system can compose multiple models together much more effectively than if the models were predominantly procedural, and also formally verify for conflicts or mistakes. On the other hand, not everything can be declarative; at some point, procedures are usually required to specify the “last mile” of provision, installation, or configuration.