Pricing, Costing and Cost-tuning PaaS

Geva Perry posts an interesting piece about perspectives on how the cloud pricing models might affect application architectures. 

One of the more interesting thoughts this kicked off for me is that a well-instrumented, granular IaaS or PaaS platform offers the application architect and the IT manager a reasonable means of regular evaluation of application efficiency.  If used as such, the detailed bill from your *aaS provider becomes a means of providing successive visits to the cost-efficiency of your app based on real usage.  As Geva puts it, "...your real-time bill from your cloud provider will scream at you if a certain aspect of your application is particularly expensive, and it will do so at a very granular level, such as database reads and writes."

This starts to suggest that, as both an architect's iterative refinement tool and as an IT manager's cost-management / SLA tool, a dashboard that calls out major changes or the loci in an application that have responsibility for the greatest absolute cost or greatest variation in cost (based on usage patterns) would be a very useful product (... no doubt, delivered as a service!). 

Does anyone currently provide this kind of application cost monitoring, tied specifically to the architectural modules that make up a cloud based application?

Thinking Out Cloud: Cloud Pricing and Application Architecture

  1. It's a pay-per-use model. Any optimization of resource utilization, big or small, will yield cost-savings proportional to the resource savings.
  2. It is typically component based pricing. In AWS, for example, there are separate charges for CPU/hours, incoming and outgoing data charges for the servers, separate charges for the use of the local disk on the server (EBS), charges for storage (storage volume and bandwidth), charges for the message queue service, etc.
  3. You get a real-time bill broken down by exact usage of components (at least on AWS).

In other words, whether you were planning on it or not, your real-time bill from your cloud provider will scream at you if a certain aspect of your application is particularly expensive, and it will do so at a very granular level, such as database reads and writes. And any improvements you make will have a direct result. If you reduce database reads and writes by 10% those charges will go down by 10%.

This is, of course, very different than the current prevailing model of pricing by discrete "server units" in a traditional data center or a dedicated hosting environment. Meaning, if you reduce database operations by 10%, you still own or rent that server. The changes will have no effect on cost. Sure, if you have a very large application that runs on 100 or 1,000 servers, tan such an optimization can yield some savings and very large-scale apps generally do receive a much more thorough cost analysis, but again, typically as an afterthought and not at such a granular level.

, ,


Virtual Infrastructure Optimization and Virtual Infrastructure Assurance

Jeff Boles has written a very interesting and very informative piece on the importance of virtual infrastructure management, and particularly its optimization in the virtualized datacenter.  He refers to the issue as virtual infrastructure optimization.  Being in the business I'm in ... next generation virtual system management for configuration and fault management ... I really appreciate the attention to virtual infrastructure (or, perhaps, more accurate virtualized infrastructure).  He's said all of the right things about optimization.

While he correctly identifies many of the problem sources -- interdependencies of the virtual and physical systems being key in the argument -- he stresses performance as the aspect or dimension on which to focus.  He then makes the statement: Faced with complexity and potentially catastrophic impacts from any change, administrators face the unknown.

The catastrophic impacts of which he speaks are rarely just a matter of performance optimization.  They are generally issues of infrastructure configuration errors and mismatches ... often mismatches between the virtualized infrastructure (e.g. the virtual switches, portgroups, and VLAN connectivity) and the physical infrastructure (the "hard goods" ... switches, storage systems, firewalls, etc.)  In fact, recent studies by Andi Mann at Enterprise Management Associates regarding virtual system management indicate that the greatest source of unplanned downtime in the virtualized datacenter (ranging from 60 - 70% of all outage incidents) is attributable to configuration errors and mismatch.  This single fact should bring to light the unpleasant truth about the way in which configuration design and on-going configuration management need to be rethought.  

Jeff points out that "...more than 85% of businesses today rely on their initial testing of known 'good' configurations or arbitrary rules of thumb rather than real data when they manage and make decisions about their virtual infrastructures."  Doesn't it make sense to provide analysis of the configurations before their use as the "golden masters", and CONTINUOUS monitoring of the topological and configuration changes being requested by the various players in order to reduce the likelihood of catastrophy? 

I liked the Q&A that Jeff uses to get across the key messages of VIA.  The one I have some trouble with, simply because I don't believe he treats misconfiguration in its entirety, is this one:

Can I immediately drill into the root cause of performance issues in my environment, and discover what happened or changed? 

While a VIO solution may arm an organization with the right data to avoid misconfigurations in the first place, VIO tools can also provide real-time or near real-time visibility into what is happening in an environment, enabling administrators to immediately identify performance anomalies and root causes.  VIO solutions can capture history, providing an audit trail that identifies when problems started, and what happened.

In a sense, what is missing from the article and from his list of virtual systems management products is infrastructure assurance.  It's not just the data required to avoid misconfiguration once an error is detected.  It's also that set of tools and systems deployed for the initial design, at the time there's a major change / revision to the datacenter, and (unlike conventional datacenters) revisited every time a "golden master" is called upon:

  1. the starting configuration is well designed for the very fluid, dynamic environment of a virtualized datacenter,

  2. that the configuration is the combined physical and virtual infrastructure elements, treated as a unified infrastructure rather than as separately designed and managed "physical configurations" and "virtual configurations"

  3. that the instrumentation supports on-going monitoring, analysis and prescriptive actions to counteract "infrastructure drift" and eliminate (or at least significantly reduce) the major causes of catastrophic failure and performance problems.

To Boles' list of key technologies (instrumentation and infrastructure optimization) I would have to add the unified (virtual and physical) infrastructure analysis and directed re-configuration.  The result is virtual infrastructure assurance (VIA) to which VIO then is applied.  These are the technologies (of which Replicate's RDA is one) which provide visibility into the causes and prescriptive actions that actively and continuously reduce virtualized datacenter failure.  These fall logically into his requirement for a holistic view of the entire virtual infrastructure and into the configuration diagnostics that include remedial actions.  Needless to say, I'd like to see these types of discovery, analysis and guidance tools invited to the party.

InfoStor : What is virtual infrastructure optimization (VIO)?, March 2009 Page 1

While the IT practitioner's every day is a swim through waves of invisible bits, there has long been some comfort to be found in the "physicality" and accessibility of key devices. When problems arise, administrators have always been able to identify a switch port for examination, a server at the end of a wire that might be causing problems, an HBA for inspection, or any number of other physical things for further examination. But in today's data center, that comfort has vanished.

In part, this is due to virtualization, and while this trend is spearheaded by server virtualization, variations include application virtualization, network device virtualization, I/O virtualization, storage virtualization, and more.


Infrastructure ... What HE said!!

How can one argue with a guy named Rich Miller who's a long-time believer in and advocate of the value of infrastructure?  You can't.  That. is. all.

Infrastructure Has ALWAYS Been Cool « Data Center Knowledge

... Here’s a news flash for those who believe that cloud computing has suddenly made infrastructure relevant: Data centers have ALWAYS been cool. Internet infrastructure has been mission-critical from the earliest days of the Internet. Cloud computing is an important trend, and is expanding the options available to end users. But consider this: every cloud computing application in the world runs in a data center. All the cloud computing apps from here forward will live in a data center. Cloud computing simply moves them from one data center to another, or spreads them across multiple facilities. ...

, ,


Cloud, Standards and Interoperable Activities

Jeff Boles has an excellent post regarding cloud standardization.  It's got a number of nicely articulated guidelines to the notion of standards for cloud computing, a pragmatic streak that runs through it when speaking for the end-user, and a nice set of "in-a-perfect-world" concepts. 

I am particularly taken with the notion of standardization around some core activities, as opposed to establishing uniform services and structure (which would seem to lead to quashed differentiation and reduced innovation).  Associated with the means of comparing core activities, a means of discovering alternate sources of the same functionality is a nice thing for the wishlist. 

At the end of the day, I do agree that the "data and services interchange layer is what needs to be standardized" ... Necessary.  I'm just not sure that covers the sufficiency requirement.

Cloudy clouds and standards - Computerworld Blogs

... in my opinion, there only needs to be standardization around a few core "activities" that are targeted more at interoperability than uniform services and structure. The naysayers have a good claim that standardization could stifle innovation, but what I care about, as an end user, is really carrying out a couple of key steps, in the same way, regardless of who the provider is.

But users need to expect when they come "up" the cloud stack, they're going to buy into more lock-in. For example, I don't think anyone on the face of the earth thinks there's hope for standardizing much of anything between something like SalesForce and SAP byDesign. At the same time, those users realize that those solutions are pretty extensible, and that they will eventually be able to store, move, and protect their data in any way they want.

The interesting thing, though, is that we've been talking about and evolving this self describing capability in SOAs for a long time now, and I think we are on the cusp of a "discoverable" solution ecosystem in the cloud....

, ,


Provisioning, Intention and Intelligence

I've been working for weeks to find a simple explanation that distinguishes the more conventional approaches to datacenter management from those that incorporate "intention," particularly as it relates to provisioning.  Doing this simply has been no small task.  The effort has come about as a result of having a continuing conversation with Rich Pelavin, one of the co-founders at Replicate, about what he refers to as the "false promise of automation" in the datacenter.  So, here are some musings.  Not a lot of conclusions... more like observations.

What do I consider the "conventional"? When I think about how most virtual system management solutions address provisioning, it's generally predicated on the end-user's ability to set out (that is, declare or describe at the beginning) the ideal configuration in terms of how the individual elements are placed, how they are individually configured, and the sequence or order in which they are deployed.  The premise seems to be that, should the configuration drift too far away from the ideal, the "perfect" model configuration can be restored, returning to some pre-defined ideal... the same one each time the resurrection is invoked.

The fallacy of automation of which Rich P. speaks seems to be this:

Provisioning based on reinvoking a script or highly specific process assumes that the "ideal" state to which the datacenter (or portion of the datacenter) returns, is indeed the ideal. 

Who's the "authority" or how was it determined that the model state to which the datacenter will return is, in fact, correct or ideal? 
Is there anything in the automated provisioning system that can compare the objectives, intentions or policies of the end-user with those embodied in the script or the "ideal" configuration that results from its execution?

Provisioning based on reinvoking a script or recipe doesn't take into account a change in the environment (to which the datacenter as a whole needs to respond).

On what basis is the script or recipe reviewed to determine whether some aspect of the external environment or the internal status of the datacenter has changed in a fundamental manner?
Is there a cogent statement of intention, incorporated in either the automated system or the human process of review and revision, that regularly -- perhaps every time the script is invoked -- revisits the intentions, assumptions and the environments to determine whether the ideal configuration enbodied by the recipe is still the ideal?

Provisioning automation which relies on conditional logic assumes that the instrumentation available to it ... the information it has to work with in order to take one path or the other, or algorithmically establish the level or scalar value of some aspect ... is complete. 

That is, whatever the system doesn't see or can't know will not have bearing on the decision.  The assumption here is that the customer/end-user has instrumented the system to the maximum degree possible, and has given over the decision making to a process which has sufficiently complete information.

The more advanced provisioning automation systems defined by the reliance on simple rule sets and wrote procedures seem to rely on a belief (hope?) that the orchestration offered will exhibit some kind of emergent behavior.

Even if the provisioning is accomplished by an orchestration system that incorporates more sophisticated logical constructs ... or just the incorporation of conditional statements in the scripting ... the depth of definition in describing the ideal is still in question.

So, as I dig into the issue, these thoughts emerge.

First, the appropriate depth of target or objective definition needs to be established.  Specifically, the discourse has to be at the level of overall intent, and therefore at the level of datacenter strategy, rather than administrative operations or sub-system tactics.

Most automated provisioning systems operate at the level of tactics and the manipulation of datacenter elements.  The more advanced, incorporate conditional logic and instrumented sensing that provide an operations point of view, based on the administrative domain (i.e., the network configuration, the storage system configuration, the arrangement/placement of virtual machines for purposes of "load" balancing).
Second, insisting that the entire datacenter strategy actually CAN be automated, leaving its operations in the hands of the "emergent behavior" that comes from the repetition of simple processes, results in either a lot of mistaken configuration, or an overly constrained, highly repetitive and therefore rather inflexible operation.

The ability to repeat simple processes is not the equivalent to an "intelligence".  It doesn't constitute the capability for abstract thought or clear intention.  This argues that the notion of an assistant or advisor to the human datacenter administrators, and (even more to the point) an advisory system that "speaks the language" of all the necessary administrative domains (servers, applications, networks, storage, ...) is the best option open to us.

Third, intention and the strategy involved in operating on the basis of intention need to be systemic or (oh.. no!!) holistic.

The intent of the datacenter's configuration and the data on which the configuration decisions are to be made need to consider the dependencies of all the datacenter's systems, their interactions and the metrics on which the datacenter's performance is objectively assessed.

Page 1 ... 6 7 8 9 10 ... 78 Next 5 Entries »