DEV Community: Darko Mesaroš ⛅️

[Boost]

Darko Mesaroš ⛅️ — Fri, 27 Feb 2026 18:01:22 +0000

Laura Salinas for AWS

Feb 27

Predicting Your AI Agent's Cost

#aws #ai #agents #beginners

Comments

5 min read

Learning Rust: Custom Error types that actually work!

Darko Mesaroš ⛅️ — Mon, 17 Nov 2025 22:56:01 +0000

TL;DR: GITHUB REPO. Tired of writing the same verbose error handling boilerplate in your Axum handlers? Me too! 🙄 By creating a custom AppError newtype that wraps anyhow::Error and implements IntoResponse + From<E>, you can ditch all those ugly match statements and embrace the beautiful ? operator. Your handler functions go from messy error-matching shenanigans to clean, readable code that automatically converts any error into proper HTTP responses. It's like magic, but with more crabs! 🦀

Recently I've been digging a lot into the axum crate for any of my Rust web projects. There are plenty of options out there for Rust web applications, but it seems that we have all settled on Axum as the go to crate. Before you even start reading this, if you have not checked it out yet - do so now ... I'll wait.

Okay, you're back! Love it? YES! 🥳 Now, let's talk about a learning project I am working on. Ever since I've discovered htmx I've been immersing myself in the world of web development with HATEOAS as my priority. Just the neatness of using hypermedia gives me a rush, and helps me with all that JavaScript fatigue. I do suggest you go and give hypermedia systems a read, a thing I have been doing over the past couple of weeks.

So, in the spirit of this book, I was following along with building some hypermedia driven system. But instead of using Python and Flask as stated in the book, I've opted to put my crab hat on, and do it in Rust. Like the big boy I am. In this post I wont explain how I did that (link to a post from the future will go here), but rather explain how I used the amazing features of Rust to eliminate a lot of boilerplate code on my side.

Errors Errors

In order to be a good web builder, you want to make sure to return the proper HTTP status codes. (I'm looking at you 200 OK with an error message). So in my handler functions I make sure to explicitly return the Status code as part of my return tuple. Something like so:

Ok((StatusCode::OK, Html("<h1>Hello World</h1>")))
// Or an Error:
Err((StatusCode::INTERNAL_SERVER_ERROR, format!("Error processing hello world")))

This would signal back to the user (and axum) that the request was either 200 OK, and here is the HTML, or 500 Internal Server Error and an angry string. Nifty!

With the glory of Rust's Result enum, we are equipped to handle any errors our back end may throw at us. So, I just match on call that can fail, and return something back depending on that Result.
In practice, say in this handler function that finds a Contact by its ID in the database, it would look something like this:

#[axum::debug_handler]
async fn get_edit_contact(
    State(state): State<AppState>,
    Path(id): Path<i64>,
    // The function signature tells us what we expect back
) -> Result<(StatusCode, Html<String>), (StatusCode, String)> {

    // This call can fail so let's match its Result
    let contact = match Contact::find_by_id(&state.db, id).await {
        // We're good return back the `Contact` into the `contact` variable
        Ok(contact) => contact, 
        // We're NOT good, return the tuple with a status code of 500
        Err(e) => {
            return Err(
                (
                StatusCode::INTERNAL_SERVER_ERROR,
                format!("Failed to find contact: {e}")
                )
            )
        }
    };

    let edit_template = EditContactTemplate { contact };

    // This can also fail, but we dont need to store it into a variable,
    // we just need to return.
    match edit_template.render() {
        // Looks good, return the HTML and 200 OK
        Ok(html) => Ok((StatusCode::OK, Html(html))),
        // Again 500 Bad, be angry here
        Err(e) => {
            Err(
                (
                StatusCode::INTERNAL_SERVER_ERROR,
                format!("Failed to render template: {e}")
                )
            )
        }
    }
}

That is a lot of boilerplate code. While I do enjoy the verbosity of Rust (makes me feel all safe and cozy), this gets real old real fast. Especially when you have multiple handler functions, that invoke multiple different calls that can fail. Let's bring in another amazing feature of rust the newtype pattern, and simplify this 👏

Building my own Error type

I wont go too much into newtypes, as there is an excellent guide that I encourage all of you to read. Simply put, they are thin wrappers that allow you to extend functionality of existing Types not native to your crate. And I am gonna use it to extend the implement the IntoResponse trait into a type I dubbed AppError. And then allow it (what ever the Error is) to be converted into anyhow::Error.

Let's first create this wrapper newtype:

pub struct AppError(anyhow::Error);

Here I am wrapping anyhow::Error into a new type called AppError. I could do the same for any other type, and just create a wrapper around it (ie. a Vec<T> wrapper: struct Wrapper(Vec<T>)). Now comes the fun part, implementing certain traits.

To implement the IntoResponse trait from axum into this new type, we only need to implement the into_response function, which needs to return a Response<Body> type. Let's look at some code:

impl IntoResponse for AppError { // 1
    fn into_response(self) -> Response { // 2
        (StatusCode::INTERNAL_SERVER_ERROR, self.0.to_string()).into_response() // 3 
    }
}

And just like that we've implemented our own way of returning an error response from a handler function. Let me explain the code a bit:
1) The implementation block for IntoResponse for AppError
2) This is the only function needed for IntoResponse and we are simply returning a Response from the axum crate
3) We just return a tuple of a StatusCode and a String coming from element 0 of the AppError struct. Oh, and convert all that into a Response

Here is a bit more complicated version of the same code, this one uses a templating engine to return some nicely formatted web pages. This version just expands the above, but should demonstrate that this all works really nicely with the rest of your codebase.

impl IntoResponse for AppError {
    fn into_response(self) -> axum::response::Response {
        // Returning a HTML page for an error
        let template = Error5xxTemplate { // 1
            // Select element 0, as that is our anyhow::Error string and convert it so it works with our template
            error: self.0.to_string(),
        };
        match template.render() { // 2
            // If the template render is successful, return the HTML page with the error
            Ok(html) => (StatusCode::INTERNAL_SERVER_ERROR, Html(html)).into_response(),
            // The render has failed catastrophically - just return some string
            Err(_) => (StatusCode::INTERNAL_SERVER_ERROR, "Internal Server Error").into_response(),
        }
    }
}

Okay, there is a lot more going on here. Most of it is the same as before, but let me break it down:

1) Somewhere in my code base I have a Error5xxTemplate struct that I use with the askama templating crate
2) I make sure the template renders okay, if so - return the 5xx error page, if not I just give a 500 error and the string back.

Now that we have an IntoResponse implemented. Let's give our AppError the ability to take errors from anywhere.

Converting other error types

To make AppError a bit more flexible, I wanted to be able to automatically convert any* (*I'll come back to this in a bit) error type. Let's look at some code and make sense of it:

impl<E> From<E> for AppError // 1
where
    E: Into<anyhow::Error> // 2 
{
    fn from(err: E) -> Self { // 3
        Self(err.into())
    }
}

We are taking advantage of a very powerful crate here, anyhow. Which allows us to work with errors in Rust way more efficiently. In our case we are using it's popularity and other crates ability to convert into this Error type.

Let me explain this line by line:

1) We are implementing From<E> for AppError. By using the generic type E we can have a wider implementation. This would be the equivalent of impl From<sqxl::Error> for AppError. Which converts the sqlx::Error type into AppError
2) This is the critical bit, and why it actually limits us to certain errors. By having this where clause, we only allow the generic type E to be the ones that already support the Into trait from anyhow::Error. Basically limiting us to types that already support the conversion into this error type.
3) We only need to implement the from function that takes an error and returns itself back. By using the support mentioned above, we can just take the error and run an .into() conversion.

By using this generic trait approach we are essentially creating the following Rust code:

// SQLX:
impl From<sqlx::Error> for AppError {
    fn from(err: sqlx::Error) -> Self {
        Self(err.into()) // sqlx::Error -> anyhow::Error -> AppError
    }
}
// serde_json
impl From<serde_json::Error> for AppError {
    fn from(err: serde_json::Error) -> Self {
        Self(err.into()) // serde_json::Error -> anyhow::Error -> AppError
    }
}
// reqwest
impl From<reqwest::Error> for AppError {
    fn from(err: reqwest::Error) -> Self {
        Self(err.into()) // reqwest::Error -> anyhow::Error -> AppError
    }
}
// ...

And so on ... You get the picture!

Actual implementation

Okay, so we have our newtype AppError, it has all the things it needs to be converted to our Error type. How does it actually work? Well, let's go back to our get_edit_contact handler function from before, and see what has changed:

#[axum::debug_handler]
async fn get_edit_contact(
    State(state): State<AppState>,
    Path(id): Path<i64>,
) -> Result<(StatusCode, Html<String>), AppError> {
    let contact = Contact::find_by_id(&state.db, id).await?; // sqlx::Error -> AppError
    let edit_template = EditContactTemplate { contact };
    let html = edit_template.render()?; // askama::Error -> AppError
    Ok((StatusCode::OK, Html(html)))
}

Whoa, that is way tighter than before. Yes, we are using the ? operator we propagate the errors up the call stack. Meaning the value of the Result returned by both Contact::find_by_id and .render() are returned back to axum as AppError newtypes.

This means we no longer have to deal with error handling within the function itself, and we are just returning the same error type back. Since it is the same error type, both function handler and axum are happy with receiving it! 🥳 Huzzah!

If you want to see the full codebase in action, you can check out my GitHub repo here. And please ignore the mess, this is just a learning repo! 🙏

Asynchronous Rust 🦀 - RustConf 2025 | Day 1

Darko Mesaroš ⛅️ — Wed, 03 Sep 2025 05:49:16 +0000

tl;dr
I was at RustConf 2025, and attended a cool workshop on Rust asynchronous programming. You can check it out here.

This year, for the first time, I've attended RustConf. It's a time for me to meet the Rust community, learn some new skills, and check up on Ferris, and see how it's doing. Rust conf is an annual conference for all us Rustaceans, and this year it was held in Seattle, WA. A place I live in, so I could easily just pop in! 🥳

Okay, let's get into day 1 - Workshop/Async day

Workshop - Async Fundamentals

To start off the event, I attended the Rust Async Fundamentals workshop by Herbert Wolverson. This gave me an opportunity to learn all about building asynchronous software in Rust.

The workshop is really great and Herbert is an excellent teacher. What I enjoyed the most is how he broke down tokio and other macros. Basically he showed us all what is exactly happening behind the scenes when you just add #[tokio::main] above your main() function. This made me realize how much heavy lifting Rust is doing, all while still giving you all the control you need!

The workshop is actually public if you wanna take a crack at it yourself, but please give Herbert a follow and check out rest of his courses. The workshop can be found on GitHub.

But, what did I learn today? 🤔

Actor Model

Okay, so I need to talk about something really neat I've learned today - and yeah, long time Rustaceans may scoff at me for this. But the Actor Model is something that I am finding incredibly useful. So what is an Actor Model? Well it's a pattern in Software Development when building concurrent programming. Basically what you are doing is organizing code around independent actors that communicate with each other through passing messages (using stuff like mpsc). The entire actix framework is an Actor framework for Rust (the one I used the most is actix-web).

It integrates seamlessly with Rusts onwership and concurrency principles. Since Rust has no Garbage Collector, actors provide an elegant way to manage memory safety. Because actors communicate via shared channels, they do not share mutable states, meaning this could help you avoid data races and concurrency bugs. 🔥

Well, let me show you in the simplest way possible (I will add comments to the code so it makes sense in a single shot):

src/lib.rs

// List of commands that can be sent to the Actor.
pub enum SharedStateCommand {
    Increment,
    Get(tokio::sync::oneshot::Sender<u64>), // oneshot is key here as this is how the information is sent back - via this channel
}


// This now spawns an actor. This actor maintains the `counter` state. The way it processes commands is through the `Sender` it returns, and in a thread-safe manner.
pub async fn start() -> tokio::sync::mpsc::Sender<SharedStateCommand> {

    // Create our tx and rx channels with a buffer capacity of 32 messages
    let (tx, mut rx) = tokio::sync::mpsc::channel(32);

    // Initialize the counter
    let mut counter: u64 = 0;

    // Spawn the actor and move everythinng under it
    tokio::spawn(async move {

        // Process the commands being sent to it
        while let Some(cmd) = rx.recv().await {
            match cmd {
                SharedStateCommand::Increment => {
                    counter += 1;
                },
                SharedStateCommand::Get(resp_tx) => {
                    let _ = resp_tx.send(counter);
                }
            }
        }
    });

    tx

}

// Function that gets the current counter value by using `oneshot` to send a command and wait for the return via the same channel
pub async fn get_counter(sender: &tokio::sync::mpsc::Sender<SharedStateCommand>) -> u64 {
    let (resp_tx, resp_rx) = tokio::sync::oneshot::channel();
    let cmd = SharedStateCommand::Get(resp_tx);
    if sender.send(cmd).await.is_err() {
        return 0;
    }
    resp_rx.await.unwrap_or(0)
}

// This is a fire and forget function where it just tells the actor to increment the counter without waiting for the results
pub async fn increment(sender: &tokio::sync::mpsc::Sender<SharedStateCommand>) {
    let cmd = SharedStateCommand::Increment;
    let _ = sender.send(cmd).await; // we dont really care here
}

Okay and then how do we use this library crate now? Well here is an example using the axum framework. More details in the comments below

use axum::{http::StatusCode, Extension, Json, Router};
use shared_state_actor::SharedStateCommand;
use tokio::sync::mpsc::Sender;

#[tokio::main]
async fn main() {
    // Start my actor here and get its handle - BTW I've imported my library here in Cargo.toml
    let my_actor = shared_state_actor::start().await;

    // Some Axum boilerplate as well as routes
    let app = Router::new()
        .route("/", axum::routing::get(|| async { "Hello, World!" }))
        .route("/json", axum::routing::get(hello_json))
        .layer(Extension(my_actor)); // THIS IS KEY - Add the actor here, so it's available to all routes

    // Start the axum server
    let listener = tokio::net::TcpListener::bind("127.0.0.1:3001")
        .await
        .unwrap();
    axum::serve(listener, app).await.unwrap();
}

#[derive(serde::Serialize, serde::Deserialize, Debug)]
struct HelloJson {
    message: String,
}

async fn hello_json(
    Extension(my_actor): Extension<Sender<SharedStateCommand>>, // Extract the layer here using Axum's extractors
) -> axum::Json<HelloJson> {
    // Here is where we bump up the counter in the actor
    shared_state_actor::increment_counter(&my_actor).await;

    // Here is where we get the current counter (it uses the oneshot channel for this)
    let new_total = shared_state_actor::get_counter(&my_actor).await;


    // Respond back
    let reply = HelloJson {
        message: format!("Counter: {}", new_total),
    };
    axum::Json(reply)
}

This such a great way to handle concurrency fearlessly (tm). 🦀 Besides this, I've also learned about Cancel Safety and Select statements in Tokio.

Wrap up

Overall feelings of Day 1 - I love it! The fact that the content is extremely technical tickles my fancy. Even though this was an essentials workshop, I felt I learned so much about Async patterns in Rust. Most of my workshop...mates(?) were incredibly skilled engineers, so even listening to their questions made me learn so many new things.

I am looking forward to day 2 when I get to visit some shorter sessions and mingle with more Rust folks!

Stay tuned for part 2.

Updates from AWS CDK! 🥳

Darko Mesaroš ⛅️ — Fri, 13 Jun 2025 19:26:46 +0000

Praneeta Prakash for AWS

Jun 13 '25

AWS CDK in Action — May 2025: Empowered Deployments, Governance, and Community

#aws #cdk #devtools #infrastructureascode

Comments 2

3 min read

[Boost]

Darko Mesaroš ⛅️ — Wed, 07 May 2025 14:40:05 +0000

Slobodan Stojanović for AWS Heroes

May 3 '25

AI Agents: how they work and how to build them

#ai #llm #programming #aws

Comments 7

26 min read

[Boost]

Darko Mesaroš ⛅️ — Tue, 15 Apr 2025 15:20:42 +0000

Todd Sharp

Apr 15 '25

Using the Momento Topics HTTP API to Update Nixie Tubes

#arduino #pubsub #learning #momento

Comments

6 min read

Amazon Q Developer CLI 1.7.3 - Now with VIM! 😍

Darko Mesaroš ⛅️ — Fri, 11 Apr 2025 04:10:02 +0000

TL;DR Amazon Q Developer CLI 1.7.3 introduces five key improvements: just type q to launch; granular tool permission controls with /tools trust/untrust commands; VIM integration via /editor command for complex prompts; multi-line editing with Ctrl+J; and enhanced context management through the /context command.

Hey there! 👋 Amazon Q developer CLI 1.7.3 is out, and this new version has a couple of really neat goodies that I really want to share with you.

1. Simplified Command

Super simple but incredibly convenient - if you want to use Q CLI right now, you can just type q. Yep, that's it! No longer need to type q chat which is great. Saves me five characters, and makes it super snappy to kick off! 🥳

2. New Tools Permissions Dialog

This is really neat. Amazon Q Developer now has the a tools permissions/control dialog. If you do /tools, it's going to give you the current available tools - these are the tools available to Q CLI (stuff that can read from disk, write to disk, use AWS API, and execute bash commands).

You can now enter /tools and then something like untrust and trust and trustall. Simply put, when you untrust a tool, that tool needs to ask for confirmation to do anything. So I can do:

/tools untrust fs_read

Now the FS read tool has per-request permissions. Anytime Q CLI tries to read something off the disk, it's going to ask me "Can I read this off the disk?" It's a really cool way for you to granularly control the permissions. Wonderful!

3. VIM Integration

This one I really like. Say, you want to enter a more complicated prompt - something with multiple lines, bullet points, or something you'd normally edit somewhere else and paste in. 🤔 What if you could use objectively the best text editor in the world: VIM, VI, Neovim (call it what you want) right in Amazon Q CLI? 👏

Now you can use the /editor command. This brings up your default set editor (in my case, it's vim), and I can just come here and literally paste or type out something inside. Once you are done save and quit (if you know how 😈), and once that's done, it automatically goes into the prompt and Q CLI can use it. Beautiful!

To configure a custom editor (emacs, nano, joe, ed ... whatever). You can do so with the export command. But make sure you do it in bash, as Q CLI is using Bash:

export EDITOR=joe

4. Multi-line Editing

Speaking of multi-line editing, you can now do this in Amazon Q Developer. Instead of entering the editor using /editor you can just hit Ctrl + j and it will append a new line to your input. Hitting Enter at the end of it will submit the prompt!

You can do multi-line things now within the actual command line. Love it!

5. Enhanced Context Controls

Lastly, there are additional controls when it comes to managing the context. Within q type /context, and you can actually see additional commands and more clarifications about the context rules that are part of Q developer CLI.

By typing /context show it will show you how the current global and profile contexts are configured.

This isn't anything new, but it's a cleaner way of having you work with your context now and looks way nicer inside of Q CLI.

Try it out today for free! 🚀

So if you have not been using Amazon Q CLI up until now, now is the perfect time to try it. It's free! Go ahead and use Amazon Q Developer CLI to build tools, automate stuff, deploy stuff, to even convert weird audio formats into .wav or anything like that. (yes it can do that too).

[Boost]

Darko Mesaroš ⛅️ — Thu, 10 Apr 2025 17:09:24 +0000

Suman Debnath for AWS

Apr 9 '25

Standardizing AI Tooling with Model Context Protocol (MCP)

#mcp #agents #genai

Comments

3 min read

Making Makefiles for fun and profit

Darko Mesaroš ⛅️ — Wed, 26 Mar 2025 15:18:57 +0000

TL;DR: Make is a 48-year-old build automation tool that's still incredibly useful today. This post explains how Makefiles work, why they're awesome despite their cryptic syntax, and shows practical examples for modern development workflows - from Terraform automation to local dev environments. You can even use Amazon Q Developer CLI to generate Makefiles without becoming a Make expert! Stop hammering that up arrow key and start automating your development tasks. 🚀

Alright, I am sure everyone has heard of make, a critical tool in the world of software development that has been primarily used for build automation. But have you really used it? Like, have you seen what it can do? Well in this post, I will go over the history of make, how it works, some cool use cases (besides just building C software) and how you can benefit from it in the year 2025.

Believe it or not, make is 48 years old (at the time of writing) which makes it older than DNS, BSD Unix, and even TCP/IP. It was made by Stuart Feldman to solve a quite common problem at the time: software developers were forgetting which files needed to be recompiled after making changes to the source code. And back then, you often had limited system time to do your debugging and compilations. Leading to, well, a terrible developer experience!

While I do not have issues forgetting to compile files, I often forget what command does what to my stack and end up mercilessly slamming the up arrow key looking back in my Bash history, hoping the same command is there. Often that is not the case. So, let's see why exactly make.

Why Makefiles

But, Darko, why not just write a deploy.sh or build.sh script and be done with it?

Good catch dear reader, that was the way it was done even back in Stuart's time, but it often involved very complex scripting that at times could be an overkill for your project. Also, the fact that simple scripts would often just brute force build your applications and just recompile everything, would just take too much time. Back then, compiling was expensive and time consuming so you had to be careful. make actually solved that problem by only compiling source code files that have changed and creating an intricate system of dependencies to better orchestrate your build process.

Let's have a look at one simple C project Makefile. Oh yeah, Makefile is a file where you outline how your build, deploy, or whatever is being done. It's what make looks for when it's run:

# Define variables
CC = gcc
CFLAGS = -Wall -g
TARGET = myprogram

# Source files
SRCS = main.c utils.c
OBJS = $(SRCS:.c=.o)

# Default target (build)
all: $(TARGET)

# Link object files to create the executable
$(TARGET): $(OBJS)
    $(CC) $(CFLAGS) -o $@ $^

# Compile source files into object files
%.o: %.c
    $(CC) $(CFLAGS) -c $< -o $@

# Clean up generated files
clean:
    rm -f $(TARGET) $(OBJS)

# Declare phony targets (targets that don't represent files)
.PHONY: all clean

... Well that looks scary! What is all that!? 🤯

Makefile breakdown

Yes yes, I know! That does look byzantine. The declarative programming language it uses definitely is an artifact of its time, and it takes some getting used to. But I will give you a crash course of what this code does:

# Define variables
CC = gcc
CFLAGS = -Wall -g
TARGET = myprogram

# Source files
SRCS = main.c utils.c
OBJS = $(SRCS:.c=.o)

First, we define all the variables! Actually, to add to the confusion, make calls these macros, but whatever. They are basically variables. And here we define certain things up front so we dont have to manually make changes down in the file. Here we tell it what compiler we are using, what compiler flags we need to set up, and the name of our program. And, as you can see, we also tell it what source files it needs to compile.

Lastly it has this cool little way of defining the OBJS variable (macro, whatever): $(SRCS:.c=.o) which simply put tells it, everything in the SRCS macro but change the .c with .o, essentially making a macro that is equivalent to: OBJS = main.o utils.o

# Default target (build)
all: $(TARGET)

This is what we call a target, basically a code block that will run and it's dependency. The all target will run if we run make all or even just make without any parameter. Because we have $(TARGET) in as it's prerequisite it will run that first. I will cover the way prerequisites work in a little bit. Speaking of $(TARGET)...

# Link object files to create the executable
$(TARGET): $(OBJS)
    $(CC) $(CFLAGS) -o $@ $^

This is where the linking happens. As you can see a bunch of macros are here, but also some weird new macros. Let me expand this code into what it would look like if we replaced all the macros with the actual values:

myprogram: main.o utils.o
    gcc -Wall -g -o myprogram main.o utils.o

Well that makes more sense! The keys here are the built in macros:$@ and $^. Which point to $(TARGET) and all the prerequisites, respectively. This makes it very dynamic, as it will include all the elements of the $(OBJS) macro automatically.

# Compile source files into object files
%.o: %.c
    $(CC) $(CFLAGS) -c $< -o $@

Now, this is actually where the compilation happens. And this is where we see a very powerful make feature called a pattern rule. What this rule says with this %.o: %.c is: "to build any file ending *.o** you need a file with the same name but ending in .c"* - Magical! 🤩

Lastly the actual compilation command just does a bunch of macro expands and appends the prerequisites and targets. For example in our current situation we will get this:

gcc -Wall -g -c main.c -o main.o

AND, since there are two *.c files, we also get this:

gcc -Wall -g -c utils.c -o utils.o

# Clean up generated files
clean:
    rm -f $(TARGET) $(OBJS)

This is my favorite part of a Makefile - the clean target! I love this, as no matter how much you start messing up with different compiled objects, you can just run make clean and it will remove all the compiled binaries and objects. Here is where you actually get creative with, and define what clean means for you.

For our example, this command will do the following:

rm -f myprogram main.o utils.o

# Declare phony targets (targets that don't represent files)
.PHONY: all clean

This last bit is also very important. The .PHONY target is necessary in order to prevent conflicts with real files. Basically it tells make that all and clean are not actual files to be created but rather names or commands to be executed.

For example, if we did not have .PHONY declared. And there was a file called clean in your project directory. Running make clean would check if the file clean needs to be rebuilt, establish that the file exists and has no dependencies, and just do nothing ....

Remember kids, always define your .PHONY targets! 👏

Common uses

Okay, so is this thing only used by C software developers? Do I need to whip out my UNIX System V license? Not at all friends, make makes (pun so much intended) a great companion to many software development projects. Let me give you a few examples I've seen floating around.

Terraform automation

My good friend Cobus, a long time Terraform user has used make and Makefiles to further streamline the way he works with the stacks he manages. You can check out the full Makefile here, but here are some cool parts that stuck out for me:

Checking for the operating system in question and setting specific macros based off that:

UNAME:= $(shell uname)
ifeq ($(UNAME),Darwin)
        OS_X  := true
        SHELL := /bin/bash
else
        OS_DEB  := true
        SHELL := /bin/bash
endif

Giving the user the appropriate amount of warning before running terraform destroy:

destroy: check
    @echo "Switching to the [$(value ENV)] environment ..."
    @terraform workspace select $(value ENV)

    @echo "## 💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥 ##"
    @echo "Are you really sure you want to completely destroy [$(value ENV)] environment ?"
    @echo "## 💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥💥 ##"
    @read -p "Press enter to continue"
    @terraform destroy \
        -var-file="env_vars/$(value ENV).tfvars"

Local Development Environment automation

With a little help from Docker and make you can easily automate creation of local development environments for your software development projects. This allows you to automate certain elements of your development workflow and shift left a lot of your building efforts. While setting up databases and services in local docker containers is possible without make - make, makes it (I am not sorry for any of these puns) way way easier.

Let me show you an example Makefile I've used for some Rust development, where I needed to spin up both Postgres and Redis in a local environment. You can see the full Makefile here

But let's look at some highlights that I find very useful. For example, here we are defining a macro PG_PASSWORD using simple assignment, meaning this expression will be only run once. This is done by using := as the assignment operator, so everytime the $(PG_PASSWORD) is referenced it wont go in and run the openssl command, rather it will just get its value.

We are using this PG_PASSWORD macro in our code to dynamically define the Postgres password.

# Generate a random password (16 characters)
PG_PASSWORD := $(shell openssl rand -base64 12 | tr -d '\n')

Before we actually execute our application, we check if the .env file has been created. If it is not, we tell the user to go ahead and run make setup. But if the file exists, we source it and just cargo run 🚀

# Run with environment variables from .env
run: 
    @if [ ! -f .env ]; then \
        echo "Environment file not found. Run 'make setup' first."; \
        exit 1; \
    fi
    @echo "Loading environment variables and running application..."
    @source .env && cargo run

There are so many more examples where make can be used. From video game development, to automatic image resizing, to data processing.

Makefiles 48 years later

Okay, now that you kind of understand the basics of make, you may think to yourself: "Darko, this language is ... what? Why is it so convoluted? Is it even worth my time?".

Well, friend, yes it is! Once you get used to make, you will never go back. But I fully understand the complexity of getting up and running with make if you never did so. So, let's adopt make 48 years later with the help of modern technology. Let me show you how you can use Amazon Q Developer CLI to generate Makefiles for your projects. 🥳

First off, Amazon Q Developer CLI is a command line based Generative AI assistant. But like really, an assistant! It does not only answer coding questions, it actually does stuff for you. From generating code, to writing deployment scripts, to even running commands on your local (and remote) systems! I really like it! 😍

To get started with Amazon Q Developer, you can do so for free by just getting yourself an AWS Builder ID and installing Q CLI. I'll wait ... ⌚

Oh, you're back! Excellent! Let me show you how I use this tool to create various Makefiles for my projects.

My link shortener CDK project

What I got here is a rather straightforward AWS CDK project that sets up my very own link shortener. This stack features some TypeScript, Rust, and HTML as programming languages. And it deploys AWS Lambda functions, DynamoDB Tables and CloudFront distributions. Oh, and it features multiple stacks. Making a Makefile quite a useful thing for managing it.

Here is the rough structure of my project:

.
├── bin
│   └── krtk-rs.ts              # CDK app entry point
├── lambda
│   ├── create_link             # Lambda function for creating short links
│   ├── get_links               # Lambda function for retrieving links
│   └── visit_link              # Lambda function for handling link visits
│   └── process_analytics       # Lambda function for analytics processing 
├── lib
│   ├── certificate-stack.ts    # Stack for SSL certificate
│   └── krtk-rs-stack.ts        # Main infrastructure stack
├── shared                      # Shared Rust code
├── website                     # Frontend assets
│   ├── assets
│   │   └── main.js             # Frontend JavaScript
│   └── index.html              # Main HTML page
└── test
    └── krtk-rs.test.ts         # Tests for the CDK stack (not yet implemented)

Within the root of this project I run AWS Q Developer CLI by running q chat. This starts off the command line chat interface.

Now, I always like to ask a bit about what my current project does, so that I add that structured thought to the context itself (although it already has access to my entire repo).

Tell me a bit about what my project does, and how is it built

Then I use the following prompt to have it generate me a Makefile

Help me create a Makefile that will help me automate certain actions needed in developing this stack. 
Make sure to include deploy commands for individuals as well as all stacks. 
Help me set up local development environments for cargo lambda as well as setting up all the necessary environment variables for them to function.

After a moment or so, it gets me the following results:

# krtk.rs Makefile
# Automates common development and deployment tasks

.PHONY: help install build bootstrap deploy deploy-cert deploy-main local-dev clean test lint env-setup

# Default target
help:
      @echo "krtk.rs - Serverless URL Shortener"
      @echo ""
      @echo "Usage:"
      @echo "  make install         Install all dependencies"
      @echo "  make build           Build the project"
      @echo "  make bootstrap       Bootstrap AWS CDK environment"
      @echo "  make deploy          Deploy all stacks"
      @echo "  make deploy-cert     Deploy only the certificate stack"
      @echo "  make deploy-main     Deploy only the main stack"
      @echo "  make local-dev       Start local development environment"
      @echo "  make clean           Clean build artifacts"
      @echo "  make test            Run tests"
      @echo "  make lint            Run linters"
      @echo "  make env-setup       Set up local environment variables"

# Installation targets
install:
      @echo "Installing dependencies..."
      npm install
      @echo "Installing cargo-lambda..."
      cargo install cargo-lambda
      @echo "Dependencies installed successfully."

# Build targets
build:
      @echo "Building project..."
      npm run build
      @echo "Building Rust Lambda functions..."
      cd lambda/create_link && cargo lambda build --release
      cd lambda/get_links && cargo lambda build --release
      cd lambda/visit_link && cargo lambda build --release
      cd lambda/process_analytics && cargo lambda build --release
      @echo "Build completed successfully."

# AWS CDK targets
bootstrap:
      @echo "Bootstrapping AWS CDK environment..."
      cdk bootstrap
      @echo "Bootstrap completed."

deploy:
      @echo "Deploying all stacks..."
      cdk deploy --all --require-approval never
      @echo "Deployment completed."

deploy-cert:
      @echo "Deploying certificate stack..."
      cdk deploy CertificateStack --require-approval never
      @echo "Certificate stack deployed."

deploy-main:
      @echo "Deploying main application stack..."
      cdk deploy KrtkRsStack --require-approval never
      @echo "Main stack deployed."

# Local development
local-dev:
      @echo "Starting local development environment..."
      @echo "Setting up local DynamoDB..."
      docker run -d -p 8000:8000 --name dynamodb-local amazon/dynamodb-local
      @echo "Creating local DynamoDB table..."
      aws dynamodb create-table \
              --table-name local-links \
              --attribute-definitions AttributeName=id,AttributeType=S \
              --key-schema AttributeName=id,KeyType=HASH \
              --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
              --endpoint-url http://localhost:8000 || true
      @echo "Starting local API Gateway..."
      @echo "Local development environment is ready."
      @echo "Run Lambda functions locally with: cargo lambda watch"

# Clean up
clean:
      @echo "Cleaning build artifacts..."
      rm -rf cdk.out
      find lambda -name target -type d -exec rm -rf {} +
      @echo "Stopping local DynamoDB..."
      docker stop dynamodb-local || true
      docker rm dynamodb-local || true
      @echo "Clean completed."

# Testing
test:
      @echo "Running tests..."
      npm test
      cd lambda/create_link && cargo test
      cd lambda/get_links && cargo test
      cd lambda/visit_link && cargo test
      cd lambda/process_analytics && cargo test
      @echo "Tests completed."

# Linting
lint:
      @echo "Running linters..."
      npm run lint
      cd lambda/create_link && cargo clippy -- -D warnings
      cd lambda/get_links && cargo clippy -- -D warnings
      cd lambda/visit_link && cargo clippy -- -D warnings
      cd lambda/process_analytics && cargo clippy -- -D warnings
      @echo "Linting completed."

# Environment setup
env-setup:
      @echo "Setting up environment variables for local development..."
      @echo "export DYNAMODB_TABLE=local-links" > .env.local
      @echo "export DYNAMODB_ENDPOINT=http://localhost:8000" >> .env.local
      @echo "export TABLE_NAME=local-links" > .env
      @echo "export AWS_REGION=us-east-1" >> .env.local
      @echo "export DOMAIN_NAME=localhost" >> .env.local
      @echo "Environment variables set up in .env.local"
      @echo "Run 'source .env.local' to load these variables."

Wow, that is a lot! And check it out, it even decided to run dynamodb-local in order to emulate my production environment. Storing that information in a .env file so that it can be used during execution. But something is off... It's has decided not to pass the environment variable to my Lambda functions via the cargo lambda watch command. So I ask it nicely:

Make sure that the cargo lambda watch also includes a environment variable for my table name as that is required by my function
s. 
Better yet do it by passing the `--env-file` parameter to the cargo lambda watch command, and pass it the path to the `.env` fi
le.

Excellent, now it has changed a part of my Makefile to also include commands to test my Lambda functions:

[...]

# Environment setup (must be run before local-dev or watch commands)
env-setup:
      @echo "Setting up environment variables for local development..."
      @echo "DYNAMODB_TABLE=local-links" > .env
      @echo "TABLE_NAME=local-links" > .env
      @echo "DYNAMODB_ENDPOINT=http://localhost:8000" >> .env
      @echo "AWS_REGION=us-east-1" >> .env
      @echo "DOMAIN_NAME=localhost" >> .env
      @echo "Environment variables set up in .env file"

# Local development
local-dev: env-setup
      @echo "Starting local development environment..."
      @echo "Setting up local DynamoDB..."
      docker run -d -p 8000:8000 --name dynamodb-local amazon/dynamodb-local || true
      @echo "Creating local DynamoDB table..."
      aws dynamodb create-table \
              --table-name local-links \
              --attribute-definitions AttributeName=id,AttributeType=S \
              --key-schema AttributeName=id,KeyType=HASH \
              --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
              --endpoint-url http://localhost:8000 || true
      @echo "Local development environment is ready."
      @echo "Use 'make watch-<function-name>' to start a local Lambda function."

# Lambda watch commands with environment variables from .env file
watch-create-link: env-setup
      @echo "Watching create_link lambda..."
      cd lambda/create_link && cargo lambda watch --env-file ../../.env

watch-get-links: env-setup
      @echo "Watching get_links lambda..."
      cd lambda/get_links && cargo lambda watch --env-file ../../.env

watch-visit-link: env-setup
      @echo "Watching visit_link lambda..."
      cd lambda/visit_link && cargo lambda watch --env-file ../../.env

watch-process-analytics: env-setup
      @echo "Watching process_analytics lambda..."
      cd lambda/process_analytics && cargo lambda watch --env-file ../../.env

[...]

I just answered with a big ol' y in q chat and were! Ready to go! 👏 I even get a nice little guide on how to use my brand new Makefile:

I've created a comprehensive Makefile for your krtk.rs project that will help automate development tasks. I've also added a .gitignore file to ensure environment variables and build artifacts aren't committed to your repository.

## Makefile Features

The Makefile includes commands for:

1. Installation and setup:
   • make install - Installs npm dependencies and cargo-lambda
   • make env-setup - Creates a .env file with local development variables

2. Build and deployment:
   • make build - Builds both the CDK project and Rust Lambda functions
   • make bootstrap - Bootstraps your AWS CDK environment
   • make deploy - Deploys all stacks
   • make deploy-cert - Deploys only the certificate stack
   • make deploy-main - Deploys only the main application stack

3. Local development:
   • make local-dev - Sets up a local DynamoDB instance and creates the required table
   • Lambda function development with environment variables:
     • make watch-create-link
     • make watch-get-links
     • make watch-visit-link
     • make watch-process-analytics

4. Testing and maintenance:
   • make test - Runs tests for both CDK and Lambda functions
   • make lint - Runs linters for TypeScript and Rust code
   • make clean - Cleans up build artifacts and stops local services

## Environment Variables

The Makefile creates a .env file with these variables:
• DYNAMODB_TABLE=local-links
• DYNAMODB_ENDPOINT=http://localhost:8000
• AWS_REGION=us-east-1
• DOMAIN_NAME=localhost

These are passed to the Lambda functions using the --env-file parameter when running cargo lambda watch.

## Usage

To get started with local development:

bash
# Install dependencies
make install

# Set up local environment and start DynamoDB
make local-dev

# Run a specific Lambda function locally
make watch-create-link


For deployment:

bash
# Deploy all stacks
make deploy

# Or deploy individual stacks
make deploy-cert
make deploy-main

The help command (make or make help) will show all available commands and their descriptions.

Lastly, let's see it in action by running a few make commands! Namely, I want to see how the local development works!

First: make install - this just installs all the packages needed to run my stack.
Next: make local-dev - this configures my local development environment by starting a local version of DynamoDB

Now, I can execute my create-link Lambda function locally, by running: make watch-create-link. This will create a HTTP endpoint where I can interact with my Lambda function like a user would. To invoke it, I can just run the following curl command:

curl -X POST http://10.0.1.11:9000/lambda-url/create_link \
  -H "Content-Type: application/json" \
  -d '{"url_to_shorten": "https://rup12.net"}'

Let's see ...

Failed to shorten URL 💥 : "Error creating a link - Service Error: ResourceNotFoundException(ResourceNotFoundException { message: Some(\"Requested resource not found\"), meta: ErrorMetadata { code: Some(\"ResourceNotFoundException\"), message: Some(\"Requested resource not found\")

Hmm, well that is a future Darko problem, I guess I need to debug those Rusty Lambda functions! 🤔

Finally, to clean up my development environment, I run: make clean

Working with static websites

Next up, what I have here is a simple landing page for an open source app I've built. It features a static website running on AWS Amplify but is deployed to it using the AWS S3 Integration. So, instead of me going in the AWS Console, uploading the files to S3, going to Amplify and triggering Deploy. Why not have a Makefile do all this for me.

Let's go ask Q:

I need a Makefile for my website here that I upload to a bucket called shuk.rs in my AWS Account. 
I want to use the Makefile to deploy the changes there as well as update the AWS Amplify website using the start-deployment aws CLI command. 
I will need an app-id for this to work. So get that value as well. Use the AWS CLI profile called `personal`. 
Here is the example of the AWS CLI deploy command for amplify: 
aws amplify start-deployment --app-id <app_id> \
--branch-name <branch_name> \
--source-url s3://amzn-s3-demo-website-bucket/prefix \
--source-url-type BUCKET_PREFIX`

I made sure to give it the example of the command I want it to run during the deployment. This ensures it gets it right, especially if this is a rather new feature. And I got this command from the documentation page.

Check this out, it actually used the AWS CLI locally to find my app-id for me. What it actually did was first search in us-east-1 and once it could not find it, it tried us-west-2 which worked.

Look at what it built here!

# Makefile for shuk.rs website deployment
# This Makefile handles deployment to both S3 bucket and AWS Amplify

# Configuration
BUCKET_NAME = shuk.rs
REGION = us-west-2
AMPLIFY_APP_ID = d32qis9bnvy6r1
AMPLIFY_BRANCH = staging
AWS_PROFILE = personal

# List of files to deploy
WEBSITE_FILES = index.html install.sh shuk.gif favicon.png

.PHONY: deploy deploy-s3 deploy-amplify clean help

# Default target
help:
       @echo "Available targets:"
       @echo "  deploy       - Deploy website to S3 bucket and update Amplify app"
       @echo "  deploy-s3    - Deploy website to S3 bucket only"
       @echo "  deploy-amplify - Update Amplify app only"
       @echo "  clean        - Remove any temporary files"
       @echo "  help         - Show this help message"

# Deploy to both S3 and Amplify
deploy: deploy-s3 deploy-amplify

# Deploy to S3 bucket
deploy-s3:
       @echo "Deploying website files to S3 bucket $(BUCKET_NAME)..."
       @for file in $(WEBSITE_FILES); do \
               content_type=$$(case $$file in \
                       *.html) echo "text/html";; \
                       *.sh) echo "text/plain";; \
                       *.gif) echo "image/gif";; \
                       *.png) echo "image/png";; \
                       *) echo "application/octet-stream";; \
               esac); \
               echo "Uploading $$file with content-type: $$content_type"; \
               aws s3 cp $$file s3://$(BUCKET_NAME)/ --content-type "$$content_type" --profile $(AWS_PROFILE) --region $(REGION); \
       done
       @echo "S3 deployment complete!"

# Update Amplify app
deploy-amplify:
       @echo "Starting deployment for Amplify app $(AMPLIFY_APP_ID) on branch $(AMPLIFY_BRANCH)..."
       @aws amplify start-deployment \
               --app-id $(AMPLIFY_APP_ID) \
               --branch-name $(AMPLIFY_BRANCH) \
               --source-url s3://$(BUCKET_NAME)/ \
               --source-url-type BUCKET_PREFIX \
               --profile $(AWS_PROFILE) \
               --region $(REGION)
       @echo "Amplify deployment initiated!"

# Clean any temporary files
clean:
       @echo "Cleaning up temporary files..."
       @find . -name "*.tmp" -delete
       @echo "Clean complete!"

Okay, I cannot have the app-id hardcoded there. So do you remember the little := operator I mentioned at the start? YES! It can actually take an expression and turn it into a command! Lovely! Let's ask it to dynamically get us the app-id during execution.

Can you make it so that you dynamically update the app-id instead of hardcoding it into the make file? The rest can stay hardcoded

And just like that! We have the correct AMPLIFY_APP_ID, which will automatically get us our app-id.

# Makefile for shuk.rs website deployment
# This Makefile handles deployment to both S3 bucket and AWS Amplify

# Configuration
BUCKET_NAME = shuk.rs
REGION = us-west-2
AMPLIFY_BRANCH = staging
AWS_PROFILE = personal

# List of files to deploy
WEBSITE_FILES = index.html install.sh shuk.gif favicon.png

# Dynamically get the Amplify app-id for shuk.rs
AMPLIFY_APP_ID := $(shell aws amplify list-apps --region $(REGION) --profile $(AWS_PROFILE) --query "apps[?name=='shuk.rs'].appId" --output text)

.PHONY: deploy deploy-s3 deploy-amplify clean help check-app-id
[...]

Lastly, I'll make some changes to the index.html and deploy the changes using make deploy

Boom 💥 It's deployed! Thank you make ❤️

Wrap up

Alright friends, I think we have explored plenty about make and how it can help us in our day-to-day developer lives. We've seen that despite being 48 years old, this tool is still incredibly relevant and useful in our modern tech stack. From its origins solving compilation problems at Bell Labs to streamlining our Terraform deployments and website updates, make proves that good tools stand the test of time.

Yes, the syntax can be a bit byzantine at first (those weird macros and pattern rules 🤯), but once you get past that initial learning curve, you'll discover a powerful way to automate repetitive tasks and standardize your workflows. No more mercilessly slamming the up arrow key hoping to find that one command you ran three days ago!

And as we've seen with our examples using AWS Q Developer CLI, you don't even need to be a make expert to start using it. Modern AI tools can help generate sophisticated Makefiles tailored to your projects, whether it's a complex CDK deployment or a simple static website update.

So go ahead, create that Makefile for your project today! Your future self will thank you when you can just type make deploy instead of remembering that 15-parameter AWS CLI command. After nearly five decades, make continues to, well, make our lives easier (sorry not sorry for the pun 😆).

Remember kids, always define your .PHONY targets! 👏

Build On Live | Observability - Show notes

Darko Mesaroš ⛅️ — Thu, 20 Oct 2022 20:19:11 +0000

Welcome to our second Build On Live Event which is all about Observability. AWS experts and community members cover topics ranging from tracing, OpenTelemetry, SLOs, eBPFs and more!

This event was hosted by Jacquie Grindrod and Ricardo Ferreira and it was a sight to be seen. With both in-person and remote guests, the industry experts covered a variety of specialty topics within the observability field

These are the show notes from that event, which was live streamed on the 29th of September 2022. The recording of this event is available on our YouTube channel, but in this article I will be linking each segment notes with its video, so make sure to hit that subscribe button! 👏

Individual session notes:

Intro and Welcome
Go Beyond Observability with AI
How to Migrate Observability Platforms With OpenSLO
Intro to eBPF: Explain to Me As if I Was Five
OpenTelemetry—The Industry Telemetry Standard
That's a lot of data! how to manage ingestion and storage costs?
Observability and Distributed Tracing at CNCF
Creating trace data with OpenTelemetry
Talking Observability with Liz Fong-Jones

Intro and Welcome

Guest: Curtis Evans, Developer Advocate at AWS

We kick off the day with your hosts Ricardo, Jacquie and a guest star Curtis. Discussing the basics of Observability and what can we expect throughout the day.

So, "explain to us like we are 5", Curtis takes an example of a e-Commerce website and what all goes on in an application and how we track each execution and process that happens in each step in your application, that can in the future give us more insights and helps us detect and solve a problem before it even occurs.

Go Beyond Observability with AI

Guest: A.B. Vijay Kumar, IBM Fellow

Did you know AI can be used to help you understand the stream of events from observability data and alert you when something is bit off? In this session, A.B Vijay Kumar from IBM gives you an overview of how to leverage AI in what the industry calls AIOps (also called Augmented SRE), which can be a powerful component of your observability strategy. He shows a nice demo where AI is used to detecting anomalies and trigger conversations on Slack that people on-call could discuss what the problems are, and what actions the AI recommends taking based on past incidents.

Also, check out the 1:14 minute mark in the video something funky happened to the camera 😅

Some links that were shared:

How to Migrate Observability Platforms With OpenSLO

Guest: Ian Bartholomew, Site Reliability Engineering Manager at Nobl9

One of the best ways to measure the availability of services is having SLOs (Service Level Objective) set to them. They help in giving you a more pragmatic way to measure things and calculate how much does it costs having a service unavailable. What you may not know is that you can define them using an agnostic standard called OpenSLO using YAML. In this session, Ian Bartholomew from Nobl9 get into the weeds of how to do that, showing step by step the definition, implementation, and migration of defined OpenSLO's from on-premise to the cloud. And he does all of this with a hands-on approach using only the terminal. How cool is that?

How do you explain/justify Error budgets to Engineering/Upper management? Well, you need to very clearly state that service uptimes will never be a 100%, it's gonna be very close but we also need to understand that all the extra nines is a lot of extra money - exponentially. So this error budget allows for an X amount to be unreliable.

Quote from Charity Majors: "Nine nines mean nothing if your customers are unhappy"

Some links that were shared:

Intro to eBPF: Explain to Me As if I Was Five

Guest: Antón Rodríguez, Principal Software engineer at New Relic

Implementing observability these days is a no turning back trip to the world of instrumentation. But instrumenting services can be a lot of work depending on the approach you use. To minimize a bit of this workload, you can use eBPF — a non-intrusive way to instrument sandbox programs in an operating system kernel. In this session, Antón Rodriguez from New Relic explains how he got involved with this technology, how he applies it to his daily job as a software engineer, and also shows a cool demo of eBPF using the CNCF project called Pixie.

Some links that were shared:

OpenTelemetry—The Industry Telemetry Standard

Guest: Michael Hausenblas, Open Source - Observability at AWS

OpenTelemetry these days is arguably a synonym for observability. This CNCF project that provides an agnostic way for developers to instrument their services to produce telemetry data such as tracing and metrics is catching on. But a project of that magnitude can be often hard to understand. In this session, Michael Hausenblas from AWS gives us an overview of OpenTelemetry, his involvement in this project with CNCF, and how can you get started with this using the right resources. He also clarifies the many sub-projects that exist for OpenTelemetry, which are handy to know as you find your way into this technology.

Some links that were shared:

That's a lot of data! how to manage ingestion and storage costs?

Guest: Richard "RichiH" Hartmann, Director of Community at Grafana

All monitoring initiatives start the same: you collect as much data as you can, you store them infinitely so you can analyze them someday, but one day the bill comes and upper management asks you to decrease infra costs. Suddenly, you shrink your monitoring infra and end up with a shared cluster for all the 100+ services that need some visibility. In this session, Richard Hartmann from Grafana Labs explains why this is an anti-pattern that should not occur every time people panic about infra costs related to monitoring. He shares some best practices about how to optimize ingestion and the storage costs of telemetry data. As he walks us over the different telemetry data, he also explains what are golden signals and how you should implement them.

Some links that were shared:

Observability and Distributed Tracing at CNCF

Guest: Yuri Shkuro, Creator of Jaeger, Co-founder of OpenTelemetry

Despite of most people think, logs are not the only way to understand the execution path of code. Traces can tell that story too, and when combined with logs, provide even a more interesting story. This is the reason distributed tracing is so mainstream these days. In this session, Yuri Shkuro, from Meta, gives his perspective about the importance of distributed tracing, how he, by accident, bumped into this technology, and how they helped it to grow during his tenure at CNCF. He also explains how projects like OpenTracing, Jaeger, OpenCensus, and Zipkin helped to pave the way to what we know as OpenTelemetry.

Some links that were shared:

Creating trace data with OpenTelemetry

Guest: Curtis Evans, Developer Advocate at AWS

There is no better way for developers to learn how to use a specific technology than rolling up their sleeves and writing some code for it to build an example. Curtis Evans from AWS strongly believes that, and he steps up to help us understand OpenTelemetry in a more hands-on way. In this session, he takes his time to instrument a microservice written in Python to produce telemetry data for traces and metrics. He highlights the difference between a piece of code with and without instrumentation, so you can have a sense of how much work is needed.

Some links that were shared:

Talking Observability with Liz Fong-Jones

Guest: Liz Fong-Jones, Field CTO at Honeycomb.io

Working with observability sometimes looks like building a puzzle with curvy edge pieces. The task at hands is to understand each piece and never lose track of the big picture. The problem is, with observability, knowing how the big picture looks like is not always possible. In this session, Liz Fong-Jones from Honeycomb shares her extensive experience with SRE and observability and shows us how observability looks like and how to pull each technology together to build that bigger picture. With an outstanding end to end example of troubleshooting a problem, fixing it in production, and coming back to development to apply the lessons learned with instrumentation, Liz shares when and how to use observability technologies to improve the system's reliability and customer satisfaction.

Also, to quote Liz from the day: "Do not be afraid of failure, failure is a learning opportunity. Break you systems as long as you learn from it, so you don't break them the same way twice!"

Some links that were shared:

Build on AWS Weekly - S1 E6 - Local Development Everywhere

Darko Mesaroš ⛅️ — Thu, 25 Aug 2022 15:09:16 +0000

Welcome to episode 6 of Build On Weekly! 🥳

Today Jacquie shows all of us and Darko how she configures her local development environment on her Macbook. On top of that she shows off some tips and tricks on how to automate said configuration for easy migrations between systems!

We will be posting here, on dev.to, to share show notes, links, socials, code, and any other things mentioned during the live stream with you! 🚀

If you have any questions, feedback or comments - feel free to put them in the comments of this post! 😇

Deployed Weekly

Today on Deployed Weekly we kick off with a warm welcome to the 500 new Community Builders we welcomed globally before taking a look at Cloud Glance, a tool that helps you navigate multiple AWS Environments with ease. Next up is the first Amazon CodeWhisperer workshop we’ve encountered while we share some of our thoughts about tools that help you to generate code. We then highlight Amazon Cloudfront’s added HTTP/3 QUIC support. Finally, we shared a link to open roles here at AWS DevRel if you’d like to come work with like us!

Links from the discussion:

Weekly Builds

Today we go on an interactive live tour with Jacquie through her terminal and IDE setup and share tips to make your environment portable between your different mac laptops. Also some cool automation steps she took to make it very easy to migrate between different workstations.

Some things we discuss:

Set up scripts
Package management using Brew and Brewfiles
Favorite fonts and theme templates

Links from the discussion

🐦 Reach out to the hosts and guests:

Jacquie: https://twitter.com/devopsjacquie
Darko: https://twitter.com/darkosubotica

Build on AWS Weekly - S1 E5 - Containers Containers Everywhere

Darko Mesaroš ⛅️ — Thu, 18 Aug 2022 15:28:42 +0000

Welcome to episode 5 of Build On Weekly! 🥳

Today Jacquie and Darko, discuss a few things around Containers and Hybrid environments. That means running your applications On-Premises AND in the cloud. In today's episode watch Darko as he sweats trying to troubleshoot a real time demo. 😅

We will be posting here, on dev.to, to share show notes, links, socials, code, and any other things mentioned during the live stream with you! 🚀

If you have any questions, feedback or comments - feel free to put them in the comments of this post! 😇

Deployed Weekly

Today on deployed weekly we take another peek at Lambda functions and .NET. What are the best strategies when running the two together. We talk about a interesting Open Source tool that helps you prototype and productionize (is that even a word?) ML Pipelines. Another wonderful CLI tool out there, for al the CLI and Tracing fans. A wrap up on the AWS Storage Day that happened the day before and finally an amazing interview/podcast over on Lex Friedman’s channel - with the best programmer in the world John Carmack

Links from the discussion:

Optimal strategy for running .NET code on Lambda functions by Steve Bjorg: https://dev.to/lambdasharp/optimal-strategies-for-net-on-aws-lambda-45kg
Sematic, an open-source development toolkit for AI/ML: https://github.com/sematic-ai/sematic
Do more stuff from the console with xray-cli!: https://github.com/mhlabs/xray-cli
Yesterday - the 10th of August - was AWS Storage Day! 🥳 https://aws.amazon.com/blogs/aws/welcome-to-aws-storage-day-2022/
Lex Friedman podcast with John Carmack: https://www.youtube.com/watch?v=I845O57ZSy4

Weekly Builds

Today we will be talking about a few things, you all should know about:

Containers and the reason we use them.
Hybrid environments.
Darko’s Macbook ECS cluster

Containers:

Just a quick word this. Containers, or more precisely Containerization is application-level virtualization. The reason for this is so that software can be packaged up in these containers and run in isolated “user spaces” called containers!

But why?

Because we want to be able to package the entire running environment of a piece of software into a single bundle and run it on many different platform. Be that the cloud or in that laptop right in front of you! Magic!

On today's episode Jacquie and Darko talk about containers, why you should use them, how to orchestrate them and what do they have to do with a Hybrid environment.

Later in the episode, check out how Darko struggles to add an extrenal "server" to his AWS ECS (Elastic Container Service) cluster. Plenty of fun times were had while troubleshooting.

Links from the discussion:

Nathan Peck’s blog post: https://nathanpeck.com/ingress-to-ecs-anywhere-from-anywhere-using-inlets/
Darko’s cluster (if it is still running): https://macluster.rup12.net/
ECS Anywhere: https://aws.amazon.com/ecs/anywhere/

🐦 Reach out to the hosts and guests:

Jacquie: https://twitter.com/devopsjacquie
Darko: https://twitter.com/darkosubotica

DEV Community: Darko Mesaroš ⛅️

[Boost]

Predicting Your AI Agent's Cost

Learning Rust: Custom Error types that actually work!

Errors Errors

Building my own Error type

Converting other error types

Actual implementation

Asynchronous Rust 🦀 - RustConf 2025 | Day 1

Workshop - Async Fundamentals

Actor Model

Wrap up

Updates from AWS CDK! 🥳

AWS CDK in Action — May 2025: Empowered Deployments, Governance, and Community

[Boost]

AI Agents: how they work and how to build them

[Boost]

Using the Momento Topics HTTP API to Update Nixie Tubes

Amazon Q Developer CLI 1.7.3 - Now with VIM! 😍

1. Simplified Command

2. New Tools Permissions Dialog

3. VIM Integration

4. Multi-line Editing

5. Enhanced Context Controls

Try it out today for free! 🚀

[Boost]

Standardizing AI Tooling with Model Context Protocol (MCP)

Making Makefiles for fun and profit

Table of Contents:

Why Makefiles

Makefile breakdown

Common uses

Terraform automation

Local Development Environment automation

Makefiles 48 years later

My link shortener CDK project

Working with static websites

Wrap up

Build On Live | Observability - Show notes

Individual session notes:

Intro and Welcome

Go Beyond Observability with AI

Some links that were shared:

How to Migrate Observability Platforms With OpenSLO

Some links that were shared:

Intro to eBPF: Explain to Me As if I Was Five

Some links that were shared:

OpenTelemetry—The Industry Telemetry Standard

Some links that were shared:

That's a lot of data! how to manage ingestion and storage costs?

Some links that were shared:

Observability and Distributed Tracing at CNCF

Some links that were shared:

Creating trace data with OpenTelemetry

Some links that were shared:

Talking Observability with Liz Fong-Jones

Some links that were shared:

Build on AWS Weekly - S1 E6 - Local Development Everywhere

Deployed Weekly

Weekly Builds

Build on AWS Weekly - S1 E5 - Containers Containers Everywhere

Deployed Weekly

Weekly Builds

Containers: