Comment

Comment on Using Clouds for too long might have made you incompetent

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.

source

Sort:hotnew top

Scipitie@lemmy.dbzer0.com ⁨1⁩ ⁨day⁩ ago
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.

source
- loudwhisper@infosec.pub ⁨1⁩ ⁨day⁩ ago
  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.
  
  source
  - Scipitie@lemmy.dbzer0.com ⁨1⁩ ⁨day⁩ ago
    Oh yeah I see…
    
    As some old philosopher once said: “shit’s fucked, yo”.
    
    Seems to be appropriate here.
    
    source
Deestan@lemmy.world ⁨1⁩ ⁨day⁩ ago
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 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 these skills more naturally - because they had to. This makes sense and I believe it.

source
- loudwhisper@infosec.pub ⁨1⁩ ⁨day⁩ ago
  
  You say “incompetent” and “less skilled” as general statements on senior engineers. Those statements are false.
  
  I am saying that the competencies of people who grew up (professionally) with outsourced services are more superficial and give them way less understanding (and agency) on the systems they oversee. I make the opinionated argument that knowing which service to use in a cloud provider is not just a different skill from implementing that functionality “manually”, but is hierarchical inferior, easier to acquire and less useful in general.
  
  A weird parallel would be someone who hikes 100% of the time with a guide who takes care of orientation, camp setting etc., and someone who goes alone. If I am simply comparing the pictures they are showing me, I might not appreciate the difference, but if you asked me who I would trust to come hiking with me, I wouldn’t have doubt, because I consider the skill “finding, choosing and listening to the guide” to be hierarchial inferior to “orient, set camp etc. by yourself”.
  
  So it’s not just a matter of matching the skills I need, is actually a much broader argument about deskilling engineers.
  
  source
  - Deestan@lemmy.world ⁨1⁩ ⁨day⁩ ago
    I understand.
    
    Obviously, “knowing which cloud services to enable” is a lesser skill than knowing how those services work. That is not a parallel or equal skill in any way.
    
    But do you assume people are just going drrrrr brain off when they don’t learn that one skillset you are accustomed to spotting?
    
    source
    loudwhisper@infosec.pub ⁨1⁩ ⁨day⁩ ago
    Well, for the relatively small sample of Kubernetes experts I interviewed, basically any topic beyond “you use this tool” was a disaster, including Kubernetes knowledge. I am not selective, it’s not like I expect a specific skillset, but what would you think if someone with a decade of platform security doesn’t understand cryptography and supply chain, Linux permissions, Kubernetes foundational concepts, container isolation or networking? At some point the question is legitimate, what are you expert in? The answer I have been able to give myself so far is “stitching together services that do stuff” and “recommend what the documentation/standard recommends”. I consider myself satisfied to have somewhat decent knowledge in some of those areas, I am not expecting someone understanding all of that, but none of them? Maybe from someone who just joined the industry.
    
    source