Bernard Golden had another interesting point in his "Skinny Straw" article, which I referenced this past week: Some applications are going to require more bandwidth than others due to the amount of data transfer required. I/O-intensive apps -- or I/O intensive sections of a given app -- may determine what you can put in a cloud and what has to be colocated close to home. As noted in an earlier post, bandwidth is the key bottleneck to cloud computing, as opposed to the memory constraints that typify traditional processing.
I think what you'll find is that the same apps that would be "problem children" for the cloud are precisely those that are costing you too much in the first place. That's right, the bane of IT delivery organizations everywhere: legacy systems.
This would be a good time to talk about chargeback. The cloud provides another way of showing how much cheaper it would be if all business units used the standards that IT prescribes.
Imagine the impact on the enterprise when all the business units that take advantage of cloud computing received monthly invoices that showed the number of dedicated ports, then a cost per port, then a single line for every passthrough charge, and finally an allocation of headquarters tax. The business unit executive or one of his direct-reports would be able to understand it in a minute. And it probably wouldn't change much month-to-month.
Contrast that with the business unit that persists in using legacy systems that do essentially the same thing. Their invoices show unhealthy detail of hardware, software, labor, floorspace, power and network consumption. Depending on workload requirements, these costs might well swing drastically up and down from one time period to the next. The exec might even have to hire a budget analyst to manage this invoice; that would certainly eat into any perceived savings from staying on a legacy system because of "organizational" reasons (i.e., his people are too change-resistant to stay current).
We will absolutely have more detail on how the cloud simplifies chargeback. I know for a fact that some of my IBM colleagues are working on this as we speak. I'll pick their brains and give you a preview.
Have a better weekend,
Bill
Friday, August 14, 2009
Thursday, August 13, 2009
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
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
Tuesday, August 11, 2009
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
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
Friday, August 7, 2009
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
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
Friday, July 31, 2009
Scattered clouds
So where is this "cloud" physically ... in meat space.
I went to find out. First, I started with a very helpful grid courtesy of John L. Willis's IT Management and Cloud Blog at http://www.johnmwillis.com/cloud-computing/cloud-vendors-a-to-z-revised/. That provided the names of the known vendors and what they provide.
The next question was, Where were they providing these services? That is, where were the actual data centers located? I got that from a combination of company web sites, regulatory filings, my own industry experience and a fantastic online resource called Data Center Knowledge at http://www.datacenterknowledge.com/.
Here's what I came up with ...
Now, I don't guarantee that this is 100% correct. It's just a first pass. I'd appreciate any comments or corrections.
Have a better day,
Bill
Thursday, July 30, 2009
Brain cloud
In a comment on an earlier entry, a reader who wishes to be known only as Alec referred to the "knowledge concentration" that a third-party provider brings. He was talking about the ASP model, but acknowledges this holds for cloud providers as well.
This knowledge concentration means that deployment "requires about 10% less effort than a customer-hosted one of the same size and complexity," according to Alec, whose statement also suggests this might hold for incident management.
But I think there's even more to it than that.
If your labor is 10% more efficient, then that's time that they can be spending on value-add projects rather than keeping the lights on. Most business cases I've seen would grant that this is a 10% savings, but that would only be true if your cloud provider's cost per person-hour were the same as your badged employees'. But you're not fishing from the same pool. If your data center is in a rural or semi-rural area where skilled workers are hard to find, then you're paying a premium for them. If you're in a major metro, you're paying a premium just on the burden rate -- and then you can consider higher salaries. But cloud infrastructure is in places with affordable labor markets where there's a concentration of IT skills. So that adds to the bargain.
And we're not just talking about the tape monkeys and board jockeys here. The higher up you go up the skills ladder, the better the payoff is likely to be. Unix admins? LAN admins? Hypervisor gurus?
Also, if your cloud's team is 10% more efficient than your home-grown team, that means that your systems are back up and running 10% faster. What's that worth in terms of productivity? Customer satisfaction? Revenue? (By the way, don't count revenue in a business case. It's misleading as all get-out. But I think it's fair to include EBIT or EBITDA, depending on whether you're presenting a cash- or accrual-basis case, respectively.)
One last point about cloud labor costs versus in-house: Growth. What are you projecting for wage inflation next year -- 3%? 3.5%? Whatever it is, it's just a projection. You really don't know. You'd be remiss not to add a risk factor to that. Depending on the size of your shop, three or four longstanding employees who know where all the bodies are buried could blow that estimate straight out of the water.
And then what are you paying them to do? You're paying them to deliver an adequate standard of service. Adequacy is defined by a service level agreement between you and ... uh ... you. There's no real penalty for violating it, except that you get an earful from the end users.
But with a cloud provider, you have a contract. You know exactly how much it'll cost next year to maintain a specific service level. If that SLA is violated, you get an agreed-to rebate. Otherwise, you know what you're paying and know what you're getting.
This knowledge concentration means that deployment "requires about 10% less effort than a customer-hosted one of the same size and complexity," according to Alec, whose statement also suggests this might hold for incident management.
But I think there's even more to it than that.
If your labor is 10% more efficient, then that's time that they can be spending on value-add projects rather than keeping the lights on. Most business cases I've seen would grant that this is a 10% savings, but that would only be true if your cloud provider's cost per person-hour were the same as your badged employees'. But you're not fishing from the same pool. If your data center is in a rural or semi-rural area where skilled workers are hard to find, then you're paying a premium for them. If you're in a major metro, you're paying a premium just on the burden rate -- and then you can consider higher salaries. But cloud infrastructure is in places with affordable labor markets where there's a concentration of IT skills. So that adds to the bargain.
And we're not just talking about the tape monkeys and board jockeys here. The higher up you go up the skills ladder, the better the payoff is likely to be. Unix admins? LAN admins? Hypervisor gurus?
Also, if your cloud's team is 10% more efficient than your home-grown team, that means that your systems are back up and running 10% faster. What's that worth in terms of productivity? Customer satisfaction? Revenue? (By the way, don't count revenue in a business case. It's misleading as all get-out. But I think it's fair to include EBIT or EBITDA, depending on whether you're presenting a cash- or accrual-basis case, respectively.)
One last point about cloud labor costs versus in-house: Growth. What are you projecting for wage inflation next year -- 3%? 3.5%? Whatever it is, it's just a projection. You really don't know. You'd be remiss not to add a risk factor to that. Depending on the size of your shop, three or four longstanding employees who know where all the bodies are buried could blow that estimate straight out of the water.
And then what are you paying them to do? You're paying them to deliver an adequate standard of service. Adequacy is defined by a service level agreement between you and ... uh ... you. There's no real penalty for violating it, except that you get an earful from the end users.
But with a cloud provider, you have a contract. You know exactly how much it'll cost next year to maintain a specific service level. If that SLA is violated, you get an agreed-to rebate. Otherwise, you know what you're paying and know what you're getting.
Wednesday, July 22, 2009
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.
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.
Subscribe to:
Posts (Atom)