DEV Community: Maxime David

Rust on AWS App Runner - Part2

Maxime David — Tue, 05 Sep 2023 14:01:00 +0000

Hey hey hey 🍕!

This is the second part of this series, make sure you've already read the first part :)

In the first part, we saw how to create a basic Rust API with a GET /pizza endpoint to retrieve the list of pizza.

In this part, let's see how to containerize our app!

Let's create our container

Since AWS App Runner is a fully managed container application service, we definitely need a container!

In this section, we will see how to build that container thanks to Docker using a Dockerfile.

A Dockerfile is a text file that contains all the commands needed to build our container, it's often compared to a recipe.

Rust as the base image

Let's start with

FROM rust:slim-bullseye
WORKDIR /app
COPY ./ /app
RUN cargo build --release

The first line describes the base image that we want to use, here the official rust one.

This is really convenient since we don't have to install rust or cargo: both are already installed in this base image.

Then we define the current working directory, here /app

Then we copy our sources (src + Cargo.toml + Cargo.lock) into the container.

Finally we build our API directly inside the container, in release mode, to be sure to have a production-ready binary.

Great, we now have our binary ready in our image!

But wait, we also have rust, cargo and a bunch of useless tools at runtime.

It was convenient to use the official rust image to build, but we don't need it anymore for the runtime. Fortunately, Docker supports multi stage builds.

Multi-stage builds

We can specify a base image to build and another one to run! That's exactly what we want!

The idea here is to have the smallest possible image so the cold start would be extremely fast. That's why we are going to use a distroless base image.

Those images are built by Google and contain almost nothing: no bash, no ssh, no utility tools which makes the image extremely small.

Let's modify our Dockerfile:

FROM rust:slim-bullseye AS BUILD
COPY ./ /app
RUN cargo build --release

FROM gcr.io/distroless/cc-debian10
COPY --from=BUILD /app/target/release/app-runner-rust / 
CMD ["./app-runner-rust"]

Here we name our first image BUILD so we can reference that later. Then from the distroless image, we copy our binary from the BUILD image! Super convenient! I love Docker :D

Our runtime image is just the distroless base image + rust binary

Let's finally build it with docker build . -t maxday/app-runner

Let's check for our image size: docker images | grep maxday/app-runner

docker images | grep maxday/app-runner
maxday/app-runner                                          latest          e278afc78403   3 minutes ago    20.1MB

20.1MB!!! 🤯 Extremely small!

Woot woot! We now have a ready to deploy container!

Local test

Before deploying, let's make sure everything looks fine by running it locally and calling our GET /pizza endpoint.

You can run your newly built docker image with:

docker run -d -p 8080:8080 maxday/app-runner

-d means detached so the container runs in the background
-p 8080:8080 means that you're bridging the host port 8080 to the container port 8080.

You can check that your container is up and running with:

docker ps

docker ps
CONTAINER ID   IMAGE               COMMAND               CREATED          STATUS          PORTS                    NAMES
e5d8978ee6ee   maxday/app-runner   "./app-runner-rust"   53 seconds ago   Up 53 seconds   0.0.0.0:8080->8080/tcp   pedantic_kare

Now you can curl the endpoint:

curl http://localhost:8080/pizza

curl localhost:8080/pizza
[{"name":"Margherita","toppings":["tomato","fior di latte"],"price":10},{"name":"Veggie","toppings":["green peppers","onion","mushrooms"],"price":12}]

Awesome! 🎉

Our container is now ready to be used by AWS App Runner.

See you next week for the final episode of this series to deploy it!

Like this content? Consider following me for more!

A question? Feel free to use the comment section ⬇️

You can find me on LinkedIn, YouTube and Twitter!

Rust on AWS App Runner - Part1

Maxime David — Mon, 21 Aug 2023 14:36:51 +0000

Hey hey hey 🍕!

Over the past few months, I've been advocating for Rust on AWS Lambda a lot!

Here is a quick recap in case you missed it!

Live coding a AWS Lambda in Rust with TDD
Lambda-Perf tool where Rust is killing the cold start game

By the way, we're almost at 256 ⭐️ which is 🤯 for a side project! I'm sure we can do it!

Rust Linz Meetup where I gave a talk about Serverless + Rust

But as you may know, serverless is NOT only about AWS Lambda. If you need compute, AWS App Runner might be a great fit!

AWS App Runner

If you see Lambda as functions as a service you can see
App Runner as containers as a service.

It means that you can focus on

building your app
containerized it (ie: Docker image)

and AWS will scale it for you, including to zero.

It also means that you will experience a cold start when no containers are up or when you need to handle more traffic.

Similarly to AWS Lambda, Rust would be a great candidate for AWS App Runner if we manage to build a tiny container which starts extremely fast!

Annnnnnd that's what we are going to try to do in the series of blog post!

Ready? Let's gooooooo! 🎉

Part1 - Create a simple Rust API - this blog post
Part2 - Containerize it! (and make it small)
Part3 - Deploy it to AWS App Runner

Part 1 - Create a simple Rust API

In this part, we will focus on building a simple Rust service.

Let's bootstrap the project using cargo
and run cargo new pizza-rust --bin
(oh yeah we're going to talk about 🍕)

You should now have this file structure:

Dependency

There are multiple web framework crates in Rust but one the most commonly used is actix_web so let's use this one!

We're also going to need serde to serialize and deserialize our pizzas.

Finally, for testing purpose, we're going to use both actix-rt abd actix-test

main.rs

Our main function will look like this:

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(move || {
        App::new()
        .service(pizza_service)
    })
    .bind(("0.0.0.0", 8080))?
    .run()
    .await
}

Here we've defined a very minimal web server, listening on 8080 and using the not-yet-defined pizza_service

Test first!

Before going too far in the actual code, let's write our unit test first.
When we hit /pizza, we want to receive a JSON array of pizza.

#[cfg(test)]
mod tests {
    use crate::{pizza_service, Pizza};
    use actix_web::{App, web};

    #[actix_rt::test]
    async fn test() {

        // define a test pizza
        let pizzas = vec![
            Pizza::new("pizzaTest", vec!["topping0", "topping1"], 1234),
        ];

        // define our in-memory db
        let app_data = web::Data::new(pizzas);

        // define our test server
        let srv = actix_test::start(move || 
            App::new()
            .app_data(app_data.clone())
            .service(pizza_service)
        );

        // perform the request
        let req = srv.get("/pizza");
        let mut response = req.send().await.unwrap();
        assert!(response.status().is_success());
        let result_pizza = response.json::<Vec<Pizza>>().await.unwrap();

        // assert the result
        assert!(result_pizza[0].name == "pizzaTest");
        assert!(result_pizza[0].toppings == vec!["topping0", "topping1"]);
        assert!(result_pizza[0].price == 1234);
    }
}

Back to main.rs

Finally, let's modify our code to satisfy our test

// let's create our pizza structure, making sure we can serialize and deserialize it!
#[derive(Serialize, Deserialize)]
struct Pizza {
    name: String,
    toppings: Vec<String>,
    price: i32,
}

// simple Pizza constructor
impl Pizza {
    fn new(name: &str, toppings: Vec<&str>, price: i32) -> Pizza {
        Pizza {
            name: name.to_string(),
            toppings: toppings.iter().map(|s| s.to_string()).collect(),
            price,
        }
    }
}

// define our GET endpoint
#[get("/pizza")]
async fn pizza_service(data: web::Data<Vec<Pizza>>) -> impl Responder {
    //just returning the JSON representation of our pizzas
    HttpResponse::Ok().json(&data)
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {

    // our fresh pizzas
    let pizzas = vec![
        Pizza::new("Margherita", vec!["tomato", "fior di latte"], 10),
        Pizza::new("Veggie", vec!["green peppers", "onion", "mushrooms"], 12),
    ];

    // in-memory db
    let app_data = web::Data::new(pizzas);

    HttpServer::new(move || {
        App::new()
        .app_data(app_data.clone())
        .service(pizza_service)
    })
    .bind(("0.0.0.0", 8080))?
    .run()
    .await
}

That's it!
Our test is now passing:

cargo test
   Compiling app-runner-rust v1.0.0 (/rust)
    Finished test [unoptimized + debuginfo] target(s) in 1.27s
     Running unittests src/main.rs (target/debug/deps/app_runner_rust-46a4a4cb852eb0c3)

running 1 test
test tests::test ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s

Final check

Let's run our API with cargo run
and hit our endpoint curl -i http://localhost:8080/pizza

curl -i http://localhost:8080/pizza
HTTP/1.1 200 OK
content-length: 150
content-type: application/json
date: Sun, 20 Aug 2023 00:26:27 GMT

[{"name":"Margherita","toppings":["tomato","fior di latte"],"price":10},{"name":"Veggie","toppings":["green peppers","onion","mushrooms"],"price":12}]

Voila! 🍕

Our API is now ready to be containerized and that's the topic of the next blog post in this series!

👋 Stay tunned for part 2 next week!

You can find me on LinkedIn, YouTube and Twitter!

How I Discovered That the AWS Lambda Runtime Might Be Written in Go

Maxime David — Wed, 02 Aug 2023 18:28:23 +0000

Have you ever wondered how your Lambda function code is triggered?

Each runtime has to conform to the AWS Lambda runtime API.

In managed runtimes, you don't need to take care of that; that's the whole point of using a managed runtime! AWS takes care of that for you.

But how?

It's hard to say because it's not clearly documented. However, while I was conducting some unrelated experiments, I made a very cool discovery!
I think you'll find it interesting too!

If you're working with Go and care about performance, you might want to look at some important metrics, such as:

the number of allocations
the time taken for each init() functions

To do so, you need to setup a environment variable:

GODEBUG to inittrace=1.

And tada 🎉!

In addition to information about the binary I wanted to test, I'm now able to see traces from another binary, which seems to be the one from AWS that conforms to the runtime API.

Here is an example of the output 👀👀👀

init internal/bytealg @0.008 ms, 0 ms clock, 0 bytes, 0 allocs
...
init go.amzn.com/lambda/fatalerror @3.7 ms, 0.031 ms clock, 336 bytes, 2 allocs
...
init go.amzn.com/lambda/interop @6.5 ms, 0.023 ms clock, 1128 bytes, 32 allocs
init go.amzn.com/lambda/telemetry @6.5 ms, 0.067 ms clock, 16 bytes, 1 allocs
init go.amzn.com/lambda/core @6.6 ms, 0.007 ms clock, 224 bytes, 12 allocs
init go.amzn.com/lambda/rapi/rendering @6.7 ms, 0.086 ms clock, 16 bytes, 1 allocs
init go.amzn.com/lambda/rapi/handler @6.8 ms, 0 ms clock, 256 bytes, 2 allocs
init go.amzn.com/lambda/rapid @6.8 ms, 0.099 ms clock, 16 bytes, 1 allocs
...
INIT_START Runtime Version: nodejs:18.v9 Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:7d5f06b69c951da8a48b926ce280a9daf2e8bb1a74fc4a2672580c787d608206

Here, we can clearly see some explicit package names coming from AWS.

Another important thing to note is that those logs are output BEFORE the INIT_START log line, which provides further evidence that it might be how AWS Lambda is managing your code!

Voila! 🎉
What do you think?

You can find me on LinkedIn and Twitter!

Benchmarking Rust for Serverless

Maxime David — Fri, 14 Apr 2023 14:35:19 +0000

Let's start with two very important questions:

(1) Why should I care to benchmark Rust since it's already super fast?

That's the question we'll try to answer in this post!

(2) Will there be a 🍕 demo?

Of course, you know that I'm a true 🍕🍕🍕 lover!

What's so special about Serverless?

Benchmarking is not specific to serverless. But in serverless components, such as AWS Lambda functions, performance really matters for two main reasons:

Cold start duration (good news, Rust is really performant as you can see in my daily updated benchmark)
Runtime duration, as AWS is billing per millisecond.

Let's see how we can measure and improve this runtime duration using benchmarks!

What are we going to benchmark?

Let's take a very simple example:

a function which returns the pizza of the day. 🍕 (I told you)

We will compare two different implementations:

one with HashMap - std::collections::HashMap
one with Vec - std::vec::Vec

(if you don't know much about Rust, you might wish to take a look at some basic Rust code before we start, like the Rust book or my Rust Youtube channel 😇)

First, let's define our PizzaStore trait:

pub trait PizzaStore {
    fn get_pizza_of_the_day(&self, day_index: i32) -> &str;
}

And our first implementation with HashMap:

// let's make sure we don't initialize a new HashMap each time
pub struct PizzaHashMap<'a> {
    cache: HashMap<i32, &'a str>, 
}

impl<'a> PizzaHashMap<'a> {
    pub fn new() -> Self {
        PizzaHashMap {
            cache: HashMap::from([
                (0, "margherita"),
                (1, "deluxe"),
                (2, "veggie"),
                (3, "mushrooms"),
                (4, "bacon"),
                (5, "four cheese"),
                (6, "pepperoni"),
                // what's your favorite?
            ]),
        }
    }
}

impl<'a> PizzaStore for PizzaHashMap<'a> {
    // let's get the pizza of the day from the cache (HashMap)
    fn get_pizza_of_the_day(&self, day_index: i32) -> &str {
        match self.cache.get(&day_index) {
            Some(&pizza) => pizza,
            None => panic!("could not find the pizza"),
        }
    }
}

Writing our first benchmark

There are quite some crates to create benchmarks but we'll use criterion here.
Let's start by creating a benches folder containing a benchmark.rs file and add our first criterion:

fn criterion_hashmap(c: &mut Criterion) {
    let mut rng = rand::thread_rng();
    // we create the cache outside of the bench function so only one HashMap will be created
    let pizza_store_hashmap = PizzaHashMap::new();
    // we call get_pizza_of_the_day with a random day index
    c.bench_function("with hashmap", |b| b.iter(|| pizza_store_hashmap.get_pizza_of_the_day(rng.gen_range(0..7))));
}

We also need a bench group (as we will add more criterion later)

criterion_group!(benches, criterion_hashmap);
criterion_main!(benches);

That's it! Let's run it with cargo bench

By default, it runs our function for about 5seconds (that's about 300M+ iterations)

     Running benches/benchmark.rs (target/release/deps/benchmark-2f28819806c8c7c9)
with hashmap            time:   [13.069 ns 13.090 ns 13.114 ns]

Left and right values are lower and upper bounds.

The number in the middle is the best estimation on how long each iteration is likely to take.

Note that those 3 numbers are extremely alike. This won't be the case if you're depending on networking for instance.

Second implementation: with Vec

Let's create a different implementation using Vec instead of using HashMap using the following code.

pub struct PizzaVec<'a> {
    cache: Vec<&'a str>
}

impl<'a> PizzaVec<'a> {
    pub fn new() -> Self {
        PizzaVec {
            cache: vec!["margherita","deluxe","veggie","mushrooms","bacon","four cheese","pepperoni"],
        }
    }
}

impl<'a> PizzaStore for PizzaVec<'a> {
    fn get_pizza_of_the_day(&self, day_index: i32) -> &str {
        match self.cache.get(day_index as usize) {
            Some(&pizza) => pizza,
            None => panic!("could not find the pizza"),
        }
    }
}

Let's create a new criterion so we can compare (that's the goal of benchmarks!)

Back in benchmark.rs we can add

fn criterion_vec(c: &mut Criterion) {
    let mut rng = rand::thread_rng();
    let pizza_store_vec = PizzaVec::new();
    c.bench_function("with vector", |b| b.iter(|| pizza_store_vec.get_pizza_of_the_day(rng.gen_range(0..7))));
}

and update our group to include this new criterion:

criterion_group!(benches, criterion_hashmap, criterion_vec);

so we can re-run our benchmarks with : cargo bench

and check the result!

with hashmap            time:   [13.096 ns 13.117 ns 13.141 ns]
with vector             time:   [7.5832 ns 7.5958 ns 7.6097 ns]

By replacing our HashMap with a Vec, our program is now running almost twice as fast!

This is a great reminder on how the data structure choice is really important depending on the use case 😇

Ok great, but how does it translate to Serverless?

Two AWS Lambda Functions have been deployed embedding each one of the implementations.

Each lambda function calls 10_000_000 times get_pizza_of_the_day

In us-east-1 with 128MB, here are the results:

Implementation	Runtime duration
HashMap	267.92 ms
Vec	87.98 ms 🤯🤯

That's it!

Of course this was a simple example but I hope I've convinced you to use benchmarks to optimize your code!

Bonus question: where does this overhead come from?

Stay tuned for the next blog post about Rust profiling!

❤️ ❤️ ❤️ Did you like this content? ❤️ ❤️ ❤️

Follow me on LinkedIn & Twitter
Check my Rust Youtube channel
Share with your friends <3

RUST: How to test println!() ?

Maxime David — Tue, 22 Nov 2022 21:07:02 +0000

Let's say we want to test that a function is correctly outputting something.

Our function may looks like this simple example: print n times the name given in parameter.

fn greeting(nb: i32, name: &str) {
    for _ in 0..nb {
        println!("hi {}", name);
    }   
}

How to test it? 🤔 It looks hard.

One easy way is to refactor our code using a Trait.
You can see Traits as interfaces.

trait Logger {
    fn log(&mut self, value: String);
}

Then, let's define a struct which implements this trait.

struct ConsoleLogger;

impl Logger for ConsoleLogger {
    fn log(&mut self, value: String) {
        println!("{}", value);
    }
}

Great! Now we can refactor our greeting function to use this trait.

fn greeting(nb: i32, name: &str, logger: &mut dyn Logger) {
    for _ in 0..nb {
        logger.log(format!("hi {}", name));
    }
}

Ok but how this is helpful for testing?

Well, now, in tests, we could define a new struct with a different implementation for our trait.

Here, instead of outputting our strings using println! we will store those in a Vec<String>
This way, it will be super easy to assert that our values are valid.

struct TestLogger(Vec<String>);

impl Logger for TestLogger {
        fn log(&mut self, value: String) {
            self.0.push(value);
        }
}

And we can finally test:

#[test]
fn greeting_test() {
    let mut test_logger = TestLogger::default();
    greeting(2, "maxday", &mut test_logger);
    assert_eq!(2, test_logger.0.len());
    assert_eq!("hi maxday", test_logger.0[0]);
    assert_eq!("hi maxday", test_logger.0[1]);
}

Voila! 🎉

Full code here: https://gist.github.com/maxday/ae3c9f219c35c228dadd5359def5a833

🚀 🚀 🚀 If you want more Rust, feel free to check my new YouTube channel here: https://youtube.com/@maxday_coding