Posts Tagged ‘cloud computing’

Cloud/IaaS: It’s all about the workload

Wednesday, April 2nd, 2014

So you think moving your server workloads to the cloud will save you money?

Think again.

The cloud paradigm is no longer new to computing, but even when it was a new computing idea, it was already an old commercial idea. When we move workloads to cloud servers, we are in effect leasing servers rather than buying them.

How is that relevant?

I can buy a big screen TV at my local electronics shop, or I can lease one next door. If I lease it, initially it will seem less costly, but over time, leasing will cost more than buying. The same is true with cars: I can buy one and drive it into the ground, over 10 or 15 years, or I can lease one, and replace it with a newer model every couple of years. Leasing will definitely cost more.

So the lesson here is that cloud == leasing, on-premise == buying. Leasing costs more but has the benefits of offloading administration to someone else, plus the opportunity to replace the product or service with a newer version quite frequently. In other words, with leasing, I pay more, and I get more.

IaaS and SaaS are the same. You don’t buy the compute capacity – you lease it. You don’t buy the hosted app – you lease access to it. Someone else manages it and someone else upgrades it once in a while. It costs more in the long run, but you get those benefits.

So does this mean that IaaS is definitely more costly than purchased compute capacity? Mostly, yes. The main exception to this rule is where the workload is sporadic. If I have a VM that needs to run for just 1 hour per day, if I buy the capacity, then I’ve effectively purchased 24x as much capacity as I needed, so even the buy-vs-lease cost savings won’t help me. It’s better to lease that for just the time windows I need it.

What does this mean in practice?

IaaS is cost effective for specific workloads — those that are only run on demand, and are shut down most of the time. Training systems. Demo systems. Peak capacity web farms. POC and lab environments. Testing systems used infrequently. There are lots of workloads where – if you have the discipline to shut things off when not in use – you can save money by moving the runtime platform to the cloud.

But who has the discipline? That’s the real problem. Human users forget to shut down their VMs, so they might move to the cloud to host sporadic workloads, but then they forget to turn things off, and wind up leasing much more capacity than they really need.

This is where Hitachi ID can help. Our Privileged Access Manager can be used to “check out” a whole machine (not just a privileged account), which has the desirable side-effect of turning the machine on. The subsequent check-in, which might be manual or due to a timeout, will suspend the same VM, effectively stopping the billing until the machine is needed again.

This can amount to a huge cost savings for IaaS used to host sporadic workloads.

If your IaaS usage fits this pattern, call us — we can save you money.

IAM in the cloud?

Thursday, March 18th, 2010

Seems like everyone is talking about moving everything to “the cloud” these days.

Increasingly, the conversation is turning to moving IAM systems from an internally hosted platform (i.e., on a physical or virtual server) within the corporate perimeter, to an externally hosted platform, run by a service provider and connected over the public Internet.

I wonder if there’s value to be had by doing this, or if it’s just the usual industry “buzz” – fickle and pointless. I rather suspect the latter.

Don’t get me wrong – I get the value proposition of moving some applications out of the perimeter and onto a cloud vendor’s network, where they get installed, configured, maintained and upgraded by specialized, skilled professionals. There are all sorts of advantages to moving apps out of the perimeter and onto a “cloud” vendor’s network:

  • No physical hardware to buy, install, power, cool and maintain.
  • No software to install and manage.
  • Someone who really understands the application in question manages it for you, instead of someone on your internal IT team who has to manage 10 different apps and is an expert with none of them.

I just don’t get that every conceivable type of application belongs outside the perimeter. Consider some counter-arguments:

  • The corporate perimeter is still very much firewalled.
  • Firewalls are porous in one direction (outbound) and usually quite tightly closed in the other direction (inbound).
  • A user provisioning, password management or other IAM application designed to manage users, identity attributes, passwords and entitlements spends much of its time connecting to your existing applications, in order to create and delete accounts, manage group memberships, read and write identity attributes, set passwords and so on.
  • If the IAM system is outside your perimeter, then it will have to “reach into” your network to do all that stuff:
    • That’s a security problem – lots of holes have to be opened in your firewall.
    • Do you really want privileged credentials for your core systems stored on a database that belongs to another company? I didn’t think so.
    • That’s a performance problem – do you really think it will get the same sort of bandwidth going across the continent as it will going 10 feet from one server rack to another, at your own data center?

So long as you still have a significant set of applications installed inside your perimeter, your IAM system should stay on the inside.

On the other hand, if all your apps are outside (and by the way, where did your corporate directory go?), sure, move the IAM system out too.

Look at it this way — your internal IAM system is probably the last one you should move out of your perimeter. Right before you turn the lights off on your proprietary data center.

Does that mean there is no use case for “IAM in the cloud”?

Not really. There are still lots of reasonable use cases.

For example, you might be managing users and passwords on other apps which themselves have been moved out into the cloud. For example, do your users sign into WebEx? Google Apps? Why not use your (still internal) IAM system to manage those? It’s really no different than managing users and passwords on your internal AD or SAP systems.

What about federation? You can certainly leverage user authentication inside your network to eliminate secondary logins to applications outside your network.

You can even go the other way – let your partners’ users sign into their own corporate directories and click right into your partner-facing apps in your DMZ.

That’s all well and good. But it doesn’t argue for relocating your core IAM function (you know, user provisioning, password synchronization/reset, etc.) out of your network’s perimeter.