DEV Community: Charles Allison

Beyond Lambda Functions: Mastering Serverless Development

Charles Allison — Tue, 04 Feb 2025 08:17:59 +0000

Introduction

AWS Lambda service is a critical component of serverless applications. It is one of the compute services for FaaS on AWS. When you deploy your functions to the cloud, AWS Lambda service is responsible for the execution. Knowing how to write and deploy functions is but a small percentage of what is required to build scalable serverless applications on AWS; it is a critical part not the only part. It is important to get ideas that can help when developing serverless applications.
This article contains some of the lessons learned in my 5 years of writing serverless applications that go beyond just knowing about AWS Lambda.
Let's dive right in!

Use Diagrams as a Guide

Diagrams have been a great tool for software engineers for a long time and it did not change with serverless development. I've worked with engineering teams that start working on large-scale systems without a simple diagram and what you hear is: "As you use the application you will get to know what it does and what happens when request 'x' is made". Maybe because of some requirements or something I'm not aware of, there is no simple documentation of the system's architecture. I have used diagrams in most of my large-scale architectures and they have been helpful. Some reasons for having a diagram as a guide include:

Birds-eye view of required components

In developing micro-services, it's safe to say that the unit of deployment is a service - a service is self-contained and has all the required functions it needs to carry out its operation. For serverless APIs, the unit of deployment is a function. Yes!, a function. However, in most, if not all cases, this function is not the only piece of your API. The function may need to read or write data from a data store, interact with data in an SQS queue or EventBridge, and many other components. The fact is there are a lot of moving parts that need to be effectively coordinated. With a diagram, you can see those parts and how they interact with each other to bring a feature to life.

Similar component concerns

The cloud offers similar products to achieving a result, of course with subtle differences and it is important to pick the right service given the right context to enable us to achieve our goal efficiently. After a system has been designed, with a diagram, you can quickly and easily depict if a service in use is the most efficient given the context of the requirement - you must however understand how each service operates in detail and avoid assumptions. Sometimes, you may have designed your architecture based on some limited requirement or even on assumptions. It is also possible that some parts of the system were rushed to quickly come up with a POC - that is fine. Having your solution in a diagram helps you understand what changes need to be done and how they affect the overall architectural solution. Diagrams also help in cases where there's a change to the requirement; it becomes easy to spot the service that should be replaced if needed and where.

Review solution across development life cycle

Software development is likened to the Civil Engineering discipline where in most cases, a building plan is drawn before actual construction begins. If this happens, then having a diagram allows you the opportunity to have your thoughts on paper(on screen) which effectively helps you review your solutions before implementation. There could be a better solution than what you originally documented. Let me also advocate that the software architecture diagram be seen as a "living document" in the sense that, it could change or be updated as the actual development progresses. This happens as you learn more about a domain or realise a better service for the job. Hence, you do not need a 100% complete diagram before you commence development. Having a visual representation of your solution, helps you make adjustments even faster as you implement your solution.

Faster development experience

I have noticed I go faster if I have a diagram that I can refer to as I implement a solution. This can be likened to goal setting and working backwards to implement the goal. It gives a feeling of having done it before. When you know the requirements and have documented the necessary services required to fulfil them, it's only a matter of your knowledge of the implementation. You really can go faster with a prepared diagram versus having to plan, think and develop almost simultaneously. It is useful here to remember that your code is not the solution - it is only an implementation of a solution.

Understand details of a service

It is typical in software engineering to start with a "hello world" type example when trying to learn a technology. It is ok and I am not against it - it's ok to get started with an example of how to use a service; it helps you quickly see requirements as well as simple outputs. However, to get the best and customise to your requirements, you will need more than a hello-world type experience. To become really good at using a service, you need to get practical with the service with as many use cases as you need to. Some of the ways to get started with a service include reviewing the documentation and reading an in-depth blog or an open-source repository with examples. However, please note that while those ways of learning are really good, they could focus on certain aspects of services, not the full capabilities. For example, it's general knowledge that Single Table Design in DynamoDB is very good. However, may not be suitable for all types of operations. Articles, blog posts, etc. have a focus - to get you to see a few things. Aside from all these, a progressive hands-on on the service is by far the best way to get a very good understanding of how the service operates, including its limitations - this helps you decide when to pick 'service a' over 'service b' when solving your requirements challenge.

Adopt EDA Early - For Efficient Scaling needs

One of the frequently talked about features of Lambda is that; it scales according to the number of requests. This means that a new instance of your lambda function is created to handle requests as they come in especially if a previous instance is "still busy". It is true that lambda scales. However, understanding its limitations is key to its efficient use and mitigation of unexpected behaviours.

Lambda does not scale infinitely, it has certain limits relating to the region of deployment and the number of functions that can be executed per time. Lambda's concurrency limit causes requests to be throttled when the limit is reached. Therefore, to build efficient systems with efficient scaling capabilities, you need to consider Event-Driven Architectures. It is very easy to postpone learning about EDAs in Serverless Architecture to a later time but I recommend that it is brought forward because it is very important and fundamental to your learning and understanding as a serverless developer and in developing efficient and scalable serverless architectures.

Two very fundamental aspects of EDAs are Queues and EventBuses. Fundamental knowledge of Amazon SQS and Amazon EventBridge can help you build efficient and scalable solutions.

What does that framework do? You may need to isolate it's orchestration

Frameworks help develop serverless applications because they provide some level of abstraction and structure as to how the application is written coupled with the ease of deployment.

Having developed several serverless applications using frameworks like AWS SAM and Serverless Framework, it is important to note that some aspects of the service or component are automated for the engineer. A good example is when AWS SAM or Serverless Framework automatically creates one of the critical components in the serverless API: the API Gateway.

In creating a custom API Gateway resource, the following resources are needed: RestApi, Resource, Stage, Method, Deployment and if you are using a custom domain, you will need both a BasePathMapping and DomainName resource.

In the SAM snippet below, just by specifying the Api type in the event source of the function, AWS SAM automatically creates those components for you - (talk about making your life easy) - and after deployment is done, you're greeted with a nicely formatted API Gateway URL with which you can access your APIs. A similar orchestration happens with the Serverless Framework.

CheckoutFunction:
Type: AWS::Serverless::Function
Properties:
  Handler: src/Checkout/index.handler
  Description: Performs order checkout
  MemorySize: 128
  Events:
    Api:
      Type: Api
      Properties:
        Path: /checkout
          Method: POST

This is useful as necessary - however, there will be times when you will need to orchestrate an API Gateway - hence, will need to define custom resources as listed above. This means you will need to know how to build an API Gateway resource just like the framework does so that you can decompose, isolate and build up as necessary. The lesson here is defaults are good, however, custom resources will need more than defaults.

Get Comfortable with IaC - Infrastructure as Code

I've been involved in projects where some resources like custom domain names are created via the AWS console. You soon find out that as the project progresses, such resources created become a breaking point for a smooth CI/CD process because they have been manually created and it is possible to forget that such resources were created (this happens a lot with S3 buckets).

IaC becomes critical when you work in a multi-account setup and you have to deploy services or environments across accounts in an efficient way - most times, offloaded to a CI/CD process - which is the best practice.

It is possible to become overly focused on functions. However, Infrastructure as Code is critical to your success in developing serverless applications. This includes defining resources like Buckets, Queues, Event Bridges, and others using code that can be checked into source control and integrated with a CI/CD process for an efficient and fast integration and deployment loop. This ensures consistency across environments, as multi-accounts are becoming common. You need to get comfortable with IaC.

Summary

This article shares insight from my journey in developing Serverless Applications on AWS. It looks beyond Lambda functions as the focus of Serverless Applications and shares ideas that I can help an engineer become better at building serverless applications including using flow diagrams for architecture visualisation, understanding the limitations of Lambda and the need for event-drive architectures. It also talks about understanding cloud service detail to make the right judgement as to what service to incorporate in architecture, with a note on the usefulness of IaC.

Some common tools used include:

Diagramming
Lucid Chart
Draw.io
ExcaliDraw

IaC/Frameworks

Pulumi
Terraform
AWS CDK
AWS SAM
Serverless Framework

I hope this helps. Let me know your thoughts in the comment section.

Serverless API Development on AWS with TypeScript - Part 3

Charles Allison — Fri, 11 Aug 2023 13:39:18 +0000

Introduction

In the last part of this series, we will go deeper into Data Access patterns, how they not only determine how we query a DynamoDB table but how they also determine the result of a query. We will also look at a fantastic feature of DynamoDB called Streams. DynamoDB Streams enables event notification for changes in a DynamoDB table. We will also look at Lambda events that have a different event source from API Gateway and how to filter them so that our handler function gets only what our business logic required. Finally, we will be looking at Amazon SNS and how we can use it to send SMS to a customer. All of this is within the context of the Tenant Service Project.

For a quick recap, in Part 1 we saw the setting up of the project and the necessary configurations when working with the Serverless Framework. Part 2 discusses the entities in the project with a focus on the Tenant entity. It also discusses the setup of the DynamoDB table which is akin to the Create Table statement along with its Global Secondary Indexes.

charlallison / tenant-service

Simple example of building Serverless API on AWS using TypeScript

Tenant Service

The Tenant Service is a serverless application built on AWS Lambda and other services using the Serverless Framework. It provides management of tenants and payments made for a property, as well as basic CRUD operations for properties.

Features

Tenant Management: Create, update, and delete tenant information, including name, phone, and property allocation.
Payment Management: Record tenant payments, including payment amount and date.
Property CRUD: Perform basic CRUD operations (Create, Read, Update) on property information, such as property details, address, and rental rates.

Architecture

The Tenant Service utilizes the following AWS services:

AWS Lambda: Handles the serverless functions for processing tenant, payment and property operations.
API Gateway: Provides a RESTful API to interact with the service.
DynamoDB: Stores tenant and property data, as well as payment records.
EventBridge (CloudWatch Events): Triggers lambda function on schedule.
AWS CloudFormation: Automates the provisioning and management of AWS resources.
Amazon SNS Sends SMS…

View on GitHub

Data Access Patterns

As already established in Part 2, the primary keys in DynamoDB are the basis for Data Access patterns; how data is accessed. These patterns do not only affect how data is retrieved from a DynamoDB table but also determine what data is retrieved.

Sample Keys in Tenant Service

The code snippet below shows different keys that form the Data Access Patterns in the Tenant Service. Recall that in Part 2 also, the default primary key returns a tenant record only because of how it was designed - it queries the table using two primary key attributes; PK and SK. When we use either GSI1PK or GSI2PK , we are making use of a different primary key which is a different access pattern from the default primary key. This access pattern certainly has a different primary hence the difference in the resultset.

// tenant default primary key - composite primary key
// Retrieves a Tenant record ONLY
{
  PK: `tenant#id=724dab0a-6adb-4d64-91fb-a95b492d9120`,
  SK: `profile#id=724dab0a-6adb-4d64-91fb-a95b492d9120`
}

// Tenant GSI keys
// GSI1PK: Retrieves tenant and corresponding record with same GSI1PK
// GSI2PK: Retrieves all tenants
{
  GSI1PK: `tenant#id=724dab0a-6adb-4d64-91fb-a95b492d9120`,
  GSI2PK: `type#Tenant`
}

// Payment GSI1 key
// Retrieve all payments for a tenant
{
  GSI1PK: `tenant#id=724dab0a-6adb-4d64-91fb-a95b492d9120`
}

// Property default primary key - composite primary key
// Retrieves a Property record ONLY
{
  PK: `property#id=463fb471-e199-4375-b745-1c17cbbc1931`,
  SK: `property#id=463fb471-e199-4375-b745-1c17cbbc1931`
}

// Property GSI1 key
// Retrieves all properties
{
  GSI1PK: `type#Property`
}

A fundamental concept that forms the basis of the single-table design is what can be described as a hierarchical relationship between records. A quick example of this concept in the Tenant Service is that every payment record must have a tenant record as its root. This means we can get a tenant and all payment records for that tenant in one call, depending on how we query the table. When a table is queried, you can imagine the resultset as having to use a GROUP BY clause so that you can see all records irrespective of the entity type, that have the same value for the attribute you are querying by - in this case, a GSI key. To illustrate this, take a look at the snapshot below.

The snapshot above shows the GSI1 tab selected which displays the records available for the GSI index: GSI1. Every record that has the GSI1PK attribute is listed as well. We can see that under the attributes, we have entries for bothtenant and payment entities. Recall that for every GSI, there has to be a corresponding primary key. We have in this case, GSI1PK as theprimary key - it is the partition key as well. The records displayed have a similar GSI1PK value and are therefore grouped on this value. See below how the GSI1PK keys are formed - they surely have a similar definition.

// payment.ts
static BuildGSIKeys(tenantId: string) {
  return {
    GSI1PK: `tenant#id=${tenantId}`
  }
}

// tenant.ts
static BuildGSIKeys(prop?: {id: string}) { // given that id is not undefined
  return {
    GSI1PK: `tenant#id=${prop?.id}`
    // ...
  };
}

This, therefore, means that if the index GSI1 is queried using a GSI1PK that matches a GSI1PK entry in the table, we will get the records for the tenant with that GSI1PK and all corresponding payment records. With this, it becomes very obvious that Data Access Patterns via GSI is a critical factor which not only determines how a DynamoDB table is queried but also determines the resultset that is returned. The beautiful thing about using DynamoDB here is the fact that a single database call is what is needed to get the records as explained - this is void of a table join as all the records reside in one table.

DynamoDB Streams

When a Tenant pays for a property, it makes sense to update the property's status as NotAvailable so that it will not be listed otherwise. This also applies to a tenant such that if the tenant is making payment for the first time, the status attribute will initially be NotActive. The tenant's status attribute will need to be updated as well to indicate that this is an active tenant. Given a table design where we have data saved in different tables, after saving the payment record, we will have to ensure that the save-payment operation succeeded before we can go on to update the property or tenant record. Well, DynamoDB has a better way of handling that using Streams.

DynamoDB Streams is a feature that generates events when data in a DynamoDB table changes. This could either be an INSERT, DELETE, or UPDATE operations. DynamoDB generates this event in near real-time, containing those changes in the table. To make use of this feature, DynamoDB Streams is enabled in the Tenant Service table resource definition by setting StreamViewType which is under the StreamSpecification key, as shown below.

StreamSpecification:
  StreamViewType: NEW_AND_OLD_IMAGES

You can then specify when the event should be triggered given the scenarios:

when a new record is added to the table: NEW_IMAGE
when an update is made to an existing record (including deletion): OLD_IMAGE
when either a new record is added or an existing record is updated(including deletion): NEW_AND_OLD_IMAGES

Thankfully, AWS Lambda is designed such that this event can be used as a trigger for Lambda functions.

With Streams enabled, we can be notified by DynamoDB when a payment record is saved to the table so that both the tenant and property status attributes are updated accordingly.

The Lambda function UpdatePropertyStatus is the event handler for updating the property status attribute when a payment is saved. It listens for an event from DynamoDB Streams for new a record entry of a payment entity and then performs the update on the property. How does it know the property that was paid for? You may ask. That is handled given that every payment has an attribute containing the attribute propertyId against which the payment was made. A similar setup is available for updating the tenant attribute status - the UpdateTenantStatus Lambda function.

UpdatePropertyStatus:
  handler: ./lambda/UpdatePropertyStatus/index.main
  description: Updates the status of a property after a successful payment
  memorySize: 128
  timeout: 10
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:UpdateItem
      Resource:
        - ${self:custom.DatabaseTable.arn}
  events:
    - stream:
        type: dynamodb
        arn: ${self:custom.DatabaseTable.streamArn}
        filterPatterns:
          - eventName: [INSERT]
            dynamodb:
              NewImage:
                Type:
                  S: [Payment]

The code snippet above shows the configuration for the UpdatePropertyStatus Lambda function - the configuration is where we set the function trigger. Taking a look at the events key, you will notice the entry is set to stream - this refers to the event source of the function. The type key defines the type of stream which is DynamoDB in this case and arn that defines the source of the DynamoDB Stream - the Tenant service table.

The Lambda function below is the UpdatePropertyStatus handler. It takes in a DynamoDBStream event payload as its argument. This event payload contains record(s) that were published when the corresponding event was raised in the table. In this payload, we then deconstruct the NewImage which is in the dynamodb field to get the newly saved payment record. And because we are certain that it is a payment record entity, doing a cast with the type-casting construct as Payment comes without worry. But how is that? By event filtering.

// ...imports

export const main = async (event: DynamoDBStreamEvent) => {
  const { NewImage }: { [key: string]: any } = event.Records[0].dynamodb;
  const { propertyId } = unmarshall(NewImage) as Payment;

  await ddbDocClient.send(new UpdateCommand({
    Key: Property.BuildPK(propertyId),
    TableName: process.env.TENANT_TABLE_NAME,
    UpdateExpression: 'SET #status = :status',
    ExpressionAttributeValues: {
      ':status': PropertyStatus.NotAvailable
    },
    ExpressionAttributeNames: {
      '#status': 'status'
    }
  }));
}

DynamoDB Event Filtering

It is important to note that Streams is enabled on a per-table basis. What this means in effect is that the DynamoDB table will generate and raise an event whenever there is a change in the table. Of course, this is depending on the used StreamViewType. For example, if a new Tenant or a Property is saved, the table will publish that event as a record-added event, not a payment-record-added or property-record-added event. This means, any Lambda functions listening for some kind of record-added event from DynamoDB Streams will be triggered. We can filter DynamoDB events such that a Lambda function will only be triggered when certain criteria are fulfilled. For the Tenant service, we want that the UpdatePropertyStatus function will only be triggered when a new payment record is saved to the table. Applying this event filter will help us guard against unwanted concurrency issues where all functions listening for some kind of record-added events will be triggered. This is achieved using the filterPatterns key.

events:
  - stream:
      type: dynamodb
      arn: ${self:custom.DatabaseTable.streamArn}
      filterPatterns:
        - eventName: [INSERT]
          dynamodb:
            NewImage:
              Type:
                S: [Payment]

The snippet above is a part of the Lambda configuration for UpdatePropertyStatus. This configuration defines through the filterPatterns key that the Lambda function should only be triggered if the event via the eventName is an INSERT operation. The NewImage represents the new record that was just saved to the table. The filter expression also defines (in addition to the INSERT operation) that the Type attribute of the saved record should be evaluated. If the attribute is of type String hence the S and the value is equal to "Payment", then the function can be triggered. With this filter condition in place, we can be sure that the Lambda function will only be triggered when a new payment record is saved to the table. Note that the Type attribute was added as part of the entity definition. See Part 2 of this series for details.

Time-Based Events with EventBridge

The payment entity has an expiresOn attribute that holds the value for the expiration of the payment. It is calculated when a payment object is created. After a payment record is saved, the UpdateTenantStatus function updates the status attribute of the tenant and sets the value of the attribute notifyOn. This attribute stores the date when the tenant will be notified about the coming expiration of rent - this is set to 1 month prior. Given this requirement, there needs to be a monthly pooling of the tenants' records that meet the criteria, so that they can be notified of rent expiration in the coming month.

In the architecture diagram, there is a SendPaymentReminder function that is triggered by the Amazon EventBridge. EventBridge is set up to trigger the SendPaymentReminder function every month, at a certain time using cron-style scheduling.

Cron Scheduling in Action

SendPaymentReminder:
  handler: ./lambda/SendPaymentReminder/index.main
  description: Notifies tenants via SMS that their rent will expire in the coming month.
  memorySize: 512
  timeout: 10
  environment:
    SENDER_ID: 'LandLord'
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:Query
        - sns:Publish
      Resource:
        - !Join ["/", ["${self:custom.DatabaseTable.arn}", "index", "*"]]
        - '*'
  events:
    - schedule: cron(0 12 1W * ? *)

Above is the configuration for the SendPaymentReminder function. Our focus here is the events key. It is set to schedule and the value uses cron syntax to schedule the function to run at noon on the 1st day of the 1st week of every month. Let's take a look at the event handler for this EventBridge-triggered event.

// ...imports

export const main = async () => {
  const { year, month } = DateTime.now();
  const date = DateTime.utc(year, month).toUnixInteger();
  const { GSI2PK } = Tenant.BuildGSIKeys();

  const response = await ddbDocClient.send(new QueryCommand({
    IndexName: GSIs.GSI2,
    TableName: process.env.TENANT_TABLE_NAME,
    KeyConditionExpression: '#gsi2pk = :gsi2pk',
    FilterExpression: '#notifyOn = :notifyOn AND #status = :status',
    ExpressionAttributeValues: {
      ':gsi2pk': GSI2PK,
      ':notifyOn': date,
      ':status': TenantStatus.Active
    },
    ProjectionExpression: '#phone, #name',
    ExpressionAttributeNames: {
      '#name': 'name',
      '#phone': 'phone',
      '#status': 'status',
      '#notifyOn': 'notifyOn',
      '#gsi2pk': 'GSI2PK',
    }
  }));

  response.Items.forEach(item => {
    const { name, phone } = item as Pick<Tenant, 'name' | 'phone'>;
    const message = `Hi ${name}, I hope you're doing great. This is a gentle reminder that your rent will expire next month. Please endeavour to pay in due time`
    sendSMS(message, phone, process.env.SENDER_ID)
  });
};

In this very simple invocation, there is no need for the event argument hence an empty argument list for the main function. When this function is triggered, some very simple calculations of the date and building of the GSI2PK key and then a query to DynamoDB. If we have tenants that meet the criteria, an SMS is forwarded accordingly.

SMS with Amazon SNS

Sending SMS is easy using the Amazon SNS API. As with every managed service, we only need to provide the necessary configuration and we're off this using the service. This assumes your account is no longer in sandbox mode else you must have to register and verify any phone number you intend to send an SMS.

In the Lambda configuration below, we specify the permissions needed to send SMS with the SNS API.

# SendPaymentReminder/config.yml - other portions omitted for brevity
iamRoleStatements:
  - Effect: Allow
    Action:
      - sns:Publish

The current implementation of the Tenant service communicates to the tenants on two occasions. The first is after a payment is made, and the second is when a reminder about the rent's expiration is due. At both times, the SNS is utilised to send an SMS to the tenants' phone number. In the simple code below, the sendSMS function takes in three arguments; message, phoneNumber and sender. These are used by the SNS API to forward the intended message to the tenant.

// ...imports

export const sendSMS = async (message: string, phoneNumber: string, sender: string) => {
  await snsClient.send(new PublishCommand({
    PhoneNumber: phoneNumber,
    Message: message,
    MessageAttributes: {
      'AWS.SNS.SMS.SenderID': {
        DataType: 'String',
        StringValue: sender,
      }
    }
  }));
}

Conclusion

In this article we talked about DynamoDB keys as the basis for Data Access Patterns, and how they can be a factor in determining the resultset of queries.

We also saw that DynamoDB Streams is a great feature and should be used where necessary. However, it is essential to apply a filter to the events so that the appropriate Lambda functions are triggered instead of having all functions that are listening to a particular source be triggered at the same time. The filter also helps us to avoid having several if conditions inside Lambda functions.

Understanding event types and the structure of their payload is key to manipulating the data. It is okay to log the event payload to CloudWatch to get an idea of this structure if the documentation is not clear enough.

This brings me to the conclusion of the series: Serverless API Development on AWS with TypeScript. I am glad to have started this series, and I believe it is presented in a way that is easy to understand.

Resources

Serverless API Development on AWS with TypeScript - Part 2

Charles Allison — Thu, 10 Aug 2023 07:13:00 +0000

Part 1 of this series was an introduction to the Tenant Service project, the AWS services used and configurations for the Serverless Framework.

In this article, part 2, we will take a deeper look at the composition of the entities because they play a vital role in how we define our table schema when adopting the Single Table design strategy. Also contained in this part 2 is Lambda function configuration with the Serverless Framework, configurations for creating DynamoDB table, keys and Global Secondary Index.

charlallison / tenant-service

Simple example of building Serverless API on AWS using TypeScript

Tenant Service

Features

Tenant Management: Create, update, and delete tenant information, including name, phone, and property allocation.
Payment Management: Record tenant payments, including payment amount and date.
Property CRUD: Perform basic CRUD operations (Create, Read, Update) on property information, such as property details, address, and rental rates.

Architecture

The Tenant Service utilizes the following AWS services:

AWS Lambda: Handles the serverless functions for processing tenant, payment and property operations.
API Gateway: Provides a RESTful API to interact with the service.
DynamoDB: Stores tenant and property data, as well as payment records.
EventBridge (CloudWatch Events): Triggers lambda function on schedule.
AWS CloudFormation: Automates the provisioning and management of AWS resources.
Amazon SNS Sends SMS…

View on GitHub

Entities

The Tenant Service contains these entities tenant, payment and property. Let's take a look at the Tenant entity.

import {v4} from "uuid";

export enum TenantStatus {
  Active = "Active",
  InActive = "Inactive"
}

export class Tenant {
  readonly id: string;
  readonly PK: string;
  readonly SK: string;
  readonly name: string;
  readonly phone: string;
  readonly status = TenantStatus.InActive;
  readonly Type: string = Tenant.name;
  readonly GSI1PK: string;
  readonly GSI2PK: string;

  constructor(data: Partial<Tenant>){
    this.id = data.id ?? v4();
    this.name = data.name;
    this.phone = data.phone;
    const { PK, SK } = Tenant.BuildPK(this.id);
    this.PK = PK;
    this.SK = SK;

    const { GSI1PK, GSI2PK } = Tenant.BuildGSIKeys({ id: this.id });
    this.GSI1PK = GSI1PK;
    this.GSI2PK = GSI2PK;
  }

  static BuildPK(id: string) {
    return {
      PK: `tenant#id=${id}`,
      SK: `profile#id=${id}`
    }
  }

  static BuildGSIKeys(prop?: {id: string}) {
    return {
      GSI1PK: `tenant#id=${prop?.id}`,
      GSI2PK: `type#${Tenant.name}`
    };
  }
}

In the src/tenant.ts file, we have pretty self-explanatory fields and two static functions. We also have an enumeration that is used to categorise tenants into;

those whose payments are still valid and have not expired as Active and
those whose payments have expired and need to be renewed or no longer reside in the property as Inactive.

The static functions, BuildPK and BuildGSIKeys are for formatting primary keys for both our default table and for Global Secondary Index (GSIs). These keys help with data manipulation in DynamoDB. These static functions are used as a convention in the Tenant Service such that the BuildPK is used to format the Primary key and BuildGSIKeys is used to format GSI keys where applicable. More about keys in the DynamoDB section.

Lambda Configuration

Lambda function configuration refers to parameters needed for the execution of a lambda function. This includes the function trigger and memory requirements, environment variables, AWS role and other services that the function will need to interact with. The Serverless Framework makes developing and deploying a Lambda function easy. However, it is up to you to organise your code in your preferred way that will be easy to navigate. I have organised the Tenant service in such a way that each lambda function resides in a separate directory to isolate them from the other functions. This provides a clear visual indication that all the required files for a function are located within a single directory.

The ./lambda directory contains all the functions that make our API. I prefer to name a function directory using _verb_s as it is easy to spot where a function resides based on its name and the action it performs. Let's take a look at the CreateTenant function.

CreateTenant Function

The CreateTenant directory contains three (3) files; config.yml, schema.ts and index.ts.

Config.yml

The config.yml file contains necessary function configurations, description, deployment and invocation mechanism using the Serverless Framework. Every necessary configuration as per application requirement for this function has to be declared here. The important keys in this file are described below:

handler - points to the TypeScript function to be invoked when the corresponding event is triggered - in this case, it is the main function.
memorySize and timeOut - has to do with the amount of memory needed and execution duration of the function
environment: key for specifying environment variables if needed
iamRoleStatements: lists permissions and the object of action in the AWS ecosystem. In the configuration below we have the dynamodb:PutItem action with permission set to allow on a database table resource via its resource name.
events: lists the triggers for the function - in this case, it is http which refers to an invocation from API Gateway. It also specifies the request method as POST and its path as /tenants.

schema.ts

This file contains the JSON schema for validating the request payload for the CreateProperty function. This JSON schema is used by middy middleware to validate the request payload before the lambda function is executed. An error is thrown if the shape of the payload does not conform to the schema.

export default {
  type: 'object',
  required: ['body'],
  properties: {
    body: {
      type: 'object',
      required: ['name', 'phone'],
      properties: {
        name: {type: 'string'},
        phone: {type: 'string'}
      }
    }
  }
} as const

index.ts

contains the code that will be executed when the function is triggered

handler is a function of type ValidatedEventAPIGatewayProxyEvent<T>. It receives an argument name event that has been formatted to match a specified schema via the generic <typeof S> construct. The event argument contains event-related fields which include body, queryStringParameters and pathParameters fields from where the user data is gotten.
The exported main function is lambda's entry point. It takes in the handler function and schema field via the middyfy function and chains jsonBodyParser, validator and httpErrorHandler middlewares together before finally calling the handler function.

Type definition function

The ValidatedAPIGatewayProxyEvent is the type definition for the handler function used in index.ts. This function sets the shape of the body and queryStringParameters fields in the request payload proxied by API Gateway.

This src/libs/api-gateway.ts file also contains a function formatJSONResponse that formats response for API Gateway.

    import type { APIGatewayProxyEvent, APIGatewayProxyResult, Handler } from "aws-lambda"
    import type { FromSchema } from "json-schema-to-ts";

    type ValidatedAPIGatewayProxyEvent<S> = Omit<APIGatewayProxyEvent, 'body' | 'queryStringParameters'>
      & { body: FromSchema<S> }
      & { queryStringParameters: FromSchema<S> }

    export type ValidatedEventAPIGatewayProxyEvent<S> = Handler<ValidatedAPIGatewayProxyEvent<S>, APIGatewayProxyResult>

    export const formatJSONResponse = (response: Record<string, unknown>, statusCode = 200) => {
      return {
        statusCode,
        body: JSON.stringify(response)
      }
    }

DynamoDB Configuration

Single-Table approach...certainly not for the faint-hearted.

Paul Swali

Designing for a relational database software system sometimes requires that one achieves normalization - a 3NF, by splitting data into separate tables where each table represents an entity. You could have a join table as needed. The Single Table design requires a different approach which could be challenging at least for the first time and in some complex scenarios.

It is important to note that DynamoDB does not constrain you to the use of only the Single table design. You are welcome to design your DynamoDB tables as though you were working on a relational database system with several tables in place. With that said, let's dive into the Tenant service table schema.

The configuration for the DynamoDB resource is found in ./resource/database-table.yml which contains some sort of DDL statement. Given the fact that all entities will be stored in a single table, we have to define generic keys that will be meaningful across all entities. In other words, the attributes selected to serve as keys and ensure data integrity must apply to Tenant, Payment and Property entities. To make that generic and easy to manipulate, it is best to name them by their function. For the Tenant service, PK refers to the partition key and SK, sort key.

The DynamoDB resource file database-table.yml reveals self-descriptive fields except for a few. The table is designed to have a composite primary key and two Global Secondary Indexes that have their respective primary keys; GSI1PK and GSI2PK. The table also enables DynamoDB Streaming via the StreamSpecification key.

TenantServiceTable:
  Type: AWS::DynamoDB::Table
  Properties:
    TableName: ${self:service}-${self:provider.stage}-Table
    BillingMode: PAY_PER_REQUEST
    AttributeDefinitions:
      - AttributeName: PK
        AttributeType: S
      - AttributeName: SK
        AttributeType: S
      - AttributeName: GSI1PK
        AttributeType: S
      - AttributeName: GSI2PK
        AttributeType: S
    KeySchema:
      - AttributeName: PK
        KeyType: HASH
      - AttributeName: SK
        KeyType: RANGE
    StreamSpecification:
      StreamViewType: NEW_IMAGE
    GlobalSecondaryIndexes:
      - IndexName: GSI1
        KeySchema:
          - AttributeName: GSI1PK
            KeyType: HASH
        Projection:
          ProjectionType: ALL
      - IndexName: GSI2
        KeySchema:
          - AttributeName: GSI2PK
            KeyType: HASH
        Projection:
          ProjectionType: ALL

DynamoDB Keys - PK & SK

A composite primary key is a primary key that consists of more than one attribute - which is used to uniquely identify a record in a table. Leveraging the composite key concept, we have the PK and SK defined in the KeySchema field. The primary key determines the Data Access Patterns in DynamoDB which is how data is accessed within a table. Care has to be taken when deciding on how a primary key is constructed. In the snippet below, we see how the Tenant's entity primary key is constructed; an id is passed in as an argument to the BuildPK function and we have an object with two attributes as the primary key - this primary key has to match the requirement of the primary key definition in the ./resource/database-table.yml file.

static BuildPK(id: string) {
  return {
    PK: `tenant#id=${id}`
    SK: `profile#id=${id}`
  }
}

To retrieve a tenant's record from the table, this primary key is used. By using the primary key, a full table scan is avoided because of its performance and cost implications. We may need to retrieve a tenant's record by a different attribute other than the initial primary key. When this happens we then need to create an alternative primary key typically seen as another Data Access Pattern. In doing so, a tenant record can be retrieved based on that attribute that now forms the primary key. How can this alternative primary key be created?

Given the needs of an application, multiple Data Access Patterns would need to be utilized for effective data retrieval

Global Secondary Index

To keep it simple, a Global Secondary Index - (GSI) enables you to create an alternative primary key using a different attribute. This ultimately provides more options with which we can query a DynamoDB table.

The Tenant entity has two fields; GSI1PK and GSI2PK that serve as primary keys to the GSIs defined in the GlobalSecondaryIndexes key. There are two indexes; GSI1 and GSI2, the key type and projection which specifies the attributes you want to return when that index is used.

The Payment and Property entities have just one GSI key which is the GSI1PK . In Part 3 of this series, we will look at the usefulness of having a generic key such that entities share similar keys but with different functionality. It is important to note that GSIs and their corresponding keys are added on a per-need basis - the needed Data Access Pattern should determine what keys are created and their composition.

Keys In Action

// ...imports

const handler: ValidatedEventAPIGatewayProxyEvent<typeof schema> = async (event) => {
  const { status }: {[key: string]: any} = event.queryStringParameters;
  const { GSI2PK } = Tenant.BuildGSIKeys();

  const result = await ddbDocClient.send(new QueryCommand({
    TableName: process.env.TENANT_TABLE_NAME,
    IndexName: GSIs.GSI2,
    KeyConditionExpression: 'GSI2PK = :gsi2pk',
    FilterExpression: '#status = :status',
    ExpressionAttributeValues: {
      ':gsi2pk': GSI2PK,
      ':status': status,
    },
    ExpressionAttributeNames: {
      '#name': 'name',
      '#status': 'status'
    },
    ProjectionExpression: 'id, #name'
  }));

  const tenants = result.Items.map(item => item as Pick<Tenant, 'id' | 'name'>);

  return formatJSONResponse({
    count: tenants.length,
    tenants
  });
}

The snippet above contains a DynamoDB Query command operation where an Index and its corresponding primary key are used to fetch one or more records from a DynamoDB table. This is achieved using the IndexName and KeyConditionExpression keys. You can also specify filter conditions using the FilterExpression key as necessary.

Conclusion

In this article we took a step further into entities and their composition, using the tenant entity as a case study. We also looked at keys, how they were constructed and their usefulness in index operations.

Lambda configuration came next as we looked at how the Serverless Framework applies our configuration for AWS Lambda. The configuration also affects how functions are written as we have to specify the services, interactions and the actual operations (permissions) that can be carried out by the function.

A major section of this article looked at the DynamoDB table service. While this isn't an in-depth review of the DynamoDB service and features, we saw the usefulness of primary key - composite and non-composite types, Global Secondary Index and how you can select what Index you intend to use for a query operation.

In Part 3 of this article, we will go deeper into how primary keys determine what data is returned. We will also see DynamoDB streams in action - with this, you can track changes to your table immediately after a DML operation without issuing another query.

Serverless API Development on AWS with TypeScript - Part 1

Charles Allison — Tue, 23 May 2023 08:57:01 +0000

Introduction

This article is written to help anyone who needs a guide in building their first serverless API on AWS using the Serverless Framework and TypeScript. If you have never built an API using the Serverless Framework, you would need to set up your development environment. Check out my post on Setting up for Serverless Development on AWS, follow the steps to download and install the components needed to complete this project.

If you are familiar with a concept or service go ahead and skip it to save yourself some time.

About this Project

This Tenant-service project represents a property-rental scenario where a tenant rents an available property and receives an SMS notification for payment. After that happens, the tenant becomes active and the property becomes unavailable to be rented by another tenant. Subsequently, an active tenant can renew the rent for their current property. Finally, an SMS notification is sent to tenants 1 month before the expiration of the rent. The operations include:

Create a tenant
Update tenant record
List all tenants by status
Delete a tenant
Record a payment transaction
Send an SMS after payment
Send a reminder via SMS, one month before the expiration

Integrated AWS Services

The Tenant service project is built on AWS as a serverless API. I have included a brief description of the AWS services used in this project and how they work. As we go on you will see how they are used in this project. These five (5) services are:

Amazon API Gateway

Amazon API Gateway receives and directs traffic to the appropriate service or handler that is responsible for that API request. Of course, such interactions must have been linked. Users can access whatever backend services you provide via the API Gateway. After the request is handled, the response is forwarded back to the API Gateway and finally, to the user. Amazon API Gateway is completely managed hence you do not need to install any server or component to start using it. It supports REST APIs as well as WebSocket APIs and also integrates easily with other supported AWS services.

AWS Lambda

AWS Lambda is one of the compute services for Serverless Computing on AWS. You can deploy a function - yes! just a function - even if the function only returns the traditional "Hello World" string, you can deploy that function to AWS Lambda and Lambda will invoke your function when it is triggered. AWS Lambda supports many programming languages but this project uses TypeScript.

Amazon DynamoDB

Amazon DynamoDB is a NoSQL, Key-Valued based Serverless database by AWS. It is highly efficient and can power high-performance applications at scale. Given it is serverless, there's no need for provisioning - you just need to configure your table and get started using it. We will be using this database to create the table used in this project.

DynamoDB Stream

Dynamodb Streams is one of the cool features of the Dynamodb Store. A stream is created when an INSERT, MODIFY or DELETE action is carried out on a DynamoDB table. Streaming by DynamoDB has to be enabled - it is not automated enabled. We will be using the streams to initiate checks and perform more logic based on an event in the table.

Amazon EventBridge

At the foundation of AWS Lambda is the concept of a trigger. A trigger is an event that causes your lambda function to be invoked or executed. An example of a trigger is a user request - when it hits Amazon API Gateway and the endpoint references a Lambda function, that function is invoked. Another way a Lambda function can be invoked is by a time-based event, similar to a cron job schedule. Amongst several uses of EventBridge, it also keeps track of schedules and triggers functions as necessary based on such schedules.

Amazon SNS

SNS is short for Simple Notification Service. It is a pub/sub for application-to-application and application-to-person messaging systems. It is serverless hence no need for installation of any kind. You only need to configure how you want to use it. We will be using it to send SMS to the users.

Bootstrapping the Project

Execute the following command in a console to clone the project and get started.

git clone https://github.com/charlallison/tenant-service.git

After the clone operation is completed, you should have a directory containing files as rendered in the image below:

Files, Folder Structure and Project components

serverless.yml - the single most important file in the project. This file contains the configuration that the Serverless Framework uses to interact with and deploy our project to our AWS platform via our account.
package.json, package-lock.json - contains information about dependencies for our project. These include the necessary AWS dependencies, TypeScript or Node-project-specific packages used.
tsconfig.json, tsconfig.paths.json - contains configurations for the TypeScript compiler - remember, the project is written using TypeScript.
src - short for Source, refers to a folder containing source code.
lambda - contains lambda functions and related configurations
resource - contains code (in yml) used to set up our table in DynamoDB and other configurations like streams and indexes.

The serverless.yml file

I stated that the serverless.yml file is the most important file in the project. If that is the case, it is worth reviewing to understand its content.

Some important keys to note:

service: sets the name of the service - tenant-service here
package: packages function individually with their dependencies. However, it excludes dev dependencies.
provider
- name: specifies the name of the cloud provider - aws in this case
- profile: specifies the profile with which to interact with the AWS platform - the profile contains credentials for authentication and authorization.
tracing: enables distributed tracing for all lambda functions in the project and the API Gateway
functions: specifies lambda function config files. We will see more of this in the next sessions.
resources: used to specify resources used in the project. We only have the DynamoDB table as our resource in this project. Its definition and configuration are located in the database-table.yml file with the TenantServiceTable key
plugins: you can call these helper function for the serverless.yml file -
- esbuild: used to build the functions
- serverelss-iam-roles-per-functions: used to indicate that each function can have its permission or role instead of grouping all under one.
custom: All the keys mentioned are defined by the serverless framework but there could be cases where you want a user-defined key. The custom key is where you can define a user-defined key that can be used in the other parts of the file.

Entities

Entities are a representation of real-world objects as used in source code relating to the context. Of course, there is a relationship with the database in which they are stored. For the tenant service, we have three entities that we will be working with. They contain fields that hold data and that can be used in operations.

When working with DynamoDB it is a good practice to include fields or attributes that will be used for indexing - more on this later. The following are entities in the tenant service project and their respective fields. It is worth mentioning that the indexing attributes are made up of the application attributes.

Tenant
- application attributes: id, name, phone, status
- primary key: PK, SK
- index attributes: GSI1PK, GSI2PK
Property
- application attributes: id, city, state, address, cost, rooms, status
- primary key: PK, SK
- index attributes: GSI1PK
Payment
- application attributes: propertyId, tenantId, amount, paidOn, expiresOn
- primary key: PK, SK
- index attributes: GSI1PK

It is okay at this point to say we will be leveraging a strategy known as Single table design. This is a table design strategy where all of your data is saved to one table with no joins — more on this in subsequent parts of this article.

Three other files that contain very useful functions are the files in the /src/libs directory. These functions are used across the service and it makes sense to have a single reference point.

api-gateway.ts: has two-fold usage:
- enables schema validation with middy
- formats the response message for API gateway service.
aws-client.ts: contains initialization code for AWS clients
lambda.ts: contains a middy function that chains body-parser, validator and error-handler middlewares.

Conclusion

We have looked at the project structure, some important files and AWS services used in this project. We now have an idea of its setup. In the next article of this series, we will look at the lambda functions and the necessary configurations needed to them deploy on AWS. Comments are certainly appreciated. If there are questions, I will try my best to answer them. I hope this was informative and thank you for sticking right on till the end.

Setting up for Serverless Development with AWS

Charles Allison — Mon, 30 Jan 2023 13:57:33 +0000

Introduction

Beginning serverless development requires that you have certain packages or software installed on your computer that make it easy to develop applications using the Serverless Framework. This article outlines the process of downloading and installing the various packages needed. You should already have an AWS account to continue with the steps below.

Step 1: AWS IAM - Programmatic Access

AWS IAM (Identity and Access Management) is an access and permissions management service provided by AWS with fine-grained control over what services and usability boundaries apply to an IAM account. One great feature of an IAM user account is that it is different from your root account therefore you can easily revoke permissions whenever you feel the need to. It is advisable to set up an IAM user account for use in your development environment instead of using your root account.

We are going to set up an IAM account with programmatic access only - such that this IAM user will be able to access AWS resources via API calls only.

Launch your browser and navigate to the AWS Management Console. Enter the word users in the search bar and then click on the Users with IAM Feature.

On the Users page, click on the Add users button - you will then be shown a page where you will enter a username.

After entering a user name, click on Next to set the permission for the user you are creating. Select the "Attach policies directly" option and check the "AdministratorAccess" policy.

At the bottom of the page, click on "Next" to review your settings and finally, click on the "Create User" button.

Click the newly created username and then select the "Security Credentials" tab. Locate the "Access keys" section on the same page and click on the "Create access key" button

To create your access keys, select the "Local code" option and agree by checking the proceed checkbox then click "Next".

Congratulations, your access keys have been generated. Copy these keys to a safe place because you will be using them in the next section.

Step 2: AWS CLI

CLI is an acronym for Command Line Interface and is typically a lightweight and text-based application that runs via the command line, where it draws its name from. You interact with a CLI using commands as specified by the developers of the CLI. One of the features of AWS CLI is creating a connection between your local development environment and your AWS account such that you can issue commands via the CLI that will be received and responded to by the corresponding AWS service through your AWS account. This typically means you don't need to visit the management console to perform these actions.

You can install the AWS CLI by following the prompts for your specific OS below.

Linux

Download the package as a compressed file - currently comes as a .zip extension and unpack the contents to an aws directory.

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" unzip awscliv2.zip

For users with ARM-based OS, you have to substitute the curl request above, for the one below.

curl "https://awscli.amazonaws.com/awscli-exe-linux-aarch64.zip" -o "awscliv2.zip"
unzip awscliv2.zip

Install by running the install executable file

sudo ./aws/install

macOS

Download and install using curl command

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"

Install using the command below - this installs the AWS CLI package to your root directory

sudo installer -pkg ./AWSCLIV2.pkg -target /

Windows

Download and execute using the command

 msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi

AWS CLI Version

After the installation has been completed, you can verify that it was done correctly by running the command aws --version. This will display an output of the current AWS CLI and its dependencies.

aws --version

Configure AWS CLI with Access Keys

You will now configure your AWS CLI with the access keys in Step 1. To do this you have to run the command aws configure --profile serverless-apps Place the respective keys when prompted by the CLI. You can allow the default entry for Default region name and format.

You should never share your access keys. You can quickly delete access keys that you think have been compromised in the Access Keys section and create a new one

Step 3: Node.js

Node.js is a runtime environment for executing JavaScript and TypeScript languages. You will be writing your applications in JavaScript or TypeScript therefore you have to download and install Node.js runtime. To download Node.js, I recommend downloading via NVM.

NVM

NVM is short for Node Version Manager. It is a tool that manages different versions of the Node.js runtime. With NVM, you can switch between versions of Node.js when necessary. For example, if Project A requires Node.js 14 and Project B requires Node.js 16, with NVM, you simply need to issue the command nvm use <version> to switch between Node.js versions for different projects seamlessly. See the commands below to download NVM.

Installing NVM

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

When either of the commands above is run via the Command Line, it downloads and runs a script that clones the nvm repository to a .nvm folder and thereafter attempts to add the line of code below to one of the profile files: [~/.bash_profile, ~/.zshrc, ~/.profile, or ~/.bashrc]

Profile file

export NVM_DIR="$([-z "${XDG_CONFIG_HOME-}"] && printf %s "${HOME}/.nvm" || printf %s "${XDG_CONFIG_HOME}/nvm")"
[-s "$NVM_DIR/nvm.sh"] && \. "$NVM_DIR/nvm.sh" # This loads nvm

After that is done and you have verified that the file was updated, you should close the Command Line and launch it. This is a way to get NVM to startup with its config. To verify that it was successfully done, you should enter the command nvm --version which will return the current version of NVM installed. I have included a snapshot of this command and the output. Ensure you have the same version number or higher.

NVM Version

nvm --version

If you face any issues with this installation, please refer to NVM README on Github.

Installing Node.js

After you're done installing NVM, you can then install Node.js via NPM. You can do so using the command below.

nvm install --lts

With this command, the NVM that's currently installed goes to work by downloading and installing the latest Node.js LTS (Long Term Support) version to your computer. After this is done, you can as well, run a command to ensure you have Node.js installed. This is done via the command node --version

Node.js Version

node --version

After issuing this command you should get an output that tells you the current version of Node.js installed on your computer.

Step 4: Serverless Framework

Serverless Framework helps you build, deploy and manage Lambda functions easily which in turn makes up your serverless application. To get started building a serverless application, you need to install this framework which is easily done by running npm install -g serverless.

Installing Serverless Framework

npm install -g serverless

To verify you have correctly installed the Serverless Framework, you should be able to successfully run the serverless --version or sls -v command. The output you get should be similar to the snapshot below on successful installation.

serverless --version

Serverless Version

With this, you have successfully installed the Serverless Framework. You can now start creating serverless applications using the Serverless Framework.

Code Editor

In developing serverless applications, you will be writing code. To aid in this writing, you need a code editor. A code editor is simply a text editor that's made specifically for authoring code. Many code editors support working with the Serverless Framework. Below is a list of some of the very popular ones you can choose from.

VS Code - Free
Sublime Text - Free/Paid
Jetbrains Webstorm - Paid
Jetbrains Fleet - Free
Notepad++ - Free
Bracket - Free

Select the one you are most comfortable with, paid or free and get cracking!

Conclusion

Congratulations! on getting to the end of this guide. Hopefully, you got similar prompts when verifying that you correctly installed any of the tools. There may be version number differences but that's perfect; it's proof you have a better version than I had when writing this article. You are now ready to get busy, developing those great serverless apps.

Happy serverless coding!

Here's Why You Need a Mentor

Charles Allison — Wed, 04 Jan 2023 13:00:13 +0000

This blog was first published in 2019, this is an updated version.

Self-taught Ninjas

Learning new software engineering concepts has never been easier. Someone new to Software engineering or any other skill can pick a course and in a few hours gain a good understanding of the concept. This has promoted lots of self-taught developers and indeed is a good thing as it shows a high level of commitment and self-motivation.

We all have learned a thing or two by ourselves and deserve applause 👏 for the commitment during the learning period and we must help others develop such attitude and tenacity towards learning because it is needed at different points in our careers.

However, as software engineers looking back at our careers, one would agree that having a mentor at some point would have been amazing. The learning or experience would have been super smooth if we had someone to guide us, share lessons learned, effectively make learning faster, someone who can help unblock us towards a goal. This is similar to a scenario where a junior engineer asks a senior a question and the response from the senior engineer is worth more (given the context) than searching online. While the junior could still motivate himself through this phase, it is essentially smarter to consult a senior who has been through the same phase to guide him accordingly.

Much learning is involved in the Tech industry and knowledge gained lasts as long as there are no updates which is barely the case🌚. Hence quick and effective learning becomes a necessary skill to have and one of the ways of achieving that is by having a mentor.

Want to get great at something? Get a coach - ATUL GAWANDE

I opted for professional coaching/mentoring some years back and it fundamentally changed my outlook on software engineering positively. Sometimes we feel some questions are irrelevant or mundane but a good mentor never misses a chance to explain or give guidance where it seems necessary. Given what I know now, I only wish I had it a lot earlier in my career; hence the reason for this blog post.

Benefits of Having a Mentor

Some of the benefits of having a mentor include:

Learnings are Faster
Focus is Improved
Hidden ideas become Obvious
Improve Your Skill
General Guidance

💨Learnings are Faster

A mentor with experience in an area provides an opportunity to rely on their wealth of knowledge. Consider learning a new framework all by yourself for the first time. Then compare that to learning under someone who is already an expert in the given framework. You will agree the latter will be faster and straight to the point. Learning anything Tech related can get overwhelming. However, with a mentor, you can gain insight worth several years of experience in a relatively short time than would have been possible. In this case, the mentor knows the various information you need per context and can bring it all together in one simple yet profound instruction or comment.

🎯Focus is Improved

We would agree that there are lots of information sources: articles, blogs, online courses, etc. that are available in the tech industry. The irony about this is; it makes it a bit difficult to pick one that solves your exact need. This could cause derailing from the focal point of your study. With a help of a mentor, you can pick the exact resource that helps you learn better. This works like a 2-edged knife; the first is that the mentor is well-aware of the resource and can guide you through the seemingly tough areas and the second is that you go all in with a razor-sharp focus, clearing out the ignorance.

💡Hidden Concepts Become Obvious

When studying a concept for the first time, there is a tendency to ignore some parts, especially one that does not readily appeal to your understanding immediately or seems to not be so useful in the long run. When this happens, there is the likelihood of missing the lessons to be learned especially when they could be vital much later. A mentor having gone through the same subject can call your attention to that and cause you to spend some more time to gain that necessary understanding. This helps you realize the importance of the concept in your study and how it impacts your overall understanding. This also applies to important ideas that are not readily seen. Having a mentor can help you avoid such mistakes and greatly improve your career.

🎉 Improve Your Skill

A mentor can notice a missing skill in a mentee and thereby help the mentee to improve in that area. For example, a back-end developer without a practical knowledge of Docker or a Cloud Infrastructure engineer that provisions infrastructure via the management console only, repeatedly without the use of IaC tools like Terraform. Whatever the reason may be for the lack of skills, a mentor can call the attention of the mentee and this can cause improvement in that area.

General Guidance

Beyond technical guidance, a mentor can help in several other areas of your career; if you should take on a specific role, if you need to develop your soft skills - this is a very important skill to gain. If you need to be the change in a company or plan an exit. Whatever the reason, we would agree that getting help is better than spending all the time or being stuck.

Summary

This is by no means an exhaustive discussion of why you need a mentor. Please share your reason, if you will, why having a mentor can boost your career or how having a mentor has boosted your career.

My AWSome journey to the Cloud: the Cloud Resume Challenge

Charles Allison — Fri, 31 Jul 2020 20:38:31 +0000

Before the lock-down, I led a team of software developers in a project to be deployed in a private cloud. I had always handed over a project after I was done writing code because I have not been part of an IT team, so I really did not bother about deployment. That took a different turn in this project because not only was I responsible for code review, implementation strategy and software architecture, but for deployment and infrastructure (to some extent). I had successfully led the project to testing phase when the lockdowns came.

Well, I decided to solidify my knowledge of Kubernetes and to get on with one of the cloud providers; AWS it was and A Cloud Guru was my choice cloud trainer. As I learnt more about AWS cloud I became fascinated with how easy it was to put services together and get your app running in a short period of time given I had just worked on a private cloud project. I thought that was all the goodness the cloud could offer not until I met with serverless. With this new knowledge of serverless and AWS Lambdas, it was a fresh love for my career as a software developer.

I kept learning and decided to write AWS Cloud Practitioner exam in July. I was studying for my exams but just couldn't let go of the serverless concepts. I took the Serverless Concepts course on Linux Academy and several other serverless introductory courses on A Cloud Guru. I just couldn't get enough of serverless - I even nicknamed myself, Serverless Junkie - and with the goal of becoming a serverless Hero someday. I also connected with some AWS serverless Heroes.

I saw a post on LinkedIn that talked about one cloud resume challenge and its deadline was for July 31, 2020. After reading through the requirements, I decided for it. And, yes, I had to pass my earlier scheduled CLP exam - that was the first requirement.

It's a long read already so won't go into every aspect of the challenge but I won't forget my late nights with moto - the very beautiful Python mocking framework for AWS infrastructure and the one and only AWS SAM (Serverless Application Model) - sweet nights indeed. These tools are great because they make the work really easy...erm, after you understand how to use them. Yeah, I read lots and lots of blogs, documentation, github samples and in the end, I successfully completed the Cloud Resume Challenge.

I'm so thankful to Forrest Brazeal for putting up the challenge and causing many to learn and improve themselves. I am really grateful. Hopefully, I can work hard enough to becoming an AWS Serverless Hero. Until next time, it is bye from me and get on learning severless.

Here's the finished project for the challenge