The most important part is the second paragraph.

Spring Boot users are only affected by this vulnerability if they have switched the default logging system to Log4J2. The log4j-to-slf4j and log4j-api jars that we include in spring-boot-starter-logging cannot be exploited on their own. Only applications using log4j-core and including user input in log messages are vulnerable.

Therefore, If you have not explicitly brought in log4j-core into your application you SHOULD be fine. Although, there is a possibility that you are using a transitive dependency (dependency of a dependency) in your application.

Full details here and here on the threat. More directly from Apache.

Here is a good read on what the vulnerability is and who is impacted.

This is how I used maven and the grep to determine if my projects were affected. If you find log4j-core version that is < 2.17.0 you should update it immediately!

mvn dependency:tree -Dverbose | grep log4

I did find a transitive dependency was using the affected jar. I am the maintainer of the dependency so I was quickly able to put in a patch. Make sure you look for updates to your own dependencies if they contain the affected jar!

Best of luck!

☁️ Contents ☁️

• Constructs
• Stacks
• Apps
• Conclusion (TLDR)

Constructs

Constructs are the basic building blocks of the AWS CDK. They create "cloud components" and encapsulate everything needed to provision the component. Under the hood, Constructs are deconstructed into AWS CloudFormation templates. Almost anything you can do in AWS CloudFormation you can do with the AWS CDK!

A construct represents a single resource. For example, an Amazon S3 bucket or an Amazon EC2 server. AWS has also developed higher-level Constructs. Higher-level Constructs can be created to abstract the complexity of provisioning multiple AWS resources. AWS Elastic Container Service (ECS) and ecsPatterns are great examples of being able to create complicated cloud infrastructure in a handful of lines of code.

// provision a load balancers, ECR repository, ECS service and task using one Contstuct!
const loadBalancedEcsService = new ecsPatterns.ApplicationLoadBalancedEc2Service(stack, 'Service', {
  cluster,
  memoryLimitMiB: 1024,
  taskImageOptions: {
    image: ecs.ContainerImage.fromRegistry('test'),
    environment: {
      TEST_ENVIRONMENT_VARIABLE1: "test environment variable 1 value",
      TEST_ENVIRONMENT_VARIABLE2: "test environment variable 2 value"
    },
  },
  desiredCount: 2,
});

Constructs communicate with each other. The AWS CDK team has done a great job of exposing attributes that allow you to create AWS CloudWatch Metrics, Alerts, and Dashboards.

Stacks

Each group of deployed resources in the AWS CDK is called a stack. These resources are directly or indirectly provisioned as a single unit. This allows you to create modular cloud infrastructure that is interchangeable.

A great example of this is grouping frontend and backend components into their own stacks. If you are building a backend for an application using AWS ECS you can encapsulate all the resources into one stack. If you decide you would like to migrate your infrastructure to serverless using AWS Lambda, you can easily spin up a new stack and tear down the old one once you are done.

Here is an example of a MetricsProps. This provisions several AWS CloudWatch metrics for a number of AWS ECS Fargate Services.

import * as cdk from '@aws-cdk/core';
import { Dashboard } from "@aws-cdk/aws-cloudwatch";
import { GraphWidget} from "@aws-cdk/aws-cloudwatch";

export interface MetricsProps extends cdk.StackProps {
    fargateService: ecs.FargateService[],
}

export class MetricsStack extends cdk.Stack {
    constructor(scope: cdk.Construct, id: string, props: MetricsProps) {
        super(scope, id, props);

        // dashboard
        const dashboard = new Dashboard(this, `'dev-dashboard`, {
        });

        // ecs     
        const ecsCPU = new GraphWidget({
            width: 6,
            title: `ECS CPU Utilization`,
            left: props.fargateService.map(service => service.metricCpuUtilization())
        });
        const ecsMemory = new GraphWidget({
            width: 6,
            title: `ECS Memory Utilization`,
            left: props.fargateService.map(service => service.metricMemoryUtilization())
        });
        dashboard.addWidgets(ecsCPU, ecsMemory);
    }
}

Apps

Apps in the AWS CDK encapsulate Constructs and Stacks. Each component must be defined in an App. Each CDK project starts with an App! This construct is normally the root of the Construct tree.

#!/usr/bin/env node
import * as cdk from '@aws-cdk/core';
import { Construct } from '@aws-cdk/core';
import { CdkApiStack, CdkApiStackProps } from '../lib/cdk-base-stack/cdk-api-stack';
import { CdkBaseStack, CdkBaseStackProps } from '../lib/cdk-base-stack/cdk-base-stack';

class DemoApp extends Construct{
    constructor(scope: cdk.App, id:string){
        super(scope,id);
        // create a small vpc for the demo
        const vpcProps: CdkBaseStackProps = {
            stage: id, 
            description: "Base VPC for AWS Cloud Application",
            yourIpAddres: "",
            tags: {env: id},
            stackName: `PublicVpcStack-${id}` // used in cloudformation for naming stack
        }        

        const base:CdkBaseStack = new CdkBaseStack(this, `CdkVpcStack-${id}`,
            vpcProps);

        // create an API            
        const apiProps: CdkApiStackProps = {
            stage: id,
            securityGroup: base.defaultSecurityGroup,
            vpc: base.vpc,
            secretName: base.databaseCredentialsSecret.secretName
        }            

        const api: CdkApiStack = new CdkApiStack(this, `CdkApiStack-${id}`,
            apiProps);
    }
}
const app = new cdk.App();
new DemoApp(app, 'dev');

Conclusion

Let's sum up what we have just learned!

• Use Constructs to provision resources.
• Use higher-level constructs to provision complex cloud components.
• Use Stacks to group resources you would like to be deployed and destroyed together.
• An App instance is your program's entry-point. This construct is normally the root of the Construct tree.

Pro Tip: A common pattern is grouping stateful and stateless components. Stateful resources are such that cannot be easily recreated like a database. Stateless are easily re-creatable such as an AWS ECS Service.

Read my No-Nonsense Guide To AWS Cloud Development Kit to learn more!

TLDR: Check out the complete code on Github.

In this post, we will use AWS Lambda, AWS Secrets Manager, and the node pg package. I'll show you how to query a Postgres database using these resources.

In my previous post, we used the AWS CDK to spin up a Virtual Private Cloud (VPC) and a Relational Database Service (RDS) Postgres database. We stored all the information we needed to log in to our RDS instance in AWS Secrets Manager.

This is what we will be building. ☝🏽

Word to The Wise

Using a serverless technology to query a relational database should be used cautiously. Constantly opening and closing database connections may be costly. Please read my Relational Database Serverless Notes if you plan on uses a serverless technology to heavily query a relational database. My use case was a CRON that would execute periodically to check for errors.

Note, if your database is not publically accessible this Lambda will need to be deployed in the VPC with proper VPC endpoints setup. I will be writing this up in a subsequent blog post. Please read this AWS document. It details the networking needed two allow communication between AWS Lambda and an RDS instance.

☁️ Contents ☁️

• 1. Initialize the Project
• 2. Create Folders for Lambda Handler (Optional)
• 3. Install pg
• 4. Create a Lambda Handler
• 5. Load Secret
• 6. Create Database Connection
• 7. Query the Database
• 8. Deploy
• Relational Database Serverless Notes
• Conclusion

1. Initialize the Project

You can follow my previous post on how to deploy a VPC and RDS database using the AWS CDK. Also, I have a post on using AWS Serverless Application Model (SAM). You can use this to start a boilerplate Lambda in 5 minutes, but that is not required.

2. Create Folders for Lambda Handler (Optional)

If you are following along with the AWS CDK blog post, we will be writing the Lambda function code in src/get-query. This folder will contain app.js. This is the code that the Lambda is going to execute. There will also be package.json and node_modules to store dependencies. (We could use a Lambda layer, but I'll leave that for a future post)

mkdir -p src/get-query
touch app.js
npm init

3. Install pg

npm i pg

4. Create a Lambda Handler

The Lambda handler is the code that gets executed when a Lambda function is invoked. Let's start with boilerplate Lambda code. We are going to import the pg client to connect and query the database. Then we will instantiate a SecretsManager client to get the database info.

const pg = require('pg')
var AWS = require('aws-sdk'),
    region = "us-east-1",
    secretParams,
    pgClient;

// Create a Secrets Manager client
var client = new AWS.SecretsManager({
    region: region
});

exports.handler = async (event, context, callback) => {

    return {
        "isBase64Encoded": false,
        "statusCode": 200,
        "body": "hello!"
    }
}

5. Load Secret

If you are not following along with my AWS CDK post you can follow this tutorial on how to add a secret to AWS Secrets Manager.

Next, let's update the handler code. We will load the secret from Secrets Manager. We use a reference from an environment variable containing the name of our secret. You only need to do this if the Lambda is cold starting. Otherwise, we will reuse the cached credentials. Note, if you are deploying this in a private VPC you will need to deploy an SSM VPC Endpoint.

    // cache the secret
    if(!secretParams){
        // get secret string from secret manager
        const secretValue = await client.getSecretValue({ SecretId: process.env.SECRET_NAME }).promise();
        secretParams = JSON.parse(secretValue.SecretString);
    }

6. Create Database Connection

Next, use the secretParams and pg to make a database connection! Again, the client will be reused on subsequent executions.

    // cache the client
    if(!pgClient){
        // https://node-postgres.com/api/client
        var connectionInfo = {
            user: secretParams.username,
            password: secretParams.password,
            host: secretParams.host,
            database: "postgres",
            port: secretParams.port
        };
        pgClient = new pg.Client(connectionInfo);
        await pgClient.connect();
    }

7. Query the Database

Finally, you can use the client to perform a query and return it to the user!

    const queryResult = await pgClient.query("SELECT 'Eli' as player_name");
    return {
        "isBase64Encoded": false,
        "statusCode": 200,
        "body": JSON.stringify(queryResult.rows ? queryResult.rows : undefined)
    }

8. Deploy

To deploy you can read my post to use AWS SAM, The Serverless Framework, or manually copy and paste the code using the AWS Console.

Relational Database Serverless Notes

Using a serverless technology to query a relational database can cause a lot of overhead with managing connections. If this is done on a regular basis it may be worth having a layer in between your Lambda and RDS. You can use RDS Proxy which will manage all the connection pooling for you. Or you can give Amazon Aurora Serverless a try! It's the only serverless relational database that I have come across.

Conclusion

That's it! Deploy your Lambda or test it locally. You should be able to communicate with RDS (if it's publically accessible). We set this up without having to use any plaintext credentials. Secrets Manager gives you a secure way of storing and retrieving sensitive information.

Check out the complete code on Github! If you have any questions feel free to DM me on Twitter!

I have another post on deck utilizing the AWS CDK to deploy these resources (VPC, RDS instance, Secrets Manager, Lamda, API Gateway). Stay tuned!

TypeScript is a strict superset of ECMAScript 2015, which is itself a superset of ECMAScript 5, commonly referred to as JavaScript. As such, a JavaScript program is also a valid TypeScript program, and a TypeScript program can seamlessly consume JavaScript. - Wikipedia

One of the best features of TypeScript is, wait for it, Types! However, one of the most cumbersome features of TypeScript, for newbies, is Types! Let's talk about what they are, why you should use them, and the problems they can cause.

Table of Contents

• What are Types?
• Why should you use Types?
• What are the downsides of using Types?
• Conclusion
• Bonus Content

What are Types? 🤔

TypeScript is a strongly typed, object-oriented, compiled language. Conversely, JavaScript is not strongly typed. In JavaScript, a variable can take many forms. A variable can be any type of object. For example a String or a Number. However, in TypeScript an object can only be one or the other.

// this is valid in JavaScript
let name = "Phillip";
name = 4;

// this is NOT valid in TypeScript
let name: String = "Phillip";
name = 4; // this will cause compiler errors!

Why should you use Types?

Types are great! They allow you to see which fields are available for an object. It also prevents developers from assigning the wrong value to a field.

A wonderful example is refactoring. I recently had to make major updates to an Angular application. Since we use Types we were able to easily modify fields and the compiler allowed us to easily make the appropriate changes to fix them! ALL HAIL TYPESCRIPT! 🙌🏽

What does a Type look like?

A Type in TypeScript is a simple interface. You define fields and the distinct type of the field.

interface User {
   id: number;
   name: string;
   dateOfBirth: date;
   age: number;
   funFacts: string[];
   activeFlg: boolean;
   mother: User;
   father: User;
   someObj: any;
   idk: unknown;
}

What are the downsides of using Types?

A strongly typed language means there is less flexibility. You need to define what your interfaces will look like. Based on how you configure your compiler there may be some strict rules to follow.

I have helped many developers debugs errors having to do with implicitly any. This means that a type for a parameter has not been explicitly defined.

Here are some examples of errors I have seen:

parameter 'req' implicitly has an 'any' type
parameter 'res' implicitly has an 'any' type
parameter 'res' implicitly has an 'any' type.ts(7006)
error ts7006: parameter 'req' implicitly has an 'any' type
error ts7006: parameter 'res' implicitly has an 'any' type
parameter 'user' implicitly has an 'any' type.ts(7006)

This is a great example of code that I found on StackOverflow which would produce one of these beautiful exceptions.

const users = [...]
// this line does not compile
let user = users.find(user => user.id === query);

The parameter user is being used in the find method but its type is unknown. Therefore, id may not be a valid attribute.

How do you fix this? 🔎

1. You can EXPLICITLY use any! The any type allows us to assign literally “any” particular value to that variable, simulating vanilla JavaScript.

   const users = [...]
   let user = users.find((user: any) => user.id === query);
   

2. The best thing to do would be to use a type to define the users array or the find method.

   interface User {id: number;...}
   ...
   ...
   const users: User[] =[...]
   let user = users.find(user => user.id === query);
   

3. In your tsconfig.json, add "noImplicitAny": false to "compilerOptions":{}.

   What is tsconfig.json? You will see this file is all TypeScript projects! This specifies the root files and the compiler options required to compile the project.

   {
   "compilerOptions": {
   ...
   "noImplicitAny": false,
   ...
   },
   "files": [
   "core.ts",
   ...
   ]
   }
   

Conclusion

TypeScript is awesome! Almost all of the projects I work on today leverage TypeScript. I feel the pros far outweigh the cons of using TypeScript over vanilla JavaScript. I highly recommend giving it a try on your next project!

Pro Tip: If you know JavaScript you already know TypeScript! 😉

Bonus Content

If you are interested in getting started with TypeScript read my article on How to Convert Express.js to Typescript!

Resources

• Typescript: TS7006: Parameter 'xxx' implicitly has an 'any' type
• noImplicitAny
• Intro to the TSConfig Reference
• Angular TypeScript Configuration
• What is a tsconfig.json

Serverless is a new buzzword. It's a popular way to deploy your code in the cloud. You can use serverless to scale to millions of requests! Serverless can execute code or event host a database. This article is a high-level overview of what serverless is.

Table of Contents

• What Is a Server?
• What Problem Does Serverless Solve?
• Scalability
• How Can You Use Serverless?
• Serverless Advantages
• Serverless Drawbacks
• Conclusion

🐦 Follow me on Twitter if you would like to see more content like this! 🐦

What Is a Server?

"In computing, a server is a piece of computer hardware or software that provides functionality for other programs or devices, called "clients". This architecture is called the client-server model." - Wikipedia

A server is someone else's computer, although you can own/run your own. The server is where an application is deployed. Most developers deploy their code to a remote server where someone else handles maintaining the hardware and software. This blog runs on a server!

What Problem Does Serverless Solve?

Servers can be expensive. For small projects, it can be a big financial obstacle. Your server needs to be running 24 hours a day to be able to handle requests at any given time. These costs add up when you pay hourly!

Here comes serverless to the rescue! You only pay when your code is being executed. Your code will get run when it needs to. You are charged for the amount of time and memory used.

Please note, serverless doesn't mean there is an absence of a server. Serverless infrastructure is running on someone else's managed server. This means you don't have to worry about patching software, network security, or uptime. You only pay when it's being used. Sounds great! Right?

Scalability

When your application (running on a classical server) starts to slow down, there are two ways to speed it up. Get a bigger server (scale-up/vertically) or get more servers (scale-out/horizontal). Both can be expensive options. You either need to provision these new servers or use services that will scale up and down automatically.

In a serverless world, you can scale to millions of requests. No new infrastructure required! There is no need to provision new servers. Hence, serverless!

How Can You Use Serverless?

Execute your code in the cloud

• AWS Lambda
• Azure Functions
• GCP Cloud Functions
• Vercel

  Serverless Databases

• AWS DynamoDb
• Amazon Aurora Serverless

  Serverless Framework

• Serverless.com

Serverless Advantages

• No servers to manage!
• Scalability from the start
• Cost-effective
• Modular code
• Easy to use deployment tools

Serverless Drawbacks

It's not all rainbows.

• Cold starts - When your code has not been run recently there is latency
• Requires proprietary tools
• May result in redundant code
• Complex caching
• Debugging can tricky
• Potential for costs to skyrocket due to buggy code or edge cases

Conclusion

In a world surrounded by servers, serverless infrastructure is coming to the forefront. Serverless can be leverage to be able to build infrastructure ready to scale from the start. You can also take advantage of the low cost to get started. Serverless is not a blanket solution. It is not perfect for all solutions. Yet, I strongly recommend you give it a try and decide for yourself.

Cheers! 🍻

Inspired By

Whats Serverless - Technically Substack

🐦 Follow me on Twitter if you would like to see more content like this! 🐦

TLDR: Checkout the complete code on GitHub Repo.

🐦 Follow me on Twitter if you would like to see more content like this! 🐦

Introduction

Today, I am going to show you how to provision an RDS instance using the AWS CDK. We will set up an AWS Secret and System Parameter that can be used to allow other resources to connect without using plaintext credentials. Never keep database credentials in plaintext!

Table Of Contents

• Introduction
• Check Out a Starter Project
• Update Dependencies
• Add a Database Secret
• Create a System Parameter
• Load Default Security Group
• Optionally Open Access From Your IP
• Configure RDS Instance
• Output RDS Endpoint
• Deploy
• Conclusion

Check Out a Starter Project

We are going to start from my last post, here is the GitHub Repo. We want to start with a base stack. A base stack is where you should keep your stateful resources. Since a database cannot be easily re-constructed you should consider this stateful. We will be updating the base stack by adding an RDS database.

Update Dependencies

First, we need to update the dependencies in package.json. We are going to need some new dependencies for this tutorial. Note, you should try to keep all the CDK dependency versions the same.

  "dependencies": {
    ...
    "@aws-cdk/aws-rds": "1.95.1",
    "@aws-cdk/aws-secretsmanager": "1.95.1",
    "@aws-cdk/aws-ssm": "1.95.1"
  }

Add a Database Secret

Next, we will start to update the base stack! First, we need to set up a secret and a system parameter. You should never keep plaintext credentials in plaintext or in source control. The AWS Secrets Manager allows you to provide credentials to a number of other AWS resources in a secure way. Let's add the secret.

    // first, lets generate a secret to be used as credentials for our database
    const databaseCredentialsSecret = new secretsManager.Secret(this, `${props?.stage}-DBCredentialsSecret`, {
      secretName: `${props?.stage}-credentials`,
      generateSecretString: {
        secretStringTemplate: JSON.stringify({
          username: 'postgres',
        }),
        excludePunctuation: true,
        includeSpace: false,
        generateStringKey: 'password'
      }
    });    

    // lets output a few properties to help use find the credentials 
    new cdk.CfnOutput(this, 'Secret Name', { value: databaseCredentialsSecret.secretName }); 
    new cdk.CfnOutput(this, 'Secret ARN', { value: databaseCredentialsSecret.secretArn }); 
    new cdk.CfnOutput(this, 'Secret Full ARN', { value: databaseCredentialsSecret.secretFullArn || '' });

A couple of notes here:

• This is going to generate a password for the username postgres
• We are using a few CfnOutputs to print some of the secret resource values. This will allow you to either identify which secret we just created or be able to access it via the AWS CLI. Note, this will not actually output a password! These values will be output in the terminal when you deploy your infrastructure.

Create a System Parameter

Next, we can simply create a system parameter with the secret. You will use this service to provide other AWS services with credentials to connect to RDS.

    // next, create a new string parameter to be used
    new ssm.StringParameter(this, 'DBCredentialsArn', {
      parameterName: `${props?.stage}-credentials-arn`,
      stringValue: databaseCredentialsSecret.secretArn,
    });

Load Default Security Group

Our next step will be to get the VPC default security group. The database should be in a security group so that we can set up connectivity between other resources deployed in a VPC.

    // get the default security group
    let defaultSecurityGroup = SecurityGroup.fromSecurityGroupId(this, "SG", vpc.vpcDefaultSecurityGroup);

Optionally Open Access From Your IP

You can optionally add a rule to allow access to the database from your IP. NOTE THIS IS NOT SECURE! You should always put your database in a private subnet! This part is for educational purposes.

    if(props?.yourIpAddres){
      // your to access your RDS instance!
      defaultSecurityGroup.addIngressRule(ec2.Peer.ipv4(props.yourIpAddres), ec2.Port.tcp(5432), 'allow 5432 access from my IP');
    }

Configure RDS Instance

Now, let us configure and create our RDS instance.

    // finally, lets configure and create our database!
    const rdsConfig: rds.DatabaseInstanceProps = {
      engine: rds.DatabaseInstanceEngine.postgres({ version: rds.PostgresEngineVersion.VER_12_3 }),
      // optional, defaults to m5.large
      instanceType: ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE2, ec2.InstanceSize.SMALL),
      vpc,
      // make the db publically accessible
      vpcSubnets: {
        subnetType: ec2.SubnetType.PUBLIC,
      },
      instanceIdentifier: `${props?.stage}`,
      maxAllocatedStorage: 200,
      securityGroups: [defaultSecurityGroup],
      credentials: rds.Credentials.fromSecret(databaseCredentialsSecret), // Get both username and password from existing secret
    }

    // create the instance
    this.rdsInstance = new rds.DatabaseInstance(this, `${props?.stage}-instance`, rdsConfig);

A couple of notes here:

• We are putting this into a public subnet. THIS IS NOT SECURE. You should always put your database in a private subnet. We are doing this for educational purposes.
• I am creating the smaller database possible to save on costs.

Output RDS Endpoint

Lastly, let's output the RDS endpoint so you can actually connect publically. Again, this is just for educational purposes. ALWAYS KEEP YOUR DATABASE IN A PRIVATE SUBNET.

    // output the endpoint so we can connect!
    new cdk.CfnOutput(this, 'RDS Endpoint', { value: this.rdsInstance.dbInstanceEndpointAddress });

Deploy

That's it! Synthesize and deploy your code and you will have a provisioned database! This may take some time to come up.

cdk synth
cdk deploy

Conclusion

To get the credentials to connect to your new database you can either use the CLI using the CfnOutput or you can manually find it in your AWS Secrets Manager console. In my subsequent posts, I will be using the RDS tutorial as a starting point for other resources to access it. Enjoy! 🍺

TLDR: Checkout the GitHub Repo with the complete code.

🐦 Follow me on Twitter if you would like to see more content like this! 🐦

Interested in having a 1:1 chat with me over this story, or AWS in general? Head over to Hire The Author and let’s connect!

TLDR: Checkout my GitHub Repo. There are only two classes you need to be worried about, cdk-base-stack.ts and cdk-app.ts.

Table of Contents

• Base Stack
• CDK App
• Conclusion

🐦 Follow me on Twitter if you would like to see more content like this! 🐦

Base Stack

The base stack of a CDK app is where you should put resources that are not going to change, they are stateless. Using this pattern, you can keep your stateful resources (VPC, RDS, DDB, etc) intact while being able to tear down and recreate your stateless (EC2, ECS, S3, etc) resources. Stateless resources can be replaced without the risk of data loss.

In this example, we will be adding a Virtual Private Cloud (VPC) to our base stack. We will be extending a Stack in this class. A Stack should be used to deploy resources independently from the rest of the app resources. Conversely, Constructs all get deployed together.

Finally, we are going to make our VPC public. Here is a reference to the VPC construct. You can create a public VPC to save costs. Private VPC's contain private subnets which require a NAT Gateway. These incur costs on an hourly basis.

import * as cdk from '@aws-cdk/core';
import * as ec2 from '@aws-cdk/aws-ec2';

export interface CdkBaseStackProps extends cdk.StackProps {
  stage: string;
}

export class CdkBaseStack extends cdk.Stack {
  private readonly vpc:ec2.Vpc;
  constructor(scope: cdk.Construct, id: string, 
                              props?: CdkBaseStackProps) {
    super(scope, id, props);

    // create a VPC with no private subnets. 
    // this is for our demo purpose as this will be 
    // cheaper since you do not need a nat gateway
    const vpc = new ec2.Vpc(this, `VPC-${props?.stage}`, {
      natGateways:0,
      maxAzs: 2,
    });    

    this.vpc = vpc;
  }
  get stackVpc() : ec2.Vpc{
    return this.vpc;
  }  
}

A couple of notes:

• CdkBaseStackProps is a pattern you can follow to pass parameters your Stack or Construct. I added a stage field to distinguish environments.
• natGateways:0 - this option ensures there are no private subnets

CDK App

To bring everything together, you can look at our app. I have created a DemoApp class Construct. This will be composed of our CdkBaseStack. You will ultimately end up adding more Constructs here to provision resources for your cloud application.

import * as cdk from '@aws-cdk/core';
import { Construct } from '@aws-cdk/core';
import { CdkBaseStack, CdkBaseStackProps } from '../lib/cdk-base-stack/cdk-base-stack';

class DemoApp extends Construct{
    constructor(scope: cdk.App, id:string){
        super(scope,id);
        // create a small vpc for the demo
        const vpcProps: CdkBaseStackProps = {
            stage: id, 
            description: "Base VPC for AWS Cloud Application",
            tags: {env: id},
            stackName: `PublicVpcStack-${id}` // used in cloudformation for naming stack
        }        

        const base:CdkBaseStack 
                  = new CdkBaseStack(this, `CdkVpcStack-${id}`,
            vpcProps);
    }
}
const app = new cdk.App();
new DemoApp(app, 'dev');

A couple of notes here:

• const app = new cdk.App(); - this is what initializes our app.
• new DemoApp(app, 'dev'); - this creates a Construct for our app. I am using dev as an environment. Once you are happy with this Construct you can simply instantiate a DemoApp for each environment! This will save you time and money.
• tags: {env: id} - tags are very useful and can help you distinguish resources in diff environments. This can come in handy when looking at your billing.

Conclusion

You now have a base class to use when deploying any infrastructure that requires a VPC by using the AWS CDK! As stated before, keep stateful resources (VPC, RDS, DDB, etc) in your base stack since you cannot easily recreate these. Stateless resources (EC2, ECS, S3, etc) can be encapsulated in constructs of their own. Stay tuned! More CDK tutorials to come!

TLDR: Checkout my GitHub Repo. There are only two classes you need to be worried about, cdk-base-stack.ts and cdk-app.ts.

🐦 Follow me on Twitter if you would like to see more content like this! 🐦

Table of Contents

• Key CDK Terms
• AWS Construct Library
  • L1
  • L2
  • L3 / Patterns
• Stacks vs Constructs
• How Many Stacks Should My Application Have?
• Getting Started - CDK Example
  • Install AWS CLI
  • Install AWS CDK
  • Create the app
  • Build the app
  • List stacks in your app
  • Add an Amazon S3 bucket
  • Synthesize App
  • Deploy App
  • Modify App
  • Destroy App Resources
• Next Steps
• Writing Your Own Constructs
• Conclusion

🐦 Follow me on Twitter if you would like to see more content like this! 🐦

Key CDK Terms

• App - You can think of a CDK app as the composition of all the resources needed for your application. This can deploy your entire AWS infrastructure.
• Stacks - A stack in AWS CDK is the same as in AWS CloudFormation. You can think of stacks as groups of resources needed for your application. This is defined as a single unit of deployment. An app can be composed of one or more stacks.
• Constructs - You can think of constructs as an individual object in a stack. These objects can be composed of one or many AWS resources. Constructs are the basic building blocks of an app or stack. Each stack is composed of constructs.
• Etc - I have listed the most important concepts. You can read more on the AWS documentation!

Here is a useful diagram explaining these relationships.

AWS Construct Library

AWS provides an entire library full of constructs that are ready to use. They are very well documented and provide no-nonsense example. Let's look at the different types of constructs.

L1

Some constructs provide a single resource such as an Amazon S3 bucket or a Lambda function. These are known as level-one or L1 for short. These constructs are very basic and must be manually configured. They will have a Cfn prefix and correspond directly to AWS CloudFormation specifications. New AWS services are supported in the AWS CDK as soon as AWS CloudFormation does. CfnBucket is a good example. It represents an Amazon S3 bucket where you MUST explicitly configure ALL the properties.

const bucket = new s3.CfnBucket(this, "MyBucket", {
  bucketName: "MyBucket"
});

L2

The next level, curated or L2, provides constructs with common boilerplates and glue logic. These will come with convenient defaults and reduces the amount of knowledge you need to know about them. They will typically encapsulate their corresponding L1 modules. A good example is s3.Bucket. This class will create an Amazon S3 bucket with default properties and methods such as bucket.addLifeCycleRule(), which adds a lifecycle rule to the bucket.

new s3.Bucket(this, 'MyFirstBucket', {
  versioned: true
});

L3

While others, called high-level or patterns, allow you to provision resources that are commonly used together. Construct patterns are designed to help you provision multiple resources based on common patterns with a limited amount of knowledge in a concise manner. s3deploy.BucketDeployment is a great example of a high-level construct. The L3 construct takes a bucket as an argument and uploads your code.

const websiteBucket = new s3.Bucket(this, 'WebsiteBucket', {
  websiteIndexDocument: 'index.html',
  publicReadAccess: true
});

new s3deploy.BucketDeployment(this, 'DeployWebsite', {
  sources: [s3deploy.Source.asset('./website-dist')],
  destinationBucket: websiteBucket,
  destinationKeyPrefix: 'web/static' // optional prefix in destination bucket
});

Stacks vs Constructs

Stacks and constructs can both be used to provision groups of AWS resources. Your cloud application can have many stacks leveraging different levels of constructs. The key difference is that stacks are deployed independently. Therefore, you should decouple constructs into stacks if you would like to isolate different layers of your cloud infrastructure. For example, you could compose multiple constructs into aDevStack. This stack can be configured for a development environment while having a different composition for production.

How Many Stacks Should My Application Have?

There is no hard and fast rule to determine this. I asked an AWS employee this question. He gave me a great response!

A stack is just a group of resources. One giant group of resources will inhibit your ability to tear down resources independently of your other resources. Dividing your resources into smaller groups can make it easier to manage and roll back/forward changes.

He recommended always putting your networking and database layer (stateful resources) into a base stack. Next, you should put your application (stateless) resources into one or more stacks. This way you can tear down the app and recreate it while leaving up your network and database layer intact.

A second recommendation came from another AWS employee. He noted the parallels between Conway's law and deploying stacks.

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." — Melvin E. Conway

Essentially, you may want to break down your stacks to mirror how your teams operates. At the end of the day, build in a way that makes the most sense for you and your team.

Getting Started - CDK Example

TLDR - Here is a link to my Github Repo with the fulling working example.

Install AWS CLI

First, you need to have the AWS CLI installed and configured. The CDK uses the same credentials as AWS CLI.

Install AWS CDK

Next, install the AWS CDK Toolkit using npm

npm install -g aws-cdk
# verify installation
cdk --version

Create The App

Create a directory and initialize a project with your language of choice. I love TypeScript!

mkdir hello-cdk
cd hello-cdk
# init project
cdk init app --language typescript

App Structure

This is what the app file structure should looked like. A few notes. bin folder is the entry point. This is where the app is initialized. cdk.out directory is where the CloudFormation template gets generated. Lastly, lib is where all of your stacks and constructs will live.

Build The App

Next, you will need to build your project whenever you make coding changes.

npm run build
# or you can watch
npm run watch

List Stacks in Your App

Verify everything is working and you see the stacks you are expecting. You should only have one stack at this point.

cdk ls

Add an Amazon S3 bucket

Next, I will show you how to add a construct. We will add a simply S3 bucket. You need to add dependencies for each package you wish to use. Please make sure all of your cdk package versions match or you can run into trouble!

npm install @aws-cdk/aws-s3

Update the stack inside the lib folder (~hello-cdk-stack.ts)

import * as cdk from '@aws-cdk/core';
import * as s3 from '@aws-cdk/aws-s3';

export class HelloCdkStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // new code
    new s3.Bucket(this, 'MyFirstBucket', {
      versioned: true
    });
  }
}

A couple of notes here

• The scope, id, and props variables are used as parameters for constructing both stacks and constructs.
• scope - This is the parent of the stack. In this case, the parent is our app. The scope for the s3 bucket is the HelloCdkStack stack.
• id - This is a way to uniquely identify resources across deployments. MyFirstBucket is the id of the s3 bucket construct.
• props - These are values that will be used to define our construct. You can see in the Bucket constructor that we are passing an option of versioned: true. These are typically always going to be optional.

Synthesize App

As I stated in my previous post, CDK uses AWS CloudFormation under the hood. We need to convert our app code into a CloudFormation template. You can take a look in the cdk.out directory to see what the template looks like!

cdk synth

Deploy App

The moment of truth! Let's deploy our bucket! If you have more than one stack defined you will need to choose one or use the --all option. You will see a nice progress bar.

cdk deploy

This is a high-level diagram of the workflow of building and deploying a CDK app.

Modify App

At some point, you will need to update your infrastructure. Let's update our S3 construct.

new s3.Bucket(this, 'MyFirstBucket', {
  versioned: true,
  removalPolicy: cdk.RemovalPolicy.DESTROY,
  autoDeleteObjects: true
});

CDK offers a very nice tool to see what changes will be deployed. This is useful for see what resources will be removed, added, or modified. You can see what IAM policies will be adjusted.

cdk diff

If you are happy with your changes you can deploy!

cdk deploy

Destroy App Resources

Finally, the day will come when you no longer need your resources! You can either just remove the resources you no longer need from your CDK code or destroy all the resources using a very useful command.

cdk destroy

Writing Your Own Constructs

In addition to using the AWS Construct library, you can also create your own! Writing your own is as simple as composing a number of constructs already available via the Construct library. This allows you to encapsulate a number of constructs and easily reuse them. Let's look at a simple example:

export interface NotifyingBucketProps {
  prefix?: string;
}

export class NotifyingBucket extends Construct {
  constructor(scope: Construct, id: string, props: NotifyingBucketProps = {}) {
    super(scope, id);
    const bucket = new s3.Bucket(this, 'bucket');
    const topic = new sns.Topic(this, 'topic');
    bucket.addObjectCreatedNotification(new s3notify.SnsDestination(topic),
      { prefix: props.prefix });
  }
}

A couple of notes here:

• All you have to do to create your own Construct is use extends Construct and instantiate!
• This construct encapsulates an Amazon S3 bucket and a AWS SNS notification into a class named NotifyingBucket.
• You can use this custom construct by simply creating a new instance new NotifyingBucket(this, 'MyNotifyingBucket');

Next Steps

I highly recommend giving the CDK Workshop a try! They go through a bigger example with fine details. Read Best practices for developing cloud applications with AWS CDK.

Conclusion

The AWS CDK is a great tool for provisioning your cloud infrastructure! You can easily set up and destroy resources with a few lines of code. Keep this code in source control to monitor changes. Reuse your code for new projects or clients! I hope you enjoyed this tutorial! I will be writing some more in-depth articles going forward.

Special Thanks

I would like to take a moment to thank both Nathan Peck and Adam Keller for helping me fine-tune this guide! They both gave me great feedback for improving this guide.

Cheers!

🐦 Follow me on Twitter if you would like to see more content like this! 🐦

Here is a link to my Github Repo with the fulling working example.

The AWS Cloud Development Kit (AWS CDK) is an open-source framework to help you provision cloud application resources by using your favorite programming languages! You can choose from TypeScript, JavaScript, Python, Java, or C#.

Simply put, you can leverage the AWS CDK to write code that will provision (create) AWS resources. If you are familiar with AWS CloudFormation, you should feel pretty comfortable using the AWS CDK. The CDK actually uses CloudFormation under the hood!

Why should you use the CDK?

Provisioning cloud applications can be very challenging. This may require a lot of manual work, maintaining templates, or using domain-specific languages. The AWS CDK allows you to harness the power of languages you already know to model your applications. You can also leverage high-level constructs that do a lot of the heavy lifting for you!

Here are MY favorite reasons:

1. You can spin up cloud infrastructure using TypeScript!
2. It allows you to reuse code. This is extremely useful when setting up multiple environments or applications.
3. The AWS CDK framework was built with best practices in mind. Using their framework and high-level constructs helps ensure, but does not guarantee, that you are using them correctly.
4. You can commit your code and leverage the AWS CDK as Infrastructure as Code (IaC). This allows each change to be documented in source control and gives you the ability to utilize the same systems as your application source code.
5. You need to write less to achieve more when compared to CloudFormation or Terraform.

🐦 Follow me on Twitter if you would like to see more content like this! 🐦

What are Constructs?

Constructs are a fundamental building block of AWS CDK. Each construct represents a "cloud component". A construct encapsulates everything AWS CloudFormation needs to create the component.

A construct can be as simple as an Amazon Simple Storage Service (AWS S3) bucket:

    new s3.Bucket(this, 'MyFirstBucket', {
      versioned: true
    });

It can also be abstract enough to create higher-level components that require multiple AWS resources. A great example of this is AWS Elastic Container Service (AWS ECS) constructs. This can require many components such as a cluster, service, task, and an Elastic Load Balancer (ELB). You can configure this with a handful of lines of code:

    // Create a load-balanced Fargate service and make it public
    new ecs_patterns.ApplicationLoadBalancedFargateService(this, "MyFargateService", {
      cluster: cluster, // Required
      cpu: 512, // Default is 256
      desiredCount: 6, // Default is 1
      taskImageOptions: { image: ecs.ContainerImage.fromRegistry("amazon/amazon-ecs-sample") },
      memoryLimitMiB: 2048, // Default is 512
      publicLoadBalancer: true // Default is false
    });

The AWS CDK provisions these resources in a safe and repeatable manner. You can reuse this code to provision multiple environments. You can also compose your own custom constructs allowing you to start new projects much faster!

Conclusion

At a high level, that's it! AWS CDK is a useful library that allows you to use your favorite programming language to provision cloud infrastructure. It allows you to quickly generate AWS resources, promotes best practices, and allows you to reuse code!

Stay Tuned -- I am writing several tutorials demonstrating how to use the AWS CDK!

🐦 Follow me on Twitter if you would like to see more content like this! 🐦

Resources

• AWS CDK Construct Library
• AWS CDK TypeScript Docs
• AWS ECS Example
• AWS CDK Workshop
• AWS CDK Workshop
• Github Examples provided by AWS

🐦 Follow me on Twitter if you would like to see more content like this! 🐦

TLDR - Here is a link to my Github with the given code.

1. Initialize the Project

You can follow my previous post on how to use AWS SAM to spin up a boilerplate Lambda function.

2. Email

First, let's write a function to send an email and return a promise.

function sendEmail(message){
    const awsRegion = "us-east-1";
    // FIXME - update this ARN
    const snsTopic = 'arn:aws:sns:us-east-1:12341234-ABCDABCD';
    const snsSubject = 'SNS Subject';
    // Create publish parameters
    var params = {
      Message: message,
      Subject: snsSubject,
      TopicArn: snsTopic
    };
    var sns = new AWS.SNS({ region: awsRegion });
    return sns.publish(params).promise();
}

3. Next, we bring it all together in the handler.

const AWS = require("aws-sdk");    

/**
 * A Lambda function that sends an SNS message
 */
exports.handler = (event, context) => {
    let message = "Hello from Lambda!";
    return sendEmail(msg).then((err,data)=>{
        console.log ("We are in the callback!");
        if (err) {
            console.log('Error sending a message', err);
            context.fail(err);
        } else {
            console.log('Sent message:', data.MessageId);
            context.succeed("Done!");
        }      
    });
};
...
...

4. Add an SNS Role

You will need to add a policy for this Lambda to be able to properly send SNS messages. We need to make a small update to the CloudFormation template to make use of this. If you did not use AWS SAM to generate the project, you can simply update the assigned role using the AWS Console.

  snsLambdaFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/handlers/index.handler
      Runtime: nodejs12.x
      MemorySize: 128
      Timeout: 100
      Description: A Lambda function sends an SNS notification.
      Policies:
        # Give Lambda basic execution Permission to the helloFromLambda
        - AWSLambdaBasicExecutionRole
        # This is the new policy
        - AmazonSNSFullAccess

TLDR - Here is a link to my Github with the given code.

🐦 Follow me on Twitter if you would like to see more content like this! 🐦

Conclusion

That's it! In a couple of dozen lines of code, you can easily utilize SNS subscriptions to send notifications.

Prerequisite

To use AWS services you must first have an AWS account. Also, you need to install SAM from the command line along with a few other requirements.

🐦 Follow me on Twitter to see even more content! 🐦

1. SAM Init

Once you have SAM installed you can get started with our first command!

sam init

Lets run sam init and use the AWS Quick Start Template

Next, you can choose between packaging the AWS Lambda as a Zip that will be uploaded to S3 or an image you can push to ECR. For right now, we are going to stick with the Zip file approach.

Now you get to choose your own runtime! There is a wide variety and just about any programmer should be able to get started. I am going to choose nodejs12.x for this tutorial.

You will subsequently need to create a project name and select a template to generate. There are some very useful options from creating an API endpoint to scheduling an event to be run periodically. We are going to use the From Scratch option

Finally, the project is generated! That was almost too easy. A README.md file was generated inside your source files. This includes very useful information that is outside the scope of the article.

SAM Test

One of the most frequently asked questions about AWS Lambda's is, "How do you test them?" Now that we have a project initialized you can test it locally! SAM comes with built-in functionality to test your Lamba Functions. There are a number of ways to be able to pass parameters as well. We are going to keep it simple for this demonstration.

sam local invoke

You can see the message that was generated in the starter project. There is also some useful logging to help you determine what costs will be associated with your AWS Lambda.

3. SAM build & deploy

Finally, we can build and deploy this Lambda to AWS in a single line of code! When you build the project SAM will compile an AWS CloudFormation template, template.yml and a samconfig.toml file encapsulating your settings. There is also a file included telling SAM how to build your Lambda Function named buildspec.yml.

sam build && sam deploy --guided

The project will get built. You can see our npm install occurring. You will subsequently be asked a series of basic questions and you can use all the default values.

SAM is very smart! Using CloudFormation, it will let you know which resources will be added, removed, or modified.

You will be asked to confirm the CloudFormation changes. Once you do so your changes will be deployed. This may take several minutes.

Conclusion

That's it! In as little as 5-10 mins you should have a testable and deployed AWS Lambda Function deployed using AWS SAM! Check your code into source control and treat it like any other part of your software system. Cheers!

🐦 Follow me on Twitter to see even more content! 🐦

Cleanup Pro Tips

Find the CloudFormation Stack

aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE

Delete the CloudFormation Stack

aws cloudformation delete-stack --stack-name my-stack

TLDL - Here is a link to my GitHub with all my Code.

🐦 Follow me on Twitter to see even more content! 🐦

Here is a look at what your file structure should look like at the end:

1. Checkout and (Optionally) Run Spring Boot App

Note: If you cannot run the app or don't have Maven installed it's not a big deal. We will get it running in the container! I just typically like to be able to run an app outside of a container before I containerize it. This helps me debug issues if the app does not run as expected in the container.

First, let's create a new Spring Boot project. Checkout the following Spring Boot starter app:

git clone https://github.com/fourgates/blog-spring-starter.git

Finally (optionally), start the project using Maven:

mvn spring-boot:run

Navigate to http://localhost:8080 or curl localhost:8080 and you should see the following message:

Greetings from Spring Boot!

2. Add Dependencies to pom.xml

Next, we are going to some dependencies to the project.

        <dependency>
             <groupId>org.postgresql</groupId>
             <artifactId>postgresql</artifactId>
             <version>42.2.6</version>
         </dependency>            
        <dependency>
             <groupId>org.springframework.boot</groupId>
             <artifactId>spring-boot-starter-jdbc</artifactId>
         </dependency>

What are these new dependencies?

• postgresql - This is a Postgres driver
• spring-boot-starter-jdbc - This is a JDBC driver to be able to communicate with a DB

3. Create a DataSource

Create SqlConfiguration.java in com/example/springboot/configuration:

package com.example.springboot.configuration;

import javax.sql.DataSource;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.jdbc.datasource.DriverManagerDataSource;

@Configuration
public class SqlConfiguration {

    @Value("${POSTGRES_USER}")
    private String user;
    @Value("${POSTGRES_PASSWORD}")
    private String password;
    @Value("${POSTGRES_DB}")
    private String db;

    @Bean
    public DataSource primary() {
      DriverManagerDataSource dataSource = new DriverManagerDataSource();
      dataSource.setDriverClassName("org.postgresql.Driver");

      dataSource.setUrl("jdbc:postgresql://spring_dev_db:5432/" + db);
      dataSource.setUsername(user);
      dataSource.setPassword(password);

      return dataSource;
    }
}

A couple of notes here:

• @Configuration - This is a Spring Boot annotation that will initialize this class before the app starts.
• @Value - These values are going to get populated from environment variables
• spring_dev_db:5432 - This is going to be the containerized DB we are going to run with our Spring Boot container. 5432 is the port we are going to use.

4. Update HelloController

Next, we are going to add a very crude example demonstrating a JDBC connection with out containerized database.

package com.example.springboot;

import org.springframework.web.bind.annotation.RestController;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.web.bind.annotation.RequestMapping;

@RestController
public class HelloController {

    @Autowired private JdbcTemplate jdbcTemplate;

    @RequestMapping("/")
    public String index() {
        // simply query to count the number of tables in our DB
        int result = jdbcTemplate.queryForObject("select count(*) from information_schema.tables", Integer.class);
        return "Greetings from Spring Boot! table_count = " + result;
    }
}

What did we do here?

• @Autowired - This injects a Bean
• private JdbcTemplate - This is an interface to communicate with our DB
• jdbcTemplate.queryForObject(...) - Here we are simply making a query to demonstrate we have connectivity with our DB

5. Create a Dockerfile

Almost done! Let's create a Dockerfile to create a container to run our Spring Boot app inside of.

### BUILD a maven builder. This will contain all mvn dependencies and act as an abstraction for all mvn goals
FROM maven:3.5.4-jdk-8-alpine as builder

# create app folder for sources
RUN mkdir -p /build
RUN mkdir -p /build/logs

# The WORKDIR instruction sets the working directory for any RUN, CMD, ENTRYPOINT, COPY and ADD instructions that follow it in the Dockerfile.
WORKDIR /build
COPY pom.xml /build
#Download all required dependencies into one layer
RUN mvn dependency:resolve && mvn compile

6. Create docker-compose.yml

Now we bring everything together with the docker-compose file! This file will start up our maven container for our Spring Boot app and another container with Postgres database.

version: "3.7"
services:
  spring_dev:
    build:
      context: .
    image: maven/builder:0.0.1
    container_name: spring_container_api
    ports:
      - "8080:8080"
    environment:
      - POSTGRES_USER=docker
      - POSTGRES_PASSWORD=docker
      - POSTGRES_DB=docker      
    volumes:
      - "./src:/build/src"
      - "./target:/build/target:cached"
    command: "mvn spring-boot:run"
    depends_on:
      - spring_dev_db    
  spring_dev_db:
    container_name: spring_dev_db
    image: "postgres:12"
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_USER=docker
      - POSTGRES_PASSWORD=docker
      - POSTGRES_DB=docker
    volumes:
      - spring_dev_data:/var/lib/postgresql/data
volumes:
  spring_dev_data: {}

A few things worth noting here:

• depends_on - We use this here because out web app needs the database to start before the app itself starts
• 'spring_dev_db' - This is the name of the database container
• image: "postgres:12" - This is an official Postgres image we are pulling
• ports - What ports we want to map
• environment - This is a VERY important part. When the database starts up these are the credentials that will be created. Additionally, a database named docker will be created.
• volumes - The first instance volume says we will be using a volume named spring_dev_data to persist data when the container is restarted. The second instance, spring_dev_data: {}, simply initializes the volume.

5. Start the App

That's all the code we need! You just need to run a few commands and your app should be up and running!

docker-compose build

docker-compose up

Navigate to http://localhost:8080/ and you should be greeted with a message telling you how many tables are in our database!

Here is a look at what your file structure should look like:

Conclusion

This was a very rudimentary example of using Docker to start up a Spring Boot app with a Postgres SQL database and a JDBC connection. There are many ORM alternatives to use to better handling the middle tier of selecting objects from the database. I will be covering them in future posts. This should provide a solid base to get up and started VERY QUICKLY when developing a Java web application using Spring Boot.

Here is a link to my GitHub with my all Code.

🐦 Follow me on Twitter to see even more content! 🐦

I have JS, PHP, HTML & CSS, but where would you suggest I go next? There’s so much to learn and it’s very confusing. I’m really scared of getting things wrong. Or asking for a road map if you like.

This is a hard question to answer. You need to ask yourself, "What are my goals"?

• Do you want to be able to build apps? Web apps?
• Do you want to design very pretty-looking websites?
• Do you want to want to make cool websites and get them to be on the first page of Google (SEO)?
• Are you interested in AI or ML? Do you like databases?

Once you figure out your goal(s), you can put a plan in place. I can help you figure out what steps you should take forward! All you need are some stepping stones. We can create a road map on how to accomplish your goal. Here is a simple roadmap for becoming a web application developer.

🐦 Follow me on Twitter to see even more content! 🐦

!IMPORTANT!

This is a high-level roadmap. This is not intended to turn you into an expert. This is ONE of MANY ways to HELP you land an entry-level web developer job. I have close to a decade of experience writing code. I regularly interview entry-level developers. If you were to complete each of these steps, absorb the material, and be able to speak intelligently about these topics I would be impressed. Take this advice with a grain of salt.

1. Learn HTML and CSS

FreeCodeCamp is a great resource for this. HTML and CSS is the foundation for any web application. Allocate 2-3 weeks for this.

2. Recreate 3 Popular Websites

Develop a landing page(s) using only HTML and CSS. Apple, GitHub, and Netflix are great choices! Understanding how popular websites are built will allow you to follow great patterns when you develop your own. Allocate 1-2 weeks to accomplish this.

3. Learn JavaScript and NPM

FreeCodeCamp and MDN are great resources for this. All modern websites utilize some sort of JavaScript framework. Node and NPM are tools used to work with these frameworks. They allow you to use libraries and tools that someone else has already written! Allocate 2-3 weeks.

4. Recreate 2 Popular Websites with JavaScript

Pick 2 complex projects and recreate their basic functionality using JavaScript, HTML, and CSS. Soundcloud and Twitter are great examples. Allocate 2-3 weeks.

5. Learn How Computers and the Internet Works

Search YouTube and Wikipedia and focus on the Application layer, HTTP, and how modern web apps work. You need to understand the basics of how web applications communicate. Allocate 1-2 weeks.

6. Learn Git and Deploying

All software projects should use source control. Atlassian has great git tutorials. Deploy your projects to Netlify or Vercel. Allocate 1-2 weeks.

7. Learn NodeJs and Express

Use official tutorials, then YouTube and StackOverflow if you don't understand something. I have a getting started tutorial here. Express and Node are great frameworks for build web applications QUICKLY. Allocate 2 weeks.

8. Learn ReactJS and Redux.

I am a big advocate for Angular. But I think ReactJS is in the biggest demand right now. Kent C. Dodds has a great course. Udemy also has some great courses. Allocate 3 weeks.

9. Learn GraphQL

Use official tutorials and YouTube (Udemy if needed). Then transfer your created apps to GraphQL. It should be relatively easy to migrate a small project to GraphQL, especially if you've gotten this far! Allocate 1 week.

10. Learn TypeScript

Learn it using official docs, YouTube & Udemy if needed. After, transfer all created apps to the TypeScript. I have written a great article describing how to convert ExpressJS to TypeScript. Allocate 1 week.

11. Build 2 Complex Applications

Pick a popular service and recreate the core functionality using learned stack: ReactJS, React Ecosystem, GraphQL, TypeScript, and ExpressJS. Then you will deploy it and put it on your resume. Allocate 2-4 weeks.

12. Create a resume, LinkedIn profile and apply for jobs

It should take you 1-4 weeks to land a job.

Conclusion

This should take you roughly ~6 months. This roadmap is not meant to make you an expert. But it should make you competent enough to land an entry-level software developer job. If you complete this roadmap I am very confident that you will be a very marketable developer! Good Luck! Reach out to me for ANY help!

🐦 Follow me on Twitter to see even more content! 🐦

This roadmap was inspired by Nick Bull!

🐦 Follow me on Twitter to see all vital content! 🐦

Here are some tips for taking the exam remotely:

• Check-in exactly 30 mins before the test starts, it took longer than I expected
• Make sure you download the software the day before! I did not know this beforehand. I thought the test was taken in the browser.
• Restart your computer the night before.
• DONT MAXIMIZE THE TEST PROGRAM WINDOW! As soon as the proctor started my test, my screen had the test toolbar on the top but the rest of the screen was black and I got an infinite spinner. I waited ~15 mins before restarting my computer and trying to start the test again. Luckily, this was only ~10 mins after my test was supposed to start bc I was able to get started earlier.
• Use the restroom before the test!
• Answer the easy questions first and come back to the hard ones. There are a bunch of questions that should be super easy.
• Once you are halfway through the test or maybe if you quickly get to the end, close your eyes and do some deep breathing for 30s. this will help you relax and focus better.
• Once the test is done and you get your pass/fail MAKE SURE YOU CLICK END TEST!! I got excited and had to use the restroom and left the room. The proctor called me and said I had to hit the button and I was not supposed to leave the room. I was not penalized since the test had ended, but I was very stressed for the next 24 hours.
• I took my exam at 1PM and got my grade the next morning.
• Celebrate your passing grade! Take the time to take notes on topics you remember that you have trouble with so you can pass the exam the next time!

Thanks again, everyone!!

🐦 Follow me on Twitter to see all vital content! 🐦

🐦 Follow me on Twitter to see all vital content! 🐦

TLDL: Here is the code in my GitHub. Here is a look at my pull-request with the necessary changes.

Prerequisite

1. Follow these instructions on how to install and configure the Amplify CLI.

2. Checkout my starter project on GitHub. Make sure you start on the feature/step-1-setting-up branch!

Initialize Amplify

1. Run the following code in the webapp folder. This will initialize an amplify project in our Angular project. You will then configure authentication. Finally, we will push these changes to AWS. You will be asked to login to your AWS account.

   amplify init 
   # make sure you store your keys for the new user!
   amplify configure
   amplify add auth
   amplify push
   

2. Install the UI using NPM.

   npm install aws-amplify @aws-amplify/ui-angular
   

Update Angular

1. Update app.module with this new code. We need to add imports for the AWS packages.

   import Amplify, { Auth } from 'aws-amplify';
   import {AmplifyUIAngularModule} from "@aws-amplify/ui-angular";
   import awsconfig from './aws-exports'; 
   Amplify.configure(awsconfig);
   ...
   imports: [
     ...,
    AmplifyUIAngularModule
   ],
   

2. AWS Amplify requires a global variable to be accessible. Add this to the top of the file src/polyfill.ts

   (window as any).global = window;
   (window as any).process = {
   env: { DEBUG: undefined },
   };
   

3. Replace all the template code in app.component.html with this

   <amplify-authenticator>
   <div>
    My App
    <amplify-sign-out></amplify-sign-out>
   </div>
   </amplify-authenticator>
   

4. Use a git ignore for amplify/team-provider-info.json. The file has sensitive info you don't want in source control!

That's it! You should be able to run ng serve and be greeted with a login screen.

If you simply want to pull my git repo you will need to delete the amplify folder and run the following commands:

amplify init 
# make sure you store your keys for the new user!
amplify configure
amplify add auth
amplify push

Here is the code in my GitHub. Here is a look at my pull-request with the necessary changes.

🐦 Follow me on Twitter to see all vital content! 🐦

Here are some screenshots from my setup:

Resource

• Sharing Amplify Projects

A little background on my experience, I am a senior software engineer and technical lead on several projects. I have spent the past year working with a couple of different apps that have been deployed to AWS. I first started with setting up a Postgres database in RDS, then got authentication working with Cognito. We set up our Jenkins server on an EC2 instance and first deployed our apps there. We run our apps in Docker containers so we were able to take advantage of ECR to store our images and ECS to deploy them in different clusters. I got pretty familiar with security groups and load balancers for handling access issues and traffic. CloudWatch has been awesome for monitoring all our applications and aggregating logs. In all, I have been exposed to a good chunk of AWS services and have deployed to dev, staging, and production environments.

I plan to follow a very similar plan I found on Reddit:

1. Go through the entire ACG video course. In order to help me digest the content, I plan on writing up some additional blog posts on topics I review
2. Read through AWS Well-Architected whitepapers
3. Go through and take Jon Bonso exams
4. Go back through the correct/incorrect answers from Bonso tests and take notes
5. Take the AWS practice exam
6. Take the exam!

I plan on watching ~2 hours of videos a week which would allow me to finish the ACG video course in ~8 weeks. I am not sure if I need to take all the labs, but I will find out! That may affect my timeline. Then I plan on spending ~4 weeks going through the whitepapers and taking practice exams.

Update (1)

When I first started this course it was 14.5 hours and now it is more than 22 hours! Between the added hours and aggressive timelines at work, it has taken me longer than expected to finish this course. I also did try to get this done a little sooner by averaging 30-60 mins a night ~5 days a week. Ultimately, it took me about 9 weeks.

Lo and behold I have finished this weekend! I was able to take advantage of the High Availability (HA) topics and S3 to make sure major improvements to the current architecture in my ongoing projects. Therefore, It has been very worth it!

I plan on using the next couple of weeks to take practice exams and read through some AWS Whitepapers. All in, it will be about 3 months to study, prepare, and take the AWS Certified Solutions Architect Associate exam. I will keep you updated!

Update (2) I Passed!

I officially passed my SAA-CO2!! I just wanted to take a moment to thank TutorialsDojo & Jon Bonso! I could not have done it without you! You have put together the highest quality exams to prepare me for the real deal. You have built a great community has always been very responsive!

I took the ACG course and then spent the rest of my time taking these exams and using the 30 question review feature. I spent 2-4 hours on each test. I took the exam then the next day I would go through every answer to take notes and read answers and documentation on every question. I only retook two practice tests that I did not pass.

I highly highly recommend joining both Adrian Cantrill - techstudyslack.com and Tutorial Dojo's slack channels! I learned a lot from being on these channels! People are constantly asking great questions and there are some really great cloud engineers on there! It's a great community.

Here are some study tips:

• Lots of autoscaling group questions, understand this topic very well!
• RDS, Mutli-AZ vs Read Replica
• ELB (classic vs network vs app)
• SQS (visibility timeout) FIFO, priorities
• Kinesis, firehose vs datastream. know what targets are available
• Lambda + API Gateway, when to use throttling
• IPv4 vs IPv6
• Lots of S3 question with classes and cost, S3 Lifecycle rules, Glacier, vs Glacier Deep Archive, know which classes have lifecycle restraints
• NACL vs Security Groups
• Dynamo DB use cases
• Elastic cache uses cases, Redis vs Memached
• NAT Gateway vs NAT Instance
• VPC Gateway Endpoint - which services use this and how to set this up
• Direct Connect components
• Lots of VPN questions, Site to Site, VPN Hub, Transit Gateway
• AWS Cloudtrail
• Diff EC2 classes (compute vs memory etc) I did not see the HDD(cold) vs SDD(general) etc questions that come up a lot on the practice
• File Gateway types
• Aurora Serverless
• IAM policies - how to construct them and know what they do
• IAM Roles when to use them? are they global?
• A lot of which file system to use (EBS, EFS, Storage Gateway, File Gateway),
• Spot Instances, in terms of cost and termination
• AWS Config - how it can be used, useful for tagging resources

AWS CloudWatch

First off — what is Amazon CloudWatch? CloudWatch is the control center for monitoring all your AWS resources in one place. You should regularly monitor your applications to ensure there are no surprise outages.

After I wake up I prepare breakfast and a coffee while I prepare for my daily standup meeting. In doing so, I normally log into our AWS account and take a look at CloudWatch to see traffic and look for anything out of the ordinary. CloudWatch is an Amazon service you can use to monitor AWS resources.

We had recently deployed a new containerized application to AWS Elastic Container Service (ECS). I noticed a few unusual metrics with the new application. The CPU seemed to be very active despite not be used and the memory utilization was increasing near 90% then diving back down.

These are not good metrics!

Immediately, I knew that something was not right. The app was frequently crashing which was causing the memory and CPU dips. Therefore, I set up a CloudWatch alarm with an SNS alert to email my team when the CPU spiked higher than 60%. In this case, someone could manually restart the application to reset the memory to prevent the application from crashing unexpectedly. This would be a bandaid until we found a proper solution. I documented the steps needed to create such an alarm.

Setup a CloudWatch Alarm

1. Create an alarm from AWS CloudWatch

2. Select a metric for the alarm

3. Select a metric category. Here I am going to use an ECS serviceName metric.

4. Select “MemoryUtilization” for your category

5. I set the alarm to go off if the average Memory Utilization was > 60%

6. Use an SNS topic to send you or your team an email

7. Make sure to add a description to keep track of different alarms

8. Finally hit create!

Setup a CloudWatch Dashboard

Next, I will show you how to create a dashboard so you can take a look for yourself without setting up an alarm! CloudWatch Dashboards are very useful to get metrics for a variety of metrics across different services all in one place. I personally create a dashboard for each environment for a client: develop, QA, UAT, staging, production, etc. You first need to navigate to CloudWatch in your AWS account.

1. Navigate to the dashboard link in CloudWatch and create a description

2. Select a type of graph

3. Select a metric. Here I am using MemoryUtilization, but CloudWatch has a huge set of metrics

4. Finally save the Dashboard!

Conclusion

I hope you enjoyed this post! Next, I will be writing a post describing exactly how I fixed this memory leak. Tune in and make sure to read my post about how to profile a Spring Boot application using Visual VM.

Ok, so in terms of CS degree, I have done scratch, the IOT & wireless comms. Covered html etc. The next module is python, which again is taking me down a different road... they are the resources I use a lot or did do to help me. How did you begin learning?

As a software engineer I literally never stop learning (and I've been out of school for 8+ years). I feel like I learn something new every day. There are a few ways to go about this:

One is setting annual goals. Every year I've made a list of things I want to learn or improve. When I first started working I wasn't very good at JavaScript. I made it a priority to take on tasks and ask for help learning JavaScript at work. In a subsequent year, I wanted to improve my SQL skills. I volunteered for every DB task my company allowed me to do!

Secondly, I am very ambitious. I love to build things! Therefore, sometimes I have an idea for an app and I just figure out how to do it! I find other apps that are similar and I try to use that as a starting point. I read articles on related topics. I try to talk to individuals who have done something similar or the same thing and ask for advice. This requires a lot of patients and you need to be driven!

Thirdly, I try to fill voids in my job or make improvements. Recently, we started doing a lot of AWS work. I asked if my company would pay for training. They agreed and now I am certified. I am now my companies go to Amazon guy. As an engineer, you need to try to solve problems!

I am not going to lie, this is NOT going to be easy. It is going to be hard. You are going to have to go outside your comfort zone and learn many foreign concepts. It will be like climbing a mountain. But at some point, the path will start to flatten out. You will find a comfortable pace and meet people to help you along the way. You don't need to do this alone. There is a great community out there just waiting to help you!

Do you know if there are any good sites to have a look at TypeScript, I’m more confused about just where to go?

I would just start with getting a high-level understanding of what TypeScript is. You don't need to go crazy with understanding every little thing about it. Understand WHY you should use TypeScript. Here are some quick resources I found.

Learn TypeScript in 5 Minutes

TypeScript From Scratch

Once you have a high-level understanding I would do something practical. If you have done something simple in JavaScript, try to do the same thing in TypeScript. A great example of something I did was using Express.js. I knew it very well and learned how to convert it from JavaScript to TypeScript. Here is a blog post describing this process. It might be a good exercise for you!

How to Convert Express.js to Typescriptt

You could also do something a little more structured like following an Angular tutorial. (I am a bit bias to Angular). Angular uses TypeScript and they have some really easy to follow along with tutorials. BUILDING apps has always been the best way for me to learn something new!

https://angular.io/start

Good Luck!

2020 Accomplishments

AWS

• I got AWS certified!
• AWS ECS has become my bread and butter
• I setup AWS infrastructure using the AWS CDK in Typescript

Work (9-5)

• I built my public-facing API
• Help develop a platform for a new sports league.
• Started to master Docker

Online Presence

• Started blogging
• Became active on Twitter

Finances

• I was able to achieve a 32% return on my portfolio!
• Upped my 401k contribution from 7% to 8%
• I was able to generate additional income by giving consulting advice on AWS!

Dev Tools

• I switched from using Eclipse to VS Code. This has made me much for efficient but took a few weeks to get comfortable. I highly recommend it.
• I learned how to use VS Code to develop code over SSH on a remote server on AWS. This is useful if you want to develop code on multiple devices and can't always commit all your code at once. It also allows you to easily demo or share your code. Developing code on a remote SSH server is seamless!
• I started using Notion for note-taking and it has been a game-changer!

Personal

• I built a Portfolio website
• I started a personal blog
• Hashnode become my favorite blogging platform
• I ran my first First 10k
• I found a passion for boxed wine

Learned Something New

• Learned .NET for a month
• Learned how to model a relational in a non-relational database (DynamoDb)

2021 Goals

AWS

• AWS cert 2, maybe? I need to weigh either more AWS certs will help me accomplish my goals.
• Start an AWS consulting business

Work (9-5)

• My current role at my company is as a Senior Software Engineer. I would like to position myself to be able to directly generate some type of revenue for my company.
• Take steps to improve me as a team lead and senior software engineer. My goal is to help improve the developers on my team by setting a high bar and mentoring. I want to help them complete tasks that they previously felt uncomfortable with because it was not their strong suit.

Online Presence

• Get 1,000 Twitter followers
• Become more active on LinkedIn and network with like-minded individuals
• Get started on YouTube

Finances

• 1 additional stream of passive income
• Market and sell something
• Bump 401k contribution from 8% to 9%
• Finish a blog series on SOLID programming that will drive an Ebook I can write

Dev tools

• Document design patterns I use on my blog. This serves as a tool to remind me of how to do something and allows me to share it with others.

Personal

• Wake up earlier
• Lift weights again
• Run a half marathon
• Start blogging about personal finances

Learn Something New

• Put up my first YouTube video
• Help my wife become an Amazon affiliate