Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Cloud IT

Adopt the Cloud, Kill Your IT Career 241

snydeq writes "IT professionals jumping into the cloud with both feet beware: It's irresponsible to think that just because you push a problem outside your office, it ceases to be your problem. It's not just the possibility of empty promises and integration issues that dog the cloud decision; it's also the upgrade to the new devil, the one you don't know. You might be eager to relinquish responsibility of a cranky infrastructure component and push the headaches to a cloud vendor, but in reality you aren't doing that at all. Instead, you're adding another avenue for the blame to follow. The end result of a catastrophic failure or data loss event is exactly the same whether you own the service or contract it out.'"
This discussion has been archived. No new comments can be posted.

Adopt the Cloud, Kill Your IT Career

Comments Filter:
  • by Sycraft-fu ( 314770 ) on Monday June 11, 2012 @03:41PM (#40287741)

    Campus decided to outsource our e-mail to Microsoft BOPS, rather than just do Exchange (or something else) on campus. Problem was that doesn't mean that suddenly campus IT just gets to say "e-mail isn't our problem, call MS!" No, rather IT still hast o do front line support but now when there's a problem you have to call someone else, get the runaround, finger pointing, slow response, and so on.

    Net result? We now have an Exchange server on campus and do e-mail that way.

    It isn't like outsourcing something magically makes all problems go away, particularly user problems. So you still end up needing support for that, but then you get to deal with another layer of support, one that doesn't really give a shit if your stuff works or not.

    Basically people need to STFU about the "cloud" and realize that it is what it always has been: outsourcing and evaluate if it makes sense on those merits. Basically outsourcing is a reasonable idea if you are too small to do something yourself, or if someone does a much better job because they are specialized at it. If neither of those are true, probably best not to outsource.

  • by 140Mandak262Jamuna ( 970587 ) on Monday June 11, 2012 @05:11PM (#40288965) Journal
    You don't get it.

    You out source when the out sourcing provider comes in and takes your IT chief and the CEO out on a nice golfing trip and gives all the members of the IT teams ball point pens with their logo on it.

    Then, after a while, the in-house software provider sales manager comes around and takes CXOs for nice island get away. And you get baseball caps with the company logo. Then they undo all the out sourced services and implement it in house.

    Then comes Accenture and Infosys and Wipro. They tell the CXO, "look, some of you are into golf, some into island vacations. We don't want to force you. Just take our cold hard cash. We are from India. We know how important it is to make direct cash payments instead of the indirect in kind payments". They get thrown out.

    Then the McKenzies and Price Waterhouses etc come in. They speak in obtuse languages, take the cold hard cash from Accenture, Wipro and Infosys, skim something off the top and pass the rest to CXO in a perfectly legal way. Of course you will get your token appreciation trinket. Probably a bamboo drink coaster for your coffee mug.

  • Re:oh please (Score:5, Informative)

    by batkiwi ( 137781 ) on Monday June 11, 2012 @08:19PM (#40290613)

    Cloud != outsourcing even.

    Cloud is an easy description for where some layer is abstracted away to the level that it doesn't matter to implementers.

    At work we now have a "private cloud." What this comprises is simply a VERY large VM infrastrcture with automated deployment and full time monitoring.

    In the old world we would check a large chart of what apps were deployed on what servers, then place new apps on the least loaded servers. As loads changed our apps didn't move, we just were hosed unless we wanted people constantly installing and uninstalling apps on shared servers. Some servers were 2003R2, some 2008, some 2008R2, some 64bit, some 32 bit, etc. Some had shared components which one app upgrading might break, others didn't even have those components so you couldn't install new apps on it.

    Now we simply say "we want instances of this app running." Our infrastructure (vmware + SCCM) spins up 3 default VMs and autodeploys the software. One will be in our backup datacenter, two in the primary. If load is too high we request more resources (more nodes, more ram, more cores). The entire systems management side of things is abstracted away.

Today is a good day for information-gathering. Read someone else's mail file.

Working...