00:00:00
All right, so I'm going to get started. This is Jets, a Ruby serverless framework. I'm going to talk about a tool I created.
00:00:05
As is traditional, the first slide is an introductory slide: who I am and what I do. My name is Tung Nguyen, and I currently run a consultancy company called Bull Ops.
00:00:11
You can see the logo up there in the top left corner. We focus on device software and infrastructure.
00:00:17
I have been fortunate enough to create a variety of tools, which are represented by the icons you see on the slide.
00:00:28
These tools range from Elastic Beanstalk to CloudFormation and ECS deployment, to name just a few.
00:00:34
It was quite an honor to be recognized as a container hero by AWS, as there were only five of us in the world in that category.
00:00:47
But today, we're going to focus on Jets, the Ruby serverless framework. One thing I'd like to point out is that, having worked extensively in the container space, I have a good appreciation for when to use containers versus serverless technology.
00:01:00
Now, the reason we're here today is because in November 2018, AWS officially released Ruby support as a runtime for Lambda.
00:01:14
This was a significant deal because, prior to this, Ruby was not an official runtime and developers had to bolt on support themselves.
00:01:26
This update placed Ruby among the first-class citizens in the serverless world. For me, it felt like a Christmas present. I even took a picture at re:Invent in front of the big stage, and I literally screamed when they made the announcement.
00:01:39
This kind of excitement for the Ruby community felt like the release of a new version of Ruby back in December.
00:01:44
For me, this was very big news.
00:01:49
I thought a good way to introduce the serverless world to this group would be to talk about some essential aspects of AWS and the compute offerings that exist today.
00:01:55
On the left side is EC2, which is a regular virtual machine that you can spin up. It takes about two to three minutes to set up.
00:02:06
You press a couple of buttons or call an API to create a machine, and then you can install anything you want on it and manage that server yourself.
00:02:12
As you move from left to right in the offerings, the level of management you have to do decreases.
00:02:20
ECS, or Elastic Container Service, allows you to run Docker containers easily on EC2 instances.
00:02:31
You don't have to manage much yourself, and on the far right, we have AWS Lambda.
00:02:39
That's what we'll focus on today. What is AWS Lambda? I put quotes around 'serverless' and a happy face because people call it serverless.
00:02:45
The term became very popular, but I think it's a bit misleading because, in order to run serverless technology, you actually need servers, so it’s somewhat of an oxymoron.
00:02:56
One definition you can think of is that it's functions as a service.
00:03:03
Essentially, it allows you to run code without managing servers; you give AWS your code, and they handle how to run it.
00:03:16
There are some benefits to using AWS Lambda. One major benefit is that you don't have to manage servers yourself; you don't have to do system upgrades or worry about security updates.
00:03:26
A team of AWS engineers handles all of that for you. You can focus solely on your code.
00:03:39
It scales on demand, depending on how many requests you send it. When EC2 introduced auto-scaling, I thought that was a remarkable feat of engineering.
00:03:56
You just configure some auto-scaling policies, set some alarms and rules, and then your system can automatically scale up and down.
00:04:09
With serverless technology, that scaling occurs automatically. You don’t have to configure anything; it just happens seamlessly.
00:04:20
Another benefit is that you only pay for requests. With AWS Lambda, the pricing model is particularly interesting: you only pay for the requests you send.
00:04:32
If you fit within the free tier, which is about a million requests a month, you can run your code for free.
00:04:41
That's a pretty appealing model. Of course, there’s also a lot of hype surrounding serverless and its benefits.
00:04:53
However, let’s address some of the hype. The term 'serverless' can be misleading at times.
00:05:03
Now, let’s talk about some considerations and limitations regarding why serverless might not always be the best fit.
00:05:14
When you configure a Lambda function, you allocate between 128 megabytes of RAM and up to 10 gigabytes.
00:05:26
A typical Ruby process, say a Puma server, usually requires about 500 megabytes. If you multiply that by the number of threads, that creates another concern.
00:05:38
But with Lambda’s self-scaling technology, you're not managing threads; it self-scales based on allocations.
00:05:53
Your main concern is making sure your Ruby process does not consume more than three gigabytes.
00:06:02
If you do have a Ruby process consuming more, you're likely encountering other issues.
00:06:11
Now, looking at CPU, the processing power you get correlates directly to the memory you allocate.
00:06:20
The more RAM you allocate, the more CPU power you gain. At around 1.5 gigabytes, you can get multi-core support.
00:06:29
Most applications use memory-bound resources within Ruby, so CPU usually isn’t a bottleneck unless you're doing specialized tasks.
00:06:37
Another consideration is the network speed. If there’s an issue here, you may notice slower performance.
00:06:46
Now, let’s discuss duration limits. The maximum time a Lambda function can run has been increased to 15 minutes.
00:06:53
For web applications, if your users are waiting for a response for 15 minutes, they’re likely long gone.
00:07:04
So unless you're running a long-running process, this is not really a concern.
00:07:12
Now, another consideration specifically for Ruby projects involves storage constraints. Your application can occupy up to 250 megabytes on the runtime file system.
00:07:24
This includes libraries and dependencies. If your total dependencies are, say, 100 megabytes, that leaves you with only 150 megabytes for application code.
00:07:37
This can indeed be a constraint, and something to monitor closely.
00:07:45
It’s possible that AWS might increase this limit in the future as they continue to improve services.
00:07:57
Next, let’s talk about the so-called cold start issue.
00:08:02
When a request comes to AWS Lambda, a container spins up.
00:08:11
There’s an overhead penalty associated with the first invocation of a lambda function.
00:08:18
If you are using a minimal allocation, say 128 megabytes, the penalty could range from one to two seconds.
00:08:28
However, if you're using a more realistic amount of memory, like one and a half gigabytes, I've seen it take around 300 milliseconds for the cold start.
00:08:37
People often overemphasize this issue, but it reminds me of Rails' Russian Doll caching.
00:08:43
The initial request may have slower response times, but subsequent requests are much quicker.
00:08:59
In most cases, unless you are building large-scale applications, the cold start shouldn’t be a large concern.
00:09:10
Functions can be reused for a period of time; I've noticed that they stay warm for four or five hours.
00:09:20
To minimize this cold start issue, developers often use what is known as pre-warming.
00:09:31
One common pattern involves creating a Lambda function that periodically calls all your other Lambda functions with a dummy payload.
00:09:41
This approach helps to keep them warm, eliminating the cold start penalty.
00:09:53
Now, there’s more to serverless than just functions. Another component is API Gateway.
00:10:04
With API Gateway, you can think of it as a front door where users send requests.
00:10:11
API Gateway routes these requests to different Lambda functions.
00:10:20
When building RESTful APIs, the API Gateway becomes essential.
00:10:27
Users make requests via URL, and that gets sent to the associated Lambda functions.
00:10:34
These functions return responses through API Gateway, making it easy to build web APIs.
00:10:45
In addition to API Gateway, there's CloudWatch, which features various functions, including scheduled events.
00:10:58
Scheduled events allow you to call Lambda functions periodically.
00:11:05
At this point, let’s take a look at the essential components of the service.
00:11:13
Lambda acts as functions-as-a-service, API Gateway handles requests, and CloudWatch provides scheduled events and logging.
00:11:20
With all these components, you can build a substantial web API architecture entirely serverless.
00:11:31
Users access the API via endpoints, which then trigger Lambda functions to execute the necessary logic.
00:11:41
These Lambda functions can interact with backend storage, such as DynamoDB or RDS.
00:11:48
At the bottom are the CloudWatch events that trigger background jobs.
00:11:57
Next, let’s look at some actual serverless code.
00:12:04
One way to create functions is through the AWS Management Console.
00:12:11
You would click on the 'Create Function' button, assign a name, choose Ruby as the runtime, and create the function.
00:12:19
You’ll then be directed to the code editor, where you can write your application logic.
00:12:27
In the Lambda function handler, the part before the period is the file name, such as lambda_function.rb.
00:12:36
The portion after the period, such as lambda_handler, indicates the method that gets invoked.
00:12:42
The function receives two keyword arguments: 'event' and 'context'.
00:12:50
The function returns a hash structure comprising a status code and body.
00:12:57
You can also test your functions live through the console interface.
00:13:06
Now, let's turn to creating an API Gateway in the AWS Console.
00:13:13
Specify that you want to create a RESTful API and provide a name.
00:13:19
Once created, you'll have access to the API routes and the corresponding HTTP verbs.
00:13:27
For instance, you can create a GET request on the homepage and link it to a Lambda function.
00:13:35
Next, you would see a visualization of the request flow from the API Gateway to the Lambda function and back.
00:13:42
Now, let’s look at creating a scheduled event in CloudWatch.
00:13:49
Navigate to the rules tab, select scheduled events, and specify your target Lambda function.
00:13:55
You can specify details like frequency, such as executing every five minutes.
00:14:02
This allows for various automated jobs running in the background.
00:14:09
So, congratulations! We’ve had a crash course on serverless architecture.
00:14:17
We discussed Lambda, API Gateway, and CloudWatch.
00:14:23
In reality, most developers do not create all functions through the AWS Console.
00:14:31
Instead, we use frameworks to code in serverless environments.
00:14:43
What I developed, Jets, represents a system where you can easily manage your application infrastructure.
00:14:52
Now, let's look at some Jet’s code.
00:15:01
Here’s a simple function in Jets, which mirrors a typical Lambda function.
00:15:07
Next, we have a Jets controller, which may look familiar.
00:15:15
Here we have an application controller from which all controllers inherit.
00:15:22
This controller contains public methods that translate into Lambda functions.
00:15:29
Jets evaluates the code, translating these public methods into Lambda functions.
00:15:37
Additionally, it provides helper methods to render JSON or XML.
00:15:44
There’s also a 'params' helper which parses the event payload.
00:15:51
Now let’s look at the routes file, which resembles typical route files you may know.
00:15:59
This file forwards HTTP methods to the correct controller actions.
00:16:06
These routes eventually provision API Gateway resources.
00:16:14
You can also create scheduled jobs through jets that become CloudWatch rules.
00:16:23
Jobs can run asynchronously without blocking web requests.
00:16:31
The Jets framework creates all necessary resources efficiently, allowing developers to focus on the coding.
00:16:39
So let's quickly revisit the components: methods in Ruby are converted into Lambda functions.
00:16:45
Routes get translated to API Gateway resources, and jobs are scheduled through CloudWatch.
00:16:52
The overall structure is quite traditional, following MVC design.
00:17:01
There are controllers, helpers, models, and views where applicable.
00:17:09
So you can see that Jets allows for a more productive and simplified experience.
00:17:17
The Ruby language enhances this productivity, as it remains concise.
00:17:29
With simplicity in the setup, you can create complex applications.
00:17:35
So let's move on to the live demo portion. I’ll perform a live demonstration today.
00:17:44
For the demo, I will go to the documentation and copy some commands.
00:17:50
Let’s start by creating a new Jets project. I’ll run the command to initialize a new demo.
00:18:00
This command generates a starter project with all the necessary files.
00:18:06
Additionally, Jet performs a bundle install to set up dependencies.
00:18:12
Once the installation is complete, I can show you the structure of the generated files.
00:18:20
Inside the app folder, we have controllers and routes created.
00:18:26
Next, I will generate scaffolding for a simple application using Jets.
00:18:36
This command will create all necessary resources for a basic RESTful API.
00:18:45
You can see a simple post controller has been generated.
00:18:52
The controller exposes basic RESTful methods that map to Lambda functions.
00:18:59
Once these resources are created, I can run a local server for testing purposes.
00:19:06
I’ll bind this to a local environment for demonstration.
00:19:14
As I run this server, I can navigate through the created scaffold and test its functionality.
00:19:22
I’ll demonstrate some CRUD operations using this interface, editing and creating new posts.
00:19:30
Now that the server is running, you can see the API responding.
00:19:38
Once I introduce the URL endpoint to the API Gateway, I can hit the endpoints.
00:19:47
I will show that all operations hookup correctly with the backend.
00:19:55
It’s functioning well, allowing for basic CRUD operations on my newly scaffolded resource.
00:20:02
This illustrates how simple it is to set up services using Jets.
00:20:09
We can leverage the AWS infrastructure while focusing on Ruby.
00:20:16
Let’s recap what we just accomplished.
00:20:23
We created an API Gateway that routes requests to Lambda functions, along with database integration.
00:20:30
This demonstrates how easy it is to combine these tools for a functional application.
00:20:38
Next, Lambda can be envisioned as glue code.
00:20:47
It serves as a connection point, coordinating various functions and resources.
00:20:54
You can glue together different events using AWS services to trigger Lambda functions.
00:21:02
Another use case is event-driven security and remediation.
00:21:10
For instance, you might want to close port 22 if it gets opened to the world.
00:21:18
You can create a CloudWatch rule that listens for changes and executes a Lambda function.
00:21:25
This function can automatically remediate the network security incident.
00:21:35
Next up, you can also integrate IoT devices with AWS Lambda.
00:21:44
Smart devices can send data through Lambda functions to execute custom logic.
00:21:51
For example, a smart kettle can send temperature readings and trigger actions.
00:22:00
Lastly, let’s look at scheduled jobs via CloudWatch events.
00:22:10
You can back up databases without needing dedicated servers for cron jobs.
00:22:20
This can greatly simplify resource management and scalability.
00:22:29
I will also mention the Jets resource model. The framework is built around easy resource creation.
00:22:38
Utilizing the adaptability of Ruby, developers can extend Jets as they see fit.
00:22:46
Realistically, programming with Ruby keeps the code concise and manageable.
00:22:54
Moving forward, I believe the future relies on frameworks like Jets to harness cloud capabilities.
00:23:02
Today, we touched on many concepts and tools available for serverless computing.
00:23:08
Now, I’m happy to answer any questions about Jets or Ruby serverless architecture.
00:23:15
If you have any queries about the framework or features, feel free to ask.
00:23:22
I appreciate any feedback or thoughts regarding the functionalities.
00:23:29
Thank you for attending; I hope you learned something valuable today.
00:23:36
I’ll now be around for the next ten minutes to answer any further questions.
00:23:43
Thank you again for your time.
00:23:50
I’m looking forward to discussing more about Jets and serverless frameworks.