Has extensive cloud implementation in your organization resulted in outsourcing?

wixter

Weaksauce
Joined
Mar 8, 2012
Messages
88
This is something mine is really starting to move forward on with stuff like Azure, Office 365, vblock, general cloud hosting and all that jazz. For anyone who has already been down this road, in terms of your onsite infrastructure like physical servers or hosts for virtual servers, how has this impacted your organization's personnel requirements? Did they lay people off? If so, can you guess at the percentage? Any people who are still around, what do they do now? How has implementing all of this changed the job requirements of your support teams, backend people, tier 3 stuff? Maybe my biggest question though is, did implementing all of this actually help your organization save money and/or improve uptime and performance?
 

4saken

[H]F Junkie
Joined
Sep 14, 2004
Messages
11,237
We have added to our Operations/Engineering team. The only requirements is that we are no longer looking for soley traditional admins. We are looking for admins with scripting/programming experience as well. You still have to have an operational understanding of how everything ties together and works while you develop your infrastructure to run from code.

You adapt or you leave is really how we looked at it. So far we haven't lost a single traditional admin in the last 2 years of our transition and they have all taken on the extra responsibility to pick up some light coding for config management and orchestration of our systems and have even applied to our "legacy" on-prem infrastructure which has in turn even increased efficiency there, as far as provisioning times, etc.

The biggest mistake people make when moving to the cloud is thinking they can forklift their traditional architecture, vms, storage, etc as is and just deploy it to cloud and expect something magical to happen. This is the absolute way to guarantee frustration and failure. I think my team, as well as myself, have enjoyed the fact we are having to really sit down and design our apps/systems to be able to handle failure. You have to build to fail, since you are no longer in control of the underlying infrastructure. If region/az A goes down, what happens to our app? Always have to ask that.

As far as the cost aspect, a 1:1 forklift will be far more expensive than, on-prem. You have to evalute your applications and systems and ask can we utilize cloud services in AWS/Azure/etc, and what do we gain. For instance we have a heavy image processing cluster that was brutal on our on-prem SAN. Very write heavy and when we had very high volume it could affect other applications in the environment. This was a perfect use case for AWS, small EC2 instances and Autoscaling. Overnight we may keep 1 instance up and as volume increases it will auto-scale out to whatever it needs to keep up with demand, then shrink back down as volume subsides. Thus the cost savings and performance savings of having 1 instance up most of the time versus 50 instances/vm's up 24/7. That is just one example, but IMO you have to audit your whole environment and identify systems/apps that are good candidates.
 
Top