Your First multi tier Serverless Architecture on AWS

Editor's Notes

• #2: Hi guys and girls. I’m Jeshan. welcome to Lambda TV where I explore serverless technologies on AWS
• #3: In this video, you’re going to learn how to set up your first multi-tier serverless architecture on AWS
• #4: You’ll learn about the services you’ll need and you’ll learn how to automate the setup. This presentation assumes that you have some experience deploying real-world apps before. To keep this tutorial to the point, I have omitted steps like how to setup the CLI so you must have a minimum of familiarity with AWS for you to get the most out of this video.
• #5: Traditional applications consist of 3 tiers: Presentation tier which represents the user interface, the logic tier which executes arbitrary logic and the data tier for storage.
• #6: You’ll learn about the prescribed multi-tier reference architecture from AWS. It is a whitepaper I read and would like to give you a walkthrough on how you can apply what’s written there.
• #7: A multi-tier architecture designed as discussed here can be used in many types of apps. Web app, especially one with a static frontend (where I’m going to focus in this video) Mobile app (I’ll leave that for a future video) Or even any kind of app that can make web requests.
• #8: In this architecture, it is AWS’s recommendation to use a front end that’s fully static. That is, it’s written only using HTML, CSS and JS. If you use PHP to generate html, then this system won’t work for you. Having a fully static website offers a lot of advantages, performance-related or otherwise; the server doesn’t have to dynamically generate the response, you can deliver your site to a global audience on a content delivery network, it can also be cached and compressed for you. So, back to AWS. You are going to host your frontend on S3 which is AWS’s main storage solution. Next, we’ll look at the 2 services for the logic tier. Next on to the logic tier...
• #9: First there’s API Gateway Amazon API Gateway makes it easy for you to deploy scalable and secure APIs. You define methods and resources just as you would in a REST api. Then you tell it which routes need to execute what logic that you have defined in Lambda functions. Then it gives you https endpoints that you can tell your frontend code to call. AWS Lambda Lambda is my favourite piece of technology currently. Essentially, it means that you upload some functions and with minimal configuration, it can run and scale as and when needed on your behalf. Lambda also encourages you to think of your applications as a decoupled set of microservices. There are no servers to run (hence the term "serverless") and you only pay for resources consumed while functions run. You can execute millions of requests for less than a dollar and there’s even a million calls that you are given free of charge every month… which is cool. If you have ever managed servers before, you know that it can be a pain to make sure your servers are always secure, or figuring out how to autoscale and even how to deploy applications at scale. Thankfully, if you use Lambda, you won’t have to worry about that anymore. You can make a lambda function run on many types of events, like uploading a file, running on a schedule or like in our case, hitting https endpoints. Now let’s look at the data tier..
• #10: 2 common options we have on AWS are Relational databases with AWS Relational Database Service (RDS) or NoSQL with DynamoDB. DynamoDB is AWS’s NoSQL offering that offers the performance we come to expect from AWS; high availability, performance and durability. There’s less administration required with it compared to a conventional relational database. Besides, it doesn’t require managing a server. We want a fully serverless solution, so we’ll go with DynamoDB for now.
• #11: In this demo, I am going to show you how to make a TODO app work on serverless. You will be able to view todos, create and make updates to them with CRUD operations. Tip: Choose a region and use it throughout this demo. I’ll be using eu-west-1.
• #12: The data tier Let me start with the data tier I’m going to show you how to setup the DynamoDB table. Our table called todo will consist of todos will consist of records that will look like the following; a completed flag to indicate that the TODO has been ticked, an ID and a title of the TODO
• #15: After a few seconds, your table will be created. Next on to the logic tier. You will recall that this consists of the API gateway and Lambda.
• #16: We will create our epic API with the API gateway. Go to https://console.aws.amazon.com/apigateway/home Create a new API by clicking Get Started:
• #18: An empty API will be created. We’ll get back to that later.
• #20: Choose the api that you just created. The select blueprint step will have many samples that you can use but skip to the Configure triggers step for this tutorial. Choose the api name that you created. Let’s leave the security open for now for simplicity. I’ll come back to it in a future tutorial.
• #21: Enter a name. We’ll use a function written in Node.js. And you’re going to paste an example code further below.
• #22: Let’s step in that code for a minute… It’s available at the link shown
• #24: I tell lambda that I’ve finished doing the server side logic with a call to the context.succeed function. Take a few minutes to understand how this works. For example, you may want to check out how the docClient object is used to make operations on DynamoDB. Let’s move on with the Lambda function creation.
• #26: This should successfully create our function.
• #27: Save this endpoint; we’ll need it soon in our web application.
• #28: Before proceeding, our microservice needs an additional permission that wasn’t added automatically for us, i.e the ability to batch write on to a dynamodb table. We need this permission to be able to delete several TODOs at once in our demo app.
• #29: Let’s add the permission quickly using the Identify and Access Management console. If you used multi-tier as role name, you can find the role directly with the link shown
• #31: One final thing before proceeding to the front end: Our demo is calling the microservice asynchronously from a web app. So, we need to enable CORS for browsers to allow it. Back to our API in the API Gateway.
• #34: Now, we’re ready to connect our frontend to our API.
• #35: Remember that our endpoint for our API is something like the one shown. Now, we need to tell our frontend to use it. The javascript file that is of interest to us is found at the github link on the screen
• #37: Now it’s time to upload your website to Amazon S3 where’ll you host your frontend code.
• #38: Create a bucket. Choose a name that suits you. If you want to use your own domain for the website (which you probably do), you must choose a name that equals that of your domain, e.g I own jeshan.co so I could choose multitier.jeshan.co.
• #41: Now we need to enable website hosting. Open properties for your bucket and use the settings as shown here:
• #43: Now to use your own domain, you want to setup a DNS CNAME record for your domain. For example, I enter multitier as host on my DNS config that points to the example link shown for my domain jeshan.co:
• #44: After you save and the DNS record propagates, your website should be available at your chosen domain. Congrats, you’re now done with setting up your first multi-tier serverless architecture on AWS!
• #45: I’d now like to cover a few topics on what I expected to find in the whitepaper but didn’t. For example, I’d love some automation. So how could I script this whole process?
• #46: Setting up the various tiers on the UI is cool but it makes it difficult to automate. I’m making a couple of Bash scripts available so that you can automate the process. 1-setup-data-and-logic-tier.sh 2-setup-presentation-tier.sh Available the link shown.
• #48: This is the Bash command to create a dynamodb table.
• #49: to upload the website you need these two steps...
• #50: There are some comments in there to help you find your way through it. Let me know in the comments if it doesn’t work for you.
• #51: If you’re not using AngularJS, you can use SDKs that can been automatically generated for you by API Gateway. At the moment, it supports the platforms iOS, Java, plain JavaScript and Android.
• #54: Here we have a very simple API; it’s just a CRUD. For a more involved API, I recommend you define the API with a tool called Swagger: it makes life easy for many reasons. We can import/export it into and out of api gateway. You can even use their editor web app to author your APIs.
• #55: I’ll cover Swagger in part 2 of this tutorial.
• #56: What the finished goods looks like:
• #57: You now have a basic multi-tier architecture up and running on AWS. It is completely serverless: You have a simple data tier running on DynamoDB that’s highly scalable without any maintenance needed. You have a logic tier set up with API gateway and Lambda that are billable as and when used. You have a static website that’s highly performant running on just a couple of cents per month. So, I hope you liked it. Thanks for stopping by,
• #58: I want to acknowledge that this wasn’t an introduction to the various services. So, I didn’t cover the basics of api gateway, S3 and so on. I wanted to focus on showing you how to get a basic 3-tier up and running
• #60: Dynamodb, api gateway, step functions, lambda, codepipeline, codebuild, cloudformation, s3, cloudfront, xray, etc
• #61: Tell me what you’d like to see because I want to make this channel a valuable free resource about serverless on AWS. If you’d like me to keep you in the loop, click the subscribe button and I’ll send you more great serverless tutorials soon.
• #62: All the links mentioned are available on the blog as a written guide. Thanks for watching!