The skill, we’re going to build is an expense tracking assistant called “My expenses”. The user can ask to add an expense record and state the amount and the category of the expense. The record will be then stored in AWS DynamoDB and associated it with an userId.

The following video gives a quick demo of what the finished product will be:

DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability. It requires no schema and can be used as a key-value or document-based store.

Skill will also require either an AWS Lambda ARN or a publicly available HTTP endpoint as a backend to process the logic behind the skill. We’ll be going with Lambda ARN, So we don’t need to run a server, and connect the skill via HTTP.

Creating a skill on the Amazon Developer Portal

1. Go to Alexa developer console https://developer.amazon.com/alexa/ and add a new skill named “My expenses”.
2. In the next screen “Choose a model to add to your skill” and pick the “Custom” option.
3. Create the Interaction model. The quickest way to configure the interaction model is through the “JSON editor” in developer console. Copy and paste the code below in the editor and save the model. This will gives you:
    — invocation name: my expenses
    — Intent AddExpense
    — Sample utterances.
    — Slots - Amount, Category

If you’re new to Alexa, please read more about Intents, Utterances, and Slots. So You’ll be able to understand the basics of Alexa.

Create Lambda function

We can write lambda function in any of these programing languages — (as of this writing ) Node.js, Python, Java (Java 8 compatible), and C# (.NET Core) and Go are supported. You can deploy the function either using AWS CLI or from AWS management console and configure Alexa to invoke the lambda.

You can also use a tool like “Serverless” — write your code, configure events to trigger your functions, and then deploy & run those functions to your cloud provider via the CLI provided by Serverless. Getting started with Serverless microservices with AWS Lambda.

For the purpose of this demo, I’ll be creating a serverless project with nodejs:

$ serverless create --template aws-nodejs

Serverless: Generating boilerplate...`

Open handler.js and update the code

serverless.yml

Deploy the lambda function with serverless deploy command and find its ARN. Go back to your Alexa developer console -> build -> Endpoint and update the AWS Lambda ARN.

Also don’t forget to update the alexa.appId = “amzn1.ask.skill.XXXX” value in your lambda function. (line 10, handler.js)

This will also create your Dynamodb table with the required permissions. You can learn more about serverless dyanamodb templating here. Behind the scene serveless.yml will be transformed in to a single Cloudformation stack, you can see them from AWS console -> Cloudformation.

AWS CLI credentials are stored in INI format in ~/.aws/credentials on a separate aws profile named serverless and serverless will pick the profile credentials during the deployment.

serverless.yml
profile: ${self:custom.profiles.${self:provider.stage}}
...
custom:
  defaultStage: dev
  profiles:
    dev: serverless
    prod: serverless

$cat ~/.aws/credentials
[serverless]
aws_access_key_id = XXXX
aws_secret_access_key = XXXX

Testing on your Echo

Now your code is ready and deployed, go try your skill out!

You can say “Alexa, open My Expenses” or just type in the words to fire your skill from Alexa developer console -> Test.

I hope you found this tutorial helpful. Please feel free to contact me, If you get stuck on anything. You can find the code at github.

Happy coding with Alexa ❤

We’ll be using the serverless framework — an open-source, application framework to easily build serverless architectures on AWS Lambda.

Prerequisites

• Node.js installed

$ node -v
v4.3.2

• Serverless framework installed — see here

$ serverless -v
1.10.2

• Install AWS CLI & create IAM Credentials — For the purpose of this demo, we’ll be using an IAM user policy with `AdministratorAccess` (Don’t do that for your production apps)

$ cat ~/.aws/credentials
[serverless-demo]
aws_access_key_id=XXXXX
aws_secret_access_key=XXXXX

Please note the AWS custom profile name is set to `[serverless-demo]` here. We’ll be using this profile in the next step.

Create the application

Let’s go ahead and generate the application template.

$ mkdir serverless-demo
$ cd serverless-demo
$ serverless create — template aws-nodejs
Serverless: Generating boilerplate…
 _______ __
| _ . — — -. — — . — . — . — — -. — — | . — — -. — — -. — — -.
| |___| -__| _| | | -__| _| | -__|__ — |__ — |
|____ |_____|__| \___/|_____|__| |__|_____|_____|_____|
| | | The Serverless Application Framework
| | serverless.com, v1.10.2
 — — — -’

Serverless: Successfully generated boilerplate for template: “aws-nodejs”
Serverless: NOTE: Please update the “service” property in serverless.yml with your service name

You’ll see the following files in your working directory:

#AppRoot/handler.js — By default template will provide a `hello` function handler.

‘use strict’;

module.exports.hello = (event, context, callback) => {
 const response = {
 statusCode: 200,
 body: JSON.stringify({
 message: ‘Go Serverless v1.0! Your function executed successfully!’,
 input: event,
 }),
 };

callback(null, response);

// Use this code if you don’t use the http event with the LAMBDA-PROXY integration
 // callback(null, { message: ‘Go Serverless v1.0! Your function executed successfully!’, event });
};

AWS Lambda can invoke this handler when the service executes your code. Handler signature has these three arguments.

• event — AWS Lambda uses this parameter to pass in event data to the handler.
• context — AWS Lambda uses this parameter to provide your handler the runtime information of the Lambda function that is executing. Ex: AWS requestId, logs, timeout values etc.
• callback — You can use the optional callback to return information to the caller, otherwise return value is null.

read more on function handler here.

#AppRoot/serverless.yml — Set the stage, profile, region parameters. The updated file should look like this.

service: serverless-demo
provider:
  name: aws
  runtime: nodejs4.3
  stage: dev # Set the default stage used. Default is dev
  profile: serverless-demo # The AWS credentials profile to use with this service
  region: us-east-1
functions:
  hello:
    handler: handler.hello

This is more than enough to test our setup. Let’s deploy our first function to Lambda.

$ serverless deploy
Serverless: Packaging service…
Serverless: Uploading CloudFormation file to S3…
Serverless: Uploading function .zip files to S3…
Serverless: Uploading service .zip file to S3 (409 B)…
Serverless: Updating Stack…
Serverless: Checking Stack update progress…
………
Serverless: Stack update finished…
Service Information
service: serverless-demo
stage: dev
region: us-east-1
api keys:
 None
endpoints:
 None
functions:
 hello: serverless-demo-dev-hello

Once completed, lambda function can be viewed from the aws console.

While the function doesn’t do anything other than printing a message, you can still test it by clicking the “test” action.

Creating the MicroService

Let’s create an example microservice, which has a RESTful CRUD API to manage book information. The book data will be stored on a DynamoDB table.

CREATE a new book — First we’ll need to add new handler to our application.

#AppRoot/books/create.js

‘use strict’;
const uuid = require(‘uuid’);
const AWS = require(‘aws-sdk’);

const dynamoDb = new AWS.DynamoDB.DocumentClient();

module.exports.create = (event, context, callback) => {
 const timestamp = new Date().getTime();
 const data = JSON.parse(event.body);

const params = {
 TableName: process.env.DYNAMODB_TABLE,
 Item: {
 id: uuid.v4(),
 title: data.title,
 price: data.price,
 author: data.author,
 createdAt: timestamp,
 updatedAt: timestamp,
 },
 };

// write the book to the database
 dynamoDb.put(params, (error) => {
 // handle potential errors
 if (error) {
 console.error(error);
 callback(new Error(‘Couldn\’t create the book item.’));
 return;
 }

// create a response
 const response = {
 statusCode: 201,
 body: JSON.stringify(params.Item),
 };
 callback(null, response);
 });
};

Let’s update the function definition in `serverless.yml` to point this new handler.

functions:
 hello:
 handler: handler.hello
 booksCreate: # A Function
 handler: books/create.create
 events: # The Events that trigger this Function
 — http:
 path: books
 method: post
 cors: true

This setup specifies that the booksCreate function should be run when someone accesses the API gateway at books/ via a POST request. Further the HTTP endpoints defined here, have cross-site requests enabled for all source domains.

Creating the DynamoDB Table

One thing I really like with Serverless framework is, by simply adding the aws resource configuration to serverless.yml we can bring up other aws resources like dynamodb tables, s3 buckets etc. Serverless Framework translates all syntax in serverless.yml to a AWS CloudFormation template — automagically.

Add DynamoDB config to serverless.yml

service: serverless-demo
provider:
 name: aws
 runtime: nodejs4.3
 stage: dev # Set the default stage used. Default is dev
 profile: serverless-demo # The AWS credentials profile to use with this service
 region: us-east-1
 environment:
 DYNAMODB_TABLE: ${self:service}-${opt:stage, self:provider.stage}
 iamRoleStatements:
 — Effect: Allow
 Action:
 — dynamodb:Query
 — dynamodb:Scan
 — dynamodb:GetItem
 — dynamodb:PutItem
 — dynamodb:UpdateItem
 — dynamodb:DeleteItem
 Resource: “arn:aws:dynamodb:${opt:region, self:provider.region}:*:table/${self:provider.environment.DYNAMODB_TABLE}”
resources:
 Resources:
 AppointmentsDynamoDbTable:
 Type: ‘AWS::DynamoDB::Table’
 DeletionPolicy: Retain
 Properties:
 AttributeDefinitions:
 -
 AttributeName: id
 AttributeType: S
 KeySchema:
 -
 AttributeName: id
 KeyType: HASH
 ProvisionedThroughput:
 ReadCapacityUnits: 1
 WriteCapacityUnits: 1
 TableName: ${self:provider.environment.DYNAMODB_TABLE}
functions:
 hello:
 handler: handler.hello

You can learn more about AWS resources configurations here.

Deploy to AWS

During the deployment, it will setup a DynamoDb table, an API Gateway endpoint and your CREATE function will be added to Lambda functions list.

$ serverless deploy 
Serverless: Packaging service…
…………………………………..
Serverless: Stack update finished…
Service Information
service: serverless-demo
stage: dev
region: us-east-1
api keys:
 None
endpoints:
 POST — https://XXX.execute-api.us-east-1.amazonaws.com/dev/books
functions:
 hello: serverless-demo-dev-hello
 booksCreate: serverless-demo-dev-booksCreate

That’s it. You now have your API Gateway endpoint to invoke the REST API call. Let’s add some book data.

Your DynamoDb table is named as `serverless-demo-dev`

Monitoring

AWS Lambda automatically monitors functions and these metrics include total requests, latency, and error rates is available through AWS CloudWatch.

You can find the complete source code in GitHub.
Happy coding ❤

Failover configuration can be either active-passive or active-active, if not you can also consider to go for a even more complex setup like active-active-passive or other mixed configurations with route53.

In this post, I’ll explain how you could build an active-active dns failover for your wep application spans over multiple aws regions.

At the end your setup should look like below.

As described in the diagram you will have 2 sets of app instances, each behind an elastic load balancer in two separate regions.

Active-Active failover is used when you want all of your app nodes in all regions to be available simultaneously, in this example both region 1 and region 2 are active. When one of the region becomes unavailable (This could happen due to application node crash, elb failures or even the region itself experiencing any problems), Route 53 can detect that it’s unhealthy and stop including it when responding to DNS queries.

I’ll be using the latency based failover for this setup. With latency-based routing, Amazon Route 53 can direct your users to the lowest-latency AWS endpoint available.

For demo purpose I’m going to deploy 2 demo web app in region us-east-1 and ap-southeast-1, each behind elb.

us-east-1

ap-southeast-1

Ideally the deployed application should be identical in both regions, but I think I said its a demo ;)

When setting up DNS Failover for an ELB Endpoint, you simply set Evaluate Target Health to true. DNS Failover for ELB endpoints is available at no additional charge — you aren't charged for any health checks.

In Route 53, create 2 records sets for each ELB endpoints as described here.

For ELB in us-east-1 (Region 1)

For ELB in ap-southeast-1 (Region 2)

Now when you access your application, you should get your resolved DNS based on the lowest latency. Since I’m living closer to ap-southeast-1, mine looks like this.

Now it’s time to see, if the failover works for real.

Let’s go ahead and stop the instances in ap-southeast-1. The ELB in ap-southeast-1 region now marks it instances as “Out of Service” and Route53 will begin to route traffic to the other healthy region — which is us-east-1.

This is a basic example of how you can use the Route53 DNS failover to detects the failures and route the traffic away from failed endpoint. Route53 evaluate the health of the load balancer and the health of the EC2 instances running behind in it.

If you want to try more complex scenario, check out the docs

— RR

Along with this expansion, SNS has also enabled the default “Opt-in” for recipients. Now the developers can deliver messages right away to recipient phone number without a prior opt-in. This will help in several occasions such as when sending OTP, MFA codes or any other direct publishing requirements in your application. As recipients, you can “Opt-out” your self by sending a SMS with “STOP” text.

AWS no longer use 30304 as the short code for SMS, instead it has a pool of short codes/long codes. However the SMS send from an AWS account will use the same code — mine was set to “NXSMS”. Ideally you can set your own Sticky sender ID, but unfortunately this doesn’t support in Sri Lanka yet.

Something really doesn’t work well is the pricing introduced for Sri Lankan carriers — Who to blame local carriers or AWS ? For Promotional text messages there is a lower rate, but still it’s way too expensive for a SMS.

But despite the cost, SNS/SMS comes with some rich set of features which doesn’t available right now from any local SMS API provider.

To send SMS you can either use AWS console or AWS API with delivery status, logging, usage reports, opt-out management etc — more on this here.

In general most web applications uses the local file system or Network Attached Storage (NAS) as the asset storage. Here is an example of a website using local file storage to host the assets.

In the example we have a web page located at http://domain.com/index.html with 2 images, a stylesheet and a javascript.

When a request is made to access the index.html, the web browser receives the response and parses the HTML, a DOM tree is built out of the HTML. However new requests are made to the web server for each new resource that is found in the HTML source (typically for all images, style sheets, and JavaScript files) — So as per this example there will be 5 requests to the web server.

List of HTTP requests from users browser to server

1. http://domain.com/index.html
2. http://domain.com/assets/logo.jpg
3. http://domain.com/assets/banner.jpg
4. http://domain.com/assets/stylesheet.css
5. http://domain.com/assets/javascript.js

The above approach works and there is nothing wrong about it, but this is not optimal.

Here is why — Consider a situation domain.com is a high traffic website. Higher the traffic the more is going to cost as you will need to scale up the servers to meet the demand. What if we move the assets to an external CDN? as per above example out of those 5 HTTP requests only 1 request will reach the nginx server — and all the other assets will be served from external CDN, saving the bandwidth, computing resources like CPU, RAM on the primary web server(s).

Another example is — If your apps are deployed on a load balanced environment with multiple web server instances, you will need to keep each instance up to date with static contents and things will be even messy with dynamic contents as you need to either copy the assets to all the nodes or use a shared storage. But with a CDN in place you will need to copy them into one place — your CDN.

That’s some theory inedeed — In my next post on CDN I’ll try and compare these two approaches and see if this really works — in terms of improved performances as well as cost savings.

If you do have any read heavy applications hopefully you must have experienced some sudden CPU spikes on your RDS MySQL read replicas.

If you’re running on a single read replica, chances are your read replica may not respond when the CPU hits 100%. The solution is to add more read replicas to your stack and distribute the read traffic evenly by enabling load-balancing. As of this writing MySQL RDS allows maximum of 5 read replicas per single master rds.

In general you can load-balance your MySQL read replicas from these logical layers.

• Application layer — Create multiple connection pools and distribute the read traffic between one or more read replicas.
• External proxy — Configure HAProxy[1] or MySQLProxy[2]

[1] http://www.haproxy.org
[2] https://dev.mysql.com/downloads/mysql-proxy/

Both these options requires some code level and server level configuration work. And these are the most well known methods to setup load-balanced environments.

There is however a quick and easy way — that is using the Route53 Weighted Routing. Let’s see how — the diagram below shows how the setup would look like once completed.

As per the diagram we have 2 application instances (EC2) and both these apps configured to connect with read replicas using a CNAME — read.db.yourdomain.com. We also have our master RDS with its 2 read replicas R1, R2 under same VPC.

For this we will be using a Private hosted zone for VPC on Route53, so the routing queries will not be public.

A private hosted zone determines how traffic is routed within an Amazon VPC. Your resources are not accessible outside the VPC. You can use any domain name.

Go to your Route53 on aws console and setup a new private hosted zone — example: db.yourdomain.com.

On your newly created hosted zone, create these CNAME records sets as described below.

Name: read.db.yourdomain.com
Type: CNAME
Value: my-rds-read1.us-east-1.rds.amazonaws.com
TTL: 0
Routing policy: Weighted
Weight: 0
SetId: read1

Name: read.db.yourdomain.com
Type: CNAME
Value: my-rds-read2.us-east-1.rds.amazonaws.com
TTL: 0
Routing policy: Weighted
Weight: 0
SetId: read2

That’s it — Route53 will now load-balance the DNS queries received to read.db.yourdomain.com between the 2 read replicas. You can also add more read replicas (up to 5) without changing your database connection endpoint on your apps.

Here is a very quick code extracted from one of a project I’m currenly working on. Here the uploaded .m4a audio files will be transcoded to HLS (HTTP Live Streaming) — m4a files will be first uploaded to a S3 bucket let’s call it “s3.audio.input”. Files will be saved on the root of the input s3 bucket s3.audio.input/{UUID}.m4a and transcoded HLS audio will be saved on s3.audio.output/hlsv4/{UUID}/index.m3u8

#### transcoder.rb #### 
class Transcoder < Message

  STATUS_SUBMITTED =  "Submitted"
  STATUS_PROGRESSING =  "Progressing"
  STATUS_COMPLETE =  "Complete"
  STATUS_CANCELED =  "Canceled"
  STATUS_ERROR =  "Error"

  def initialize(message)
    @message = message
  end

  def create
    uuid = UUID.new
    transcode_job_uuid = uuid.generate

    transcoder = Aws::ElasticTranscoder::Client.new(
      :access_key_id => "YOUR_AWS_ACCESS_KEY_ID",
      :secret_access_key => "YOUR_AWS_SECRET_ACCESS_KEY",
      :region => "us-east-1")

    #HLSV4

    options = {
      pipeline_id: "1432361831290-XXXXX",
      input: {
        key: "ACB685E9-8C3C-4E5D-A49A-8F3BB5298DDC-201509021233.m4a"
        },
      outputs: [
        {
          key: "hls_64k",
          preset_id: '1351620000001-200071',
          segment_duration: "10"
        }
      ],
      playlists: [
        {
          name: "index",
          format: "HLSv4",
          output_keys: ["hls_64k"]
        }
      ],
      output_key_prefix: "hlsv4/#{@message.id}-#{transcode_job_uuid}/"
    }
    job = transcoder.create_job(options)

    @message.update_attributes(
      transcode_job_uuid: transcode_job_uuid,
      transcode_job_id: job.data[:job][:id],
      transcode_job_status: job.data[:job][:status],
      state: Message::STATE_PUBLISHED)

  end

end

As you have already noticed, I’m using an UUID to keep track of the data submiited to S3, Trancoder pipeline with active record — (MySQL database).

The example above writes the resulting job data to active record object immediately after submit the job to transcoder service. job.data[:job][:id] is the uniqe identification (Usually looks like 1441177406727-xxxxx) returned from AWS which you can use for further querying the transcoder API and get the details of the submited job.

@message.update_attributes(
      transcode_job_uuid: transcode_job_uuid,
      transcode_job_id: job.data[:job][:id],
      transcode_job_status: job.data[:job][:status],
      state: Message::STATE_PUBLISHED)

You can also configure Elastic transcoder to work with SNS. AWS transcoder service will trigger SNS notifications to a predefined topic based on these events.

• On Progressing Event
• On Warning Event
• On Completion Event
• On Error Event

For example once the transcode job is finished SNS will notify the status of the job to an endpoint you have configured on your SNS topic.

Hope this helps — Happy coding :)

— RR

Install nvm — Let’s clone the nvm repository

$ git clone https://github.com/creationix/nvm.git ~/.nvm

Update your profile config file — Depends on what you use .bashrc , .zshrc or .profile you need to add this line. Mine is a .zshrc

$ echo "source ~/.nvm/nvm.sh" >> .zshrc

Find the list of nodejs versions out there

$ nvm ls-remote

Your output would looks like

v0.1.14
v0.1.15
v0.1.16
v0.1.17
…..
v4.1.1
v4.1.2
v4.2.0
v4.2.1
v5.0.0

Install the required version of your choice — I’m going to go for the latest stable version here

$ nvm install v5.0.0

This will install both nodejs v5.0.0 and npm. Let’s verify

➜ ~ node -v && npm -v 
v5.0.0
3.3.6

Additionally you can set the default nodejs version using

nvm alias default 5.0.0

And we’re ready — Happy coding :)