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."
I can define the cloud for you. Cloud (noun) : The symbol used to indicate parts of the network that you have no knowledge of. Frequently used by people to describe external computer resources as a new concept when their knowledge of computers only extends back to 1998.
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).
I bet experience is the key here. Only candidates with at least 8 years experience in managing cloud computing in a virtualised environment will be considered.
And don't forget to list your four years experience with administering Windows 7.
In my experience, there's plenty of choice. Not all of it great, of course, but there are some real gems passing along every now and then. They just get swamped in job offers for big Java enterprisey stuff. I try to scare them away by mentioning I don't want to work with Java, JSP or Struts, but since my CV contains the word "Java", they still contact me.
Interestingly, they also contact me when they need an Erlang or Python expert, despite the fact that I have no experience in those languages. But my CV says I want to learn them. Really, nobody ever reads CVs. They just do basic pattern matching and assume that's good enough.
My most interesting recent offer was from a company that wanted to switch to Scala. They had no Scala expertise yet, but needed some people wiling to learn and guide the transition. But it was almost an hour commute, partially by train, and I want to go to work by bike. But there's enough choice to be this picky, so the job market isn't exactly slow where I live.
synonym of 'fog'.
One very simple example: Do you have ever set up Google Apps for a domain, with email, contacts, calendar, Google sites and so on? Yeah, it's all in the cloud and all you have to do is clicking on buttons and filling out forms. Now go and look at some user trying to set this up. More likely than not he will get as far as configuring the MX-records and then he will cry for help.
All this cloud stuff seems to be so simple, but it very much isn't. And yes, this actually is nothing a real pro would like to bother with (you'll be fighting more with the UIs than anything else) but there is high demand for this, people think they can finally get away without someone who knows what he does, but they can't.
Most of this is in no way interesting or satisfying work but just fighting half-wit user interfaces. It's sometimes insulting, actually. Instead of really setting up things and controlling things you're hanging off someone else's setup and try to beat some sense out of it. It's often frustrating, you often will have to come to the conclusion that things you would like to do just can't be done because they're not offered and you can't do anything about that. But hey, it's just work.
Me? I'd rather setup a full server park from scratch with old PCs and Linux than fighting the "cloud", but guess what's in demand more. And yes, there's a whole army of trained monkeys out there, knowing every cloud service under the sun and with superhuman point-and-click abilities, but if you really know your job and also know about problems and limitations you can still easily make some money with this. Fun is this not, though. Fun is making things, not using things.
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.
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.