DEV Community: Forrest Brazeal

The cloud resume challenge

Forrest Brazeal — Mon, 27 Apr 2020 16:45:25 +0000

We're now at that point in quarantine where even the jobs people thought were safe are starting to dry up. Friends and family are telling me: "I've been thinking about changing careers and going into IT. Maybe doing something in the cloud, like you. Where should I start?"

So I'm making an offer right now, before God and the internet and everybody: send me your resume, and I will do my best to help you get a job in the cloud.

Yes, there are some conditions. The first two are easy.

The first condition is that I am not personally hiring anybody at the moment, and cannot force anyone else to hire you. But I have a relatively large network of connections, at least forty percent of whom seem to be tech recruiters, and I will make as much noise as possible to get their attention on you and your resume.

Second condition: you must not have prior professional IT experience on your resume (except maybe something super entry-level like helpdesk), and you can't have a college degree in a tech-related major. I want to focus on helping new people break into the industry.

If you are fortunate enough to have a job in the cloud already, please share this post with #CloudResumeChallenge -- let's get it in the hands of the people who need it.

OK, now the important conditions.

Your resume needs to have the AWS Cloud Practitioner certification on it. This is an introductory certification that orients you on the industry-leading AWS cloud -- if you have a more advanced AWS cert, that's fine but not expected. No cheating: include the validation code on the resume. You can sit this exam online for $100 USD. If that cost is a dealbreaker for you, let me know and I'll see if I can help. Here are some exam prep resources.
Your resume needs to be written in HTML. Not a Word doc, not a PDF. Here is an example of what I mean.
Your resume needs to be styled with CSS. No worries if you're not a designer -- neither am I. It doesn't have to be fancy. But we need to see something other than raw HTML when we open the webpage.
Your HTML resume should be deployed online as an Amazon S3 static website. Services like Netlify and GitHub Pages are great and I would normally recommend them for personal static site deployments, but they make things a little too abstract for our purposes here. Use S3.
The S3 website URL should use HTTPS for security. You will need to use Amazon CloudFront to help with this.
Point a custom DNS domain name to the CloudFront distribution, so your resume can be accessed at something like my-c00l-resume-website.com. You can use Amazon Route 53 or any other DNS provider for this. A domain name usually costs about ten bucks to register.
Your resume webpage should include a visitor counter that displays how many people have accessed the site. You will need to write a bit of Javascript to make this happen. Here is a helpful tutorial to get you started in the right direction.
The visitor counter will need to retrieve and update its count in a database somewhere. I suggest you use Amazon's DynamoDB for this. (Use on-demand pricing for the database and you'll pay essentially nothing, unless you store or retrieve much more data than this project requires.) Here is a great free course on DynamoDB.
Do not communicate directly with DynamoDB from your Javascript code. Instead, you will need to create an API that accepts requests from your web app and communicates with the database. I suggest using AWS's API Gateway and Lambda services for this. They will be free or close to free for what we are doing. You will need to write a bit of code in the Lambda function; you could use more Javascript, but it would be better for our purposes to explore Python -- a common language used in back-end programs and scripts -- and its boto3 library for AWS. Here is a good, free Python tutorial.
You should also include some tests for your Python code. Here are some resources on writing good Python tests.
You should not be configuring your API resources -- the DynamoDB table, the API Gateway, the Lambda function -- manually, by clicking around in the AWS console. Instead, define them in an AWS Serverless Application Model (SAM) template and deploy them using the AWS SAM CLI. This is called "infrastructure as code" or IaC. It saves you time in the long run.
You do not want to be updating either your back-end API or your front-end website by making calls from your laptop, though. You want them to update automatically whenever you make a change to the code. (This is called continuous integration and deployment, or CI/CD.) Create a private GitHub repository for your backend code. Set up GitHub Actions such that when you push an update to your Serverless Application Model template or Python code, your Python tests get run. If the tests pass, the SAM application should get packaged and deployed to AWS.
Create a second private GitHub repository for your website code. Create GitHub Actions such that when you push new website code, the S3 bucket automatically gets updated. (You may need to invalidate your CloudFront cache in the code as well.) Important note: DO NOT commit AWS credentials to source control! Bad hats will find them and use them against you!
Finally, in the text of your resume, you should link a short blog post describing some things you learned while working on this project. Dev.to is a great place to publish if you don't have your own blog.

And that's it. When you have done all this, add my GitHub username (@forrestbrazeal) as a collaborator on your repositories. If you have indeed met the conditions listed above, I will give you a personalized code review, then make as much noise about you as I can to anybody who will listen (including sharing your awesome blog post!).

Now, before you say it ... obviously, I have no right to tell you to do any of this stuff. You will have to open a large number of browser tabs to figure out the steps. It will take you quite a few long evenings at the kitchen table. You might reasonably conclude that none of what I just suggested is worth the dubious reward of having a random industry professional share your resume with a few thousand people.

But if you give this project a try and realize that you hate it, or you're just not interested, you'll have learned a valuable lesson about whether or not you really want a career in the cloud -- because these are the types of problems that real cloud engineers and developers really work on.

And I believe that if you can, in good faith, complete the Cloud Resume Challenge, you will already have more useful skills than a lot of people who graduate from university computer science programs. Specifically: you will understand something about full-stack software development, version control, infrastructure as code, automation, continuous integration and delivery, cloud services and "serverless", application security, and networking. And you'll have learned by doing, because I didn't give you enough instructions to figure any of this out without going down some late-night rabbit holes. Most importantly, you will have demonstrated the number-one skill in a cloud engineer's toolbox: the ability to learn fast and google well.

Those are skills you can take to a job interview. And I'll do my best to help you get one.

Good luck!

CI/CD, AWS, and Serverless: 5 tips I learned the hard way

Forrest Brazeal — Wed, 29 May 2019 18:42:16 +0000

So you want to build a serverless app on AWS?

Great! There are lots of cool posts that show you how to get started.

An Intro to the Power of Serverless with AWS Amplify

Jared Short for Trek10 ・ May 29 '19

#aws #graphql #tutorial

But how do you get that app off your laptop and into the cloud? You could zip your code and upload it manually into the AWS console every time you change something, but that would get old pretty fast.

What you probably want is some kind of CI/CD (continuous integration / continuous delivery) system, where code is automatically tested and released to your environment when you push changes to a source control repository.

An example CI/CD pipeline

I've been building CI/CD pipelines for serverless on AWS for years, and I've picked up a few tricks along the way. Here are five tips I wish somebody had told me when I first got started.

Test code locally and services in the cloud

There are several ways to run a Lambda function on your local developer machine -- for example, the Serverless Framework's serverless-offline plugin or the AWS SAM CLI.

This works great for quickly testing changes to your code. But a serverless app is a lot more than just code: permissions, service configurations, and other things can go wrong as you glue services together to build a truly cloud-native application.

So local testing is not enough. The more external services you integrate with, the more you'll have to mock, and the more your tests will take on a tinge of unreality. You'll be testing a system that doesn't exist.

Instead, my rule of thumb is to test code locally and services in the cloud. This might involve the following steps:

Make an initial deployment in AWS that contains the definitions for services your code depends on (for example, deploying an underlying IAM role or a DynamoDB table).
Run your Lambda function locally as you develop and test the code, reaching out to cloud services for your dependencies.

This way, you can quickly iterate on code, but if something breaks on the cloud side, you'll know! When your Lambda function works locally as expected, you can push it to the cloud as well, where you should...

Prioritize end-to-end functionality tests over unit tests

As a general rule, we want to be writing less code in the serverless world. It's quite possible to write a useful service in AWS using mostly configuration. For example, you can build a CRUD API using API Gateway and DynamoDB alone - no Lambda functions in the middle required.

The more "serverless" you get, the less code you can usefully unit test, and the more you have to rely on tests of your deployed infrastructure.

Lately I've been using Cypress for end-to-end tests of serverless APIs. It's a Javascript test framework that works with assertion libraries like Jest and Chai. You can query your API directly, no inside knowledge of the code required. This is testing your service the way your users will experience it, so you can be sure your expectations match reality.

If you want to test AWS resources directly, a cool project to check out is Erez Rokah's AWS Testing Library, which lets you write tests directly against deployed resources like DynamoDB tables or SQS queues.

If you're writing tests, of course, you'll need some place to run them. AWS provides a managed build service called CodeBuild that you should be paying attention to, because...

AWS CodeBuild is hugely underrated

Ever had to babysit a build server that was constantly crashing because one rogue job ate all the disk space? That's not a very "serverless" thing to do.

Fortunately, AWS CodeBuild spins up a completely separate Docker-based build environment for every invocation of a build job. It's truly ephemeral compute, pay only for what you use, and it's pretty cheap -- 500 build minutes a month will run you a cool $2.00. The containers can take a few seconds to initialize, but that's way better than managing a pool of build runners that may flake out on you at any time.

Once you've got CodeBuild in your corner, you should take a look at another AWS tool for developers, because ...

AWS CodePipeline is the single best way to manage CloudFormation releases

CloudFormation is AWS's infrastructure-as-config service: you create a template that defines your Lambda functions, IAM roles, etc. (The Serverless Application Model, or SAM, which makes it easier to define serverless apps on AWS, is just CloudFormation with a little special sauce.)

Another annoying CI/CD thing I've had to do a lot is write scripts that poll AWS CloudFormation for updates. CodePipeline is really good at doing that for me. So I can trust it to manage my serverless infrastructure deployments as they roll from development, to staging, to production environments.

None of these services come without gotchas, of course. The most important one I can warn you about right now is this:

CodePipeline only supports one branch per pipeline (at least for now)

No doubt this will change someday, but at present you can trigger a CodePipeline from only one source, such as a repository branch. If you have branch-based workflows, this gets frustrating quickly.

One workaround is to dynamically create a new CodePipeline per branch using a Lambda function, which has worked pretty well for us at Trek10 -- well enough that we recently open-sourced the idea as an AWS Quickstart. That Quickstart contains the CloudFormation templates needed to spin up dynamic CodePipelines that include CodeBuild jobs, Lambda tests, and lots more -- so what are you waiting for? Give it a try, and hit me up in the comments if you have other questions.