DEV Community: Josemy Duarte

How to shutdown a Go application gracefully

Josemy Duarte — Sat, 29 Apr 2023 17:59:10 +0000

How to shutdown a Go application gracefully

All this started by noticing that my Go applications showed an increased number of errors when I was shutting them down. After some investigation I found out that the problem was related to the lifecycle of the components of my application. Why was this happening? Because I was not shutting down my application gracefully. Meaning that I was not giving the opportunity to the components to finish their work before shutting down all of them.

Let me explain this with an example.

The problem

Let's say that we have a web server that is using a database. When we receive a request we need to query the database to get the information that we need to return to the client. If we are not shutting down the application gracefully, we might receive an error when we try to query the database because the database connection might be closed before we can use it. Also, we might still have some requests inflight and all of them will fail if the database connection is closed.

The solution

Easy, we need to give the opportunity to the components to finish their work before shutting down the application. In the case of the web server, we need to stop receiving new requests and wait for the inflight requests to finish. In the case of the database, we need to close the connection only after all the requests that are using it have finished.

I noticed a pattern here. I had to shutdown the components in the reverse order that I started them. Meaning, that I had to shutdown the web server first and then the database. This way, I could make sure that the web server was not receiving new requests and that all the inflight requests had finished before closing the database connection. So, I decided to create a Manager struct that will manage the lifecycle of my application. This struct will have a Start method that will start all the components of my application and a Shutdown method that will stop all the components of my application.

The code

Let's see how this looks like in code. First, I defined a common interface for all the components of my application.

type Component interface {
    // Name returns the identifier of the component (mainly for logging purposes)
    Name() string

    // Start is called in order to start the component.
    // The initReady channel should be closed when the component's initialisation has finished. 
    // Some starts are blocking so by closing the channel we signal the manager that it can move on to the next component.
    Start(initReady chan struct{}) error

    // Shutdown is called to stop and cleanup the component.
    // There is a limited time to do so which is controlled by the ctx.
    Shutdown(ctx context.Context) error

    // StartTimeout returns timeout within which the component is expected to be start
    StartTimeout() time.Duration
}

Then, I defined the Manager struct that will manage the lifecycle of my application. It allows to Register new components and since it is important to shutdown the components in the reverse order that they were started, I decided to store them in a slice.

// Manager is responsible for managing all the component's lifecycle.
type Manager struct {
    components []Component
}

// Register registers a new component.
func (m *Manager) Register(component Component) {
    m.components = append(m.components, component)
}

The Start method will start all the registered components of the application. It will iterate over the slice of components and call the Start method of each one of them. It will also wait for the initReady channel to be closed before moving on to the next component. This way, we can make sure that the components are started in the correct order. If the Start method of a component returns an error, the Start method of the Manager will publish the error in the errCh channel and return it.

func (m *Manager) Start() chan error {
    log.Printf("Starting %d components...\n", len(m.components))
    errCh := make(chan error, len(m.components))

    start := time.Now()

    // Start all the components in order.
    for _, c := range m.components {
        log.Printf("Starting component %s...\n", c.Name())

        // Create a channel to signal that the component's initialization is done.
        initReady := make(chan struct{})

        // Start the component.
        go func() {
            errCh <- c.Start(initReady)
        }()

        // Wait for the component's initialization to complete.
        select {
        case <-initReady:
            log.Printf("Component %s initialization completed\n", c.Name())
        case <-time.After(c.StartTimeout()):
            errCh <- StartTimeoutError{ComponentName: c.Name()}

            return errCh
        }

        // Check for errors during startup.
        select {
        case err := <-errCh:
            if err != nil {
                errCh <- fmt.Errorf("failed to start component %s: %w", c.Name(), err)

                return errCh
            }
        default:
            log.Printf("Component %s started successfully\n", c.Name())
        }
    }

    log.Printf("All components started in %v", time.Since(start))

    return errCh
}

The Shutdown method will stop all the registered components of the application. It will iterate over the slice of components in reverse order and call the Shutdown method of each one of them and wait for it to finish before moving on to the next component. This way, we can make sure that the components are stopped in the correct order, and we can give them the opportunity to finish their work. If the Shutdown method of a component returns an error, it will be added to the errs slice, and it will continue with the next component. All the errors will be returned at the end of the method in a single error.

func (m *Manager) Shutdown(ctx context.Context, gracePeriod time.Duration) error {
    log.Printf("Shutting down %d components...\n", len(m.components))

    start := time.Now()

    var errs []error

    shutdownDone := make(chan struct{})
    go func() {
        // Start shutting down all the components in reverse order.
        for i := len(m.components) - 1; i >= 0; i-- {
            c := m.components[i]
            log.Printf("Shutting down component %s...\n", c.Name())

            // Check for errors during shutdown.
            if err := c.Shutdown(ctx); err != nil {
                errs = append(errs, fmt.Errorf("failed to shutdown component %s: %w", c.Name(), err))
            } else {
                log.Printf("Component %s shutdown successfully\n", c.Name())
            }
        }

        close(shutdownDone)
    }()

    // Wait for the components shutdown to complete or timeout.
    select {
    case <-shutdownDone:
        log.Printf("Shutdown finished in %v\n", time.Since(start))
    case <-time.After(gracePeriod):
        return ShutdownTimeoutError{TimeOut: gracePeriod}
    }

    // Check if there were any errors during shutdown.
    if len(errs) > 0 {
        return ShutdownError{Errors: errs}
    }

    log.Printf("Shutdown completed successfully\n")

    return nil
}

The result

We end up with a simple way to control the lifecycle of the components of our application. No component should be stopped without finishing its work, and no component should be started before all the components that it depends on have been started. We have complete control over the order in which the components are started and stopped.

Feel free to check out the full code on GitHub. There are some tests and a simple example of how to use the Manager struct.

Being honest, I don't know if this is the best way to manage the lifecycle of the components of a Golang application, or if I just reinvented the wheel. I would love to hear your thoughts on this.

If you have any suggestions or improvements, you
are more than welcome to open a pull request on the repository.

Why data-driven decision matters

Josemy Duarte — Fri, 16 Jul 2021 09:04:15 +0000

“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.”

― Jim Barksdale

Businesses often make decisions based on opinion rather than facts. Why? I think it is mainly due to 3 main reasons:

Bias - If I think A, most certainly my users/clients also think A
Speed - Planning, experimenting, analysing takes time and resources
Risk - Experimenting imply risk of something going wrong

Let me elaborate I little more on this reasons:

Bias

By following an empirical approach, we ensure that product changes are not driven by the most opinionated and vocal Netflix employees, but instead by actual data, allowing our members themselves to guide us toward the experiences they love.

―The Netflix Tech Blog

Couldn't say it better. But also keep in mind that change is the only thing that it's constant. So keep measuring even after your experimentation has finished, since what was true 2 years ago might not be true today.

Speed

Making a decision just for the sake of moving fast can backfire, as making a mistake can cause a greater delay than running an experiment to make a data-driven decision.

Risk

You need to be very careful how you run your experiments, as doing something wrong can cause your customers to lose money, and consequently, you can lose customers and trust. This could lead managers to avoid making "big" changes and trying new things or simply trying only things that can be done "safely".

Experimentation

Making experimentation easy and safe will increase innovation. Also, keep in mind that It's all about feedback and validating hypothesis. You can't get feedback until it's in your customer's hands.

Having barriers on innovation will have an impact on how fast your company grows. How to approach these issues? First, don't be afraid of your customer's feedback, use it to guide your product evolution. Second, make experiments safe and easy to measure, which will lower the effort required to gather data to make informed decisions.

How do we do that? Having technology and mechanisms that allow you to:

Run your experiments on a small subset of customers. That will allow you to test your hypothesis but also reduce the impact of any possible issue on your experiment.
Monitor all relevant KPI. That allows you to have an eye on how the experiment is going and knowing if something is wrong at any given moment.
Make it easy to turn off any ongoing experiment. If you notice any undesired result from your metrics, you will be able to stop it before it has a greater impact on your customers.

Don't forget that simplicity is key for this to succeed. So avoid burying this under heavy processes and try to keep them as lightweight as possible, so engineers don't feel discouraged to run experiments.

Creating a Twitter Bot with Go

Josemy Duarte — Sat, 13 Mar 2021 13:02:55 +0000

I keep experimenting with go and bots, so this week I decided to create a Twitter bot. It's not the typical bot that just publishes things or does some scraping, this one will react to mentions; each time someone mentions the bot, it will reply with a "hello". This is possible through the Account Activity API of Twitter, which will call our service for every new event related to our bot.

Brief explanation

The code is pretty simple and straightforward, so I will not get into too many details; there are 3 endpoints on our server:

POST `/webhook/twitter`

This is where the behavior of our bot lives. So, in my case is only replying with "hello", but here is where you would make any customization in case you clone/fork it.

GET `/webhook/twitter`

For security reasons, Twitter requires us to have an endpoint that will solve a CRC request. So we follow Twitter guidelines and that's what this endpoint is doing.

POST/GET... `/`

Nothing fancy. Just returning "Server is up and running" for you to make sure that the server is up and running.

Fork it, clone it, use it!

Feel free to clone/fork the repo and customize it to your need. You will find instructions to deploy it on Heroku or even try it on your machine if you want.

Putting Text on an Image with Golang

Josemy Duarte — Tue, 02 Mar 2021 11:37:02 +0000

Since the beginning of my career, I have been focused on Java as my main programming language, but recently I switched to a company that uses Golang, and to help me to learn more about the language I decided to build something.

The service that I build in summary just puts some text on a given image. Its main purpose is to help me create the posts that I publish on my Instagram account DevsQuotes.

I used to create my posts with Photoshop but it was taking me too much time to get a simple image ready, then I discovered Adobe Spark which simplified the flow a little, but with this service now is super simple since I integrated it with a Telegram Bot and now I just need to send a message and I have my image ready to be published. Yes, there is room for improvement, but keep in mind that this was just a PoC which mission was to help me get comfortable with GoLang and simplify the process to create images for my Instagram.

TL;DR Show me the code!

type Request struct {
    BgImgPath string
    FontPath  string
    FontSize  float64
    Text      string
}

func TextOnImg(request Request) (image.Image, error) {
    bgImage, err := gg.LoadImage(request.BgImgPath)
    if err != nil {
        return nil, err
    }
    imgWidth := bgImage.Bounds().Dx()
    imgHeight := bgImage.Bounds().Dy()

    dc := gg.NewContext(imgWidth, imgHeight)
    dc.DrawImage(bgImage, 0, 0)

    if err := dc.LoadFontFace(request.FontPath, request.FontSize); err != nil {
        return nil, err
    }

    x := float64(imgWidth / 2)
    y := float64((imgHeight / 2) - 80)
    maxWidth := float64(imgWidth) - 60.0
    dc.SetColor(color.White)
    dc.DrawStringWrapped(request.Text, x, y, 0.5, 0.5, maxWidth, 1.5, gg.AlignCenter)

    return dc.Image(), nil
}

That piece of code makes all the magic. With the help of Fogleman library manipulating images in Go is a breeze. Let's check what this is doing:

bgImage, err := gg.LoadImage(request.BgImgPath)

It loads the image in which the text will be printed.

imgWidth := bgImage.Bounds().Dx()
imgHeight := bgImage.Bounds().Dy()

Records the Width and Height of the image.

dc := gg.NewContext(imgWidth, imgHeight)
dc.DrawImage(bgImage, 0, 0)

Creates something like a canvas (or context) in which we are going to start working.

dc.LoadFontFace(request.FontPath, request.FontSize)

It loads the font to use on the message to be printed.

x := float64(imgWidth / 2)
y := float64((imgHeight / 2) - 80)

Records the middle of the image on X and in Y it also subtracts 80 because I want the text to be a little bit above the middle.

maxWidth := float64(imgWidth) - 60.0

We define the maximum width that your text can occupy. Subtracting 60 from the total width of the image is like generating a margin, so our text does not reach the edge of our image.

dc.SetColor(color.White)

We are defining the color in which we are going to paint/print

dc.DrawStringWrapped(request.Text, x, y, 0.5, 0.5, maxWidth, 1.5, gg.AlignCenter)

It prints the content of request.Text on our canvas in the middle of the image with an alignment centered.

The result will look like this:

For more context on how all this works and even try it by yourself if you want visit the DevsQuotesPrinter repository. It has instructions for you to be able to deploy it on GCP, Heroku or to try it locally, so feel free to play with it.

Do I really need to test my code?

Josemy Duarte — Sun, 28 Feb 2021 14:01:01 +0000

It is difficult to find any developer who does not agree with the title of this publication, even more, if asked in a job interview. Although, some developers took what Kent Beck once said "I get paid for code that works, not for tests" as a license to not create tests at all. I think we should take his words with special care. He did not mean that you should not develop tests because you are not paid for that, but that you must concentrate on your production code.

Tests are important because they give you confidence when you make changes and ensures a certain level of quality in the service being tested. They also serve as some kind of documentation of the expected behavior of a piece of code. But everything needs moderation, no tests might be as harmful as too many bad tests.

Now, if the title question creates debate, the following content might not be for all audiences.

What should I test?

I know of companies that do not care at all about test coverage, others that think anything below 90% is bad. So, how much testing is enough?

Do I need 100% Coverage?

Continuing with Kent Beck quotes I would like to bring one of your tweets on this topic:

Being proud of 100% test coverage is like being proud of reading every word in the newspaper. Some are more important than others.

--Kent Beck (@KentBeck) Dec 24, 2016

Also, as pointed in his book Extreme Programming Explained: Embrace Change:

It is impossible to test absolutely everything, without the tests being as complicated and error-prone as the code.

Testing everything will probably lead you to perform non-orthogonal tests, which increases the likelihood that when you make a small change in your code, thousands of tests will be broken. Then, you spend more time fixing tests than creating code that works.

When making small changes causes many tests to break, developers are afraid to make changes because each time this happens they feel frustrated and unproductive. If we take into consideration that one of the reasons for testing is to feel safe when making changes to the production code, then we can agree that there is something wrong with the equation.

So, no, I don't think you need 100% coverage. I know that is a controversial statement, there are some good reasons to argue the contrary, but I think that the pros of that aren't enough to aim for 100% coverage.

What is (not) a Unit Test?

Sometimes is easier to define something by saying what is NOT, and Michael Feathers can help us with that. For him a test is not a unit test if:

It talks to the database
It communicates across the network
It touches the file system
It can't run at the same time as any of your other unit tests
You have to do special things to your environment (such as editing config files) to run it.

You might ask: Why? Well, mainly because tests that do that sort of thing are generally slow and cause unstable tests. The idea of tests is to give you quick feedback on your code; If something broke or if you have the desired behavior; If you have tests that work sometimes and fail other times without obvious reasons, you will lose confidence in your tests, ignore them because "it is normal for these tests to fail".

Finally, unit tests must be quick, they are designed to give you quick feedback. You should not have to think twice before executing them. If they are slow, they lose their reason. Developers will not execute them so often, they will avoid wasting that time.

Should I test third-party libraries?

Well, if you do it, for sure it won't be an easy task. Steve Freeman in his book Growing Object-Oriented Software, Guided by Tests has a couple of good arguments to persuade you to avoid it:

Depending on the quality of the library might be hard to get the right state to be able to test it.

When you use a third-party library, you must adapt to its design implementation. You gain the value of what they provide but lose some freedom in the implementation. Sometimes, that design is not easy to test and will require a lot of work just to establish the correct state to be able to test it. Also, you have to deal with the second point:

Pain to keep test up to date with upgrades to the library.

Even if you are using an open-source library and can redefine the API to facilitate testing and use for your purpose, you will have to spend some time each time a library update is required.

So, what should we do? No tests at all? No. Define an adapter, test the adapter. And later test these adapters with focused integration tests to confirm your understanding of how the third-party API works.

There are some exceptions where mocking third-party libraries can be helpful. We might use mocks to simulate behavior that is hard to trigger with the real library, such as throwing exceptions. Similarly, we might use mocks to test a sequence of calls, for example making sure that a transaction is rolled back if there’s a failure.

Testing private methods

In Pragmatic Unit Testing, Dave Thomas and Andy Hunt write:

Most of the time, you should be able to test a class by exercising its public methods. If there is significant functionality that is hidden behind private or protected access, that might be a warning sign that there's another class in there struggling to get out.

A private method usually is an implementation detail. Testing implementation details is not good for your health. Usually causes that when you do a small refactor many tests fail. You should be able to test your classes through its public methods.

Testing implementation Details

Programmer tests should be sensitive to behavior changes and insensitive to structural changes. You write a new test when you need to fulfill a new requirement, no because you created a new method or class. That means that you should not write a new test just because you refactored the code, a refactor is a structural change, hence the behavior should remain the same.

When you test implementation details instead of behavior there are a couple of things that can go wrong:

Break when you refactor application code. False negatives
Not fail when you break the application code. False positives

The first one, because your test is highly coupled to the structure of your application code. The second one, because you are testing structure, not behavior.

To put closure on this subject I would like to quote Ryan Fynke. In his article he found an elegant way to put the difference between testing implementation details and behavior:

When I test for behavior, I’m saying:

“I don’t care how you come up with the answer, just make sure that the answer is correct under this set of circumstances”

When I test for implementation, I’m saying:

“I don’t care what the answer is, just make sure you do this thing while figuring it out.”

PD: Just for fun, read this story.

My path to AWS Solutions Architect - Associate certification

Josemy Duarte — Sun, 17 Jan 2021 19:43:50 +0000

I finally got the AWS certification 🤓! I read many stories about how people prepare to pass this exam. Everyone has their own way of learning so I wanted to build my own strategy out of all the things that I felt could help me from the experiences of others. Now I want to share how I did it, hoping I can help someone.

Some background

For me, scheduling the exam was difficult because I always felt that I was not ready for it, that I could study more. But in January 2020, I found the strength to schedule my exam; I didn't feel like I was 100% ready, but I didn't want to put it off. How did I convince myself to do it? I thought that even if I didn't pass the exam, I would get the experience of doing it and know how difficult it was (maybe it was easier than I was imagining) and what knowledge required a little more of work on my side. In the worst case, I could use that experience to pass it on a second try, right? So I scheduled it for the end of March. Unfortunately, COVID had other plans. Due to the lockdown, my exam was canceled. I forgot about certification for a few months until I noticed that the year was ending and I hadn't rescheduled the exam, so again I had to convince myself to schedule an exam. Now it was for the 7th of January 2021, and this is what I did to prepare myself...

A Cloud Guru

I found that A Cloud Guru offered a specific course that prepares you to pass the AWS Solutions Architect exam, so I decided to give it a try. It has some "Exam Tips", some quizzes to test your knowledge, a certification-like exam, and some labs that you can follow with a demo account that they provide you so you can try everything they teach you, without using your own AWS account and no unwanted charges. I found those labs helpful for hands-on experience with products that I never had a chance to test. In addition, there is a public forum where people can ask the instructors questions. Sometimes you find your doubts already answered.

FreeCodeCamp

The last two weeks before my exam, I watched the FreeCodeCamp video. It is an 11-hour video that describes and shows all AWS services related to Solutions Architect certification. It has a nice cheat sheet at the end of each section (pay special attention to those).

Jon Bonso's Practice Exams

Reading about people's recommendations on preparing for certification, I came across many recommendations for the Jon Bonso Practice Exams. In the end, you don't know how good your progress is if you don't measure it. The Udemy course gave me 6 practice exams with the same number of questions you face for certification. The best part is that once the exam is over, it not only tells you whether or not you passed but shows you all your wrong answers with a detailed reason of why your choice was wrong and why the other option was better. I found that explaining why my reasoning was wrong gave me a better understanding of AWS services.

So the day before my exam I took all the practice tests again to see if I could pass them on the first try and feel comfortable with the type of questions and the time constraints.

Advise

I would recommend people to read the FAQs of the services tested in this certification. I didn't, and I think that had some repercussions on my final score. I was too focused on taking practice tests and watching the videos that I didn't read the FAQs. Don't miss out on those points and take a few minutes to read those pages.

Pass the exam and celebrate!

And that was all, with those 3 things I was able to pass my certification. I wish you all the best if you are preparing for it!

Also, keep in mind that A Cloud Guru subscription may not be suitable for everyone; I mean, it costs more than AWS certification alone. I'd say it's useful if you want to learn other things too (it has courses for other certifications and for other cloud providers). Alternatively, you can follow the FreeCodeCamp labs with your AWS free tier account and just remember to clean up all resources to avoid unplanned charges.

How to automate tests for webhooks

Josemy Duarte — Thu, 24 Dec 2020 12:30:10 +0000

Problem

Has it happened to you that you are coding a test that requires you to wait for a webhook notification? It is a problem because normally the third-party service is outside your network and your machine will not hear their notification unless you provide them with your public IP, and sometimes the public IP is not a feasible option.

The automated tests that I have seen for these scenarios aren't too pretty. So maybe there is a better/prettier way to do this, but I wanted to share my approach in case anyone finds it useful.

Why?

When your code needs to interact with a third party, you should probably take some time to read their documentation to learn how to make requests to them and how they will respond.

Unfortunately, sometimes their documentation is out of date and when that happens your trust in their documentation disappears. Therefore, you will want to see for yourself that everything really works as expected and be prepared for any undocumented behavior that you encounter.

Besides that, I think it's useful to have tests between my code and anything outside my control to be able to know that everything works as expected.

How?

I used testcontainer to integrate into my tests the lifecycle of the Docker containers that I required. Testcontainer lets me forget about having to run docker run and docker stop before and after running any of my tests, as it integrates those commands with the start and finish of related tests.

I used ngrok to open a tunnel from the Internet to my container so the webhook could target the server waiting on my test. In other words, it allows me to have an URL for my public IP and makes accessible my machine from outside my private network.

And a small web service that will be listening for any request made to the Ngrok URL.

Proposal

Putting all the pieces together this is more or less what I build to be able to automate a webhook test.

To illustrate what I did I made a dummy project that you can find here.

Please, feel free to suggest improvements and suggestions 😉

Originally posted on josemyduarte.github.io

Earthly: building automation tool

Josemy Duarte — Mon, 13 Jul 2020 08:33:17 +0000

There is a new building automation tool in the neighborhood named Earthly. Its intention is to simplify CI pipelines, but nothing like an image to explain it better:

I would describe it as a docker multistage build with batteries. It actually has a Docker-like syntax.

These are some features right from their repo:

🐳 Build anything via containers - build container images or standalone artifacts (eg binaries, packages, arbitrary files)

🛠 Programming language agnostic - allows use of language-specific build tooling

♻️ Reproducible builds - does not depend on user's local installation. Runs the same locally, as in CI

⛓ Parallelism that just works - builds in parallel without special considerations the user has to make

🏠 Mono-repo friendly - ability to split the build definitions across a vast directory hierarchy

🏘 Multi-repo friendly - ability to import builds or artifacts from other repositories

Building something with Earthly

Some days ago while taking a look at Quarkus I found Funqy, part of Quarkus’s serverless strategy that aims to provide a portable Java API to write functions deployable to various FaaS environments like AWS Lambda, Azure Functions, Knative, and Knative Events (Cloud Events). So I decided to see how easy would it be to build a simple "Hello World" with Funqy and Earthly.

I'm not going to focus on the Funqy part since I simply followed their guide. I wanted to know how complicated it would be to define a build.earth file that allowed me to test and build a native quarkus application. This was the result:

FROM quay.io/quarkus/centos-quarkus-maven:20.1.0-java11

WORKDIR /java-example

deps:
    COPY pom.xml ./
    RUN mvn -B de.qaware.maven:go-offline-maven-plugin:1.2.5:resolve-dependencies
    SAVE IMAGE

build:
    FROM +deps
    COPY src src
    RUN mvn -Pnative clean package
    SAVE ARTIFACT target/ /target AS LOCAL target

With that file, I am creating a reproducible build that will create a target folder with my artifacts.

As said before, it is very similar to Dockerfile syntax. Apart from just a few new intuitive commands, if you know Docker you will get comfortable with Earthly really fast.

Describing build.earth

base

This section initializes the build environment, it is like a base for all other steps, it applies to all "targets".

(1) Base Docker image

(2) Setting working directory

(1) FROM quay.io/quarkus/centos-quarkus-maven:20.1.0-java11
(2) WORKDIR /java-example

deps

This section gathers all my project's dependencies.

(3) Target's name

(4) Copy the pom.xml to allow earthly to create a layer/cache of the dependencies of my application.

(5) Runs maven and download all my application dependencies.

(6) Saves this container as an image. This allows the following steps/targets to use all the hard work done by these commands.

(3) deps:
    (4) COPY pom.xml ./
    (5) RUN mvn -B de.qaware.maven:go-offline-maven-plugin:1.2.5:resolve-dependencies
    (6) SAVE IMAGE

build

This section actually builds my artifact.

(7) Target's name

(8) Defines that this target is built from deps target. There is a dependency.

(9) Copy all my source code into the container.

(10) Maven command to execute all my tests and build my artifact.

(11) Saves output into my machine on a target folder.

(7) build:
    (8) FROM +deps
    (9) COPY src src
    (10) RUN mvn -Pnative clean package
    (11) SAVE ARTIFACT target/ /target AS LOCAL target

Of course, this is a toy example. You can have earthly files way more complicated (even multi-repo projects). It was also really easy to integrate it into Github Actions. This is the repo for anyone who might want to take a deeper look Earthly Repository.

Originaly posted on my personal blog

AWS Lambda: Quarkus vs Plain Java

Josemy Duarte — Mon, 29 Jun 2020 05:49:09 +0000

In my current job I've been using AWS Lambda with plain Java 8, and to be honest, the first time this didn't sound too good for me. I mean, don't get me wrong, I'm mainly a Java Developer, but from previous experiences, I know how slow a Spring Boot app can be to start and the fact that serverless functions have what it's known as "Cold Start" didn't make too much sense for me.

However, they didn't have too many problems with cold starts because first, plain Java (no framework) is faster than SpringBoot and second for those services that it is unaffordable a cold start there is something called "Warm Up" which previously it was just a CRON that would make a call to your Lambda to keep it alive and avoid cold starts, but now AWS has released a new feature called "Provisioned Capacity" which will initialize the requested number of execution environments so they can be ready to respond to invocations.

On the other hand, not so long ago I saw a demonstration given by a RedHat employee of their new project Quarkus. It showed how incredibly fast it was to start a Java app and how well it works with Kubernetes, as Quarkus was meant to make Java more cloud-friendly.

Just a few days ago, my brain decided to relate AWS Lambda with plain Java (as in my current job) and Quarkus, and I was wondering what the results would be in terms of cold start, memory, and speed for the following requests. So this is my experiment, probably not the most scientifically accurate, but I hope it gives you an idea of the performance of these technologies with AWS Lambda.

Experiment

I developed two simple projects: one with Java 8 with the default DynamoDB client and the other with Quarkus and the Quarkus DynamoDB client. Both projects will simply print the received request, query an existing DynamoDB item, and return it. At the end of the post, you will find the repositories if you want to play around with them (note that the code is not beautiful, it was developed just for the sake of this experiment). And these are my findings:

Plain Java 8

Code

public class HelloLambdaHandler implements RequestHandler<GameScoreRequest, DynamoGameScore> {

    public DynamoGameScore handleRequest(GameScoreRequest input, Context context) {
        System.out.println(input);
        final GameScoreRepository repository = new GameScoreRepository();
        return repository.find(input.getUserId()).orElseThrow(NoSuchElementException::new);
    }
}

Logs

Quarkus Java 11

Code

@Named("test")
public class TestLambda implements RequestHandler<GameScoreRequest, DynamoGameScore> {

    @Inject
    GameScoreRepository repository;

    @Override
    public DynamoGameScore handleRequest(final GameScoreRequest input, final Context context) {
        System.out.println(input);
        return repository.get(input.getUserId());
    }
}

Logs

So, in terms of cold start, we can appreciate that for the first request Plain Java 8 took almost 24800ms to finish while Quarkus did it in less than half with 9000ms.

The following requests with the function "hot" took Plain Java 8 an average of 484.78ms. While for Quarkus it took an average of 503.55 ms. Since these numbers are only for 3 requests and the numbers are very close to each other, I would dare to say that they would probably converge to the same number with a larger sample. Anyway, we can accept that after the cold start, the following requests seem to last more or less the same in Plain Java 8 or Quarkus.

In terms of memory, it's fair to note that Quarkus (172mb) required more memory than Plain Java 8 (137mb). But keep in mind that Quarkus provides us with a dependency injection feature (among other things) that our other option doesn't provide.

Yeah, I know, probably I should try making 1K requests and take the average or probably my code is not fair with one of the subjects under test, I'm completely open to suggestions, but what I can guarantee is that I did this 3 times (destroying all the infrastructure and creating it again) and the results were similar.

Another point to take into consideration is the size of the package uploaded to AWS. We can appreciate that in this case, Quarkus is heavier than Plain Java 8.

PD: I know there is a feature in Quarkus that allows us to produce a native app, which could have a faster cold start, but so far I have not been able to get it to work with AWS Lambda. When I make it work I will publish my findings.

Repositories

Quarkus
Plain Java 8

DEV Community: Josemy Duarte

How to shutdown a Go application gracefully

How to shutdown a Go application gracefully

The problem

The solution

The code

The result

Why data-driven decision matters

Bias

Speed

Risk

Experimentation

Creating a Twitter Bot with Go

Brief explanation

POST /webhook/twitter

GET /webhook/twitter

POST/GET... /

Fork it, clone it, use it!

Putting Text on an Image with Golang

TL;DR Show me the code!

Do I really need to test my code?

What should I test?

Do I need 100% Coverage?

What is (not) a Unit Test?

Should I test third-party libraries?

Testing private methods

Testing implementation Details

When I test for behavior, I’m saying:

When I test for implementation, I’m saying:

My path to AWS Solutions Architect - Associate certification

Some background

A Cloud Guru

FreeCodeCamp

Jon Bonso's Practice Exams

Advise

Pass the exam and celebrate!

How to automate tests for webhooks

Problem

Why?

How?

Proposal

Earthly: building automation tool

Building something with Earthly

Describing build.earth

AWS Lambda: Quarkus vs Plain Java

Experiment

Plain Java 8

Code

Logs

Quarkus Java 11

Code

Logs

Repositories

POST `/webhook/twitter`

GET `/webhook/twitter`

POST/GET... `/`