Want an IT Job? Add 'Cloud' To Your Buzzword List 187
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."
ignoring the 5 brain-dead replies so far... (Score:0, Interesting)
Is there any way an amateur programmer with a CS degree but only 3 years work experience under his belt could add this to his resume in a reasonable time frame and thus become a shoe-in for entry-level cloud positions?
I am desperate for work. It has been 2 years now :( Reading that pile of SQL .NET and so on books doesn't seem to have helped my prospects at all, because recruiters and interviewers always only care about responsibilities I had in my last job, and wouldn't trust that I could do or know anything else.
The last recruiter I met pointed to the word "Linux" on my resume and said, "And LINUX, what the HELL is that anyway? I mean, you can probably tell me that you heard of it one time in college and it is an operating system or SOMETHING. Yeah?"
Re:Today's word..."Cloud" (Score:2, Interesting)
Which is why internal "clouds" have always amused me to no end...
Personally, as a *nix generalist, even the idea of an external "cloud" is ridiculous to me. What the hell does a company actually do, if it outsources even it's own knowledge management?
But I agree that an internal "cloud" is just as misguided. The sad fact is that most companies with more than a few hundred employees are organized as collections of surprisingly small fiefdoms. Even until recently, the idea of centralizing something as common as IT infrastructure really was so foreign to the typical corporate structure that it had to be sold in a way that those fiefdoms could treat it as an external service.
Re:Today's word..."Cloud" (Score:5, Interesting)
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:But only those with experience are wanted. (Score:3, Interesting)
Very.
And referring to all those job ads asking for more years of experience in a certain tech than that the tech is around. This has been featured several times here.
Re:Today's word..."Cloud" (Score:3, Interesting)
I sat through a cloud lecture by some Microsoft guy, and he said it's aimed at startups, that don't know what server load to expect, and want a scalable solution. Practically Microsoft hosts the app with database and everything, the app must be written against a specific cloud api (in some .net language), and they bill by CPU time, network throughput and database size.
Re:Today's word..."Cloud" (Score:2, Interesting)
...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.
Which is why internal "clouds" have always amused me to no end...
It's understandable that you'd think that way if you don't understand how wildly organizational structures vary from organization to organization, and you're used to organizations where there is "The IT department" and customers of that IT department. In that case, yes, why on earth would The IT department build a "cloud", when the only customers of it would be themselves?
I'll give you an example of where this is arguably a good idea: NASA. Across ten or so centers, there are hundreds of generally self-sufficient small projects. The norm for many projects is to run their own small data centers (ranging from a single server running under someone's desk and up), because shared services typically don't provide the flexibility they need. Often this is software dev, wacky data distribution (like GDS), that sort of thing.
In that environment, an Infrastructure cloud (IaaS, whatever buzzword strikes your fancy) starts to make sense. Which is exactly what NASA is doing, though I'll reserve judgment as to how good of an idea it was until it's been in place for a couple of years. :) But in theory and on paper, it's not unreasonable to have an "internal" cloud.
I have no doubt that it would be similarly a "good idea" in other organizations, like a large university.
Re:ignoring the 5 brain-dead replies so far... (Score:4, Interesting)
Also, I think it's easier to be a convincing generalist than a convincing specialist there's always someone with more experience than you). So don't do just SQL, or just .Net, or just Linux. Show them you know a bit of everything, and can learn new stuff quickly, and tell in your CV what specific kinds of things are still on your to-learn list.
Definitely this. When I'm hiring a contractor/freelancer for a one-off job, I want specialist knowledge. When I'm hiring someone permanent, experience is always great but really what I want to see is that they have some interest beyond just slotting into a specific role for the sake of job security. If nothing else, showing that you have a broader interest than just .NET gives the impression that you're not just in this for the 9-5 but actually have a genuine desire to learn. I would also add that, even while out of work, there are things you can involve yourself in to show potential employers that you weren't just bumming around. Try writing to local business and offer your services cheap or even free, try and get involved with local charities or community events. It might pay little or nothing short term but if it lands you the job you want long term then it's as good as money in the bank. Finally, depending on location, you might consider doing some contracting - the lack of experience is a bit of a draw back but I know plenty of successful contractors who started out with less (just be realistic about earning potential until you get more experience), even during a downturn there's usually plenty of contract work (often more so, because companies look to get people in for short term projects rather than hiring permanent developers).
Re:Today's word..."Cloud" (Score:3, Interesting)
The symbol used to indicate parts of the network that you have no knowledge of.
That's the definition as it pertains to networking. It's now been extended to other types of hardware and certain types of software, and it all works on the concept of "I don't know where it is or what it looks like, but I do know that if I wave my hands like this then it all works just fine." As long as things actually do work, then that's a good thing: you're saved the effort of thinking about lots of frankly irrelevant crap (well, irrelevant to you; someone cares about it...)
Re:no I won't (Score:5, Interesting)
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.