AWS Lambda is a Linux container. Unless you are like me and have gcc working under it you are probably stuck in their garden of Go/NetCore/Python/Ruby/JS and don't care to much about it's Linux nuances.
Why are Linux skills a prerequisite for knowing AWS? Sure everything runs on Linux but the services themselves are managed and if you're going the serverless route or using Beanstalk you never need to know anything about Linux.
Eventually I want to learn Linux only because in AWS the Windows Tax is real for EC2 instances and they charge by the hour for instances instead of per second billing like they do for Linux - meaning you have to be real careful about autoscaling policies.
> Why are Linux skills a prerequisite for knowing AWS?
There are certainly a lot of parts of AWS you never use Linux, but I don't think you'd be qualified for a (more than junior) role where AWS was listed as a requirement. (In the same sense of being a web developer but not knowing Javascript, or being a Rails developer and not knowing SQL - you can get some of your job done, but not 100% of it)
Though AWS's marketing may imply otherwise, I think you'll find things like Lambda aren't the dominant use of AWS; I believe (no real statistics to back this up) the majority of AWS is still traditional workloads on EC2. And on EC2, according to https://www.zdnet.com/article/ubuntu-linux-continues-to-rule..., about 90% of EC2 instances are running Linux. (it's a bit of an older article, but the tool they reference to show platform usage is throwing an error right now)
- net ops - creating VPCs, security groups, load balancers, RDS instances, etc. You either do that through the AWS console (I wouldn't except for quick testing), the AWS CLI, CloudFormation (a yml file) or a scripting language - no Linux requirement.
- devops: Using CodePipeline the build step you either use the build agent on an EC2 instance (which could be Windows) or one of the prebuilt Linux Docker containers for the codebase you are using. Most of the time the command line that you use isn't any different between Windows and Linux. I did have to run apt-get to download zip.
For simpler scenarios you can use Beanstalk with Windows/IIS or Linux.
Development - if you are developing on an EC2 instance and you're developing Windows software, why do you need Linux if you're using a Windows instance? Even if you're using a pre instance launch script (UserData) if you're using Windows, you can use regular Windows commands or Powershell.
If you're using AWS services like RDS, DynamoDB, Redshift, ElasticSearch, etc. You need to know how to use those specific tools but you don't have access to the underlying operating system anyway.
For programs that must run on Linux like when using Lambda, you can run Linux shell commands but you usually don't need to.
The one wrinkle I've run into developing on Windows and deploying to Lambda with Python is C based Python modules. You can't just bundle the Windows versions in a zip file. I use Code Build anyway for that and my yml file imports the Linux versions and created the deployment zip file.
I would compare the lack of Linux fundamental skills and working in the Cloud arena, to learning cursive before learning to print. You might be able to pull it off, but the advantages to understanding the Linux building blocks behind the cloud magic cannot be understated. There will be numerous situations where having these skills in your back pocket can solve problems that aren't necessarily articulated in standard cloud workflows.
What would that be? In AWS everything is managed and the only time that you actually get near the OS are EC2 instances for some custom programs when you aren't using Docker/Fargate (serverless Docker) or Lambda and every now and then a few shell scripts.
Any complicated sceneries usually revolve around scripting AWS resources and for that I would use Python.
I'm using Docker just as a serverless app container with Fargate for long running apps - services that are inappropriate for Lambda. All of the infrastructure resources are managed AWS services - configuration, databases, load balancers, messaging, autoscaling, etc.
For Windows stuff, I'm using autoscaling EC2 instances. The issue like I said above is that the granularity for billing Windows EC2 instances is 1 hour compared to per second billing for Linux instances.
I'm not anti-Linux but the ops stuff for AWS revolves around either scripting with the CLI and batch files for simple stuff or Python+Boto3 for the more complicated scenarios.
As a developer, all the resources are managed, you never touch the underlying OS.
> I'm using Docker just as a serverless app container with Fargate for long running apps - services that are inappropriate for Lambda.
But what are you doing in that Docker container? Anything more than just pulling the default container? Every container I've built required pulling packages, setting some permissions, etc. A Docker container isn't OS-less, and you still have to be mindful of the same concerns as if it wasn't a container.
> As a developer, all the resources are managed, you never touch the underlying OS.
Sure. Though I'd posit is that if all you're doing is using fully managed services on AWS, it's akin to installing and configuring Wordpress - you use PHP, but you're not a PHP developer.
Why would you use AWS and then create a bunch of EC2 instances to host servers for databases, caching, ElasticSearch, messaging, configuration, orchestration, etc? That kind of defeats the purpose of going with AWS. If all you're doing is using a bunch of EC2 instances to simulate what you're doing on prem, you might as well go for much cheaper VPS providers. AWS is not buying you anything if you're still managing all of your own servers.
We're on ECS now (using EC2 - for persistent workloads, Fargate is much more expensive), but we ran a lot of traditional EC2 containers for years.
We ran alot of application code on EC2 while using services like SQS, RDS, etc. At one point we used Cloud66 that used our AWS backend. We do a ton of background processing; combined with spot instances, it's a great platform for scaling up and down in the hundreds of instances. In every one of these situations, there were often needs to SSH into those machines, review log files, look at htop, etc.
Even for the "VPS use case" AWS provides compelling advantages: better firewall control, image management, VPC isolation, API automation, etc.
> As a developer, all the resources are managed, you never touch the underlying OS.
Sure. Though I'd posit is that if all you're doing is using fully managed services on AWS, it's akin to installing and configuring Wordpress - you use PHP, but you're not a PHP developer
That seems to come with the implication that if you're using managed services like SQS (instead of installing your own message service), RDS (instead of installing your own database), and you're using other AWS services you're not a "real developer".
If you're using some of the surrounding services, it makes perfect sense to use AWS.
No, I think it's perfectly fine to leverage managed services. (We did however replace SQS with Sidekiq, as that was a better fit, and we do use Redis on Elasticache) I tend to take the position of letting AWS save me time and configuration, but being prepared to run those pieces outside of AWS (which I'm already doing when I develop locally)
> That seems to come with the implication that if you're using managed services ... you're not a "real developer".
Let's bring it back to the original point: "cloud" as a desired skill employers are hiring for. Obviously that's so ambiguous it's ridiculous, and maybe it should be split into "managed cloud services" and "infrastructure as a service". But as long as there are employers out there seeking "cloud" as a singular term, I think it's disingenuous to answer that call if you can only work with the managed pieces.
There is a distinction but it has little to do with Linux.
Netops - do you know how to properly configure AWS resources and architect it. This has nothing to do with Linux. If you want to tie your fate to AWS (no judgement), you learn how to do that via the AWS Console, the CLI, CloudFormation or scripting. If you don't want to tie yourself to AWS, use something like Terraform.
Devops: If you're a Windows shop, you can set up a Windows Jenkins server (I wouldn't) or use a CodeBuild agent running on Windows EC2 instance. If you're using Lambda, you can use one of prebuilt Docker containers and create a yml file to run your commands. You can then either use a Lambda or CloudFormation template for deploying your code (if it's a Lambda function - never tried using CF for any other type of deployment)
If you're a Windows developer using the various AWS services, you use the appropriate package.
Where does having to know Linux come in if you're not developing on Linux?
> Where does having to know Linux come in if you're not developing on Linux?
If the job you're applying for indicates they're not using Linux, then it has nothing to do with it. If a company indicates the generic "cloud", in lieu of further constraining criteria, it's reasonable for them to assume the bulk use case (EC2 was the 2nd service launched on AWS, and there are millions of EC2 instances running; it's hardly a dying platform)
Check out the top links on Indeed for AWS. How many of them have Linux as a requirement as opposed to knowing the different AWS technologies?
I never said that EC2 instances were obsolete, but as a "cloud architect", companies aren't bringing you in for what you can do within an EC2 instance besides probably bootstrapping it using start up scripts. That's what the developers are for.
There are plenty of all Windows shops using AWS as far as development. Even if you came in as an "Cloud consultant" to a shop that was doing everything on prem running Linux, they have Linux expertise in house, what they don't have is cloud expertise.
Even if you have never touched a Linux computer in your life, you could still tell them how to develop using AWS technologies. All of the supported language SDKs work the same regardless of platfitndc.
Mandarin? That seems pretty random. I mean, I can speak and read it, but I have never put that on a resume for a programming job. It's just not all that relevant.
