| YMMV. I came the other way. I started with AWS a couple decades ago. I was lucky 'cause I worked at Amazon and there was always a friend-of-a-friend inside the organization which could put me in touch with someone who understood what the system was doing. Documentation in the early days was bad. We learned to reverse-engineer what was happening underneath the interface abstractions. Kind of a sh***y experience, but if you banged your head against the wall enough times, you were able to figure it out. Then a whole bunch of AWS people left to go work on Azure. It's not that Azure was made exclusively of AWS people, but you can definitely see some AWS fingerprints all over Azure. The abstractions and interfaces are similar. GCP seemed to be a different creation, exporting different abstractions. Starting with account creation. How do you create an account? AWS is pretty straight-forward. GCP has several different (undocumented) account types you have to understand before you can complete account creation. Or, you can just guess and pick one at random. AWS Lambdas (for instance) are pretty straight-forward to create. You create the lambda via a command line interface, a {java|javascript|python|c#} program or via the console. It is an entity you identify with a ARN/URI and do things to it. GCP seems to have different ways to identify GCPs (is it an index? is it a name? is it a URL? is it a URI?) and the answer to how to do things was always "you write a python program to do that." (Not so much because there was only a Python SDK, but because there were only Python code examples.) AWS docs weren't the best in the world, but they were easy to find. And they documented the underlying objects that exported methods / abstractions to modify those objects' state. It was often mildly confusing what you were looking at (abstract, HTTP API or JavaScript SDK) but it was pretty straight-forward to work it out. Over time the AWS docs improved slowly. Azure interfaces and docs seemed to follow AWS pretty closely. Getting back to the GCF example. It's well known Lambdas are bits of code you write smushed into a container with the lambda runtime and deployed on a lightweight container. If you REALLY want to know, you can find out if two of the containers are running in the same VM, but you're sort of warned against it. GCF on the other hand... is it running in the same container? maybe. is it running in the same context? answer unclear. ask again later. It seemed to me the GCF guys wanted to make things a bit more abstract and herd programmers away from assumptions that are easy to make on AWS Lambdas or Azure Functions. And I think that mentality pervades GCP; It's a bit more abstract while AWS and Azure expose more concrete interfaces (until it doesn't in which case you have to ask your TAM to find an engineer who can send you copies of the documentation about an interface they haven't documented publicly.) It may sound like I'm down on GCP. I'm not really. But it *did* seem to "feel" very different from what I was used to over on AWS and Azure. Smart developers shouldn't have a problem moving from one to another, but when I moved from AWS to GCP, there was a month or two where I wasn't especially productive because I assumed it (GCP) behaved the same way as AWS and when I learned it didn't I had to spend time researching and recoding. Seems like getting a no or low cost account on AWS, Azure and GCP is pretty straight-forward. Maybe doing a project on AWS and Azure to demo your mad skillz (and to learn how they're different) would be a good idea. That way you could put an AWS project on the resume and it won't be a lie. Maybe what I'm saying is... yeah... under the hood it's all pretty similar, but the interfaces are different enough that you can take a productivity hit until you learn how they're different. As for me... if someone could demonstrate competence in one, I'm confident they could pick up the others without too much of a delay. I would eat the cost of an engineer having to read manuals and write test code to figure out a new environment if they were reasonably smart and worked well with others. |