What followed this incident was a commitment to take a different approach to DevOps. We brought in a new DevOps leader, added some talented engineers, provided the team needed breathing room, and invested in the critical path projects the engineers felt would pay the most dividends: proactive monitoring, cookbook standardization, streamlined release management, and the development of essential internal tools. What followed was a series of successive changes that resulted in a “tipping point” for our DevOps investment, driving increased reliability, quality, scalability and maintainability of our infrastructure. This investment has also resulted in a series of powerful innovations in asset, cost, security and system management, some of which we have found the time to provide back to the open source community (e.g. Sensu, SmartCloud implementation of Fog).

In reflecting back on that experience, we iterated multiple times through what I now realize was a virtuous cycle. We initially invested in automation in order to increase the standardization and reliability of our cloud infrastructure. This investment resulted in better quality and maintainability of our infrastructure, which allowed us to be more agile in our release cycles. Faster releases allowed us to increase our pace of innovation, which provided better operational and system scalability. The increased scalability allowed us to get ahead of our growth, enabling investments in proactive automation and tools, which resulted in the virtuous cycle starting again.

While there is likely no single playbook to get a DevOps team to enter the virtuous cycle, ours started with a talented team, good leadership, commitment to the culture of DevOps, and a willingness to follow the instincts of the engineers.

___

Re-posted with permission from HighTechInTheHub.

CloudHealth Technologies is searching for a DevOps lead to design, automate and support our cloud infrastructure. A successful candidate will be one of the founding five members of an engineering team building a cloud performance management platform. They should have deep knowledge of Chef, Ruby, Linux and Amazon Web Services. They should also have a proven track record in automating cloud infrastructure, be an active contributor to open source, and be passion about infrastructure as code.

If you want to learn more, send us an email today.

History
Cloud management is actually a faster growing extension of the systems management industry, which was estimated by Gartner to be $18 billion in 2012 with an 8.5% CAGR. Just as systems management is not a single product category, neither of course is cloud management. Instead cloud management is comprised of several product categories, each an emerging market segment in its own right.

By way of history, the product categories for systems management vendors of physical infrastructure resulted in numerous successful IPOs and acquisitions in the 1990s and 2000s, creating many billions of dollars in shareholder value. This market growth was then consolidated over a decade into a few companies, primarily IBM, HP, BMC, CA, Microsoft and Symantec. To give a sense of scope of the individual markets, Gartner estimated the 2012 size of availability & performance management to be $4.6B, configuration management $3.4B, application management $2B, and $1.8B for network management.

But the disruptive innovation of cloud computing has fundamentally altered the systems management landscape, spawning a new crop of cloud management vendors that are filling the wide gaps left by their systems management predecessors. We’ve watched as new names (e.g. PuppetLabs, Opscode) have stepped in to fill the gaps created by the inability of legacy systems management vendors to address the challenges of the cloud. With the very successful IPO of Splunk, there are early signs that history may again be repeating itself.

The Taxonomy
To put some order to the evolving product categories, we have divided the industry into five product categories and four phases, e.g.:

The categories reflect the problem to be addressed by a product, and include:

• Automation & deployment - Products focused on automating and deploying cloud infrastructure and applications.
• Configuration management - Products that enable the control and risk management of changes to cloud infrastructure and applications.
• Fault management - Products that provide real-time alerting and/or notification of current or potential failures in cloud infrastructure and applications.
• Cost management - Products that optimize the cost of cloud infrastructure and applications.
• Performance management - Products that optimize the performance or availability of cloud infrastructure and applications.

The four phases reflect the lifecycle in which a customers’ cloud infrastructure progresses, including:

• Plan - The planning process for deploying cloud infrastructure and applications.
• Deploy - The deployment of cloud infrastructure and applications.
• Manage - The ongoing operations and support of cloud infrastructure and applications.
• Troubleshoot - The troubleshooting of issues with currently managed cloud infrastructure and applications.

Using this taxonomy, you can draw circles around the vendors to understand their positioning in the market. To demonstrate, we’ll show a few examples.

Example Usage
We have made a controversial decision in my examples: if a vendor does not support the planning, deployment, management and/or troubleshooting of public, hybrid or private cloud infrastructure, they are not a cloud management vendor. Unfortunately many vendors are re-marketing their distinctly non-cloud products as cloud, further confusing the industry and potential customers.

Deployment Management
The left circle shows what is by far the most crowded and hotly contested area of cloud management: the automation, deployment and configuration management of cloud infrastructure and applications. The products include both open source and commercial solutions, and span vendors such as RightScale, Enstratus, ServiceMesh and DynamicOps (VMWare). There are 30+ vendors in this segment, with no clear market leader, and a lot of Do It Yourself (DIY) among customers. In addition, cloud vendors are increasingly seeing this category as an extension of their cloud services (e.g. Amazon OpsWorks, Cloudformation and ElasticBeanstalk).

Fault Management
The next circle shows the emerging fault management category, which is a semi-crowded market that has also seen some early IPOs / acquisitions (e.g. CloudKick). To further confuse matters, some of the vendors in the Deployment category offer basic fault management features, which often are insufficient for most customer use cases. No product here has strong brand recognition, and there is an ongoing love-hate relationship here with the open source product Nagios.

Cost Management
We are not yet convinced cost management is a standalone value proposition, or is a feature of another product category. But this category has several active players (e.g. Cloudability, Cloudyn, Newvem), primarily focused on helping you understand your Amazon bill. Since this category did not have a corollary from the systems management industry, it will need time to mature in order to accurately predict its future – but there is at least enough vendor activity to warrant its mention.

Conclusions
We strongly believe we are watching the disruption of an $18 billion industry, as existing market leaders in systems management struggle and fail to break free of the value chains that anchor them to increasingly outdated and ineffective value propositions. The result: this may be the most exciting transformation of the IT  management market since the emergence of the world wide web.

The core tenants for the engineering team at CloudHealth Technologies are a reflection of my past experiences, including:

Hire Great Engineers
While great engineers come in all shapes and sizes, they share a few common traits: strong analytics, a passion for the craft of building software, a desire to tackle complex problems, and a drive to build products that matter. They also share one other trait: they prefer to work with other great engineers. We desire to hire only the best engineers from their previous companies. When it comes to hiring, we focus on talent over specific experience, passion over work history, and analytics over previously held titles.

Clarity of Mission
The mission of CloudHealth Technologies is to deliver software that delivers business performance management for the cloud. To achieve this, we are building a highly distributed multi-cloud SaaS infrastructure that collects, analyzes and correlates billions of data points from disparate data sources each day. The solution takes unique advantages of building on distributed cloud fabric for near real-time elasticity and fault tolerance. We seek engineers that want to join our mission and embrace the challenges the come with complexity, scale, and big data analytics.

Lean Startup Thinking
Our company was founded using Lean Startup principles, and so continuous customer engagement is in our DNA. We believe startup success derives from the acquisition of validated learning, and that the greatest epiphanies that arise from constant experimentation. At CloudHealth, product management is not a department, but the company.

Just Enough Process
Too much process will suffocate a great team, and too little will produce chaos. We strive to achieve just enough process. Our current process is agile, leveraging Kanban for flow and Scrum for organization. But we also know the right process is one that continuously evolves to meet the changing needs of the team, product and business.

Passion
You can see our professional passion at a design meeting or code review: the team expects excellence, whether it is in the approach to handling of exceptions or the adherence to the right design pattern. We have a no compromise attitude to the software we create, and we expect each member of our team to deliver to the highest standard.

Continuous Learning
Autodidacticism is a trait shared by many of the best engineers in our profession. We seek engineers who are engaged in open source projects, hack new technologies in their free time, and always strive to learn more.

Joining Our Team
At CloudHealth, we believe we can create one of the best software teams in Boston, building products that drive real customer value and support a fast-growing business. If you have an interest in joining our team, please contact me directly. I can always make time for a cup of coffee with a talented Boston-based engineer looking to learn more.

___

Joe Kinsella, Founder & CTO

• Price per virtual core per month – used to evaluate the cost effectiveness of the processing power of the instance type
• Price per GB disk per month - used to evaluate the cost effectiveness of disk for the instance type
• Price per GB memory per month - used to evaluate the cost effectiveness of memory for this instance type

Result: Processing
Rackspace and Amazon offer the most cost effective options for compute, with several instance types in the $40-$50 range per virtual core per month. For example, the Rackspace 1024MB RAM 40GB Disk instance comes in at $43.20 per virtual core per month. An Amazon m1.small is also highly competitive, coming in at $44.01 per core per month. Rackspace has several instances on the high side as well, with the 30720MB RAM 1200GB Disk instance costing $1296.00 per virtual core per month.

Result: Disk
Amazon dominates the category for cost effective local disk for an instance, with a price of $0.21 per GB per month for several instances, including the m1.large and m1.xlarge. On the extreme high side of cost per disk we have Microsoft, with $1,478.44 per GB per month for its ExtraSmall instance (note: this is skewed by the fact the Azure PaaS model expects the usage of BLOB storage instead of local disk).

Result: Memory
Amazon provides the most cost effective options for memory, with several instance types in the $13-14 per GB per month range, including the m2.xlarge, m2.2xlarge, and m2.4xlarge instance types. The best in the category is the Amazon cc2.8xlarge, which comes in at $13.03 per GB per month. IBM comes in on the high side, with 7 instances pricing between $53-86 per GB per month, including the 64-bit Copper, Bronze and Platinum instance types.

Instance Type Comparison

[table id=4 /]

[table id=2/]

The four fundamental architectural principles that separate cloud and legacy applications include: design for elasticity, design for infrastructure as code, design for unreliability, and design for platform services. Software architectures that fail to take advantage of one or more these principles are less likely to be effective cloud applications, and more likely to increase the ranks of future cloud dropouts.

Design For Elasticity
The dirty little secret of the cloud is that running cloud infrastructure is in general more expensive than running dedicated physical hardware. The primary economic advantage of cloud computing is consumption-based pricing, which is only effective if you have: a) moderate to substantial inefficiencies in your management of physical hardware, b) high infrastructure growth rates, or c) software that can take advantage of elasticity.

Taking advantage of elasticity requires adhering to design principles such as loosely coupled services, idempotency, asynchronous communication, infrastructure automation, and integrated intrumentation. Adhering to only some of these design principles yields a more rigid software architecture, not fully capable of exploiting the potential of elasticity.

Design For Infrastructure As Code
Most cloud applications are built on the principle that infrastructure is code. This results in efficiencies in developing, deploying and operationally supporting infrastructure that transform the traditional economics of software. It also results in architectures that emphasize software over hardware, effectively relying on virtual equivalent of commodity hardware. The investment in automation is also a core building block for scaling, elasticity, and the ability to leverage new cloud-based pricing mechanisms (e.g. auction-based pricing, reservation pricing).

Design For Unreliability
While pre and post-cloud architectures share many similarities, there is one area where they differ dramatically: their expectations toward failure. Pre-cloud architectures assume failure could occur; cloud architectures assume failure will occur. Amazon stated in its 2007 paper Dynamo: Amazon’s Highly Available Key-value Store that “customers should be able to view and add items to their shopping cart even if disks are failing, network routes are flapping, or data centers are being destroyed by tornados.”

In other words, the cloud architectures assume failure is the rule and not the exception; whereas most legacy applications are designed for reliable performance and physical proximity (e.g. consistently high disk IOPS, consistently low network latency). The result is the cloud is often an adverse computing environment for legacy applications.

Design For Platform Services
Cloud computing vendors have gradually moved from low-level compute and storage to application services such as databases, key-value stores, and object stores. While platform services are still in the early stages of maturation, these services offer core building blocks that can eliminate substantial software and operational complexity from your applications. Cloud architectures are becoming increasingly reliant on point vertical services that eliminate complexity while providing cost-effective platforms for future growth.

Conclusions
I wince every time I hear of someone migrating their legacy application to the cloud with no architectural changes. While we all know it can be done, I can’t help but to think it is creating a new generation of cloud dropouts that will soon be blogging on why they moved back to physical hardware (e.g. Mixpanel, Zynga). If you are going to the cloud, do so with eyes wide open, fully embracing the design principles required for successful performance, reliability and cost in the cloud.

___

Republished with permission from HighTechInTheHub.com.

What Is a Reserved Instance?
Reserved instances allow you to make a one-time payment to your cloud provider in return for a discounted hourly charge. Amazon and IBM are the only two public cloud vendors that make reserved instances available today, each with very different incentives and pricing models. The cloud vendor rationale for reserved pricing is simple: by getting customers to commit to the usage of specific infrastructure, they can better manage their capacity, and therefore pass these savings on to their customers.

Amazon provides three types of reserved instance types: light, medium and heavy. You can reserve instances for either one or three years, depending on how long of a commitment you are willing to make. Heavy reserved instances provide the best discounts, but require more utilization over the term to realize the full benefits. In addition, three year terms provide better cost savings to one year terms.

Analyzing Reserved Pricing
When Amazon first released its three types of reservations (heavy, medium, light) last November, I couldn’t help but think there must be a sadistic streak in the AWS pricing team. But when you analyze the model, it becomes clear there are some simple rules to determine whether reservations make sense for you. To better understand the model, we have provided the below table, which shows the price savings for a c1.medium instance (two virtual cores, 1.7GB memory, 350GB disk) at different levels of utilization.

[table id=3/]

As you can see, Amazon has linearly increased the penalty for underutilizing instances with each graduated reservation type (light, medium, heavy), while at the same time increasing the percentage utilization required to achieve cost savings during the reservation term. For example, a 3 year heavy reservation for a c1.medium that is used 80% of the the term will provide a 45% cost savings; but utilizing this node for only 20% of the term will result in a -119% savings. Note: all hourly costs in the table are computed by including the one-time reservation cost in the hourly rate, in order to provide what we consider the actual hourly rate. Also, with heavy reserved instances, Amazon charges you at 100% utilization for the contract term independent of what you actually utilize.

Rules for Using Reserved Instances
The basic rules you can follow to determine if and what type of instances to use are as follows:

• If you cannot commit a specific instance type for at least the next year, do not use reserved instances
• If you cannot commit to a specific availability zone for at least the next year, do not use reserved instances
• If you cannot commit to utilizing an instance for at least 40% per year or 30% for the next three years, do not use reserved instances
• If you can commit to utilizing an instance more than 70% for the next year or more than 50% for the next three years, use a heavy reservation
• If you can only commit to utilizing an instance for 50-70% of the next year, use a medium reservation *
• If you can only commit to utilizing an instance for more than 40% for the next year or 30% for the next three years, use a light reservation

By applying these rules to all your compute infrastructure, you almost certainly will identify one or more areas where you can save money through the use of reserved instances. A typical AWS customer can reduce their monthly bill by 30-40% using reserved instances.

Conclusions
Amazon is known as a price leader in cloud computing, reducing pricing on AWS services 19 times in just the last year. But one of the most underutilized pricing discounts has been available since 2008. So if you run instances on Amazon, save your organization money by losing your fear of commitment. At Chez Amazon, it’s reservation required.

___

Republished with permission from HighTechInTheHub.com.

Background on Disruptive Innovation
The simple fact is that existing market leaders are incentivized to invest in sustaining their markets. In the language of The Innovator’s Dilemma, they develop value networks of customers, suppliers and shareholders that influence a company toward the sustaining changes necessary to maintain and grow their current markets. When these value networks are confronted with disruptive innovation, they cannot effectively respond since it requires competing with and/or diverting resources from their established products, markets and customers.

Disruptive technologies are almost always easy for market leaders to ignore, since they start as inferior to existing mainstream solutions. Do you remember the high price and poor quality of the early digital cameras? The complexity of the first digital music players? The price and storage limits of the first solid state drives? The feature limitations of the first smartphones? It was only as they matured and began to enter the mainstream markets did established market leaders begin to view them as competitive. Those of us local to the Boston area need only to look at at the dead carcasses of our past – e.g. Digital Equipment, Wang, Data General, Polaroid, Apollo, Prime – to recognize the impact of disruptive innovation.

Disruption in the Cloud
When cloud computing first arrived in the mid-2000s, its price and performance were inferior for most computing use cases. But like all disruptive technologies, it offered features that appealed to a market segment with few or no alternatives: on-demand infrastructure and consumption-based pricing. These changes in characteristic appealed most notably to high tech startups, where the value of time to market and monthly billing trumped long term price and performance. Web hosting providers were one of the first to recognize cloud computing as a competitor, as Amazon Web Services started to adversely impact their market share. Not long after the cloud entered this first mainstream market, most industry analysts realized its disruptive potential and the cloud hype cycle had begun.

Since computing is a collection of different industries, the response to cloud disruption has varied. Some have embraced cloud computing, choosing to either migrate to the cloud or offer their own cloud services. Others have defended their current markets with a marketing-driven rebranding of their existing solutions, or by trying to offer low-end cloud services as a upsell to their more feature rich traditional services. And still others have hedged their bets, trying to embrace the cloud while hoping to delay the disruption in their existing markets.

Timing of Disruption
To qualify the timing and impact of the disruption, it is important to consider the different types of computing workloads. For the purposes of this analysis, we have chosen to categorize workloads as either cloud-centric and cloud-enabled*. Cloud-enabled is used to describe the legacy applications that are moved to the cloud (e.g. applications that leverage traditional software and hardware infrastructure); cloud-centric is used to describe applications that are designed for the cloud (e.g. applications that leverage cloud application services, automation, and cloud frameworks). The below graph shows the timing of the progression of the cloud computing disruption, with an expectation that the underlying cloud infrastructure will have matured to offer comparable or better performance and features for cloud-centric applications by 2013, and for cloud-enabled applications by 2017.

Last Words
This week the CIO of a public company said to me: “The cloud will never provide the performance necessary for running my SAP infrastructure.” While I couldn’t argue with him in 2012, I also couldn’t help but wonder if he and his predecessors may have said the same thing about the web, client-server, or even the personal computer. So while I nodded in agreement, I kept his business card so I can check back in with him in a few years.

Disruptive innovation is like a watching a slow moving tank heading your way: adapt or watch the treads roll over you.

___

Republished with permission from HighTechInTheHub.com.

How Cloud Pricing Works
To review what is wrong with cloud support, we’ll use Amazon as an example, since it is both readily recognized as one of the highest quality providers of IaaS services and is a pioneer in consumption based pricing. Amazon offers a typical tiered support model, with four tiers (Bronze, Silver, Gold, Platinum). At the high end (Platinum), you pay the greater of $15K per month or 10% of your monthly bill for phone support and 15 minute responsiveness; at the low end (Bronze) you pay a flat fee of $49 for access to community forums.

So if you are an Amazon customer who spends $100K per year on AWS infrastructure and need one hour phone support, you will pay an additional $10K per year for Gold support. Premium support – which comes with 15 minute response time and architectural support – would cost you an additional $180K per year.

There are essentially two problems with this approach to cloud support:

#1: Not My Issue
The classic software maintenance model was created before SaaS and MRR, and represented a way for software providers to drive recurring revenue. The typical model resulted in customers being charged 20% on average annually for a provider to support the software. The issue with applying this model to cloud support is that there is no custom installation of software for a customer, so the likelihood of the support being specific to the customers’ specific use is substantially lessened.

To prove the point, I did an analysis of one year of support issues across a series of AWS accounts for which I am responsible, and found that 80% of all issues were caused by failure or performance problems with the underlying APIs.  The breakdown was as follows:

• 38% of issues were related to the provisioning and deprovisioning of infrastructure (e.g. API call to delete instance becoming stuck)
• 21% of issues were related to reboot API requests either failing or taking an unexpectedly long time
• 21% of issues were related to performance issues with the network or storage infrastructure

Amazon offers a world class cloud with highly reliable infrastructure. But when my team opens a support issue, it is almost always not related to our application. The reason is simple: the interface between a cloud provider and a customer is limited to a well-defined API. The cloud provider does not support what you do with the infrastructure you provision with the API, and you do not have direct visibility into the health and performance of the infrastructure behind the API. So in effect, your support costs are paying for the privilege of asking what is happening on the other side of the API requests.

#2: Proportional Costs
The second issue with the pricing of cloud support it that it is priced proportional to your monthly costs. This actually made sense with software licensing, where the complexity of supporting an installation was directly proportional to its scope and thus cost. But as mentioned previously, the cloud provider is not actually supporting your specific use of their infrastructure, but rather the availability, performance and security of their infrastructure.

So if we exempt support issues related to failed or non-performing API calls, is a user with 100 instances likely to open 10 times the number of support issues as a customer with 10 instances? Is a customer with a 1000 instances likely to open 100 times the number of support issues as a customer with 10 instances? It is much more likely the frequency of support issues is related to the experience of the customer and quality of the cloud infrastructure.

Solution: Consumption-Based Pricing
The time has come for a cloud provider to innovate in the pricing for support. We need support services that are priced per incident, with different tiers to allow customers to pay more for either accelerated or consultative services (e.g. architecture consulting). In the meantime, I recommend customers carefully review their support needs and the available options to ensure they are getting the best value for their money.

___

Republished with permission from HighTechInTheHub.com.