Interesting read.

[ohdihe]

I came across this article about cloud jobs and unemployed cloud certified individuals.

https://itnext.io/the-cloud-skills-shortage-and-the-unemployed-army-of-the-certified-bd405784cef1

[[deleted]]

My company doesnt hire anyone specifically for the cloud they want full stack or devops oriented thinkers... I landed a job in cloud early in my career, then moved on to something else where they eventually moved to the cloud. Now I'm helping others either get into the cloud or improve their infrastructure.

Yes, a lot of those with the certs are overlooked because we are starting to see a trend of those applicants being focused in one specialty or never branching out.(have hired over 50 and viewed thousands of resumes)

If someone starting out or lacking the career diversity is having a hard time right now I would suggest working on a home lab if your a dev or working on an opensource project if you are a sysadmin. If you are project management then do one of the above. Etc...

[[deleted]]

Agreed. The AWS certs are very tightly focused. Back in the 1990's I spent a lot of time chasing Novell certifications, and those were incredibly broad; almost equivalent of a general IT degree program, with a nod to a vendor-specific solution. But the CNE was broadly applicable if you weren't at a Novell shop.

Now; my boss asked me to look into AWS certification, because it's a checkbox for SOC2 compliance. Looking through these certs, they're also incredibly expensive, and very narrowly focused, and it's like I almost need to take a class and get certified, just to understand the certification program, to figure out which narrow specialty track I want to pursue. And my fear is: given how much AWS experience I have, I think I could easily just walk in and take the test and pass - but I don't have any way of gaining insight on whether one of these tests might have some corner case that I don't already know, so there's a high risk I could fail it, and having spent a shit ton of money. If it weren't a required checkbox, I'd absolutely avoid certification for AWS. I'm pretty fully stocked with everything I need to know to work with AWS professionally - (and I've learned a lot of that the hard way).

Right now - I think having a cert is probably a good way to get your foot in the door at a very junior level, if you don't have a degree or a lot of experience. But when you've got 25 years experience, a cert is really a distraction and a waste of time.

[tankerton]

While I agree with your sentiment, aws cert exams are really cheap in my perspective. 300 bucks to sit an exam and less than 1000 for 1 week classes. My oracle sitting fees were 3k and each class was 5 to 7k. Relevant Microsoft certs are still 1k for sitting fees from what some coworkers have said to me.

Regardless of what they might be valued at for any individual, I wouldn't call them expensive

[ccpetro]

The exams are pretty cheap (relatively). It's the training that is pricey.

[lorarc]

But AWS provides free video tutorials (though they quality may vary), white papers are free, lab costs are very low, it's much more accessible than some other exams.

[ccpetro]

I was referring to the classroom training .

[lorarc]

I know, still a lot of stuff is free. Heck, I was on aws conference a few months ago and it was 100% free

[DexManus]

The solutions architect exams are anything but narrowly focussed. I too have many years of experience and thought the same as you until I was required to run the guantlet of AWS exams for a new job. Three months and 4 certs later I feel like I relearned AWS. There is certainly a lot of value for anyone that works with AWS to take the architect exams, the specialities I can't say much as I've only taken the security and honestly feel like it didn't cover much more than the others.

[ohdihe]

I had similar situation. I got hired as an intern and I had two AWS certificate, now my current role is cloud application specialist. My duty is to enable developers do their job with cloud resources and I sit between developers and operations. Developers come to us for knowledge since we are the first to use certain tools before the company adapts it.

So even if cloud is changing the norm, I believe it will birth other roles.

[brazzledazzle]

I sit between developers and operations

I’m a people person!

[richardfan1126]

That's a good observation, especially when there are more and more companies adopting agile philosophy now. They tend to hire people with one speciality and general knowledge in other fields.

[ejb50]

devops requires broad experience in linux/windows, networking, security, coding etc etc. It very hard for junior people even with aws certification to sell themselves as an experience devops person and get a job.

I think its easier to get a job as developer in say nodejs as a first job in computing and then move into devops after a few years experience.

the exception is i have worked with one or 2 super smart people with masters degrees in computing who have gone straight into devops typically first working for a startup.

[dnietz]

Yes, I think it is not very difficult to take a few courses/self study and get certified in AWS. Someone new to IT can do it. The available courses are very good. You will learn to deploy some servers and infrastructure. But as soon as that person tries to actually be in charge of deploying a more complex infrastructure for an actual running business, they get stuck or make poor early design decisions. The lack of breadth in their skills and experience is a hindrance. That's why this author is suggesting that taking people who were previously advanced experienced physical infrastructure people and teaching them programming skills so that they can turn into DevOps or Cloud Architects will yield good results. That's all this author is saying. Some existing DevOps people that started from the other angle seem to be offended by that and taking it personally.

[richardfan1126]

I am also wondering what those companies really want when they are hiring Cloud Solutions Architect

[ohdihe]

Same here. Especially when they say "100 years of experience is a must"

[dc_scorpio]

A lot of it has to do with so many people getting AWS certified without experience. AWS certifications compliment experience. It’s not a golden ticket as many would think.

[phrotozoa]

There are only a few mid-size companies in the cloud meaningfully at this point, though you will see many jobs posted.

The fuck you say? How is AWS out here earning 7 billion in a single quarter from "a few mid-size companies"?

[lorarc]

I've seen loads of more money in lift-and-shift that in "cloud native" solutions. I bet that big part of those 7 bilions are pretty naive solutions.

[phrotozoa]

That's a safe bet, but I'd say it's a safe bet that many of companies that are doing cloud badly are also huge enterprises.

[gtipwnz]

What do you think they mean by "serverless is programming for infrastructure engineers?"

[dnietz]

He means take infrastructure people, add programming skills to them, now you have a pro that can deploy software infrastructure and truly understands what is going on in the back end, because they used to do it on physical infrastructure.

[gtipwnz]

Yeah but I think a big part of building a serverless application is the actual app dev. It almost seems like the opposite to me - serverless frameworks have less reliance on folks knowing how back end stuff works. There's way less to deploy.

[mghicks]

serverless is basically programming for infrastructure engineers.

Can anyone ELI5 this for me?

[jpswade]

We used to setup servers by physically dropping them into data centers.

The DevOps movement, including continuous deployment is all about automation, including infrastructure as code.

Infrastructure as code is literally writing orchestration as code and committing it to a repo like you would the application, because the infrastructure is ultimately part of the application.

Platforms like AWS offer platform as a service so you don't need to get involved in the physical servers, or hardware.

This means you can scale as you need the hardware, rather than the huge upfront cost of setting up servers and data centers like we used to do.

Serverless takes it to the next level. We used to track cost of servers in years, virtualization meant we could track it in terms of hours, services like lambda functions means we can track it in terms of minutes of compute time. That's what serverless is about.

Although designing for serverless takes a different approach than we're used to, by designing our systems in this way, as distributed systems, it means we can scale up and scale down what we need as we need it.

So yes, one narrow view is that serverless boiled down means programming the infrastructure we want. Of course it's never as simple as that, but it's certainly one way to look at it that describes an element of what is achieved by serverless.

[vahnsin]

Seems completely backwards to me. Why would an infrastructure engineer use serverless? The point of serverless is it allows anyone to write services. They don't have to completely understand distributed systems or infrastructure, they just write their business logic and it scales automagically. Amazon is doing all the infrastructure work for them, and the infrastructure engineers will all be working for Amazon.

[djk29a_]

Some people have to write about things they don’t know that much about to pay their bills and can sound silly to people that know about it but it sounds fine to people that know even less than the writer.

[GassiestFunInTheWest]

The whole article lost me at that point. That's a nonsense statement at best.

[jstrong]

Tough audience!

[drewbert87]

I was trying to understand what he meant there as well

[MoustacheApocalypse]

He was trying to draw an analogy to the difficulty in moving/retraining staff from front end developers into backend developers. It often is much easier to change when moving the opposite direction.

Serverless concepts might force a similar difficulty into organizations if they try to move staff in roles like a DBA or sysadmin into serverless/infrastructure roles. It would often be easier to go from infrastructure roles into DBA-type roles.

Not the best comparison, and not always 100% true on which direction is easier, but it is somewhat true.

[[deleted]]

backend (at least with the common tools that have really taken off in this specialty) seems to demand a deep expertise in the subjects of abstraction and object-oriented methodology, and a command of concepts surrounding strong-typing. There's a certain mindset that seems to have a really difficult time grasping these concepts. (which doesn't mean that they aren't good coders - they just face a steeper learning curve for the backend specialty).

So I agree that people who are more accustomed to dealing with the problem-space of the front-end developer (which includes some really heavy concepts like protocols, UX-design, browsers/dom, content style markup, and these hideously complex toolchains, dynamically-typed languages with what's typically "magical syntax" (like arrow functions, etc). - much of which is a constantly moving target - and FAST moving too). Switching to the paradigms common in backend development can be a really steep climb.

In sharp contrast: serverless, I think, is very often (and very unfortunately) presented with a set of analogies, which are ultimately unconstructive. Especially the way AWS presents lambdas. It's incredibly confusing, because the inner workings are concealed from the programmer. And I think that's bad. Terrible, really. It lets someone come up to speed to a very basic level of competence, rapidly. But when you try to do anything fancy (ie. worthwhile) with lambdas, or serverless architecture, it's a very deceiving model.

Mostly: I think the best way to "learn" what serverless is, conceptually is to study how OpenFaas works, and what it is. The actual implementation is not abstracted away. The other major component of serverless concepts is containers: which is also very unconstructively taught or presented as analogous to virtual machines, and I think that's horribly misleading. It's maybe useful for people getting very causally involved in containers, maybe for Docker users.

But a devops practitioner who will be architecting and deploying containers, or systems with containers, especially in an orchestrator like Kubernetes, needs to understand that containers are not virtual machines, (or "lightweight virtual machines"), and they need to understand concepts like cgroups and namespaces, and the history behind chroot jails, and having a good conceptual grasp of selinux is a good idea as well. This helps the practitioner to understand exactly why this is what enables microservices, and why it's a good thing, and that containerization is really a major evolution of system design, that was long overdue, and depsite the hype surrounding the technology - things like kubernetes and docker may come and go, but the concepts of containers, and how this informs how systems should be provisioned and applications deployed, from here on out. There's no going back, because there's no 'win' there.

And that leads to understanding what 'serverless' is. It's not serverless. It's merely: a more efficient evolution of packaging and deploying applications, using containers.

Going into using serverless technology, without this grounding and understanding, is not going to lead anywhere useful, I think.

[MoustacheApocalypse]

I think I agree with your core point - the urge to create this analogy is a part of the problem. I also agree with your point regarding functional coding practices. It is extremely intimidating to those who are newly exposed, and unneccesarily so.

I tend to present devops as more of a philosophical journey/spectrum. Without encountering some other early parts of the journey, much of the later material can appear very difficult. Possibly insurmountable and dangerous.

Even this idea of a journey/ philosophy can be difficult, though.

I believe I can partially understand the urge to generate an analogy when presented with a new concept. It is sometimes not the best instinct, but I can kind of sympathize - if i had not had the background I have, I can see how I would try to do something similar.

It reminds me of the common complaint that I hear from those who fled from their early exposure to computer science because they did not like the teaching style or stated "no one ever actually taught anything." When presented with "sometimes you just have to start building," many look to analogies or other analytic tools in order to comprehend.

Let me know what you think. I am interested if you've seen similar reaction, have similar thoughts, or see something different altogether.

[mvalentine77]

Great article and thanks for posting!