>
That said; we also have "Cloud Engineer" as a job title, so I'm not sure we will learn this lesson.I don't bill myself as such, but I am basically a "Cloud Engineer". My expertise is in no way dependent on a particular cloud, and I've done work in GCP, AWS, Azure, Rackspace, and even a private cloud or two. A VM is a VM, Postgres is still (more or less) PG regardless of who is hosting it. Sure, there are specifics, but even cloud-specific stuff really doesn't differ too much, and it's pretty easy to find the common memes between the two. I can assign a role to VM in AWS, an IAM service account to a VM in GCP, and an "identity" in Azure. All 3 then permit the VM to make API calls to the respective cloud. All 3 fetch their access token in basically the same (but incompatible, of course) ways: HTTP request to a magic link-local IP.
A lot of the concerns I deal with, such as "can we survive an outage? what types?" depend on concepts like failure domains that apply equally to a cloud or to a datacenter.
But at some point, I had to dip my toe into a new cloud. I started a new job, and they used this thing called "Azure", and at that point, I'd never heard of it before. But you approach it with an open mind and the right balance of "some of my old knowledge might be relevant, but this new thing might also work differently and I should be prepared to build a separate mental model around it if the old knowledge is leading me astray."
… and I'd expect the same from someone doing "data analytics"; I'd expect something like "math is math, how I collect the data might change, what APIs I use to process it might change but the math is the same."