Archive for June, 2011
Boston CTO monthly b’fast meeting. VC panel: “Bring me this business plan for …. x” http://t.co/CLwmbbr
cloud promises quick
beware hidden expenses
elastic apps fix
In 2006 Amazon Web Services flashed brilliance with a “light bulb moment” that sparked the imaginations of leading edge technologists and entrepreneurs. Literally overnight “The Cloud” had arrived. The cloud offered the ability to create, launch and operate SaaS applications in a way never before possible. Using simple and secure API’s a software engineer could harness vast quantities of compute and storage services, on-demand and with no up-front costs, without touching a single physical atom. The cloud allowed small, efficient teams to build an application that could serve a very a large audience.
Within a couple years of launch, Amazon Web Services, nee “the cloud”, brought cloud computing to the technical masses. Thus was coined the phrase “infrastructure as code” and a new reckoning by the old guard enterprise software, hardware and hosting companies that times were changing (and in 2011 hindsight, the times would be changing rather quickly.)
For a technologist, cloud concepts seemed deceptively simple: Just design a software architecture that is tuned for cloud computing operating characteristics. The cloud offered the capability to automatically scale up and scale down. The cloud offered cost efficiencies. The cloud offered incredible reliability. And all these fine attributes were possible without sacrificing one for the other. For software architects used to the traditional co-located hosting design patterns, the cloud was something entirely new to comprehend. The differences are many, but the reward for adopting the cloud and succeeding was greater than the hardship to change our collective thinking.
The core requirements for every SaaS application are scale-up, reliability and efficient infrastructure utilization. Scaling in the cloud means harnessing the on-demand capabilities. Reliability in the cloud means designing for failure by making software mirror what “physical” hardware used to supply in the co-located world. Operating cost-efficiently means “gaming” the cloud to find every place where you can process more work with less compute resources.
But in reality, taming the cloud is not a trivial pursuit. If in this new “cloudy” world infrastructure is code, and invoking more API calls can launch more infrastructure, then we thought we were dining at the “all you can eat buffet.” Heartburn ensues. The best guidance is before you start to build a cloud-enabled application you need the scaffolding in place to “raise the app” with all the necessary supporting infrastructure required to operate a dynamic cloud-based SaaS system. Retro-fitting the augmenting management framework after the fact is the wrong approach for the cloud. This approach worked in the old world with software designed for dedicated hosting, but the cloud is such a different environment the old world thinking does not transfer well to the new cloud world.
Below are three prime areas to focus on when planning to build a cloud-based software stack.
1. Effective Budgeting with a Cost Control System
Compared to a traditional dedicated data center environment, it’s way too easy to spend money in the cloud. “Purchasing” in the cloud is psychologically different when the duality of two mindsets (using purchase orders to buy everything up front versus consume small bits at a time) have to reconcile with the vastly different operating styles of dedicated compared to cloud. In the dedicated environment, big capital expenditures get multiple approvals and are on many people’s radar. But in the cloud, most teams start their cloud relationship with a credit card and pay monthly for the previous 30 days of small micro-charges for gigabytes of storage and hours of cpu time consumed. Read more…
(ed. A version of this post appears at the Sonian Big Data Cloud blog)
A cloud software company’s worst nightmare came true for Dropbox this past weekend when a software bug allowed anyone to login to an account (over a four hour time period) using any password. It’s unknown if or how many accounts were accessed inappropriately. So far there are no reports of data breaches.
This recent occurrence, coupled with other non-cloud, but seemingly similar themed data breaches as reported by Citi Bank, Sony and LulzSec, has moved the “can the cloud be secure” conversation into the spotlight. The short answer is yes, the cloud is secure, and here is why.
Defining Cloud Security
Data security in the cloud is a combination of “inherited responsibilities” between the cloud infrastructure provider (Amazon, Rackspace, Softlayer, etc.) and the independent software vendor (an ISV, i.e. Dropbox), and the customer.
Data security in the cloud is really two components: resiliency and privacy. Resiliency means when a customer stores data in the cloud, the cloud vendor should not lose that data. Privacy means nobody but the customer should be able to “see” the data stored in the cloud.
The cloud vendor is responsible for data resiliency. Cloud vendors provide Service Level Agreements (SLA) that provide a measure of resiliency so that customers can compare one cloud versus another. For example Amazon Web Services provides a “eleven-nines” of cloud storage resiliency, while SoftLayer offers “five-nines.” These SLAs are far better than what a typical enterprise can achieve in their own data center.