Skip to main content

Cloud Jobs

Cloud is the current buzz in the industry and various cloud service-providers are jockeying for position to be #1. Beyond the hype and bravado I've been wondering who is really taking the lead because from my point of view it feels like it's down to Amazon and Google.

So I searched a few job-sites to see which cloud service providers are seen as being requirements for positions and the results are below.

cloud-jobs-20140424

 

Lots of "Cloud" jobs and AWS (Amazon Web Services) occurs quite frequently with Azure (Microsoft) and Rackspace relatively hot (compared to OpenShift, Softlayer and Oracle Cloud). Google App Engine (GAE) gets a few hits whilst the general search for "Google" (which covers "Google Apps" and so much more) if included would bring the search results into a comparable position to AWS but this is too general to include as "Cloud" so I've excluded it here. Google Compute Engine got no hits.

So Cloud is big, Amazon are #1 (currently) and Azure is pretty popular; which shouldn't be much of a surprise from the enterprise perspective. That OpenStack has a presence compared to end service-providers such as SoftLayer (IBM) and OpenShift (RedHat) indicates that there's work in the open-source cloud space which is good to see (AFAIC) and some of this looks to be in building private clouds. But the lack of any hits for Softlayer, OpenShift or Oracle Cloud is a bit of a surprise. I'd have thought someone would be after skills in this stuff. Anyway, my somewhat unscientific reckoning as to where we are based on a very small and selective sample of data is:

  1. The notion that "Amazon=Cloud" is hard to shift and the rest look to be rather slow to the party.

  2. Microsoft Azure is the preferred option for many enterprises who have a historic investment in all things MS and .NET.

  3. Google may be late to the IaaS party but since the net is the bloodline for Google I suspect that in the wider context of "cloud" they'll probably do ok (they've also got a hell of a lot of compute capacity lying around).

  4. Open-source cloud has a comparatively strong position compared to where OSS usually is (i.e. as the lowest cost option when you get down to IT as a commodity).

  5. There's a lot of demand for cloud which doesn't have any of these big cloud service providers as a requirement so the space for competition should be pretty hot despite this apparent Amazon/Microsoft duopoly.


Ok, it's hardly scientific and the scope of these service providers varies significantly so comparison is perhaps unfair. There's also the fact that some search results are of the form "... help us move from X to Y" which yields hits on both X as well as Y and though skills are required in both items it's really Y that should be preferred. It's also a very narrow selection of jobs in Britian today and says nothing about the rest of the world or what's already in use. Anyway, for this evening it's answered my question and I'll be reading up on my AWS, Azure and OpenStack to keep my skills current this weekend... :)

For the record, job sites searched were; jobserve.com, monster.co.uk, and totaljobs.com.

 

Comments

Popular posts from this blog

An Observation

Much has changed in the past few years, hell, much has changed in the past few weeks, but that’s another story... and I’ve found a little time on my hands in which to tidy things up. The world of non-functionals has never been so important and yet remains irritatingly ignored by so many - in particular by product owners who seem to think NFRs are nothing more than a tech concern. So if your fancy new product collapses when you get get too many users, is that ok? It’s fair that the engineering team should be asking “how many users are we going to get?”,   or “how many failures can we tolerate?” but the only person who can really answer those questions is the product owner.   The dumb answer to these sort of question is “lots!”, or “none!” because at that point you’ve given carte-blanche to the engineering team to over engineer... and that most likely means it’ll take a hell of a lot longer to deliver and/or cost a hell of a lot more to run. The dumb answer is also “only a couple” and “

Inter-microservice Integrity

A central issue in a microservices environment is how to maintain transactional integrity between services. The scenario is fairly simple. Service A performs some operation which persists data and at the same time raises an event or notifies service B of this action. There's a couple of failure scenarios that raise a problem. Firstly, service B could be unavailable. Does service A rollback or unpick the transaction? What if it's already been committed in A? Do you notify the service consumer of a failure and trigger what could be a cascading failure across the entire service network? Or do you accept long term inconsistency between A & B? Secondly, if service B is available but you don't commit in service A before raising the event then you've told B about something that's not committed... What happens if you then try to commit in A and find you can't? Do you now need to have compensating transactions to tell service B "oops, ignore that previous messag

Equifax Data Breach Due to Failure to Install Patches

"the Equifax data compromise was due to their failure to install the security updates provided in a timely manner." Source: MEDIA ALERT: The Apache Software Foundation Confirms Equifax Data Breach Due to Failure to Install Patches Provided for Apache® Struts™ Exploit : The Apache Software Foundation Blog As simple as that apparently. Keep up to date with patching.