I will admit to having early skepticism of the Platform as a Service (PaaS) offerings exemplified by Microsoft Azure and Salesforce.com. Among my many objections were the lack of support for existing workloads, vendor lock in, lack of support for the available applications / open source, and a predisposition toward supporting only green field applications. It always surprised me the stubbornness with which Microsoft defended its PaaS approach, before finally bringing to market their own IaaS offering in 2012. But by this time, most other vendors (e.g. Rackspace, HP, IBM) had established credible IaaS offers in the market.
There are of course many reasons to think Amazon could be much more successful in PaaS than their predecessors. By delivering IaaS to an early adopter market that wanted consumption-based pricing of storage, network and compute, they have grown a nascent business to one that is estimated at $4B+ in annual revenue. The established and rapidly growing customer base provides them a clear target market for their PaaS services, deep experience in customer workloads, and a high optimized / reliable infrastructure to support their platform offerings.
But there is one technical difference between Amazon’s platform services that should worry every other cloud provider: AWS has built its PaaS directly upon its IaaS.
Yes, I know that seems like an obvious way to build platform services in 2013. But you only need to look around to realize this is surprisingly uncommon (e.g. Microsoft Office 365, IBM SmartCloud Object Storage). While Amazon does not publicly discuss its service implementations (Wizard of Oz: “Pay no attention to the man behind the machine”), with some basic sleuthing, it is clear this is the the case (e.g. historical outage reports, AWS resource bill).
What this means is Amazon has established the first closed loop virtuous cycle for building a full stack of cloud infrastructure and services. AWS is leveraging their optimized infrastructure to deliver IaaS services to a rapidly growing IaaS customer, then using this same IaaS infrastructure to develop and deliver higher level / higher margin platform services (e.g. Kinesis, AppStream), which in turn are driving additional innovation back into the IaaS services (e.g. C3 and I2 instance type families).
The cloud game is not over by any means. But in the two decade march toward cloud computing’s total transformation of our technical landscape, one cloud vendor seems to be rapidly approaching cloud escape velocity.
It has suddenly become trendy to use “the M-word” when discussing Amazon. Yes, you know the word I mean. I almost don’t even want to say it… but here it goes… Microsoft.
I’m not sure when the Microsoft / Bill Gates / 1990s comparisons started, but it is definitely in vogue right now. I suspect Brad Stone’s biography of Amazon, Everything Store, has contributed to the comparison. I also think AWS re:Invent may have helped fuel the fire, as Amazon came across as exactly what it is: a highly innovative, highly dominant, and highly aggressive market leader in “the single greatest disruption of our lifetime” (from Andy Jassy’s keynote). You only needed to watch the body language of Citrix’s chief evangelist as he was grilled on Amazon’s announcement of WorkSpaces, to understand the power of the Amazon cloud war machine.
But behind all the talk, the dirty little secret is that most software developers have a soft spot in their heart for Amazon. Why? They freed us from the interminable prison of IT and their physical infrastructure. I still cringe remembering the days of hardware requisition forms, product back orders, and long waits for IT to rack and stack my hardware.
But when I think about Amazon and “the M-word”, I can’t help but recall a chapter in Everything Store that recounts a memo Jeff Bezos wrote to his executive team called “Amazon.love”. The memo was a prescient introspection into how Amazon could avoid following the path of current and former bad guy corporations, such as Microsoft, Wal-Mart, and Goldman Sachs. The memo outlines what works and does not work for a corporate culture. Here it is in its entirety:
- Rudeness is not cool.
- Defeating tiny guys is not cool.
- Close-following is not cool.
- Young is cool.
- Risk taking is cool.
- Winning is cool.
- Polite is cool.
- Defeating bigger, unsympathetic guys is cool.
- Inventing is cool.
- Explorers are cool.
- Conquerors are not cool.
- Obsessing over competitors is not cool.
- Empowering others is cool.
- Capturing all the value only for the company is not cool.
- Leadership is cool.
- Conviction is cool.
- Straightforwardness is cool.
- Pandering to the crowd is not cool.
- Hypocrisy is not cool.
- Authenticity is cool.
- Thinking big is cool.
- The unexpected is cool.
- Missionaries are cool.
- Mercenaries are not cool.
He forgot one though: disrupting the bureaucracy of corporate IT is cool.
Amazon and their head of AWS, Andy Jassy, officially kicked off Day 2 of re:Invent with a 90 minute keynote in a concert-sized auditorium packed with 9K+ attendees. He made a few interesting announcements, including AppStream, WorkSpaces, and CloudTrail (my personal favorite). He also took the time to espouse Amazon’s commitment to their customers, took a soft jab at IBM who is running ads on Vegas buses, discussed Amazon’s belief in continuously lowering prices, and pontificated on the AWS view of private / hybrid clouds. He handed the mic over to other speakers at various times in the keynote, including: Jeff Smith, CEO of Suncorp; Stephen Orban, CTO of Dow Jones; Arzhang Kamarei, President of Tradeworx; Kevin Baillie, founder of Atomic Fiction.
My geek attention span started to wane after about 75 of the 90 minute keynote, so hopefully I didn’t miss anything important in the last few minutes. But it was hard to sit in that audience and not appreciate the velocity and scale Amazon has amassed with AWS (250+ new service / feature announcements year to date). It was also hard not to notice that this scale has resulted in them aggressively moving into new markets and taking on new competitors.
Overall, I would rate the keynote a solid B/B-, being a little too repetitive with last year, and missing a little of the thunder that comes with a big price break announcement. Also, while I enjoyed the speakers, the discussions about how AWS could enable enterprise agility was just a little off the mark for me. But I still have high hopes for Werner Vogels and Day 3.
There were a lot of good sessions today, but the biggest theme for me was an uneasy sense that Amazon may not have clear boundaries around competing with its rapidly evolving ecosystem. For example, Boston has been home to more than a few VDI startups, all of which I am sure have at least raised an eyebrow at WorkSpaces. The same can be said of AppStream, which seems to directly compete with partner offerings available today on the AWS Marketplace.
I’m not sure the accuracy of Brad Stone’s Everything Store, but in one chapter he described how Amazon entered the jewelry vertical in the late 1990s/early 2000s by deliberately watching how their own partners sold in the marketplace. One re:Invent attendee relayed a comment from a colleague that being an Amazon Technology Partner can at times feel like being the main character in the Truman Show, where you live an Amazon constructed reality controlled from above.
But my nagging feeling cannot sway me from my self declared AWS fan boy status. I think some competition is inevitable with the scope of the disruption in the cloud. But with Google becoming increasingly aggressive in directly competing with AWS, Amazon might want to remind itself of an interesting motto: “Don’t be evil.”
Day 1 of re:Invent is wrapping up, which has been mostly a soft pitch for attendees arriving for the official kick off tomorrow. There was a hackathon, bootcamps, partner meetings, and an evening reception, all generally low key. I must confess to feeling like I walked into a rock concert this morning upon entering the registration room, with a live DJ blaring music that had a little too much affinity for the years 1980-1984 for my tastes. Within minutes of arriving, the registration line grew to 100+ deep as everyone lined up to get their pass and swag (and good swag it was).
Usually when a conference host tells you it is “sold out," I take that as meaning: look at how well we did in getting attendees to the conference, but of course you can get a last minute pass. But when Amazon says this event is sold out, they really mean it. We tried to get an extra pass for a colleague through front and back channels, but had no luck (Amazon to me: “No soup for you!”).
This afternoon I had an interview with Jeff Barr, Amazon’s cloud evangelist. I had never met Jeff, so we gathered in a small video booth in the exhibit hall shortly before the shoot. There was a surreal moment pre-shooting as we chatted about his recent AWS meetup tour across the U.S. while a coordinator dusted makeup on our faces (note: I don’t look any better with makeup). The actual interview went surprisingly quickly, and and should be up on the site tonight. I’m hoping it comes out well.
I took in only one session today, having most of my day taken up with planned meetings in our suite. We went with a low profile this year, being too new a company to justify buying a booth, and clearly too cheap to buy enough exhibit hall passes for all our attendees. I was glad to see some good local Boston companies here though, including Acquia, Basho, Brightcove, Cloudant, CloudTP, ParElastic, Cloudbees, NuoDB, and Stackdriver. But I will confess to thinking we should have had more of a presence from Boston though (only 10 of 173 booths), especially given our region’s hardcore enterprise / infrastructure heritage. But maybe next year.
The reception tonight was in the exhibit hall. It was jam packed and hard to talk with so much noise in a confined area. Several companies had brought out big crews to man the booths, and it made for an impressive sight. Amazon and RightScale had the biggest booths, but Amazon’s had a lot more activity due to the bartenders lining the booth. Overall it was a great reception, but hard to network.
If you didn’t already know, I’m a big believer we are at the beginning of a 20+ year transition that will be as pervasive and disruptive as the internet from 1993-2013. I believe that like the internet, this disruption will impact every industry, with ITSM only being one I most recently have liked to discuss. I had mentioned this to Jeff Barr while we were making small talk before the interview, and he told how his journey from 2001 to now hit home for him last year when he walked on stage at re:Invent to 6K attendees. That must have been quite a rush for someone seeing the cloud from those early days.
So I’m glad to be here in the middle of what promises to be a loud, imperfect but highly productive conference, that we will some day reflect on as a key mile marker in our journey that results in a seismic disruption in the industry. It’s been a long day though, so going to sign off early. More tomorrow.
Picture of Acquia booth taken before the opening of the exhibit hall, as everyone was setting up.
Several years ago after taking a new VPE role, I heard my system administrators throwing around foreign terms like “converging nodes”, “cookbooks”, “knife”, and “recipes.” I had never used Chef, and had the distinct feeling I’d walked into a high tech kitchen. Over the next few weeks, I sought to make sense of our Chef investment, and it wasn’t long though before I was hooked. Over the coming months, the size of our cloud computing infrastructure would triple (700+ servers, 1.5+ PB storage), and Chef became an essential component to managing our growth.
But I know managing cloud infrastructure with Chef is not for everyone. So for those of you not using Chef, here are the top 10 reasons to support your decision.
#10 - You’ve Never Met a Server You Wanted To Configure the Same Way Twice
Your servers are like children: each unique and special in its own way. Chef would not only turn all your children into identical clones of each other, but also force them to remain identical after they go out into the world. Is that a fair way to treat your children?
#9 - Your Infrastructure Never Changes After Deploy
Once you deploy a server, you never have a need to change it. All you need to do to replace a server is find the documentation for the time you launched it (you did document this, right?), follow the manual instructions (the deployed packages are still available, right?), and presto, you have an... identical server?
#8 - Who Needs Cookbooks When You Have Images?
You have found the Easy Button to automation and configuration management: images. After manually configuring a server, make an image. You probably should also take an image after each change to a server too. That doesn’t happen often, right? And you probably should also take an image per server too, since each is configured slightly differently. Easy button, right?
#7 - Who Needs 1000+ Community Cookbooks?
It’s great that the Opscode Community Cookbooks provide out of the box automation for 1000+ applications (e.g. MySQL, Postgres, Cassandra, ElasticSearch, Apache), but they probably don’t have your applications. And even if they did, these cookbooks couldn’t possibly configure the applications based on your specific needs. Right?
#6 - You Like Staying Up Until 4 AM to Replace a Server.
Admit it: you like the rush of staying up until 4 AM to replace a server. Where is the rush in launching servers from a command line that converge to a known standard configuration?
#5 - No ROI in Automation.
Sure, you could make the investment to automate all your infrastructure. You could even make the commitment to have Chef manage configuration changes to your servers. But where is the return on investment for making it easy to deploy and support consistent infrastructure?
#4 - Real Geeks Do It Manually.
What will happen to your geek street cred if word gets out you automated all your infrastructure? Real geeks do it manually.
#3 - Excel: The Only Way to Manage Infrastructure.
Everything you need to know about your infrastructure is in Excel. If you need to know what operating system version you are running, check the Excel spreadsheet. If you need to know the version of different applications, look in Excel. Need to know whether a critical security patch was deployed to your frontline web servers? In Excel you can trust.
#2 - Real Sys Admins Use Perl, Awk, Sed.
Real system administrators do not write in a language like Ruby. They use real tools like Perl, Awk and Sed.
#1 - Naming Your Servers After Smurfs Is… Normal?
Quick, one of your servers is down! Is it PapaSmurf? ClumsySmurf? LazySmurf? It probably was GrandpaSmurf (he was old anyway). Naming your servers after Smurfs, Star Trek, and the Princess Bride is... perfectly normal.
Kepler has his law of planetary motions, Newton his law of gravity, and Einstein his theory of relativity. I’d like to announce my own contribution to the physical laws of the universe: the 10 immutable laws of cloud computing.
Note: I am willing to share the serious mathematical proofs behind these laws in exchange for Red Sox World Series tickets.
#10: This Month’s Bill Will Be Higher Than Last
Has your CFO ever asked you whether the cloud bill will be higher, lower or the same next month? Don’t waste time trying to correlate current and projected usage to find the answer. The answer is simple: higher.
#9: Eventually Consistent Is Never Wrong
I love eventual consistency. I know E.F. Codd is turning over in his grave thinking: Why the hell didn’t I think of that!? I love it so much I am trying to get my wife to adopt an eventually consistent approach for household tasks. When will I clean the gutters? Eventually. When will that critical document be updated in the database? Eventually.
#8: Availability: It’s Not Your Fault
After every major cloud provider outage, I read articles of cloud dropouts blaming their move to physical infrastructure on the recent outage. I can’t help but hear the words of the Scooby Doo villain: “I would have gotten away with it, if not for those meddling kids.” If a cloud provider’s service degradation causes an outage in your application or service, it’s their fault, not yours. I give you a mulligan. Your CEO, however, may think otherwise.
#7: Cloud Pricing Not Human Consumable
So let me explain AWS Glacier pricing to you. You get charged $0.01 for every GB you store in Glacier. You don’t get charged for putting data into Glacier. Data transfer out however to the internet is charged at a tiered pricing that starts at $0.12 per GB and goes up to… contact us. Data transfer within Amazon is free within the same region in which your data resides but $0.02 per GB for another region. You can only retrieve up to 5% of your average monthly storage pro-rated per day each month (GMT time of course). Exceeding 5% will result in a $0.01 per GB retrieval fee. Also if you plan to delete an item prior to 90 days, it will cost you $0.03 per GB. Oh, did I mention the $0.05 per 1K upload / retrieval charge? One last item: if you plan on moving S3 objects to Glacier, the move will result in an additional 32 KB of Glacier data plus an additional 8 KB of S3 standard storage data.
#6: Trust But Don’t Verify
Once you pass 1 million or so objects in a cloud object store, it is essential you do not try to audit the data. Auditing cloud data has the same result as the quantum mechanics observer effect, where the act of observing changes the outcome of the results. Your cloud provider has your data, so just trust them. Besides, it’s not like you could verify your millions of objects anyway.
#5: The Bill Is Always Right
There is a two step process to managing cloud bills: 1) receive the bill, and 2) pay it. Anything else is just… well, wasted time. Amazon is the most advanced provider in supplying insight into their billing, but until Microsoft fixes the defect with opening a 50 million row CSV in Excel, it is best just to pay the bill.
#4: The Other Cloud Provider Is Always Better
I have good news for those of you thinking of switching cloud providers: the one you are considering is better than the one you have. Don’t confuse me with actual names of providers. You know all those issues you have with unexpected server reboots, random I/O degradation, high network latency, and increasing costs? They all go away when you switch to the new provider.
#3: Physical Infrastructure Was Better
We all know that everything worked well before the cloud. I don’t know about you, but the physical infrastructure I used to manage was always available, secure, and performing. To the best of my knowledge, I never had an issue with my physical infrastructure. In addition, it was cheap.
The memories of managing your own physical infrastructure will always exceed the realities of managing your current cloud.
#2: Everything Will Get Bigger
All provisioned infrastructure in the cloud has an inherent tendency toward becoming bigger. The m1.small AWS instance would someday like to grow up to be an m1.xlarge; the bucket/container storing 1GB of documents aspires to someday hold 100TB; the 50GB volume hopes to someday become a 1TB volume. You cannot stop a law of nature. Quit trying.
#1: The Off Switch Is Broken
Many of us can still hear the words of our parents: “Did you shut the lights off?” We have been conditioned from childhood to turn things off that consume cost or waste energy. Unfortunately the virtual light switch in the cloud is permanently broken and cannot be fixed. So don’t blame your engineers when they forget to shutdown systems they are no longer using. No one knows who broke it or when it happened, but the off switch is most definitely not working.
Article Posted by John O'Keefe, Senior Director of Operations, Acquia, Inc
Handling scale is one of those things people talk about that is an odd mixture of bragging and legitimate challenge. At Acquia, the Operations team is tasked with managing over 6,500 AWS instances, over 12,000 EBS volumes and over 5 million S3 objects. In your early days of growth you’d be able to keep track of this infrastructure just using a spreadsheet but as you can imagine this sprawl really gets out of the wheelhouse of what a spreadsheet can handle after you get past a few dozen servers. It’s not just a matter of keeping track of them individually, you also need to keep track of the relationships.
While the Cloud offers many benefits and a significant amount of flexibility, it also comes with some serious challenges. You may have read our blog post from September 12th, titled “The 6 Most Frequently Requested AWS Cloud Management Reports.” The blog highlighted the #2 challenge that customers face is making an “AWS Reserved Instance purchase.” It’s basically a leap of faith.
As a finance and operations person, I am use to making a wide variety of investment decisions; you gather the facts you need, understand how the new asset will be used, talk with the team involved, and calculate the financial savings and resources required. Sounds pretty straight forward, doesn't it? Well, it’s not quite that easy in the Amazon Web Services cloud. When it comes to RI purchasing, things get pretty foggy, real fast.
If you have multiple accounts, and many configurations, managed by multiple groups and functions, supporting several applications and environments, RI purchases quickly become an enormous task. It can be a challenge to simply see what’s current, not to mention plan for the future. Even experienced AWS account reps and solution architects struggle to provide information to their key customers. So, it often comes down to a large leap of faith based on little information and some big “guesstimates” ...sometimes the six figure kind…$$$.
So, what should we expect in managing a cloud ecosystem? Information on cloud performance? Cloud utilization? Where, how and by whom our resources are being used? YES…YES...and YES! That’s exactly what’s needed to make good business decisions and we should not accept anything less, just because it’s “in the cloud.”
So here is my go to strategy that’s part of every RI purchase decision:
- Instance usage by Instance type, availability zone, and O/S. This should provide trends over time, hopefully weekly or monthly and broken down by RI Usage and On Demand or Spot. Depending on your organization, you may need this broken down by groups or functions.
- Current monthly cost for each with a breakdown by the above categories.
- Current RI Inventory.
- Current RI pricing from Amazon.
Once you have this, you can work with your team to determine if the demand for your instances, based on what they are doing, will increase, decrease, or stay the same. You should also establish a target or threshold for the % of Reserved Instances vs. Total Instances, as most firms need to make incremental capital investment in RI’s over time, as well as, track their impact in rapidly changing environments. Armed with this information, you can effectively and confidently evaluate the upfront commitment you need to make, identify the expected monthly savings, and ultimately the payback period for your investment. You then can determine if the investment should be spread over some period of time.
Now you say, “Well Dave, it’s not that easy to get this information and the information you do get takes a lot of time to pull together, and by then, everything has changed! Not only that, but the environments are much more complicated and span across accounts and functions! It just takes too much time and effort.”
This is exactly what we heard from numerous AWS customers, so we’ve enhanced the CloudHealth platform to solve the RI purchase challenge…and a whole host of other issues as well. Check it out. I’m happy to show you!
Over the past several weeks we have talked with dozens of enterprise organizations about their “cloud use case” and their top five requirements that would make life a whole lot easier.
The gist of most conversations is that cloud computing is awesome…gives us a faster, more scalable way to accomplish things without all the overhead costs of infrastructure. But…and here it comes…getting actual data, reported from a reliable, repeatable source, is extremely painful. In some instances, we heard that it is “impossible.”
We, the CloudHealth Technologies Team, compiled the list of responses and came up with the “6 Most Frequently Requested AWS Cloud Management Reports” (Why 6? There was a tie for #5). See if anything here sounds familiar…
#1 – Trended Instance Usage Reports – On the surface this didn’t sound like any big deal. However, when we asked the follow-up question, “What specifically do you want to see?”, things got interesting.
Turns out you wanted to be able to automatically, slice and dice the data on numerous dimensions: time (hourly, daily, weekly, annually), regions and availability zones, by Instance Type, Reserved versus On-Demand. And most importantly you wanted to see the usage metrics that were segmented by your unique business groups.
Sounds like people are getting tired of running spreadsheet analyses.
#2 – Reserved Instance Modeling – This was a very close contender for the #1 spot. Everyone we talked with said that making Reserved Instance purchases was really, really difficult. The problem is that they were never confident that the purchases they made were the right purchases.
To make things even more confusing, we heard repeatedly that there was no way to see what Reserved Instances were used, where, and by whom (department, customer, application, etc).
#3 – Cost Allocation of an AWS Bill - While this report was frequently requested, there were a variety of “cost allocation” definitions and what was requested.
Some companies simply wanted a better view of their AWS bill. Anyone who has tried to review an AWS “Detailed Bill” will completely agree with this one.
However, the majority of companies were looking to view their AWS bill in relation to the actual groups within the organization that consumed the assets and services. The request was stated in a variety of ways: cost versus department, cost versus environment, cost versus customers, cost versus customer groups that require pass thru billing.
Our take-away on this topic was that customers were looking for flexibility in their reporting. And…spreadsheet analysis is nearly impossible when dealing with extremely large data sets (i.e. AWS Detailed Billing)
#4 – Historical Volume Analysis – Up next on the list was Volume reporting. More than 85% of the customers we talked were challenged in their ability to get a clear picture of what they had in their infrastructure that was being used. At a base level they were looking for Volume reporting that directly related to what was Attached and In Use versus Unattached and simply generating costs.
The initial request was quickly followed by…”what’s really important to us is the ability to see where the Unattached Volumes exist.” Once again, customers were looking to directly relate the assets and services they have within their cloud environment to their business groups.
#5 –Instance Performance – The next most frequently requested report focused on Historical Instance Performance Trends. More than 80% of customers, large and small, were looking for a repeatable methodology that would allow them to evaluate the CPU, Memory, and Disk Utilization performance of their Instances. Not surprisingly, they want this information for things beyond just Instances. They want to understand performance for functional business groups and workloads running across functional clusters.
The discussion on Instance Performance also touched on the desire to review Instance Types to determine if the correct Instance had been deployed for its use case. Most customers had little to no insight if they were using the correct resources and when in doubt, they deployed something larger to ensure success.
A number of customers expressed concern that they felt “exposed” due to lack of visibility.
#6 – Consolidated View – Finally, tied for #5 was a report/visual that would allow organizations to see everything they had in one place. We heard repeatedly that customers had multiple consoles and dashboards that they had to look at in order to see their cloud environment.
The problem with a “multi-console” approach is that there is no single source for information. It’s difficult to track and things aren’t necessarily reported in the same way...in some cases they don’t even speak the same language.
Customers said that it’s critical to not only see everything in one place – accounts, assets, services, groups, costs, revenue, provisioning, performance, etc., but it is also important to have an understanding of what’s changing in the environment and to be able to trace activities through some type of Audit report.
So there you have it. “The Most Frequently Requested Reports for Managing an AWS Cloud Environment.”
Here are the key take-aways from our conversations:
Performing spreadsheet analysis to get reports is awful – tedious, time consuming, somewhat inaccurate, most of the time outdated before the report is finished. Flexible reporting is a must.
Correlating cloud costs to business groups and metrics is critical, yet elusive.
Making decisions when you can’t visualize the impact and result is a stab in the dark and can leave you very exposed.
“Snapshot in time” reporting is not good enough. Data reporting must be continuous and give a historical perspective. The cloud is constantly changing and so is the infrastructure and services we are trying to manage.
- Managing the cloud is a business issue…especially if the cloud is your business.
For most of us, when we think of our cloud ecosystem, we immediately think infrastructure - servers, storage, networks, applications, VM’s, hypervisors, load balancers, etc. We also think scalability, on-demand, and self-service for IaaS, PaaS, and SaaS. And, don’t forget we have to manage the infrastructure, so there are configuration/provisioning/deployment tools and fault/performance tools to manage our networks, systems, storage, security, and applications.
But, from a business perspective, what is the cloud made of?
Looking at the cloud from a purely technical infrastructure point of view does not provide a "holistic view of the cloud." An organization’s cloud ecosystem also includes numerous business processes and groups. There’s pricing, billing, revenue, budgets, and forecasts. We have customers, products, services, departments, and environments. Each of these “non-technical” cloud components is an asset within the environment that helps to define value to the business.
Value can be defined in many ways and is unique to each organization. It dictates how we measure and report on the assets against business objectives. For example, we can technically measure cloud infrastructure by it’s availability, capacity, performance, redundancy, and security. Things that answer the question, “Are my cloud infrastructure and services up, responding, backed up, and safe?” But from a business perspective we must also be able to measure availability, capacity, performance, redundancy, and security for specific functional business groups utilizing the cloud. We need to answer the question, “Am I delivering the appropriate service level to my customer/user/service/etc.?”
From a business perspective we must also evaluate and measure things like; cloud resource availability compared to end-user expectations, OPEX & COGS of cloud resources compared to budgets, cloud usage against forecasts. These are metrics that answer the business question, “Am I delivering a viable business in the cloud?”
So, a holistic view of the cloud needs to include an aggregated and integrated view of all assets within the ecosystem. We need to evaluate how they are performing, and how they measure against expectations as they relate to the business and technology groups consuming the service. We should compare the business drivers of these groups, (budget, forecast, revenue, etc.) with the associated performance and cost. Ultimately, we need to be able to optimize performance and cost based on value to the business and the goals created for our cloud ecosystem.