Blog

Serverless, it can help you brew beer

25 Oct, 2024
Xebia Background Header Wave

I like to combine technology with something more practical. This helps me understand the technology much better. Plus, when you have a practical example, it’s also easier to explain to my wife and friends. During the coronavirus pandemic, I started brewing beer. Brewing beer involves a lot of steps, and the brewer needs to take many steps. But some steps can be automated!

Brewing 101

Before we dive into the automation part, let’s do a quick brewing introduction. To brew a beer, you need the following ingredients:

  • Malted grains
  • Hops
  • Water
  • Yeast

The grains are crushed just enough to be broken inside. The other layer needs to be somewhat whole. We can then start the mashing process in water around 60 degrees. This will extract the sugars from the grain. When this process is done, you must separate the water from the grain bed. Afterward, you can sparge some additional water through the grain bed to grab the last bits of sugar from the grain.

The product we now have is called wort. Now it’s time to boil the wort. Depending on the recipe, you need to add hops and other ingredients. The general rule for hops is that when you add hops in the beginning, it makes the beer more bitter. Adding more towards the end adds more aroma. The type of hops that you add also plays a role here.

After you boil the wort, it’s time to cool it down. You need to bring the wort back to around 20 degrees. Again, this highly depends on the yeast you are using. When the wort is cool enough, you want to add as much oxygen as possible to it and the yeast.

Close the kettle holding the beer and make sure it has a water lock. The yeast will start eating the sugars in the wort and producing CO2 and alcohol. The CO2 will escape through the water lock, and the alcohol will stay in the wort.

How does Serverless help?

During the fermentation process, the density of the wort changes. It’s slowly changing from wort to beer. The sugars will decrease, and the alcohol will increase over time. But when is this process done?

Density can be measured, so by putting a device in the wort, you can send updates about the density. When you combine this with some cloud expertise, you can build some cool things! Since this device would only send some reading with a value, I don’t need to wait for a response. The API needs to be as fast as possible! When the device waits for confirmation, it consumes more power. Since this device is floating in a fermenting chamber, you can’t hook it up to the power grid or change batteries.

Due to this requirement, I used the API Gateway service from AWS. It allows you to place the incoming payload directly into an SQS Queue. This creates a really fast API for the device floating in my fermenting chamber. Using a queue completely decouples it. A secondary process can just read the messages from the queue and process them accordingly.

How about security

When the device sends its data, it also contains the identifier of the device itself. I used this device ID to link it to a registered device. If the device is unknown, I would just stop processing the message. This would allow you to tie a device to a particular tenant in your solution. However, when you know the endpoint, you can still inject messages. To prevent this from happening, you could use mTLS. The downside in my case is that that has an impact on the battery life. Another other option would be a custom authorizer. This allows you to use a Lambda function to use business logic to decide whether the call can be performed.

In my case, I used the usage plans functionality. The documentation clearly states that you should not use the usage plans for authentication. And I am not! I only use it to limit the pressure on my backend, just in case someone figures out my API endpoint and tries to DDOS me. When the payload is malformed or the device ID is unknown, I will directly drop the messages anyway. So, the impact is limited unless they know the identifiers of my devices.

Conclusion

Real-world examples help illustrate our options for serverless technology. They help you consider other dimensions, like do I have enough battery life? These pros and cons need to be considered during your design. Based on those questions, you might pivot your solution’s architecture.

If you want to know more about what I have automated, make sure you follow me on my social media.

Joris Conijn
Joris is the AWS Practise CTO of the Xebia Cloud service line and has been working with the AWS cloud since 2009 and focussing on building event-driven architectures. While working with the cloud from (almost) the start, he has seen most of the services being launched. Joris strongly believes in automation and infrastructure as code and is open to learning new things and experimenting with them because that is the way to learn and grow.
Questions?

Get in touch with us to learn more about the subject and related solutions

Explore related posts