Want an IT Job? Add 'Cloud' To Your Buzzword List

jfruhlinger writes "There was a predicted uptick in IT hiring for late this year, but it's mid-November and it hasn't happened yet. Kevin Fogarty does see growth in one area, though: cloud and virtualization experts are being fought over, lured away from in-house jobs to cloud consultancies popping up everywhere."

Comments

Re:Today's word..."Cloud"

[digitalhermit]

The "Cloud", as referenced here, is nothing more than the delegation of responsibilities...specifically those of infrastructure. That's it. It's not some mystical cure all. In fact, it's nothing more than a glorified way to outsource applications.

Well, no. The cloud they referenced was an "abstracted data-center infrastructure" and not necessarily a means of outsourcing applications. Yes, the downside/upside is that it eases moving workloads from internal to external clouds, but that's the point.

Now there are specific technologies which lend themselves to this concept ( those of virtualization, certainly ), but the overall goal is the same; the business doesn't want to worry about the infrastructure behind their app. They simply want it to work.

Is that a bad thing not to want to worry about the infrastructure? Traditionally servers are designed around the concept of a physical server. We used to name servers by rack number or some other geographic location. Virtual machines were often named according to what physical server they resided within. Cloud technology, once the marketing speak is burned away and the APIs get to a mature and standard state (i.e., an in-house or an outside hosted cloud looks the same to an application), would allow other ways of managing the hundreds of thousands of machines in large data centers.

For example, capacity planning is a big deal. One of the responsibilities of a system engineer is to ensure that workloads can run properly on the servers. When there is a planned outage on one server or an increased load due to seasonal or scheduled work, the admins have to juggle the resources of the servers. In a planned outage we may use VMWare VMotion or Workload Migration and swing the workloads across. But then we often have to worry about IP changes, hostnames, virtual host software levels, etc.. With a properly configured internal cloud, this is a non-issue. I can literally click a button and remove a physical server from the cluster and it's completely transparent to end-users. Need to add capacity? I SAN-boot a cloned disk and the new server is automatically part of the cloud and ready to take on work.

We used to build our environments around managing discrete servers. Even if we had streamlined the process, it was still very much centered around the physical box. For example, we can stand up a box in a manner of minutes using RHEL kickstart, but if we wanted to add high availability this often meant configuring heartbeat IPs, swing SAN disks, /etc/hosts files for private IP ranges, etc.. HA on a cloud is almost too trivial to detail.

Of course it's not there yet, but it's where the more recent virtualization technologies was 5 years ago (and yeah, virtualilzation has been out for decades, but it has only within the past decade really surged).

Re:no I won't

[DrgnDancer]

YMMV, but in my experience there are three types of "low level" jobs in IT (not programming per se, though there are definite corollaries here, but "support IT"):

1) Low level tech support grunt for a large company. You're going to be dealing with nothing but users. They are the entire focus of your life, if you get to deal with an "obscure network and infrastructure problem" it's purely by accident because your user happened to discover it. Even then, since you probably have minimal access to servers and network equipment, the best you'll probably be able to do is escalate it.

2) Systems/network admin for a small company or facility. You'll still have to deal with users. You're probably the entire IT department, or at best the junior member of a very small team (all of whom want to push user issues off to you for the same reason you don't want to do them). On the bright side you're far more likely to be directly involved in building, deploying, and supporting the infrastructure. On the down side, unless it's either a really odd company or in the infrastructure business, the stuff will be incredibly vanilla. Windows AD and file servers attached to a few workstations on one or two logical networks and getting to the Internet via some form of SDSL. Probably a firewall appliance sitting between you and the DSL modem, and, if the company actually hosts its own Internet facing presence (most small companies don't), a small DMZ with the web and mail server. Not much for obscure here.

3) Data center lackey for a large company. On the bright side, no users. On the downside you probably mostly haul boxes, rack system, replace parts, and make accounts. If you're both smart and lucky though you might be able to get yourself in good with the higher level guys and they'll trust simpler (for relative values of "simple") problems to you.

Three offer the best possibility for what you want, though you usually have to be patient. Two is how I came up, and frankly I thought it was the best overall situation. You'll have to deal with users, a lot, but I don't really mind users to be honest (I'm a fairly social person, IT geek or not). The thing is, you pretty much to get see every aspect of IT. It's all on a smaller scale of course, but you actually get to do the planning, executing, and maintenance of your very own setup. You don't get a lot of obscure problems, but frankly those sound a lot sexier when you're sitting in college looking for a challenge than when you have a guy breathing down your neck wanting to know when things will be back up while you're still trying to figure out what the Hell happened in the first place.