Item from TheStreet.com: Amazon VPN

I get more comments on security than any other topic on this blog. So I thought I'd pass this on to you in case you haven't seen this before:


http://www.thestreet.com/story/10590792/1/amazon-locks-up-data-with-cloud-vpn.html?puc=_cnnmoney&cm_ven=CNNMONEY&cm_cat=Free&cm_pla=Feed&cm_ite=Feed

Amazon is rolling out a virtual private network for the EC2 computing offering and plans to extend it to the S3 storage offering.

Have a better day,

Bill

What's the difference between "cloud" and "clod"? (Answer: "U")

As part of my daily research, I subscribe to LinkedIn's Cloud Hosting & Service Providers Forum, where I saw an interesting post yesterday.

It was about the now-defunct, though highly successful in the short run, Car Allowance Rebate System. Let's be honest: Cash for Clunkers was at best pure, New Deal "pump priming". It didn't create a lot of demand, it didn't take a lot of gas guzzlers off the road, it didn't save the planet, it didn't even save people a lot of money on a new car purchase, but it did burn through inventory and turn the most rock-ribbed, flag-waving, staunch-Republican car dealers into grateful supplicants of a Democratic administration (less than a year after the GOP nationalized the banks, but I digress, still shaking my head in utter incomprehension.)

But forget about Cash for Clunkers as public policy. What does it mean to IT? Turns out, it actually does mean something, but you had to be looking for it. Rich Bruklis, a Hewlett-Packard storage product manager out of Houston, was. Putting aside the HP-IBM rivalry, I thought he had an excellent point about the difficulty car dealers have had actually getting the Washington cash to go with the Detroit clunkers:

"Would Cloud Computing help prevent the frustration of auto dealers and their delayed claims from Uncle Sam? ... [url address] ... Tuesday morning, I predict the summary from the media will highlight the US Gov't's inability to keep the web site up and process the last minute claims."

Well, we'll find out together tomorrow whether Mr. Bruklis's prediction is correct. I'll take this as a gentleman's bet, though; as a former journalist, I have a sense the media will largely miss this story. Reporters can appreciate the coolness of a new iPhone but, like everyone else, they are scared to death of explaining anything as complex and un-sexy as e-commerce infrastructure. (Don't get this MBA started at how fast they run away from a story that involves dollar signs and math.)

But what I got a huge chuckle out of was that, in the middle of Mr. Bruklis's post, was a link to a story in Cloud Computing Journal: http://cloudcomputing.sys-con.com/node/1079385. Imagine my surprise when I clicked that link and went straight to a 404 screen. Tried again, and I got the site's frame but no text. One more time, and I finally got through to the article, which Mr. Bruklis wrote.

Despite the irony of an article lambasting the Transportation Department for IT bumbling being hosted on a site that's takes more time to load than a freight train, the piece is really worth the read.

Have a better day,

Bill

Back-to-school shopping

If you haven't read the UC Berkeley RAD Systems Lab paper, "Above the Clouds," it's well worth the effort.

Written in a conversational rather than academic tone, it discusses the technical, line-of-business, financial and historical drivers of cloud computing. It also authoritatively defines cloud computing: software-as-a-service plus utility computing. SaaS providers can be utility computing customers. The other Whatever-aaS models are not included, nor are private clouds.

It also defines three economic engines of the cloud phenomenon. I list the first two just to be thorough. We'll be discussing the third:

1. Pay-as-you-go. The authors use the term "fine-grained" to describe the micro level at which capex is moved into opex.
2. Hardware deflation. Processing, storage and network horsepower all constantly decline in unit cost, but at different rates; cloud providers can benefit from the "float" and, maybe even pass them on to you, the consumer.
3. Elasticity of average and peak utilization. This old conundrum -- how to provision enough computing power for crunch time without drastically overpaying for 300 days out of the year -- is a step closer to solution in the cloud.

This third point is, of course, most crucial to startups and to web-based businesses that might have to dial back down considerably after the novelty wears off. But I venture to say there isn't a CIO in the world who isn't concerned about capacity management.

The Berkeley authors provide an interesting example:

"Target, the nation's second largest retailer, uses [Amazon Web Services] for the Target.com website. While other retailers had sever performance problems and intermittent unavailability on 'Black Friday' (November 28), Target's and Amazon's sites were just slower by about 50%."

This is all the more amazing because Amazon's EC2 offering is essentially just virtualization in the cloud, according to this same paper. "An EC2 instance looks much like physical hardware, and users can control nearly the entire software stack, from the kernel upwards. This low level makes it inherently difficult for Amazon to offer automatic scalability and failover." They suggest Google's AppEngine platform for that purpose. One wonders what Target.com's results would have been if it resided at Google.

But what I'm wondering is, what will the results be on this coming Black Friday, and the Black Friday after that? There's a first-mover advantage here: The capacity was indeed available, albeit at a degraded level. We've all been hearing about the slow back-to-school retail season, and how stores are dreading an equally dismal holiday season. They're going to cut back on expenses, and that's going to make the cloud particularly attractive to them. Nobody has bigger seasonal capacity requirements than retailers. That means there will be more direct competitors in the mix. Cloud providers are also struggling with elasticity. Will they be willing to buy all the capacity they need for 30 Shopping Days 'Til Christmas, even if most of it lies fallow for the rest of the year?

I don't think so. Expect outages this year, overcapacity the following year, and outages again the year after that.

Think I'll actually get reacquainted with the mall.

Either that or start shopping now.

Have a better day,

Bill

In case you missed the JVC story

Thanks to Jeff Schneider ...

JVC to Move to the Cloud: Will spend $27.4 million more or less (2.6 billion yen) so IBM can lift it into an outsourced cloud

http://www.linkedin.com/news?viewArticle=&articleID=58149256&gid=1911277&articleURL=http%3A%2F%2Fnews%2Egoogle%2Ecom%2Fnews%2Furl%3Ffd%3DR%26sa%3DT%26url%3Dhttp%253A%252F%252Fau%2Esys-con%2Ecom%252Fnode%252F1066343%26usg%3DAFQjCNHfNp8qc4AC8dkvs5Dmql4PnoXsVw&urlhash=ntIv&trk=news_discuss

I'm not just a happy IBM employee. I'm a happy IBM shareholder.

Have a better day,

Bill

(more substantive post coming soon)

Quick reminder ...

If you haven't already, could you please take a quick look at the 31 July entry, "Scattered Clouds"?

I'd like to see how close we can get to mapping the entire cloud infrastructure, then continuously updating it.

Your comments will be crucial.

I expect to have a more substantive post tomorrow.

Have a better evening,

Bill

The cloud's "skinny straw": How to not be the sucker

My IBM colleague Mark May flagged this interesting article for me, by open source guru Bernard Golden for CIO magazine online:

http://www.cio.com/article/499137/The_Skinny_Straw_Cloud_Computing_s_Bottleneck_and_How_to_Address_It

The crux of Golden's argument is that cloud computing moves the IT bottleneck from memory tonetwork bandwidth. That is, as you migrate to a cloud solution, it becomes someone else's problem to refresh the hardware, so you'll always have up-to-date hardware that can effectively run all your applications (or else, presumably, you've got someone to sue). The bottleneck, then, moves to the network connecting your enterprise to the cloud infrastructure. Golden calls that network bottleneck, "the skinny straw".

I agree with Golden, but I see the implications a little differently. Here's my take on it (for his, follow the link above):

Assuming that the cloud provider's LAN is sufficient, you're facing two potential skinny straws. The first is the point-to-point line charges. You need to make sure that you've got all the bandwidth you need, and then some to allow for growth. Then you have to negotiate those line charges for all you can squeeze.

I once wrote a white paper describing how there is no linear function to describe how big a pipe you've got, how far it goes from one city to another, and how much you're paying. I wrote that paper in 2002, right after the collapse of Global Crossing, when the communications industry was overbuilt and in a state of panicky retreat. But you know what? I bet I'd reach the same conclusion if I did the same research today.

You should also make sure that the terms you negotiate are for the same length of time as your agreement with the cloud provider.

The other network cost to consider is the last-mile charge from the local hub to the cloud provider's back wall. If you can negotiate this directly with the network service, great. But more likely you'll have to negotiate with the cloud company. Do not let them lump this in with the rent; make sure that this cost is broken out. Do not pay for such sunk costs as actually digging the trenches and laying the cable. Pay only for the real cost of the ping for the month.

And here's an important rule of thumb: It should cost less -- much less -- to pay for one mile's worth of fiber than for the thousand miles of fiber you're riding between cities. Does that sound too simplistic? Do me a favor: Call the budget analyst responsible for your WAN and see what the ratio is now.

Then get back to me. I might be the only one in the world interested in the answer -- but I am that.

Have a better day,

Bill

What gets asked, and what gets done

I came across a fascinating blog today ...

http://srinikumar.wordpress.com/

Srini Kumar asks, "Do you know what your CEO wants?"

Don't assume you do. Kumar enumerates five different points of departure between what CEOs are after and what their technology lieutenants pursue. Maybe that's why CIO is rumored to stand for "Career Is Over". (I know a guy who was offered a chance to combine the CIO role with the CTO role. The new position would be called Chief Information and Applications Officer. He declined to take it after I pointed out that his job title would be "CIAO".)

At least two of Kumar's points resonate here:

1) "Taking years building frameworks or standards which gets outdated ... ." I recently did a business case for a customer who wanted to compare a buy-versus-build-versus-outsource decision. But they wanted to focus on the annual operating cost deltas, to the exclusion of analyzing the time-to-go-live. That's what they wanted so that's what I delivered, but it would have been my preference to make some educated guesses about how soon each of these options could be up and running. The more you capture this, the better cloud computing looks.

2) "Jump onto bleeding-edge solutions where there is no need and no expertise." Another argument in favor of concentrating knowledge in dedicated cloud facilities. Most companies simply can't keep up and waste their time, talent and strategic focus if they try.

Kumar's day job is as the Java chief at offshorer Satyam. His solutions are simple. Kumar is a strong proponent of Software as a Service, off-the-shelf apps, going outside for expertise, and using technology to simplify rather than complicate.

Of course, if this approach was always the least expensive and least risky option, everyone would be doing it. Still, I'm in broad agreement here and wanted to share these thoughts with you.

Have a better day,

Bill

Lost on the Op-Ed page

First, sorry for the disappearing act. I was given the brief to start this blog in my spare time, then they took away my spare time. I've got the work-life balance to post at least every few days now going forward.

But I'm not going to blog just to blog. One thing that prompted me out of remission was an op-ed piece in the New York Times by Harvard Law's Jonathan Zittrain. As with many Ivy types, he makes some remarks that are obvious given a moment's thought, are expressed very well, and not quantified worth a damn.

http://www.nytimes.com/2009/07/20/opinion/20zittrain.html?_r=1&scp=1&sq=lost%20in%20the%20cloud&st=cse

Zittrain's thesis is that the cloud is a dangerous place. It's great to have all your data backed up offsite but -- and this is why we need Harvard on the job, to think of these things for us -- What If Something Goes Wrong?

The infrastructure could fail. The keepers of that infrastructure might even betray your confidential information. Right to privacy -- a dubious enough concept in the real world -- is practically non-existent online. Under the Patriot Act, the government can grab your data without a warrant just as easily as it could tap your phone. And then heaven help you if you're actually sending packets outside U.S. borders!

All good points, Professor Zittrain. The op-ed piece was directed at a general readership (although most Times subscribers would probably bristle at that characterization) and was focused more on personal computing. So it's not surprising that they're nothing that any decent CIO hasn't already thought of.

The questions, then, are how real are these risks? How can they be mitigated? And most important: How much could they cost you?

Real? Sure they're real. System failure is definitely real. Industrial espionage is a possibility. Beyond that, maybe we're just descending into paranoia.

Zittrain suggests some public policy solutions to mitigate: Fair practices law could compel cloud providers to send your data back to you upon one-click request and delete it from their own devices. Other privacy protection statutes could be enacted. And of course cloud customers can take matters into their own hands by improving their encryption and deploying other security options.

At what cost, then? Legislation is expensive, but doesn't tend to hit the CIO's p&l statement. Industry groups have lobbying firms on retainer; it may be time for industry groups to put Zittrain's public policy initiatives on the front burner. Security can be costly; I've had clients whose firewall servers consisted of $50,000/year of software stacked on $5,000 (one-time) worth of hardware. But that just reminds me of what's been written on bumper stickers about school district taxes: "If you think education is expensive, try ignorance."

Zittrain hits on one critical hidden cost of the cloud, and on this point I think he's quite right and actually displays the kind of foresight that Harvard people are supposed to display on a regular basis: The cloud could shackle innovation.

"Both the most difficult challenge -- both to grast and to solve -- of the cloud is its effect on our freedom to innovate," Zittrain writes. "The crucial legacy of the personal computer is that anyone can write code for it and give or sell that code to you -- and the vendors of the PC and its operating system have no more say about it than your phone company does about which answering machine you decide to buy."

(Answering machine? They still sell those?)

The point, again directed at the personal computing public, is well taken in the corporate world. If you have people on your team who love to tinker and are good at it, the cloud will put opportunities out of their reach.

They won't be able to write spaghetti code. They won't be able to forget to tell anyone about it and never enter their changes into the CMDB. They won't be able to cause outages just by going on vacation. They won't be able to negotiate outrageous raises because they're the only ones who understand the "improvements" they made. They won't be able to retire at 39 and come back as $400/hour consultants at 40.

Instead, such monkeying around can only be done by people who do the same system administration and operation tasks day in and day out for a variety of customers with similar requirements, applying their professionalism and knowledge concentration seemlessly and invisibly.

Hmm, maybe the standardization benefit outweighs the innovation cost.

Define quote-unquote success

So you just signed a statement of work hiring contractors to help you transform from the parochial, siloed organization you are to the lean, plugged-in, "cloud" organization you want to be. How will you know when the job's done? And once it is, how will you know if you succeeded or failed?

There are three steps you need to take verify that your company has benefited from implementing a cloud solution.

First, identify key performance indicators. KPIs can include such puddle-deep thoughts as "Reduce IT infrastructure costs," "Improve operating costs," "Improve business process efficiency," or "Improve customer service and satisfaction." The trick is to get away from the warm-and-fuzzy and into hard numbers.

The second step is to capture metrics that support these KPIs. The surest ways to "Reduce IT infrastructure costs " are, of course, to reduce the number of servers and the number of people. Each box and each belly-button has an incremental cost. Do you know what those costs are? That's where it all falls apart, you see. Not a lot of gthe IT departments I've worked with excel at determining how much they'll save by taking one server off the floor. They do tend to understand the savings of taking back a system administrator's badge, but at some point you run out of people who actually know something about computers. A person who gets the same amount of money deposited in her checking account twice a month is easy to understand from a cost perspective. But what about that incremental server? How much does that standard hardware build cost? How much does that standard software stack cost? Oh, you don't have hardware or software standards? Or you do, but you don't understand how to burden the network or storage components? Or you're not sure how to distinguish between physical and logical servers? Or you're not sure how the software is licensed? If you have any of these problems, I'd recommend gaining a clearer understanding of your costs before you proceed with cloud computing projects or any other supposed cost savers, or you'll never know for sure if you've made good decisions.

The last step is the investment analysis. I don't like the term "ROI". I've got an MBA with a finance specialization and I'm not sure what it means so, I'm here to tell you, the sales rep from your vendor doesn't have a clue. A colleague of mine from IBM's IT Business Management community of practice tells me that there are at least 23 accepted formulas for "return on investment". (The one I mean when I use the term is also called "return on invested capital," and applies more to corporate financial reporting than to anything I ever found in a data center.) So what do your decision makers mean by ROI? Net present value? Internal rate of return? Payback period? What's your discount rate? What's your hurdle rate? Again, if you don't have a handle on these, good luck getting anything -- cloud or otherwise -- greenlighted. I assure you, the number-crunchers who work for the lines of business know this stuff inside-out and will have a much easier time justifying their pet projects to the CFO than you will.

Whether you use ITIL or CoBIT or PRM-IT or whatever process mapping system you choose, there's a big block that deals with how well you understand your costs. If your capabilities in this area are not as mature as they should be, this could be a huge barrier to your ambitions to grow into the cloud.

For more on this, click http://www.ibm.com/ibm/cloud/ibm_cloud/.

Have a better day,

Bill Freedman
bfree@us.ibm.com

Kicking off

Welcome, and thanks for joining the discussion.

To briefly introduce myself, I work for IBM as a business management consultant. I handle a lot of the number-crunching, CFO-facing stuff. Basically, I'm called upon to do three things:

1. work directly with clients to develop business cases, chargeback models, and other stuff that involves working with spreadsheets (i.e., the junk that everyone else in IT spend their careers avoiding);
2. develop intellectual capital as part of IBM's Global Deployment Center; and
3. lead the global core team for the roughly 1,000 IBMers worldwide who comprise the IT Business Management community of practice.

Because of my misspent past -- my first career was in journalism -- the PWGPMTM (people who get paid more than me) asked me to start a blog about where business management processes intersect with the new "cloud" approach. Since they're not actually paying me to do it, though, and this is being done on my own time, they're going to have to live with the risk of Freedman being a loose cannon. I will make the bosses this one assurance: I won't write anything that will reflect negatively on IBM customers; if I have to cite a real-world example, I'll do everything I can to mask who it is I'm talking about.

So let's take a look at this intersection.

As for business management, I know exactly what that is: governance, alignment, costing, charging. I don't know too many companies that are doing it correctly, but I know what it is. (My experience is skewed, of course. The companies that do have a handle on it wouldn't be hiring consultants to help them, right?)

As for cloud, I don't know anything about it. Here's what one IBM document has to say about it:

Cloud is a synergistic fusion which accelerates business value across a wide variety of domains.

Huh?

Here's what I think it is: turning fixed costs into variable costs.

This has been around forever. "Cloud" is just a way of marketing it. I hope it works this time.

We used to call it "on-demand". We used to call it "the utility model". We still call some of it "application service provider". But it's all the same thing. Rather than buy all the components you need for your hardware, then construct a building that can provide all the power, pipe and ping you need to run those machines, then roll your own applications, you pay someone else to handle it for you.

Metaphorically: You don't own the utility grid anymore. Just the light switch.

This is not a new idea. Don't get me wrong, I'm not dismissive about it at all. I think it's great if we can get to it and I dedicate this blog to those of you who, through your comments and links, collaborate with me in making this space the home for all who'll be building business cases to support the cloud model at your own companies.

For an overview of what IBM is doing, click here: http://www.ibm.com/cloud/.

If you have any comments on what you see there, or here, please click the "Comment" button and let's talk it out.

I look forward to a fascinating conversation with you.

Warmest regards,

Bill Freedman
bfree@us.ibm.com