Just how important is a cloud API anyway?

14 06 2011

Since the dawn of the computer era complex hardware and software systems have been plagued by a fatal shortcoming that leaves them far less effective than they might have otherwise have been. The designers of these systems often failed to develop them with a critical feature in mind – Management. Management as a feature you might ask? Indeed it is and yet it’s always the feature last thought of.  It’s no surprise then that users complain about the management capabilities of most complex systems’ so called management products.

The Management of a thing is often more costly and complex than the thing itself, yet management of any technology that’s worth its weight in tin has always been an afterthought. Why is this and what does it mean for the cloud? In part, management is not well understood so the folks that design systems don’t focus much effort there. But beyond that, management is often thought to be provisioning. Or monitoring. Or security. Rarely is it looked at as a life cycle that encompasses those activities and more.

The result is that management technology has traditionally been bolted on after the product is developed (HP Openview) or rendered so simple as to be difficult to use (SNMP). It almost always ends up as an arcane CLI to cover the basic “management” check box. In an odd way this is understandable. Design teams focus on features – feeds and speeds and other, sexier, line items on the data sheet. They then ship the system and move onto the Next Big Thing. In the meantime customers have to install and operate” the thing” and subsequently have to manage it.

So, left to fend for themselves, they create their own DIY way to manage the technology.

This happens because vendors of “The Next Big Thing” typically have no idea how customers will actually use their products.

About a decade ago customers started asking for “APIs” to interface with the complex systems and, being nothing if not customer focused, the product folks obliged. Unfortunately they still didn’t know how customers used their products so the first generation of APIs where very heavy, complex things that were not very useful. Script controlled CLI lived on.

But a funny thing happened as a result of the IT vendor rush to the cloud. Companies like Rackspace developed their cloud products as if they were going to use it themselves (in fact they do!) and APIs became a significant feature of the product. Good, fast, useful APIs even became part of the definition of what a cloud was! Suddenly, the API as a feature became the API as a product and the API as a service.  Rackspace now has a robust, supported, well documented API and is a pioneer in perpetuating APIs via the OpenStack project.

The rise of the API has become critical because it allows customers to use products in ways the vendor never could have imagined. APIs enable a thriving partnership ecosystem like the Rackspace Tools Program so that companies like Smartscale can innovate and rapidly develop feature that customers think up. Smartscale adds value on top of the Rackspace platform so that users don’t have to. But most importantly the Cloud API starts a conversation about what customers really want a product to do and it gives them a way to express their requirements with code.

We have moved from SOAP to Open Flow, baby steps to a brave new world that has seen open religious wars over the importance of API compatibility in the cloud. The power of the cloud comes from the API so we can define the management we want without having to wait for a vendor to update the clunky CLI.





SaaS, PaaS or IaaS – nobody rides for free

14 04 2011

“The mountain is high
The valley is low
and you’re confused on which way to go” – Free Ride, Edgar Winter Group

In the 1970’s a buddy and I decided to hitchhike our way across the country. Occasionally we would catch a ride with someone whose bumper sticker declared a desire to be compensated for hauling us to the next stop. That iconic 70’s bumper sticker came to mind during yesterday’s VMware Cloudfoundry announcement. Brilliant demo after brilliant demo ticked off but I still had this nagging sense that, just like our trip across the USA, there is still no free lunch to be had, particularly in the cloud.

“But”, you might complain, “look at all the open source software for cloud, the cloud is Free!” Indeed the last 8 months in the cloud have been unlike anything we’ve ever seen in the IT industry. The speed of innovation has been breathtaking and the competition particularly brutal. Starting last July with the announcement of OpenStack, a free, Open Source IaaS platform that, when delivered, will instantly crush the business of about 20 odd Cloud Stack vendors, to yesterday’s VMware announcement of the next major turning point in the cloud – Cloudfoundry – a free Open Source PaaS platform that will instantly dissolve the business of the dozen or so PaaS vendors (including one of VMware’s own products VMForce) the cost of cloud software has been a race to zero.

Both of these stacks are awesome and the prospect of being able to stand up either or both of these types of clouds with no software cost is just unbelievable and inspiring and downright cool. That is until you realize that you still have to manage the underlying systems of these clouds.  Whether its racks of computers, storage and network gear in your own datacenter or zillions of virtual machines in a public cloud provider you will need staff and tools to keep your cloud engine running. Both IaaS and PaaS stacks do a great job of obscuring the supporting technology and, like the idiot lights in your car, can make you complacent about the humming hardware underneath the hood. So with software now free, hardware prices dropping exponentially and datacenters getting more efficient (reducing power costs), the only real costs left are the management costs. The people and the tools to help them manage the infrastructure are more critical to success than ever before and, while management has traditionally been a back burner IT component, it is often the most critical and costly part of a cloud system at any layer – SaaS, PaaS or IaaS.

We returned from our 70’s journey a bit older and a lot wiser about the world. As you make your way into the cloud remember that, as alluring as it sounds, it’s not free.





Amazon at the Crossroads

10 07 2010

As things stand today Amazon, with its very popular Amazon Web Services suite of products, is the largest and most successful of the cloud computing companies. In fact, they may be the only cloud provider company making money in the cloud business as this is turning out to be a tough market. (Disclaimer: I am using public/private cloud vendors to mean “cloud” for this article and specifically excluding SaaS vendors that like to call themselves “cloud”).

Unlike the 1995 Web 1.0 bubble where anyone that could hack HTML and Perl could start a million dollar company, cloud is proving to require an order of magnitude more skill and financial resources in order to be a player. Companies are having to invest significantly and show patience as this cloud market slowly rumbles to life. The stakes may never have been so high and it has brought out the worst in the market players so far.

But why is Amazon who have a four year lead on ATT, IBM, Microsoft, HP et al in anything less that a perfect postion? If Amazon plays its cards right, it would seem,  it could use its chronological and technology lead to cement itself as the next big IT platform leader. Cisco, VMware, BMC and other traditional enterprise vendors are all deeply concerned with the notion that Amazon wants to be the World’s Datacenter.In fact, Amazon is wildly popular with small, start up companies which is interesting given that market’s infatuation with open source and freemium business models since Amazon’s web services are neither Free or Open (a fact the incumbent players whine about constantly).

The problem for Amazon is they are traditionally a consumer company. They sell stuff on the web. Amazon has little experience dealing with big business as a customer and far less still in building the ecosystems of partners and resellers it takes to become successful in the enterprise arena. The question is, then, will they try to be like Microsoft or will they try to be like Apple?

Recent history may hold the answer.

Microsoft built its market share largely through monopolistic business practices in the Eighties and Nineties. This meant that, to be a Microsoft ISV, you were getting into bed with a very dangerous potential competitor. As a Microsoft ISV pre-antitrust you had to have your product running on Windows, but in doing so you risked having Microsoft steal your idea and either embed your functionality in its OS or get into the application business and compete directly against you. Many a well funded and otherwise successful ISV succumbed to the Microsoft “ecosystem” approach. No need to list the victims like Netscape, Lotus and Word Perfect here. They are well known.

Apple, on the other hand, with it’s wildly popular new Apps store, has taken another tack. Although its implementation has been a bit hamfisted so far, its market approach to developing an ISV ecosystem has resulted in 200,000 ISV applications and a billion application downloads in only a year or so of operations. To be sure there are other problems with the iTunes model such as store overcrowding and the Voodoo like application selection process but those will be resolved once Apple reconciles the resources it has on the app store with the demand for inclusion in it. The point is that ISVs have little worry that Apple will take their idea and compete with them.

This raises the question of the future of Amazon’s AWS platform. The short history of AWS is one that has it’s origins in a purely Infrastructure as a service model. This was very attractive to entrepreneurs who saw loads of opportunity to build value on top of the platform and were willing to risk investing in a small but potentially high growth market. The present Amazon is migrating to a PaaS model and, in the process, killing off it’s fledgling ISV ecosystem

But over time AWS has added functionality that seems to compete with the budding AWS ISV ecosystem players. Features like the AWS Management Console, Elastic Map Reduce and CloudWatch monitoring compete directly with companies like RightScale, Concurrent, Ylastic and Hyperic (representing over $25 million in venture capital investment) At the same time Amazon has done little in the way of ISV ecosystem development. It’s partnership programs are “place holder” at best. Their AWS business development strategy seems to be an ad hoc, tactical effort.

This is not the kind of ecosystem one would expect from a serious platform contender.

So, will Amazon think that it can and must build everything in order to attract the Enterprise customer, or do they intend to develop and nurture an ISV market like virtually all other successful platforms? Will Amazon open the door for Google and Microsoft by killing off its nascent ISV market? Does Amazon, until now a consumer company, even realize how their actions are impacting their budding ISV ecosystem? My guess is it’s more a function of inexperience than monopolistic intent but the impact may very well be the same.





Is the Cloud more or less expensive than co-location?

7 06 2010

Last year industry lobbyist Uptime Institute commissioned a McKinnsey report on the cost of Cloud Computing designed to inject FUD into the cloud debate.

The report from McKinnsey claimed that Cloud Computing is MORE expensive than the traditional, physical data center.

While  McKinnsey gave this report at the Uptime Institute, who’s membership is dominated by data center operators and Managed Service Providers, cloud computing’s main competition, the report does make good points about the hype and the mistaken use cases touted by some cloud proponents. This is reminiscent of the level of hype/promises in the mid 1990 about the World Wide Web.

Many of the claims and counter claims being made about Cloud Computing were meaningless at that point as there weren’t enough practitioners to make debate relevant. Fast forward a year and Amazon’s AWS service is reported to be doing half a billion dollars in revenue per year. Obviously Cloud is catching on.

So we decided to see if that jump in Cloud usage was driven by Cloud becoming cheaper than co-location. Prices have adjusted a bit and concerns over security are getting solved or proven to not be problems after all.

In order to help shed some light on the value and risks associated with Cloud we will attempt to do a simple, apples to apples financial comparison between two popular alternatives for building a Greenfield data center using both “The Cloud” in the form of Amazon Web Services and building a physical data center.

Can a datacenter be built in the Cloud with economics similar to co-location?

Companies are being bombarded with hype about Cloud Computing. Large, incumbent vendors are re-branding their legacy technology as Cloud, while the media labels every technology under the sun “Cloud” in order to drive readership. It’s no wonder that the picture around cloud is murky at best. This not only creates confusion, it forestalls companies from making rational, timely decisions about if and when to use cloud computing. In order to help shed some light on the value and risks associated with Cloud we will attempt to do a simple, apples to apples financial comparison between two popular alternatives for building a Greenfield data center using both “The Cloud” in the form of Amazon Web Services and building a physical data center.

Scope

This analysis examines the potential for using Amazon Web Services (AWS) as a virtual data center with building a traditional physical data center in a colocation facility such as Savvis, ATT or IBM. To keep things simple we have not included a third option of locating and building a data center at company owned property as that alternative adds the costs of real estate, power, cooling, taxes and physical security to the equation greatly increasing costs over either of the first two approaches (but that is certainly possible to do and has the benefits of ownership and physical control.)

We have also not included storage, data transfer, CDN, monitoring, geo-location and other extra features as direct cost comparisons are difficult due to the difference of buy vs. build for most of them (while one can buy these features from AWS or build them yourself, it is difficult to calculate the cost for the latter and, therefore, to make a fair comparison between the two.)

Assumptions

We’ve used as an example a medium sized data center model comprised of 1000 servers. The assumptions are that all the servers live in one datacenter located in a single US geography with no failover or disaster recovery. I’ve assumed there are 40 servers per rack for a total of 25 racks and that the colo facility will charge $1000 per powered rack per month. The average cost to buy a quad core commodity server is $2500. I’ve also assumed that networking gear will equal 20% of the server budget. We also assume that procurement for the colo approach will be spread equally across each quarter of a fiscal year in order to better control budgets and to give operations time to ingest the hardware and that all of this capital budget is absorbed in the first fiscal year. We have also assumed that, as a result of an AWS feature called Elastic Load Balancing – the ability to automatically bring servers up and down based on load – the absolute number of servers needed in the AWS approach is half of the colo approach. This may be conservative as physical servers typically run at 25-30% of their capacity. It is also common to provision physical data centers for “worst case” scenarios that can only be estimated. Lastly we’ve assumed that, in a cloud based datacenter, admins can better leverage automation tools and so have a two to one advantage in productivity over admins in a physical data center. (This may also be conservative as we’ve seen anecdotal evidence of a Ten to One advantage.) The cost of building that kind of automation (i.e. a private cloud) would be prohibitive for this small a data center.

Conclusions

The analysis shows that during the initial investment year one, AWS has a significant advantage of over 60 percent less that the colo approach. However, over the three year life span of a server AWS would costs almost 19 percent more than the colo approach. In year four, when a server refresh would be in order for the colo, the procurement cycle would repeat meaning a new investment of Three Million Dollars while the AWS approach cost would be steady state or declining slightly. Therefore, in year four the four year accumulated advantage swings to the favor of AWS by 18 percent.

It’s important to note that this model does not capture the value of time to market. The time required to build out each data center is dramatically different. While an AWS based datacenter of this size could be brought up for the first time in a matter of days (or hours), a physical datacenter of this size would take months to accomplish. In fact, companies that have used the cloud cite business agility as the number one advantage of a cloud over a physical data center – not cost differentials. Additionally, the time and cost required recreating the management tools, virtual machine support, monitoring and other software that would put a colo on par with a cloud for ease and rapidity of deployment (i.e. a private cloud) is considerable – perhaps more than the entire data center itself.

So what are your thoughts?

To download the white paper and supporting spreadsheet –





Enterprise Clouds: The last gasp of the old gaurd

18 05 2010

The Last Router

I have asserted in previous blogs that the term Enterprise Cloud is an oxymoron created by incumbent IT vendors and worried CIOs who fear that they are on the verge of massive change that won’t be in their favor.  My position is even more resolute now that Virtual Datacenters in the cloud will replace physical datacenters in the basement because they are cheaper and easier and don’t require power, real estate or large IT staffs. The result will be the utter collapse of the current incumbent IT vendors. Amazon, just four years after creating the IaaS market is generating $650 million dollars a year from this “side business”. Today I believe my thinking has been off a bit. I now believe Cisco will sell its last Enterprise Router in the year 2015.

To some people that’s a pretty scary prediction – it should be.

There has been much debate about whether CIOs will ever move their brick and mortar (iron and wire?) datacenters into the cloud because of concerns over data security or insufficient SLA or simply the loss of control. CIOs in general don’t like being on the leading edge of a technological sea change because they find little, if any, value in that kind of risk. However, at the dawn of the SaaS phenomena the CEO took CRM away from IT because it was clearly a cheaper and better solution for automating the sales force.

In the datacenter world it’s clear that the ridiculous and socially irresponsible costs of running a power sucking, carbon spewing enterprise datacenter with a footprint the size of a football field, 24/7/365 does not help anyone’s bottom line. The fact that it’s a beehive of headcount doesn’t help. Moving the datacenter into the cloud, it will be reasoned, will free up resources to focus IT on solving business problems rather than tending to infrastructure. After all, who’s IT staff is more competent, yours or Amazon’s? In the end, given all of the risk and change and pressure from entrenched IT vendors, CIOs will not choose to move their datacenters into the cloud. Their bosses will.





How Cloud Computing will change the nature of Data Center jobs

28 11 2009

In this economic environment it’s understandable that people are concerned about anything that could cause job losses. Globalism, for all its benefits, has been disruptive of many industries workforces and, according to the latest polls , 36% of us are worried about our jobs. The advent of Cloud Computing and it’s data center automation characteristics has, at first glance, the potential to eliminate the jobs of many data center workers. Cloud Computing, the argument goes, will ultimately gut the data center staffs of large and small businesses alike.

There may be some credence to that argument.

Cloud computing has the potential to disrupt an entire class of IT worker, those that physically build and maintain the data center. While Cloud vendors, ourselves included, are touting the cost benefits of the new technology we generally talk about converting Capex to Opex. Additionally, we site time to market or “Business Agility” as another key cost reduction benefit. Most of us, however, don’t see data center work going away. Rather, we see it changing from one of pulling cables and inserting blades to building monitoring and scaling policies or writing VM bundling scripts. Maybe writing a few lines of Ruby to enhance a puppet library. The workers that do the physical labor in the data center will still be needed but most likely will need to migrate to the geographies that host the massive new cloud centers being built in places like Oregon, Washington or the Mid West’s wind farms.

The classic Sys Admin, however, still has a role front and center in the new Cloud based data center. The Cloud Sys Admin never again sets her eyes on a physical server but instead manages a 10,000 node grid from her iPhone while standing in line at the corner cafe. Not necessarily a bad thing…