by Bill Sempf
In the mid-nineties, new directions in managerial accounting made cost center bookkeeping popular in large organizations. In this model, departments within an organization traded almost like a miniature economy, with some departments earning a net gain for the company and some departments delivering a net loss.
The profit centers - as those who earned money are called - get to call the shots, because ultimately they pay for everything. Loss-generators - called cost centers - get to follow along. Information Technology departments become the poster child for the cost center ('cause those computers are EXPENSIVE!) and IT managers became sometimes destructively frugal. Because bonuses are delivered based on keeping costs low, no expense is spared the razor.
In the early 2000s, Information Technology departments began to show that they were more than cost centers. With the popularity of the Internet the web site suddenly became a profit center, throwing the model all out of whack. A faintly golden age of IT departments reared its head, while IT managers effectively got anything they asked for.
We all know the story from then to now. The bubble burst (again). The IT departments are cost centers (again). The IT managers are forced to make tough decisions and do more with less (again). It's like the nineties all over again.
Virtualization puts a lot more tools in the IT manager's belt than before; that's for certain. Cloud Computing - a natural outgrowth of virtualization and internetworking - offers even more flexibility because of an interesting shift in what bucket the costs go.
Here, we will look at Cloud Computing, a little history, and implementations. We'll perform some economic and accounting analysis, and then see how an IT manager might implement cloud computing in his or her own environment.
Some background on Cloud Computing
John McCarthy, the inventor of Lisp, mentioned in a talk at MIT that "computation may someday be organized as a public utility.[i]" He wasn't talking about internet access; mind you. That already is more or less a public utility. He was talking about computation itself - the virtual 'crunching of numbers' that business computing is so good at.
Defining Cloud Computing
Cloud computing is when a company or organization connects many computers to distribute processing power[ii]. As generally implemented, it is processing power virtualized and accessed over the Internet. The general idea is that of a user sitting at a terminal that uses hosted applications taking advantage of services, storage space and resources provided on another computer, through an internet connection[iii].
This definition means a lot of things to a lot of people. The average user is no longer using Outlook Express or Thunderbird for his mail; he is using Gmail. The average office worker isn't saving her word documents on her C drive anymore; she is loading them on SharePoint or Documentum. The average gamer isn't even getting friends together at the house to have a LAN party anymore; he is playing Halo or World of Warcraft against virtual opponents in a virtual space.
All of these are computing in the cloud, but cloud computing as a technological concept is clarifying with age. The big players are marketing cloud computing as a:
1. Scalable application hosting space,
2. with specific offered services,
3. billed like a utility.
Let's take each of these for a moment.
Providing an application hosting space is nothing new. Since the advent of the World Wide web in 1989 and its acceptance in 1995, organizations have been providing space to host web sites and applications for anywhere from free to thousands of dollars per month. Providing a basic web server and usually a set of libraries for web development, these web hosting companies are a needed part of the overall internet space. They provide large and small applications access points to the Internet from secure servers.
While application service providers do provide a standard level of libraries, usually it is restricted to one of the common web libraries, like ASP.NET or PHP or Perl. The first divergence of cloud computing from application service provision is that of the services offered. Protocols like SOAP and REST provide access via HTTP to higher-level services like ecommerce engines, secure messaging and document management. Cloud providers give access to this battery of services residing in the same network, making a truly distributed application platform.
Finally, the most important piece of the pie is the billing structure that has grown up around cloud computing. Just as Dr. McCarthy suggested, cloud computing is billed like a utility, not like a service, making a closer match between use and cost.
If you get cable TV, you pay for a month of the service, no matter how much you consume - it is a service. They provide a service and you subscribe. If you get electric utility, though, and don't use it, you don't pay for it. If you use a lot, you pay a lot. This is the utility billing model. Application Service Providers charge like a service, and cloud providers charge like a utility. This is key.
Riding a into history on a cloud
On that topic, let's take a trip into the past. Dr. McCarthy wasn't so far off back in 1961. IBM was already providing time sharing to small organizations with strategically located mainframes when he gave his talk.
Cray made inroads in the organizational time-sharing market in the seventies and eighties. With the increase in power of PCs, utility computing seemed to be lessening in necessity. The computing boom of the 90s changed a lot of that, because the data collection requirements of business increased.
The World Wide Web itself is a cloud computing environment, with its own user interface. Large scale hosted applications like Amazon and Google are practically clouds themselves. The next step - providing services from Google and Amazon to smaller applications - is a logical extension to the World Wide Web model.
Let's start with time sharing. When you talk about things coming around and going around, it doesn't get much closer than this. TSOs were set up by large computing companies, to share loads of application usage. Several services were offered, like programming languages, file processing and storage, and printing. Oh, and the service was billed by the hours connected, seconds of CPU time and space in storage. All of this sounds strangely familiar.
There clearly are some differences between the cloud and TSOs. TSOs are not capable to be accessed anonymously, which is a hallmark of a cloud computing application - or any web application for the matter. Philosophically too there is a difference - TSOs were specifically designed for number crunching, and there is more of a broad, user-driven goal to cloud computing. At the base definition, though, this is clearly the beginning of the cloud - right at the beginning of computing.
Client/Server systems also work on the time sharing model. Notice that we are talking about one big massive monstrous powerful machine in the center and hundreds of threads out from there? Remember that later. First it was mainframes then Client/Server systems. Anyway, Client/Server systems effectively represent the effort to prove the superiority of a single machine in terms of processing power.
Wait - stop right there. Aren't we past that? Didn't we do this with mainframes? Yes, indeed we did, but in the meantime, personal computers stepped into the fray and showed that there was a lot of processing that could be done on the client side. Client/Server systems changed all of that for two applications in particular - graphics and massive data processing. Keep in mind that back in '85 there wasn't an easy way to do parallel processing on a PC. If you had a LOT of data to munge, a mainframe or a Client/Server system was your only shot.
In a certain way of looking at things, Client/Server systems morphed into the first internet servers. They were initially available only to those physically near to the machine, due to the large scale bandwidth requirements. Then as networks became more sophisticated, users became more and more remote. First they were at the building level, then the campus level, then the city level. Anywhere the local network could reach was fair game.
However, the growing ubiquity of the internet and the related protocols made the distance between the servers and the users greater, and the experience richer. Standard business servers purpose built for handling certain computing tasks became the norm on the Internet, just as PCs had become the norm on the desktop. Supercomputers and very large scale servers were still handling big computing tasks, but specialization generally triumphed over brawn.
As internet related tasks became more specialized – like searching 13 billion pages of data for instance – the servers that ran them also had to become more specialized. While supercomputers, for instance, were good at long running math problems, they were not any better than any other computer at lookups on indexes. Gradually, a new server paradigm was born – the server farm. This is where a number of smaller computers work together to solve a very specific set of problems.
Two key technologies ushered in the technological backbone of cloud computing: virtualization and shard computing. Remember, the cloud is basically a big server farm that meets our three requirements. The same technology can be used in both places.
Virtualization is best described by looking at an answering machine. When direct dial phones became popular finally, people found a need to have a tape recorder answer the phone when they weren’t home. There was a physical device that would answer the phone, play from one tape and then record whatever came down the line onto a second tape.
Eventually someone had the bright idea to use a chip to record the outgoing message and the incoming voice. Once we went into the realm of the digital, there was nothing stopping the whole machine from being digital. The logic and storage all became ones and zeros. After that happens, the hardware can be abstracted away. No, we don’t have answering machines – the voice mail is served up as a service from our phone provider utility.[iv]
Shard computing is simply the practice of putting a little bit of the data in each of several physical servers to distribute the load in a parallel way. It is sort of the opposite of virtualization – there are literally thousands of small machines, each with a little database. If you need to look up an item, for instance, you can send the request to all of the machines, and they will all look, and they will all respond – thus essentially enforcing automatic parallel processing.
This is the birth of the cloud. These machines are out there to serve specific purposes – as soon as the purpose is served as a utility, the basic definition for cloud computing is met, and we have reached the current time.
Who is providing this anyway?
Amazon was the first of the large web 2.0 organizations to start offering its custom computing platform to small applications for cloud computing. They partitioned some of the virtual space in their hosting centers for these applications, making a flexible hosting center that would ebb and flow with the needs of the various constituents. For instance, TheMasters.com, which only gets traffic in April, wouldn't conflict with the needs of indy500.com, which really only uses bandwidth in July. These are the kinds of web applications that could make the best use of early cloud computing, for scalability.
Other big Web 2.0 companies have followed suit, and we will look at Microsoft and Google in addition to Amazon specifically in a moment. There is also a crop of new Web 3.0 companies that are bring the disruption that we all look for in the Internet market. These include Aptana, who is focused on the Ruby and PHP crowd, Nasstar in Europe, and Gridlayer.
The small companies are paving the way with the new ideas and changing the landscape a lot. Let’s take a look at three basic types of services provided now, coming from three of the largest providers.
Comparison of cloud providers.
Just like IBM was the key provider of time sharing services in the sixties, the large Internet players are leading up the cloud services provision today. Microsoft, Amazon and Google are putting their server farms out for rent in the new game, and providing the key services that have built their companies to the general application building public.
It goes without saying that there a number of different providers of cloud services, and that the three particular services that I am looking at here aren’t even the only services offered by the companies in question. I have picked on specific products from Microsoft, Amazon and Google to highlight three of the most common cloud environments. Let’s look at the services provided in turn.
Azure
Windows Azure is an operating system, really, that hosts the Azure Services platform. I like to think about it as Internet Information Services in the Sky. Microsoft describes it as computation services, simple storage and the development tools to go with it:
Computation Services
The key to the computation services is the ability to run ASP.NET applications or .NET code in the cloud. The hosting environment is effectively Internet Information Services and the Microsoft .NET Framework, just as you would get on a Windows Server at an Application Service Provider. The file system is locked out, and there is a small runtime API that supports things like logging and local scratch storage. This is all managed with a web based management console that helps you deploy, scale and upgrade your application.
Security is supported by a configurable Code Access Security policy just like the managed code is today. Full Trust is also supported so that Windows Communication Foundation and Windows Workflow Foundation is supported. Because Full Trust is supported developers can also call into unmanaged DLLs. Because unmanaged DLLs are supported, FastCGI is available. This means that customers of Azure are allowed to deploy applications written using non-Microsoft languages like PGP or Ruby on Rails if they can provide runtime libraries. All of this makes for a very flexible implementation, barely distinguishable from an application service provider.
Simple data storage services
Three key data stories that come out of Azure are:
· Blobs, tables, and queues hosted in the cloud
· Authenticated access and triple
· Access to data with simple REST interfaces
Development Tools
Also, there are three significant points for development tools
· Complete offline development environment, including computation and storage services
· Complete command-line SDK tools
· Visual Studio add-in that enables local debugging
This is about as broad a cloud computing gets and still isn’t just web hosting. The definitional saving grace is the soon-to-be-announced pricing plan, which meets our definition of cloud computing nicely.
S3
S3, for Simple Storage Service, is storage for the internet, according to Amazon. They position it as ‘designed to make web-scale computing easier for developers.’ It is a much lighter and simpler cloud platform than Azure, and Amazon likes it that way. Their marketing positions it thus:
· Write, read, and delete objects containing from 1 byte to 5 gigabytes of data each. The number of objects you can store is unlimited.
· Each object is stored in a bucket and retrieved via a unique, developer-assigned key.
· Authentication mechanisms are provided to ensure that data is kept secure from unauthorized access.
· The service uses standards-based REST and SOAP interfaces designed to work with any Internet-development toolkit.
· And it is built to be flexible so that protocol or functional layers can easily be added.
This is all driven off of a set of principles, some of which really show the differences from Microsoft’s ideas.
· Decentralization: data and code is spread throughout the data centers to assure that there are no bottlenecks or single points of failure
· Asynchrony: the system keeps moving forward, without locking or race conditions.
· Autonomy: Individual parts of the system make decisions based on local information
· Local responsibility: Individual parts of the system are responsidle for their own state, not depending on other tiers.
· Controlled concurrency: Concurrency is not the responsibility of the developer.
· Failure tolerant: S3 expects to break, and is designed to continue running in the event of a breakdown on some or even most of the parts.
· Controlled parallelism: Parallel processing is supported, encouraged and will improve the developer's lot in life.
· Decomposition: The opposite of the Microsoft model - small, combinable services rather than massive, rich services.
· Symmetry: All nodes in S3 are the same, so no custom configuration is required.
· Simplicity: The system should be made as simple as possible (but no simpler).
The storage is global, and the services offered consist of storage management, and that’s about it. S3 is cloud computing at the most refined. Azure is cloud computing at the most sophisticated.
The Google Apps
Google is doing things a little differently. Though Google does provide application hosting through the app engine, they are clearly focused on the components of the cloud, and provide client-driven access of these components through Google Gears, a JavaScript library for application development in the browser.
This perspective requires a more client-centric view of cloud computing, but it still meets our three standards of application hosting, online access and utility billing. The only difference is that Google is providing most of the applications as their own services or embracing third party services, and usually providing them free of change complete with a user interface.
For example, take Remember the Milk. RTM is a third party service that stores tasks and manages them. Google has a calendar service and UI as part of Google Apps - one of their cloud offerings. It seems like a match made in heaven, and it is. You can merge your RTM tasks right into Google Calendar thanks to the provided services, and then even make them available offline using Gears.
Once again, though, we have massive vendor lock in here. If Google decides to start charging (I already pay for RTM) then I have to struggle to get my data out and reintegrated, or pay.
The Dollars and Sense
Speaking of money, the title of this talk is Economics of Cloud Computing and we need to talk dollars and cents.
There are three ways to look at this. When I was a student at THE Ohio State University, I learned an important lesson about money. There is the way that the business owners view it, the way that the economists view it, and the way that the accountants view it. The way the business owners see it as cash in hand - finance. The economists view it as effect on the community - economics. The accountants have a big list of rules. They view it THAT way. You all know how accountants are.
A recent article in Open Source Magazine – heavily quoted – points out some numbers realities, as shown here:
Purchase - on Premise
· $ 15,000 - Quad-Core Servers ( 5 x 3,000 each )
· $ 750 - 1/2 Rack + Gigabit Switch
· $ 15,750 - Total Hardware cost
· $ 5,800 = Annual amortized cost, 5% over 3 years
· $ 0 - Assuming no incremental real estate cost
· $ 2,000 - Annual power & AC cost
· $ 7,800 - Total annual cost on premise
Purchase - at Colo
· $ 8,000 - Colo fees; 1/2 Rack + power + bandwidth
· $ 5,800 - Annual amortized cost
· $ 13,800 - Total annual cost at Colo
Cloud
· $ 35,040 24x7x365 Amazon EC2
· ( $.80 per high CPU Server instance hour )
· $ 8,320 40 hours x 52 weeks
· $ 688 40 hours x 4.3 weeks[v]
The conclusion is that Cloud computing isn’t always the best economic option, but it fails to take into consideration two very important things.
The first is the difference between operational and capital expenses, which makes a difference to the accountants.
The second is paying for someone to manage it, which is a dramatic oversight, and makes difference to the business owners. The grid should look a lot more like this:
|
Internal IT
|
Managed Services
|
The Cloud
|
|
|
Capital Investment
|
$40,000
|
$0
|
$0
|
|
Setup Costs
|
$10,000
|
$5,000
|
$1,000
|
|
Monthly Services
|
$0
|
$4,000
|
$2,400
|
|
Monthly Labor
|
$3,200
|
$0
|
$1,000
|
|
Cost Over 3 Years
|
$149,000
|
$129,000
|
$106,000
|
So this is about the money. Hate to say it, I really hate to say it, but what is going to make cloud computing take off is the financial an economic realities of hardware, staff and power consumption. Each of our money wizards has a perspective on this, and we will take them one at a time.
How the business owners see it
The entrepreneur and the CEO have the same thing in mind most of the time: cash. Theirs is a world of finance not accounts, where cash on hand is the most important figure.
Upfront investment is one of the most important considerations for the small business owner especially. While the early pundits espoused the Internet as a way that David could slay Goliath because “on the internet you can look as big as you want to be.” But this isn’t true, nor was it ever.
Even the most modest success story required pretty beefy server power. Once your big idea became even slightly successful, your company had to be prepared to pay the piper in terms of hosting bills or your own servers and bandwidth. The price for success on the internet is high.
The large enterprise has the same problems with cash. Any application that a Nationwide or Chase Bank puts on the internet is going to have an instant audience, and will have to have the server power to support it out of the gate. Additionally, large organizations are lacking that entrepreneurial spark, so there is also the software development and integration costs to consider.
While corporate environments have sophisticated server farms, and sometimes even a good virtualization strategy, they still have to be able to scale. Buying enough server hardware and licenses to support the most traffic a company like Nationwide will ever have is very expensive.
Cloud computing provides a solution for both of these company types. Because it is priced like a utility, the organization only has a cash layout for the initial use. This benefits the small company because until critical mass is reached the costs are very low. The large company only has to pay for the usage for applications today – and tomorrow they can add more with only the marginal increase in cost.
All of this leads to an increase in cash on hand. This provides two very important pieces of the puzzle – the small companies can grow organically and the large companies can buy the small companies. And the cycle continues.
How the bean counters see it
Accountants tend not to care about cash – they see everything in terms of accrual accounts. The bucket that something goes in is as least as important as the amount that goes in. They view our little list of costs like this:
|
Internal IT
|
Managed Services
|
The Cloud
|
|
|
Capital Investment
|
$40,000
|
$0
|
$0
|
|
Setup Costs
|
$10,000
|
$5,000
|
$1,000
|
|
Monthly Services
|
$0
|
$4,000
|
$2,400
|
|
Monthly Labor
|
$3,200
|
$0
|
$1,000
|
|
Cost Over 3 Years
|
$149,000
|
$129,000
|
$106,000
|
The reason for this is that capital investment is an Asset and everything else is an Expense. To tech companies Assets are a bad thing, unless they are intellectual property. In general, computers are a bad investment, and that is what technology companies buy.
A capital asset is something that provides worth to a company, like a building. When you buy a building, it will help you earn money. Since it has a lifespan, you are expected to amortize the costs against your organization for the life of the asset. If the IRS says a building lasts 20 years, then you get the tax benefits of buying that building slowly, over those 20 years.
Computers are capital assets too, but they have a really short lifespan comparatively. Problem is, if you spend $40,000 on computers in year one and make zero money with them while you are starting up, you still don’t even get to write all of those computers off on your taxes in year one.
By comparison, cloud services are considered a utility. Utilities are an Expense, and go in a whole different bucket. Expenses are not assets, and can be fully written off against your bottom line for the IRS. This means there is a significant tax savings associated with ‘renting’ your computer time rather than buying it. That makes the accountants happy.
The economics of the situation
Economics can’t always be boiled down to guns and butter. However, if the use of cloud computing does in fact reduce the cost of the upfront investment, then it has the effect of reducing the price of a product when demand is low, effectively making more of the product available when demand grows. Cloud Computing has the effect of actually slightly changing the shape of the supply curve.
I barely remember my microeconomic theory and I nearly minored in the stuff. Let’s refresh. The vertical axis is price of a good and the horizontal axis is the quantity available. Usually goods are commodities, like guns or butter, but in this case we are talking about whatever computer services you are selling.
Inside the graph is a supply line, which shows that the cost, and thus price, increases when quantity produced increases. There is also a demand line, which displays the quantity that is likely to be purchased at a certain price. This number is lower when the price is higher.
Reducing the fixed cost has the effect of shifting the entire supply curve downward, as shown in Figure 1. This means that the company can stay in business longer, even selling a minimal quantity of the good. Reducing the upfront variable cost has the effect of reshaping the line making the earlier part of the curve flatter. This has the effect of keeping price lower, longer, driving more demand for the good, earlier.
Figure 1 – Moving the supply curve downward
Take Craig’s List, who made early use of the cloud model. The low upfront costs allowed them to spend seed capital on other expenses, show better numbers to the stakeholders, and grow much faster. They made use of the reduced cost of doing business when the demand was low to scale faster as demand grew. Of course, as demand continued to grow operational expenses drove the cost and thus the price higher, but the initial outlay of cash was lower because of publishing to the cloud.
This works for any entrepreneurial organization, as well. If you are starting an application in your garage, you could host it at an ISP which is priced like a subscription, essentially adding a fixed cost to your project. Alternatively, you could get your own server, which is a tremendous upfront capital expense. The cloud gives you the opportunity to start paying for just what you use. If you don’t use much, you aren’t out much – it’s a true variable cost.
Large companies can do much the same. If an application is being hosted in house, some hours of a server administrator’s time must be expended on keeping the environment afloat – applying patches, running tests, and fixing problems. In the cloud, this is taken care of for you. Additionally, the project has less fixed cost, and more variable, so if it isn’t successful you can mitigate your risk. Lower risk means that more projects can be tried, which is better for everyone.
So where does that leave us? Cloud computing requires less cash at the outset, lowering the barrier to entry for entrepreneurial firms. It has a significant tax benefit reducing the number of capital assets that the organization must procure before providing the service. Finally, it lowers and flattens the supply curve, driving more demand earlier.
Implementing cloud computing
I feel guilty giving a technical talk without any technical details. Let’s take a few minutes and look at how cloud computing can be implemented in your organization.
First, you must take a broad look at the applications under your control and see how they might best be implemented in the cloud. As we have discovered, the different providers give different levels of service for different prices. The needs of your applications will determine the choice of vendor.
Second, you must prepare your application for the cloud. This could be anything from the redeployment of certain assets to a complete rewrite of an application to suit the available services. It could also be somewhere in between – a mesh between cloud services and installed applications.
Finally there is deployment, which has to be a carefully planned dance with well understood safeguards. Moving applications to the cloud can be disruptive to well understood deployment patterns. Changes to those patterns should be undertaken with care.
Selecting a vendor
Different vendors provide different services. If we just look at the three gorillas in the room, we have already discovered that. Let’s stick with the three services we discussed earlier, knowing that there are more, because they offer a good broad overview of the landscape.
At the simplest is S3, or the Simple Storage Service provided by Amazon. S3 is basically a hard drive in the sky, and there is little in the way of provided services. The platform is not an operating system at all in the strictest sense – you wouldn’t really write an application and plop it up on S3 and forget about it like you would with your ISP or server farm.
S3 is appropriate for applications that need to make use of distributed assets. For instance, some social networking sites put the photos that users share on S3, because the simple push and pop mechanism is perfect for the storage of large binary objects like photos, and the services make it easy to get the photos up and draw them back again. Because it is priced like a utility, the social site doesn’t have to pay the large capital expense that would be required if they bought all of the servers necessary to handle the largest possible load.
Even smaller sites can make use of a service like S3. For instance, in a project I recently completed I recommended that a poorly performing web application store its numerous web graphics, stylesheets and javascript files on S3. This gets around the asset deployment problem that plagues web sites, since most browsers only download two items at a time from a given domain. Additionally, it reserves the application’s bandwidth for business-critical operations.
The richest existing cloud implementation to date is Microsoft Azure. Azure is a place that you can use to plop your whole application in the cloud and forget about it. It is built on the .NET framework, and allows unmanaged code as well, so even a PHP or Ruby on Rails product could be uploaded wholesale. Additionally, they provide a host of other services, from weather lookup to Live Login for authorization and authentication.
Azure is a platform that you would design and build a whole product for. Microsoft provides tools as part of Visual Studio that allow you to create an ASP.NET web application, and just publish it right to Azure just like you would copy it to your web server. It is essentially a very large, very powerful, very scalable hosting provider that happens to be billed like a utility.
In addition, you pick the deployment. Do you need a database server, a business logic server and two web servers? Configure it right from the web. Have you found that the database is struggling under the load? Just fire up another one. Unlike the shard computing approach used by Google and Amazon, Microsoft is making rich use of virtualization to provide server utility.
Why is it a cloud then? Two reasons – it is priced like a utility, only charging for the bandwidth and cycles used. Second, it provides certain services, like the SQL Data Service, which is essentially a database in the cloud. While Azure blurs the lines between cloud computing and just using a good ISP, it certainly is part of the conversation.
So Azure is good if you have a program that is already written for a supported engine, like ASP.NET especially, and want to place the whole app in the cloud. The back end of the system will need to be rewritten to make use of SQL Data Service, which is something of a barrier to entry, but the additional services you get might be worth it. If the application converges with anything connected to Windows Live or anything that COULD be connected to Windows Live, it’s a sure bet that a small rewrite for Azure will be worth it.
Google Apps has taken things a whole different direction. They are keeping the cloud, and just giving you the services. The problem with that is that you have zero control over the data itself. The benefit is that it is free, at least right now. I have a hard time arguing with free.
So Google is a strong contender if you have an application that resides in the browser, and could make use of the services already provided by Google. Does your application need search capabilities? How about manage documents or images? Google has an app for that. The services provided by Google Gears would give you a key in to using Google Search, Google Docs or Picassa for your needs in that particular area.
This is a good simple fast and cheap way to add a feature that users might be longing for to an existing application. Google isn’t a great place to store things, or move your program to, but it does provide a lot of bang for just a little buck.
Preparing your applications
Obviously, application preparation depends heavily on the style of cloud you are heading for. In general you are looking to do more or less the same kind of design changes to a cloud implementation that you are when going to a server farm – because that is often what you get. The two most common trouble areas in preparing your application are transactional support and security.
Supporting transactions
The transactional problem is a common one. If a customer in San Diego is looking to buy your last widget, and a customer in Boston is looking at the same widget, they both have a chance of ordering that self same widget, and both expecting to get it. Usually, in a single server context the solution is to lock the thread containing the widget object, using a Singleton model, like this:
Public Sub Order(ByVal widget As Product, ByVal quantity As Integer)
SyncLock widget
Try
If quantity > widget.Inventory Then
Throw New ApplicationException("We are out!")
Else
widget.Ship()
End If
Catch ex As Exception
Debug.Print(ex.Message)
End Try
End SyncLock
End Sub
This won’t work in a multi-server environment, however. Since the thread is only locked on one server, two users could still potentially order the same widget, and Inventory would be a negative number when it was all said and done. We don’t want that, especially is the item is BlueJackets playoff tickets or the like. We need the system to be able to lock across multiple servers.
In his book Cloud Application Architectures[vi], George Reese talks about a few solutions to this problem. The first and most common solution to this is to perform your transactional logic to the database, and use a stored procedure to perform the business processes. Neither George nor I are a great fan of this option, as it leads to unmanageable code, and even more vendor lock-in. Also, if working in a shard environment, there is a good chance that state will still not be managed correctly.
Another possibility that seems to be gaining traction in the cloud community is using a shared locking system, usually in the database itself. Before performing business logic, the database could check a table of locked objects for the identifier to the object being processed. If found, it would wait. If not found, the identifier would be stored for its own thread, the processes performed, and then the lock would be removed.
Of course, many database vendors have existing transactional mechanisms, like SQL Data Service in the Microsoft Azure system. Microsoft has implemented a Tabular Data Stream model overtop of the property bag schema that is the foundation of SQL Data Services. The Tabular Data Stream supports client transactions just as SQL Server would with a BEGIN and END TRANSACTION statement. If you can let the tools work for you, then do so.
BEGIN TRANSACTION OrderTransaction
BEGIN
IF @onhand < @quantity
BEGIN
PRINT “We’re out!”
ROLLBACK
END
ELSE
BEGIN
INSERT itemnumber, quantity INTO orders
COMMIT
END
END
END
Planning secure applications
There is no getting around the core problem of Cloud Computing from the CIO’s perspective – all of your data is on someone else’s computer. When designing an application – or even before that, when conceiving of one – people rarely have to worry about protecting the application from itself and its environment. When the server is in your basement, that just isn’t a problem unless a malicious users gets through the barriers set up, which is a whole different conversation.
When your data is on the cloud, you have to remember that all of this virtualization and shard computing aside, there is still a physical computer somewhere with your database and files on it. That machine’s security is not up to you, so you have to assume that it isn’t secured at all. This is a tremendous challenge.
Mr. Reese has another suggestion for this scenario that I agree with fully, and that is: encrypt everything. Encrypt your sensitive data within the database. Encrypt your network data with SSL. Encrypt the backups. Obfuscate your binaries. Act like anyone can walk in and look at the system drive – because in reality they can. There is some system administrator from Amazon, Google or Microsoft maintaining that system and he is probably wearing that “I can read your email” t-shirt they sell on ThinkGeek.
Be informed about your vendor’s security policy. There are a number of articles out there on the various cloud provider sites with 1500 words about nothing when it comes to the implemented security measures. We all realize that none of these companies are going to implement weak security, because the first significant break in the armor might spell doom for that organizations entire cloud effort. Nonetheless, if you don’t get the answers you want about the provider’s security, press harder until you do.
Deploying
Testing and deployment is in essence no different for a cloud application than any other application. You should be writing your tests as you write your app. Components should be unit tested. Check-in requires a passed integration check. Deployment from source control is still the norm. Labeling, branching, forking, all of that good stuff still applies.
The point I want to make is that you will have to revise the details when you move to the cloud. If you are using a sharded data model, for instance, then testing the broad transaction or memory management controls will have to be an expected part of all the unit tests. Integration testing will have to take the distributed nature of cloud computing into consideration. Testing in the cloud is slightly different, and your new deployment model must support that.
If you are using an application service provider as your host now, you likely have a QA box under your desk or in the local server room to do pre-deployment shakedowns. After the move to the cloud there will no longer be a QA machine under the desk. Management probably won’t go for a QA Cloud under your desk because you will need a bigger desk.
Decisions will have to be made about development against cloud services, as well. All of the cloud providers have test implementations of services, but your QA practices will have to change to take them into consideration.
These are all small things, but they will get overlooked by the upper level decision makers when cloud computing becomes an organizational reality. The time and costs involved with changing existing deployment patterns have to be factored into the total cost of ownership of a cloud application.
It just makes economic sense
Just as the standalone power generators of the last century gave way to the electric utility grid, it seems that the corporate server farms of the last decade are already giving way to computing power served up as a utility. Without technologies like the Internet, virtualization and shard computing, cloud computing would still be a farfetched idea, but the time has indeed come.
We have seen that the reduction in capital expense that is provided by the implementation of cloud computing has the benefit of flattening and lowering the supply curve, making new goods cheaper for longer. It also has the benefit of changing the tax landscape, making it a sound investment for large corporations. Finally, I think we have shown that the cash savings it provides gives small and large businesses the wherewithal to grow at a more reasonable pace, and massage the business cycle in their own way.
Implementation of cloud applications will be a reality for quite a few of you, and I hope the few implementation details I have provided will be helpful. The choice of vendor is dependent on your applications needs. All of those applications will need to be analyzed for best utilization of the cloud services. Finally, deployment procedures, along with security and testing, will need to be revised.
Cloud computing might be the ‘next big thing’ or it might just be the next thing, but either way it makes a lot of sense in this economic environment. The scalability it offers, and the cost savings that most companies will see, are good reasons to consider it for your suite of applications.
[i] "Centennial Keynote Address," John McCarthy. MIT, 1961.
[ii] "Cloud computing," Next Generation Education Project, Wiki, 2008.
[iii] "Cloud Computing for the Masses," Tim O'Reilly, 2008.
[iv] The Big Switch, Nicholas Carr. W. W. Norton, 2008.
[v] “The Economics of Cloud Computing”, Open Source Magazine, 2009
[vi] Cloud Application Architectures, George Reese. O’Reilly, 2009.
Subscribe (RSS)
