My take on how a decade (or more) of using cloud services for everything has seemingly deskilled the workforce.

Just recently I found myself interviewing senior security engineers just to realize that in many cases they had absolutely no idea about how the stuff they supposedly worked with, actually worked.

This all made me wonder, is it possible that over-reliance on cloud services for everything has massively deskilled the engineering workforce? And if it is so, who is going to be the European clouds, so necessary for EU's digital sovereignty?

I did not copy-paste the post in here because of the different writing style, but I get no benefit whatsoever from website visits.

Using Clouds for too long might have made you incompetent | Loudwhisper

(loudwhisper.me)

That's the thing! I think it wouldn't be conceivable that your "principal engineer" (real position for one of the people) doesn't understand the basic theory of the stuff they are implementing. Now it feels you can instead work years and years just shuffling configuration and pressing buttons, leading to "senior" people who didn't gather actual years of experience.

I don't want to pretend I am outside this logic. I am very much part of this problem myself, having started my career 10 years ago. I do despise cloud services though (if anything, they are super boring), so I tend to work with other stuff. But I could 100% just click buttons and parrot standard and keep accruing empty years of experience...

This is quite a trite argument from my point of view. Also, this is from the perspective of the business, which I don't particularly care about, and I tend to look from the perspective of the worker.

Additionally, the cloud allows to scale quickly, but the fact that it allows to delegate everything is a myth. It's so much a myth that you see companies running fully on cloud with an army on people in platform teams and additionally you get finops teams, entire teams whose job is optimizing the spend of cloud.
Sure, when you start out it's 100% reasonable to use cloud services, but in the medium-long term, it's an incredibly poor investment, because you still need people to administer the cloud plus, you need to pay a huge premium for the services you buy, which your workforce now can't manage or build anymore. This means you still pay people to do work which is not your core business, but now they babysit cloud services instead of the actual infra, and you are paying twice.

Cloud exploded during the times of easy money at no interest, where startups had to build some stuff, IPO and then explode without ever turning a single dollar of profit. It's a model that fits perfect in that context.

This is quite a trite argument from my point of view. Also, this is from the perspective of the business, which I don't particularly care about, and I tend to look from the perspective of the worker.

Additionally, the cloud allows to scale quickly, but the fact that it allows to delegate everything is a myth. It's so much a myth that you see companies running fully on cloud with an army on people in platform teams and additionally you get finops teams, entire teams whose job is optimizing the spend of cloud.
Sure, when you start out it's 100% reasonable to use cloud services, but in the medium-long term, it's an incredibly poor investment, because you still need people to administer the cloud plus, you need to pay a huge premium for the services you buy, which your workforce now can't manage or build anymore. This means you still pay people to do work which is not your core business, but now they babysit cloud services instead of the actual infra, and you are paying twice.

Cloud exploded during the times of easy money at no interest, where startups had to build some stuff, IPO and then explode without ever turning a single dollar of profit. It's a model that fits perfect in that context.

Mind you that my take and experience is specifically in the context of security.

I struggle to make the parallel that you suggest (which might work for some areas) with a security engineer.

Say, a person learned to brainlessly parrot that pods need to have setting x or z. If they don't understand them, they can't offer meaningful insight in cases where that's not possibile (which might be specific), they can't provide a solid risk analysis etc.

What is the counterpart to this gap?
Because I struggle to see it. Breadth of areas where this superficial knowledge is available is useless, IMHO.

My take on how a decade (or more) of using cloud services for everything has seemingly deskilled the workforce.

Just recently I found myself interviewing senior security engineers just to realize that in many cases they had absolutely no idea about how the stuff they supposedly worked with, actually worked.

This all made me wonder, is it possible that over-reliance on cloud services for everything has massively deskilled the engineering workforce? And if it is so, who is going to be the European clouds, so necessary for EU's digital sovereignty?

I did not copy-paste the post in here because of the different writing style, but I get no benefit whatsoever from website visits.

Using Clouds for too long might have made you incompetent | Loudwhisper

(loudwhisper.me)

My take on how a decade (or more) of using cloud services for everything has seemingly deskilled the workforce.

Just recently I found myself interviewing senior security engineers just to realize that in many cases they had absolutely no idea about how the stuff they supposedly worked with, actually worked.

This all made me wonder, is it possible that over-reliance on cloud services for everything has massively deskilled the engineering workforce? And if it is so, who is going to be the European clouds, so necessary for EU's digital sovereignty?

I did not copy-paste the post in here because of the different writing style, but I get no benefit whatsoever from website visits.

Using Clouds for too long might have made you incompetent | Loudwhisper

(loudwhisper.me)

I'm reminded of when my boss asked me whether our entry test was too hard after getting several submissions that wouldn't even run.

Sometimes prospective employees are just shit.

I got asked the same. I simply pointed out the test is a reproduction of last week's bug that took down prod at 2am and got paged to fix, and is therefore as realistic as it gets of what they'll need to be able to handle.

It's always DNS, everyone should know that.

At least where I work, our cloud team is ~35 people who manage the whole thing.

The datacenter team? In the hundreds.

Cloud is not the answer to every infra problem, but the flexibility, time to market, and lifecycle burden are easily beneficial weighed against finops. I’m an Azure engineer myself, it’s no comparison the benefits to a managed solution vs rolling your own DC for a lot of regular business workloads and solutions. Beyond that personally I’ve been able to skill up in areas I wouldn’t be able to otherwise if I was stuck troubleshooting bad cables, rebuilding a dead RAID array, or planning VMWare scaling nonsense.

I went through hiring several times at several companies, being on the interviewer side.

Typically it's not the talent pool as much as what the company has to offer and how much they're willing to pay. I referred top notch engineer friends, and they never made it past HR. A couple were rejected without interview because they asked too high of a salary, despite asking under market average. The rest didn't pass HR on personnality or not having all the "requirements", because the really good engineers are socially awkward and demand flexibility and are honest on the résumé/CV, or are self taught and barely have high-school graduation on there (just like me).

I've literally seen the case of: they want to hire another me, but ended up in a situation where: I wouldn't apply for the position myself, and even if I did, I wouldn't make it to the interview stage where I'd talk to myself and hire myself.

Naturally the candidates that did make it to me weren't great. Those are the people that do the bare minimum, have studied every test question (without understanding), vibe code everything, typically on the younger and very junior side. They're very good at passing HR, and very bad at their actual job.

It's not the technology, it's the companies that hire that ultimately steers the market and what people study for. Job requirements are ridiculous, HR hires engineers on personnality like they're shopping for yet another sales associate, now it takes 6 rounds of interviews for an entry level position at a startup. VC startups continue to pay wildly inflated wages to snatch all the top talent while established companies are laying off as much IT staff as possible to maximize profits.

I'm not in any way, shape, or form an engineer so I don't really understand the exact details of your post.

However, you post reminded me of a really good episode of a podcast called Hidden Brain. In it the host, discusses the topic of knowledge with a cognitive scientist.

At one point, they talk about how sophisticated technology has gotten that people don't know how to solve problems if that technology brakes, especially since technology is getting so good that it makes fewer mistakes. They use an airplane as an example in which an experienced pilot forgot how to get out of a nosedive and crashed the plane. On a smaller scale, the host mentioned that he has a hard time navigating if his phone's GPS doesn't work.

Its a really interesting listen if you have the chance.

Because a security engineer focused on cloud would rightfully say "pod security is not my issue, I'm focused on protecting the rest of our world from each pod itself.". With AWS as example:
If they then analyze the IAM role structures and to deep into where the pod runs (e.g. shared ec2 vs eks) etc. then it would just be a matter of different focus.

Cloud security is focused on the infrastructure - looks like you're looking for a security engineer focused on the dev side.

If they bring neither to the table then I'm with you - but I don't see how "the cloud" is at fault here... especially for security the world as full of "following the script" people long before cloud was a thing.

I get you that it's easy to over-provision in the cloud, but you can't return an on-prem server. A cloud VM, just shut it down and you're done.

AWS talks about minimizing undifferentiated heavy lifting as a reason to adopt managed services and I find that largely to be true. The majority of companies aren't differentiating their services via some low-level technology advantage that allows them to cost less. It's a different purchasing model, a smoother workflow, or a unique insight into data. The value an organization provides to customers should be the primary focus of the business, the rest is a means to sharpen that focus.

I mean, the person in question had "hardening EKS" on their CV. EKS still means that the whole data plane is your responsibility. How can you harden a cluster without understanding the foundation of container security (isolation primitives, capabilities, etc.)? Workload security is very much part of the job.

I mean the moment some pod will need to run with some privilege (say, a log forwarder which gets host logs), and you need to "harden" the cluster, what do you do if you don't understand the concept of capabilities? I will tell you what, because I asked this very question, and the answer was "copy the logs elsewhere", which is the "make it work with the hammer solution" that again shows the damage of not understanding.

I am with you about different scopes, skillsets etc. But here we were interviewing people with a completely matching skillset on paper.

I agree with your lack of affection for cloud services, but I think your view might be a little skewed here. Does a senior mechanic need to understand the physics of piston design to be a great mechanic, or just gather years of experience fixing problems with the whole system that makes up the car?

I'm a Senior Systems engineer. I know very little about kernel programming or OS design, but i know how the packages and applications work together and where problems might arise in how they interact. Software Engineers might not know how or don't want to spend time to set up the infrastructure to host their applications, so they rely on me to do it for them, or outsource my job to someone else's computer.

A cloud VM, just shut it down and you're done.

If this flexibility is needed, and it's an "if", a dedicated server does the same. But even a cloudVM is already lower level compared to other services (which are even more abstract) - like EKS, SQS, etc.

The value an organization provides to customers should be the primary focus of the business, the rest is a means to sharpen that focus.

In my experience this often translates in values that flows to AWS, while the company giving value to customers is stuck with millions of cloud bills each month, and a large engineering footprint that eventually needs to cut, leaving fewer and fewer people working on the product.

That said, I acknowledge that cloud has business reasons to exist, I wrote an entire other post about my hate for it, but I still acknowledge that. However there are some myths that finally are getting dispelled (outsource infra and focus on your product).

Mind you that my take and experience is specifically in the context of security.

I struggle to make the parallel that you suggest (which might work for some areas) with a security engineer.

Say, a person learned to brainlessly parrot that pods need to have setting x or z. If they don't understand them, they can't offer meaningful insight in cases where that's not possibile (which might be specific), they can't provide a solid risk analysis etc.

What is the counterpart to this gap?
Because I struggle to see it. Breadth of areas where this superficial knowledge is available is useless, IMHO.

I'd like to understand how self managing all the lower level components abstracted by the cloud is saving on headcount. Care to math that out for us?

Yeah I can see that.

However, you are now arguing a different point than I am getting from your original post. Maybe my fault in interpretation ofc, but the main difference (in my view) is:

You say "incompetent" and "less skilled" as general statements on senior engineers. Those statements are false.

You also say "missing the skills you are looking for" which is obviously true.

And the implication that before cloud, people developed the specific skills you need more naturally - because they had to. This makes sense and I believe it.