DEV Community: Evandro Pires

Is Serverless expensive at scale? Only if you are using it wrong

Evandro Pires — Mon, 29 Sep 2025 17:17:47 +0000

I have been part of the serverless ecosystem for some years now. I have spoken not only in Brazil, but also in Latin America and the US, sharing knowledge and use cases through talks, the Sem Servidor podcast, and the events I organize on this topic.

During these years I always heard the same objections about serverless. I can say they usually focus on three points:

At scale it becomes too expensive
Vendor lock-in is a blocker
It adds too much complexity

I will make a series of posts about each one of them. For now, let’s start with the first one.

Breaking biases

When we talk about serverless, what comes to your mind? Let me guess: function as a service (or Lambda, for those who use AWS).

That is very good, and Lambda helped to democratize serverless a lot. But at the same time, it created a big bias: the idea that serverless is only function as a service. In reality, serverless is a much bigger ecosystem.

By concept, serverless means services where you don’t need to manage servers to have automatic scalability and high availability.

Bias 1: Serverless is only Lambda. Lambda is important and works as the glue for many serverless architectures, but we cannot reduce serverless to this service alone.

Lambda is an important type of compute, but it is not the only one. For example, in AWS we can run containers in ECS Fargate with no servers to manage, with high availability and automatic scalability. When Lambda is not a good fit, this is a strong alternative for building software with very low operational effort.

I am using it in one of the operations I am involved with, and the time spent on operations is close to zero — a great cost-benefit.

Bias 2: Containers are not serverless. Yes, we can run containers in a serverless way and enjoy the advantages of low or zero operations while still having scalability and availability.

And serverless is not only about compute. We also have serverless services for storage, databases, messaging, and more.

Let me guess again: you use S3 every day, like drinking coffee. Then you are already using serverless. If you used SQS, that is serverless too.

Most of the time these services work very well, even at scale, without being a problem.

I am not here to defend serverless at all costs. My point is to help you think clearly: not everything makes sense for every case, and not everything is bad either.

Bias 3: Serverless is only compute. In reality, we already use many serverless services like S3, SQS, and API Gateway without even thinking of them as serverless. And when people say “serverless is too expensive”, many times they are only talking about Lambda.

But there is more to explore.

Architecture that makes costs work

Designing an architecture that balances infrastructure cost and operation cost (people’s time) is complex. And this is where human thinking still adds value, even with AI growing in our work.

First, remember: we cannot look only at infrastructure costs (the cloud bill). We also need to consider the time spent by the team to make everything run: scaling services, configuring servers, deployments, and so on. All this is part of the cost.

The serverless paradigm was created to be event-driven. To get the best of scalability, availability, and costs, we need to bring our architecture closer to this model.

Just doing lift-and-shift of an old app into synchronous functions or containers will not work. If the goal is only “to be in the cloud”, then other services are cheaper and better, of course.

But if the goal is to get the best from the cloud, then serverless can be your strongest ally.

For example, the granularity of a Lambda function can make the difference between sustainable cost or exploding bills. Many successful cases of Lambda use group CRUD operations into a single function instead of splitting too much.

And don’t forget: Lambda is not the only compute. In many real scenarios you will have both containers and functions, working together, orchestrated by workflows or event brokers.

No architecture can save a bad business model

Who never worked in a company where the pressure to reduce cloud costs was constant? Of course, optimization is important, but many times we don’t stop to ask: is the business model aligned with the architecture? Or the other way around?

The truth is: no architecture can save a bad business model. What works is a good architecture aligned with the business. If costs grow but revenue does not, the problem is not only technical.

Building a cloud solution is not only about writing code, some endpoints, and a web page. Maybe it works in very the beginning to validate an idea. But when we talk about scale, the architecture and the business model must be aligned.

The services where cost really hurts

There are some services considered serverless (even with some controversy) that are expensive by design, not by misuse.

Aurora Serverless v2 is one example. It has great elasticity and value, but for small workloads the baseline cost can be too high.

OpenSearch Serverless is another case. It should be the obvious choice for vector search in LLM use cases, but many people prefer Postgres with vector extensions because the entry cost of OpenSearch is high.

These services need more attention to make sense, especially in early-stage startups where cost sensitivity is high.

Conclusion

We saw that serverless is not only Lambda or functions. It can also be containers. And it is not only compute: it includes storage, messaging, and highly managed services.

We need to avoid the trap of forcing the traditional model into serverless. Instead, we should adapt to event-driven design to get the best results, especially in cost.

And remember: the business model must be aligned with the architecture. If the factors that increase costs are not the same that increase revenue, no architecture (and no FinOps) will fix it.

Used in the right way, serverless gives cost predictability and reduces waste, especially compared with provisioned infra built for peaks.

If you want to learn from experts and companies that are succeeding with serverless, I invite you: on November 8th we will discuss this in depth at ServerlessDays São Paulo — a full day of real experiences, myths and truths, and how to scale without surprises.

About the author

Evandro Pires is co-founder of tnkr and an entrepreneur in different areas. He worked as CTO of one of the biggest tech companies in Brazil, where he led Cloud Native, Data, AI, SRE and DevOps teams, impacting more than 1 million users every month. Recognized as the first AWS Serverless Hero in Latin America, he is also an ambassador of sls.guru in the region.

He is the creator of the Sem Servidor podcast and organizer of the Sem Servidor Conf and ServerlessDays São Paulo, initiatives that grow the serverless community in Latin America.

He has been programming since he was 12 years old, when he learned to code with his father in Clipper. He is a pizza lover and enjoys making pizzas on weekends to have fun with his family.

What serverless developers need to know about the 12 Factors

Evandro Pires — Thu, 04 Sep 2025 02:34:35 +0000

Building distributed, scalable, and resilient systems is a more and more difficult task. When we choose serverless architectures, it’s not different, even serverless giving us many of the things we need for this kind of solution.

In this context, the 12-Factor App model, first proposed by Heroku in 2011, is still a valuable guide to align good practices in development, operations, and maintenance of modern applications. And more: it fits almost naturally with the serverless model, but there are important differences.

In this article, we will explore each of the 12 factors, understand how to apply them in serverless environments (especially on AWS), and show examples from the special episode of the Sem Servidor podcast, with Evandro Pires, Caio Henrique Pardal, and Gabriel Oswaldo.

What Are 12-Factor Apps?

The 12-Factor App model defines a set of good practices to build modern SaaS applications that are scalable and portable. It is not a strict method, but a philosophy of architecture that tries to guarantee:

Easy maintenance over time
Portability between environments
Horizontal scalability
DevOps practices included by default

These factors can be used with monoliths or microservices, but they become even more important in serverless architectures, where services are small, temporary, independent, and highly scalable by default.

“The only thing we know for sure when we build software is that it will get worse over time,” said Gabriel Oswaldo in the podcast. “The 12 factors appear as a guide to slow down this erosion.”

Factor 1: Codebase

"One codebase tracked in revision control, many deploys"

The application should have one single versioned codebase, stored in a system like Git. Even if there are many deployments (like production and staging), they must come from the same codebase.

This is already well-known in software development. But in serverless, the challenge is how granular this codebase should be.

Even with many Lambda functions, the ideal is that each system has a clear and versioned codebase, with consistent deploys.

“It’s important to understand who is calling the Lambda, what is its context, and how the functions are grouped around a goal. That helps organize the codebase better.” — Caio Pardal

Serverless best practices:

Use monorepos organized by business domain
Group Lambdas by business context, not by single function
Tools like Serverless Framework, SAM, or SST help with unified versioning

Factor 2: Dependencies

"Explicitly declare and isolate dependencies"

All dependencies must be declared clearly, isolated, and versioned, to make the application environment reproducible and predictable.

In serverless, each function has its own environment. Poorly managed dependencies increase build time, cold starts, and make maintenance harder. All of this results in something worse: unnecessary costs.

“Lambda Layers help share dependencies, but you need to be careful with versioning,” says Gabriel. “Sometimes it’s better to include dependencies inside the function than to create a generic layer that becomes a mess.”

Serverless best practices:

Declare dependencies in package.json, requirements.txt, or pom.xml, isolated by function for better optimization, but calculate the productivity cost of this granularity
Use Lambda Layers with strict versioning
Prefer small libraries (avoid big monolith libraries)

Factor 3: Config

"Store config in the environment"

Application configurations, like credentials, environment variables, and external URLs, must be outside the code, and possible to change without new deployments.

Environment variables are the best place to store configurations, but they should never be in the code.

“This is essential in distributed systems, because each function can have different configs,” explains Evandro.

Serverless best practices:

Use AWS Systems Manager Parameter Store or Secrets Manager
Never store tokens or keys in the code
Use IAM to limit access by function

Factor 4: Backing Services

"Treat backing services as attached resources"

External services like databases, queues, caches, or APIs must be treated as attachable and replaceable resources, without needing big changes in the code.

In serverless, everything is a backing service: databases, caches, queues, authentication systems. Decoupling is already the default.

“The cool thing about serverless is that it makes you think plug-and-play,” says Evandro. “You connect S3, Dynamo, API Gateway... everything as decoupled resources.”

Serverless best practices:

Treat everything as a service: S3, RDS, DynamoDB, Cognito, etc.
Replace services without coupling (example: switch Redis for DynamoDB as cache)
Use environment variables to configure URLs and access

Here we have an important discussion in serverless. On one side, some people say serverless forces vendor lock-in - because of these native connections with the cloud provider. On the other side, the 12-Factor App encourages using software engineering standards to reduce this dependency. So, it creates a good balance.

Factor 5: Build, Release, Run

"Strictly separate build and run stages"

These three stages in the app’s lifecycle (build, package, and execution) must be separated clearly. This allows control and traceability between versions.

In serverless, the build usually creates a zip package or a container image. The release can be done using CI/CD. The run happens in Lambda.

“Lambda already forces you to do this right,” says Gabriel. “You have to package, upload to the cloud, and use a pipeline.”

Serverless best practices:

Use tools like CircleCI, GitHub Actions or even CodePipeline
Automate deploys with Infrastructure as Code (IaC)
Use blue/green or canary deployments — Lambda has this natively

Factor 6: Processes

"Execute the app as one or more stateless processes"

The application must run as one or more stateless processes. Persistent data or context must be stored outside the function.

This is the heart of serverless when using Lambda: temporary executions with no local state.

“Lambda is literally a stateless process that scales to zero” remembers Gabriel.

Serverless best practices:

Store state in DynamoDB, S3, or external databases
Avoid global variables inside functions
Use Step Functions to orchestrate long-running processes

Factor 7: Port Binding

"Export services via port binding"

The app should expose itself as a service, listening on a defined port and accessible via protocol, without needing external application servers.

In serverless, this is done by API Gateway, AppSync, or EventBridge (to share only a few examples). The app “listens” to events or endpoints and reacts to that.

Serverless best practices:

Define API contracts with OpenAPI/Swagger or event contracts with EventBridge, including versioning
Use API Gateway or AppSync to expose the app
Use separate handlers for each endpoint — this helps with portability

Factor 8: Concurrency

"Scale out via the process model"

Scalability should come from running independent processes in parallel, allowing horizontal scaling when demand increases.

Serverless already scales automatically per request. Each invocation creates a new isolated process.

“Scalability is built-in. You just need to make sure your code is ready for it” says Caio.

Serverless best practices:

Check AWS concurrency limits (concurrency reserve)
Use queues (SQS, Kinesis) to manage traffic spikes
Avoid race conditions by using transactional control in the database

Factor 9: Disposability

"Maximize robustness with fast startup and graceful shutdown"

App processes should be disposable, they can start and stop quickly. This helps with resilience, continuous deployment, and scalability.

Cold starts are the main challenge here. But, with good practices, you can reduce the impact of it. And remember: microservices also have cold starts! When they need to scale, they take some time to start receiving requests — this is also a cold start. The difference is the scale and granularity.

“Lambda is born and dies. So everything must be ready to run from the beginning with no previous state. That’s pure disposability.” — Gabriel Oswaldo

Serverless best practices:

Depending on the case, use lightweight runtimes (Node.js, Go)
Keep dependencies small
Use Lambda Provisioned Concurrency when necessary

Factor 10: Dev/prod parity

"Keep development, staging, and production as similar as possible"

The dev, staging, and production environments should be as similar as possible to avoid errors caused by differences.

Serverless helps a lot here. In traditional environments, keeping dev and staging close to production is expensive. In serverless, you can create environments that are very similar and low-cost — you only pay for what you use.

“We use a dev environment very close to production because everything is serverless. Tools like serverless-offline or localstack help, but the real benefit comes when you automate everything with IaC.” — Caio Pardal

Serverless best practices:

Use separate stacks per environment with IaC (like Terraform, SAM or Serverless Framework)
Automate deploys per environment
Emulate services locally with localstack or SAM CLI — but many people prefer using the real cloud

Factor 11: Logs

"Treat logs as event streams"

Logs must be treated as continuous event streams, sent to an external system where they can be stored, indexed, and analyzed.

Lambda sends logs to CloudWatch automatically. The challenge is to collect, aggregate, and monitor them properly. And another challenge is cost. Careless logging in serverless can get expensive.

“CloudWatch is the default in serverless, but it’s not enough. We aggregate logs with Datadog and also use JSON format to make analysis easier.” — Gabriel Oswaldo

Serverless best practices:

Aggregate logs using CloudWatch Logs Insights or AWS OpenSearch
Integrate with Datadog, Grafana, Lumigo, or similar tools
Use structured logs in JSON format — Powertools for AWS Lambda helps standardize this

Factor 12: Admin Processes

"Run admin/management tasks as one-off processes"

Admin tasks and scripts (like database migrations or maintenance commands) should be done in isolated processes, outside the main app flow.

In serverless, use one-time functions, automated scripts, or temporary jobs.

“With Lambda it’s easy to create admin scripts. We have several functions just for data maintenance, triggered by events or scheduled on EventBridge. That’s way better than mixing it with the main app.” — Gabriel Oswaldo

Serverless best practices:

Use scheduled Lambda functions, Step Functions, or Fargate for batch jobs
Never include maintenance scripts in the main app flow
Separate admin functions with different IAM roles

Conclusion: Serverless and the 12 Factors Work Together

Many of the 12 factors are already built into serverless, but understanding the principles behind them helps avoid traps like too much coupling, messy deployments, or poor observability.

“The secret is to know the principles and apply them smartly. Serverless encourages good practices, but also needs responsibility.” — Evandro

The 12 factors are still a reliable guide to build software that ages well. And when applied to a well-architected serverless environment, they don’t just make sense — they increase your ability to deliver value with speed, scale, and quality.

🎧 Listen to episode 39 (only in Portuguese) of the Sem Servidor Podcast about the 12-Factor App — available on audio platforms or YouTube.

Sem Servidor Podcast

The Sem Servidor podcast is an initiative to share serverless and cloud computing knowledge in Portuguese.

🎙 Listen to many episodes on our website: semservidor.com.br

About Me

This is Evandro Pires. I'm a husband, father of two, but also an AWS Serverless Hero, Serverless Guru Ambassador, Entrepreneur, CTO, Podcaster, and Speaker.

Cut costs and boost innovation by building a serverless-first mindset with sls.guru

Join our team and help transform the digital landscape for companies worldwide!

How I built a Chrome Extension with AI to understand any web page

Evandro Pires — Fri, 27 Jun 2025 12:33:00 +0000

In recent months, I've been exploring ways to teach people how to build real products using artificial intelligence. Instead of talking about AI in theoretical terms, I decided to create a practical experience that shows how AI can enhance everyday tasks and turn simple ideas into powerful solutions.

That's how this project was born: a Chrome extension with a smart side panel, capable of understanding any web page, generating summaries, answering questions, and simplifying content — all in real-time, with the help of Bedrock on AWS using the Nova model.

In this article, I share the technical architecture, the decisions I made, the challenges I faced, and how you can replicate (or evolve) this idea.

The Problem: Too much information, too little time

The internet is full of useful content: technical articles, tutorials, papers, news. But the volume of information is massive, and time to digest it all is scarce.

Sometimes we just want to quickly grasp the main point of an article. Other times, we want to translate or simplify technical text. And almost always, we have questions about what we just read.

Despite the popularity of ChatGPT, using AI still requires stepping out of your reading flow, copying text, writing prompts, and pasting content back. It's an experience that interrupts more than it helps.

My hypothesis was simple: what if AI came to you? What if, while browsing any site, you could open a side panel and ask:

"Summarize this text for me?"
"Explain this part in simpler terms?"
"Translate this content into my language?"

With this idea, I began sketching the project.

The Idea: a reading assistant in your browser

The product was born with a clear premise: to help anyone interact with the content of a web page directly in the browser, with the support of a powerful and easy-to-use AI.

To achieve this, I needed three key pillars:

Context: The AI needs to know what’s on the current page.
Command: The user needs to ask a question or trigger an action.
Intelligent Response: The AI must reply in a helpful way, in the user's preferred language.

The result is a Chrome extension that, when activated, opens a side panel where users can ask free-form questions or use quick buttons like "Summarize page," "Extract data," or "Simplify language." The response appears right there, smoothly and in context.

Technical Architecture: simple, modular, and scalable

The project is divided into two repositories:

Frontend: the extension and side panel code.
Backend: a lightweight API that orchestrates prompts and communicates with the language model.

The extension is built with React and TailwindCSS, using Chrome's native APIs for side panels, content scripts, and message passing.

When the user clicks the extension icon, the side panel opens. At that moment, a script extracts the visible content from the current tab — mainly <main>, <article>, or body.innerText, filtering out menus, sidebars, and other noise.

That text is then sent to the backend, which builds a custom prompt based on the selected action and the user's language, and sends it to the model (in this case, Amazon’s Nova via Bedrock). The response is returned and displayed directly in the panel.

The backend was implemented with Node.js and Express.js, deployed using Serverless Framework v3 on AWS ECS Fargate, and exposed through an Application Load Balancer. The container model was chosen, even though it's serverless, because the interaction with Bedrock returns a data stream and can exceed the 30-second timeout of API Gateway.

Why AI makes sense here

The choice to use a generative model like Nova was not random. Here are three main reasons:

AI understands language better than any handcrafted logic — Summarizing a technical text, rewriting it informally, or answering open-ended questions requires context and nuance, something that regex or traditional scripts can't handle well. LLMs solve this brilliantly.
Generalization is key — This product isn't made for one type of content. It needs to work with blogs, news, documentation, scientific articles, content in English, Portuguese, Spanish... A model like GPT generalizes very well without manual tuning.
Real-time with clear value — The experience is immediate. You see content, click "Summarize," and in seconds you have a helpful response. It's not a generic AI — it's useful because it's contextual.

Prompting and Language Control

On the backend, each predefined action is transformed into a custom prompt. The user's selected language is always included explicitly at the beginning of the prompt to ensure the model responds correctly.

This approach provides coherent and localized answers without needing to train additional models or implement separate translation logic.

Optimizing token usage

Sending an entire page to an LLM that charges per token is impractical — both technically and financially. So I implemented a smart extraction and truncation strategy:

Filter out irrelevant blocks (menus, footers, scripts).
Prioritize <article>, <main>, and visible content.
Limit the text to a maximum of 4000 tokens per request (this limit is self-imposed, but customizable).

In future versions, I plan to use embeddings to semantically compress content before sending it to the model (you can contribute to this — see the GitHub repo at the end).

Results and next steps

With this simple structure, I validated a functional MVP that meets the goal: make AI useful within the web reading flow. Users can get answers and content transformations with a click, in real time, without leaving the page.

Next possible steps:

Interaction history per page
PDF and Google Docs analysis
User-customized prompts
Shareable summary links

What I learned building this

I developed this project using a mindset I've been refining to build AI-powered products in a robust and productive way. I systematize each stage with heavy use of AI combined with my knowledge of product and development. With this, I can create solutions like this in minutes — maybe hours, but never days.

This project also taught me a lot about applying AI in a practical and user-centered way. Here are three important lessons:

AI doesn’t need to be complex to be useful — The value lies in the integrated and fluid experience, not in technical sophistication.
Prompt engineering is as important as code — A good prompt is worth more than a thousand rules.
AI products need to be opinionated — Too many options can confuse users. Creating clear buttons like "Summarize" and "Simplify" guides the experience.

Conclusion

This project is a great example of how generative AI can be applied with purpose in simple and useful products. It shows that with a good idea, some code, and thoughtful decisions, it's possible to transform web browsing into a smarter, more accessible experience.

If you want to use this as the basis for a workshop, hackathon, or your own product, the repositories are open. Happy building — and happy prompting!

Frontend & Extension: https://github.com/epiresdasilva/ai-chrome-sidepanel-frontend
Backend: https://github.com/epiresdasilva/ai-chrome-sidepanel-backend

About Me

This is Evandro Pires. I'm a husband, father of two, but also an AWS Serverless Hero, Serverless Guru Ambassador, Entrepreneur, CTO, Podcaster, and Speaker.

Cut costs and boost innovation by building a serverless-first mindset with sls.guru

Join our team and help transform the digital landscape for companies worldwide!

How I built a cost-effective serverless landing page for my businesses

Evandro Pires — Wed, 21 May 2025 14:55:14 +0000

As a multi-business entrepreneur with distinct brands and domains, I needed a smart, scalable way to publish lead-capturing landing pages—without breaking the bank. Here's how I used AWS serverless technologies to make that happen.

The Problem

Running multiple businesses means juggling different audiences, branding strategies, and domain names. One of the most effective tools in my marketing stack is the classic lead-gen landing page—offer value (like an eBook), get a contact in return.

My go-to tool for landing pages was great—until I needed to use it across multiple domains. The moment I tried to scale beyond a single domain, the monthly cost jumped from R$79 to R$1200 (BRL). That made no sense for my needs or budget.

So I asked myself:

What if I could build my own landing page infrastructure using AWS serverless services?

Spoiler: I did. And it works beautifully—for almost free.

The Solution

I built a fully serverless, deployable landing page system that:

Works across any domain I own
Runs on AWS's free tier (with marginal cost when scaling)
Stores leads in DynamoDB
Sends confirmation emails via SES
Hosts HTML/CSS/JS from S3 + CloudFront
Can be cloned and customized in minutes

To make it even better, I integrated Amazon Q Developer to generate the initial HTML skeleton. It helped me overcome my design limitations and ship fast.

✅ You can find and use the open-source repo here

Architecture Overview

Here’s how each AWS service plays its role:

Amazon S3

Hosts static assets: HTML, CSS, JS, PDF eBook
Configured for static website hosting
Public access for landing page, private access for eBook

Amazon CloudFront

Distributes content globally
Handles HTTPS and custom domains
Reduces latency and adds DDoS protection

API Gateway

Exposes a POST endpoint for form submissions
Validates inputs and forwards to Lambda

AWS Lambda

Validates and stores form data in DynamoDB
Sends emails via SES
Returns a URL to download the eBook

Amazon DynamoDB

Stores user registration data
Schema-less and scales automatically

Amazon SES

Sends email confirmations to users
Notifies me about new submissions

Serverless Framework

Used for Infrastructure as Code (IaC)
Deploys all resources with a single command
Manages environment variables, roles, and permissions

Deployment Simplicity

Once you clone the repo and configure environment variables, the setup is:

serverless deploy

That’s it. Your landing page goes live, and you’re ready to collect leads securely and reliably.

Real-World Use Case: E-book Download Page

I used this solution to create a lead magnet for one of my businesses. Here’s what it does:

Visitor sees the landing page
Fills out a form to get an eBook
Gets the PDF immediately + confirmation email
I receive the lead data and can follow up later

Why This Works

✅ Cost-Effective

You pay only for what you use. No servers. No idle costs.

✅ Scalable

Traffic spike? No problem. AWS handles it for you.

✅ Reliable & Secure

With HTTPS, IAM, DDoS protection, and Amazon's SLAs.

✅ Easy to Maintain

Update HTML, deploy changes via GitHub—no backend maintenance.

Who Should Use This

This solution is ideal for:

Entrepreneurs managing multiple brands/domains
Startups with lean budgets
Developers looking for marketing autonomy
Anyone needing a secure lead-gen solution that scales

Visit the demo page here

Final Thoughts

Sometimes the best solution is building your own.

If you’re a developer-entrepreneur juggling costs and domains like me, this approach might be your next favorite tool. It's fast, cheap, scalable—and entirely yours.

Feel free to clone the repo, make it yours, and publish landing pages that convert without the SaaS pricing trap.

About Me

This is Evandro Pires. I'm a husband, father of two, but also an AWS Serverless Hero, Serverless Guru Ambassador, Entrepreneur, CTO, Podcaster, and Speaker.

Cut costs and boost innovation by building a serverless-first mindset with sls.guru

Join our team and help transform the digital landscape for companies worldwide!

IoT Architecture with AWS: Processing MQTT Messages with Persistence and API

Evandro Pires — Thu, 08 May 2025 13:53:43 +0000

This article presents a practical, scalable, and cost-effective solution for handling large volumes of IoT messages using AWS serverless services. It originated from a real business demand: an environmental services company needed to receive information in near real-time (though not necessarily process it immediately) from geographically distributed sensors, using MQTT as the communication protocol. Below, we detail the main challenges, the proposed architecture, service choices, and the benefits delivered.

Business Challenge

The company monitors environmental indicators for large clients, such as hydroelectric power plants. The main requirement was to capture and store field sensor data — for example, river levels — which send MQTT messages periodically. The company’s current system is a monolithic application primarily designed for human interaction (visualization, analysis, and report generation), not for large-scale ingestion.

Thus, the challenge was twofold: on one hand, to ensure these messages were reliably received and securely persisted, even with high volume; on the other, to avoid impacting the core application, which could become a bottleneck. Additionally, it was necessary to account for future growth: more sensors, more clients, and higher message frequency.

The Serverless Solution

The proposed approach was to create an intermediate solution that works as an intelligent "buffer" between IoT devices and the core application. Since the data doesn't need to be processed in real time, the architecture focuses on reliable ingestion, minimal transformation, and efficient persistence, with later scheduled consumption by the main system.

AWS IoT Core was chosen as the entry point for being a fully managed service with native support for the MQTT protocol, massive scalability, and strong integration with other AWS services. It receives messages directly from the sensors.

AWS IoT Rules acts as a message orchestrator. Using a SQL-like syntax, it transforms incoming messages, adds useful metadata like timestamp, topic, and an automatically generated uuid, and redirects them to the persistence layer:

SELECT *, timestamp() as timestamp, topic() as topic, uuid() as id, 
       timestamp() + 2592000 as expirationTime, 'pending' as status 
FROM 'devices/data'

This eliminates the need for custom code at this stage, reducing potential points of failure and accelerating development.

Amazon DynamoDB was selected for data persistence due to its ability to auto-scale with millisecond latency and native TTL (Time To Live) support. We implemented two TTL rules:

30 days for pending messages (not yet processed)
24 hours for processed messages

A Global Secondary Index (GSI) with status as the partition key and timestamp as the sort key allows the application to easily retrieve pending messages in chronological order:

messagesTable.addGlobalSecondaryIndex({
  indexName: 'status-timestamp-index',
  partitionKey: { name: 'status', type: dynamodb.AttributeType.STRING },
  sortKey: { name: 'timestamp', type: dynamodb.AttributeType.NUMBER },
});

AWS Lambda was used to implement two main endpoints: one to query pending messages, and another to confirm (ACK) message processing, updating the status to processed and reducing its TTL:

// Updates status to 'processed' and sets new expiration
UpdateExpression: 'SET #status = :status, expirationTime = :expTime',
ExpressionAttributeValues: {
  ':status': 'processed',
  ':expTime': now + 86400 // 24h in seconds
}

These functions are triggered on demand, scale automatically, and require zero server management.

Amazon API Gateway completes the cycle by exposing these functions as a secure RESTful API. The main application can, for instance, poll every 15 minutes for pending messages and acknowledge them after processing the data.

The entire infrastructure was defined using AWS CDK, ensuring version control, reproducibility, and ease of maintenance. Setting up a new environment takes just a few minutes.

A working proof-of-concept project is available here: https://github.com/epiresdasilva/iot-core-example

Benefits

From a technical perspective, this architecture eliminates the need to manage infrastructure or worry about scaling. All components are natively integrated and scale on demand. Business logic is cleanly separated and can evolve independently.

From a business perspective, the gains are significant:

Lower infrastructure costs: no idle resources and pay-as-you-go pricing.
Virtually infinite scalability to support growing numbers of clients and sensors.
Greatly reduced time-to-market for new projects.
Increased reliability and traceability with TTL and automatic logging.

Conclusion

This architecture shows how to build an efficient and resilient buffer for IoT data using a few AWS services — all serverless. With minimal maintenance effort and excellent cost-benefit, the company now has a robust ingestion pipeline, ready to scale safely.

About Me

This is Evandro Pires. I'm a husband, father of two, but also an AWS Serverless Hero, Serverless Guru Ambassador, Entrepreneur, CTO, Podcaster, and Speaker.

Cut costs and boost innovation by building a serverless-first mindset with sls.guru

Join our team and help transform the digital landscape for companies worldwide!

How we tripled our innovation capacity and cut costs by 75% with a Serverless-First Approach

Evandro Pires — Fri, 11 Apr 2025 00:01:33 +0000

It was 2020. The pandemic at its peak. A career shift. I stepped into the leadership role of an applied research team at a new company with a clear mission: to kick off a new era of technology-driven innovation.

This team had always played a pivotal role in the company’s journey. Over the years, it spearheaded experiments with emerging technologies that became true turning points. For instance, the team led the company’s transition to a cloud-native architecture, replacing legacy application servers with microservices—a move that laid the foundation for today’s platform, supporting dozens of products, more than 700 microservices, and over 1.2 million active monthly users.

It was also the team that explored and validated facial recognition and NLP-based chatbots—initiatives that earned international recognition. Long before ChatGPT made AI mainstream, we were already experimenting with language models. So when generative AI exploded, we were well-positioned to act fast.

But experimenting is very different from turning new tech into product. That’s where the real challenge lies. Especially in an environment where testing hypotheses was expensive and slow. That bottleneck was throttling innovation.

Working with innovation means embracing uncertainty—and accepting that most of what you try won’t work. Statistically, only a small fraction of ideas create real business value. If your success rate is 10%, and you want 10 validated ideas, you need to test 100. It’s basic math.

In 2020, our average cost per experiment was $186, and we were completing just 0.57 experiments per professional per year. Scaling innovation with those numbers simply wasn’t feasible. Hiring more people or increasing budget linearly wasn’t the answer.

We ran an internal assessment to understand what was getting in the way. Here’s what we found:

Provisioned infrastructure that incurred cost even when idle;
Limited AWS expertise, which slowed development and created bottlenecks;
Projects executed individually, limiting collaboration and peer learning;
Lack of a clear cadence in our workflows, leading to inconsistency and inefficiency.

That’s when I proposed a mindset shift: what if we adopted a serverless-first approach?

Instead of provisioning and managing infrastructure for each experiment, we would use AWS serverless services—only paying for what we actually used. Since our experiments didn’t require constant uptime or production-grade environments, serverless was a perfect match from both a technical and financial standpoint.

"Adopting a serverless-first mindset allowed the team to focus on what really matters: generating insight and validating ideas quickly, affordably, and with minimal operational drag."

The team got on board. We launched a collective learning journey: we enrolled in courses together, ran internal challenges, and created a space for ongoing knowledge sharing. One of the highlights was the internal URL shortener challenge. The goal? Build it entirely using AWS serverless tools—at zero cost. Not only did it work, but it also sparked a DynamoDB modeling workshop that benefited the entire team.

Of course, the shift wasn’t just technical. We also reworked our team dynamics. We moved to pair programming, adopted two-week sprints, broke work into smaller, more manageable chunks, and ensured visibility across projects. This kept our momentum going—even when outcomes were uncertain. Learning became a constant.

With this new model in place, momentum picked up. A standout moment was when we were tasked with developing an electronic signature solution on a tight timeline. Thanks to our serverless-first foundation and the team’s growing maturity, we delivered a fully integrated, production-ready solution in just three months.

By 2021, the results were clear: we went from 0.57 to 1.25 experiments per professional, and the cost per experiment dropped from $186 to $45.

In 2022, things got even better: 2.11 experiments per professional, and just $39 per experiment. We had built a true innovation engine.

"When innovation becomes routine, impact stops being an exception and starts becoming strategy."

Other wins soon followed. We built a no-code machine learning platform that allowed our clients to run models without writing code—featured on the AWS Blog:
https://aws.amazon.com/pt/blogs/aws-brasil/como-a-senior-sistemas-criou-uma-plataforma-de-aprendizado-de-maquina-no-code-utilizando-aws/

When generative AI gained traction, we didn’t scramble—we accelerated. We launched the AI Agent Factory, a fast and easy way for our product teams to build AI agents integrated into our systems, while abstracting away technical complexity. This also became a benchmark in the industry:
https://aws.amazon.com/pt/solutions/case-studies/bedrock-senior-sistemas/
https://aws.amazon.com/pt/blogs/aws-brasil/a-fabrica-de-agentes-da-senior-sistemas-utilizando-ia-generativa-para-aumentar-a-eficiencia-operacional/

Conclusion

As technology leaders, we need to understand that innovation isn’t just about having good ideas—it’s about creating the technical, cultural, and operational conditions to turn those ideas into business value.

Embracing a serverless-first mindset, combined with simple, structured, and collaborative processes, transformed our slow and costly experimentation into an agile, efficient, and high-impact innovation engine.

That decision we made back in 2021 laid the groundwork for everything we achieved when the AI wave arrived.

So here’s a question for you: how many ideas are going untested in your organization because of high costs or slow cycles? Maybe it’s time to rethink how you approach innovation.

About Me

This is Evandro Pires. I'm a husband, father of two, but also an AWS Serverless Hero, Serverless Guru Ambassador, CTO, Podcaster, and Speaker.

Cut costs and boost innovation by building a serverless-first mindset with sls.guru

Join our team and help transform the digital landscape for companies worldwide!

How my kids learned English with Serverless and GenAI

Evandro Pires — Thu, 06 Mar 2025 01:42:32 +0000

I'm a father of two kids; currently, they are 8 and 6 years old.

Last year, I received an invite to participate in the AWS Global Heroes Summit, a yearly meeting of all AWS Heroes from around the world.

Happily, the meeting was scheduled to take place during the kids' vacation here in Brazil, so it was an easy decision to have our family vacation together in Seattle, WA—the city where the event was held.

My kids love learning new languages and having new experiences when traveling. When we traveled to Argentina, they wanted to learn some words and sentences in Spanish. When we told them we were traveling to the US, they wanted to learn more English.

The school where they study has English classes every day, but we knew they needed to practice more before the trip to be better prepared.

Here is where I, as the nerd that I am, stepped in: how could I use technology to help with that? Especially Serverless and GenAI. And that’s how this project started.

The Idea

The idea was very simple. What if I created a memorization app for my kids? But I didn’t want to manually think about the words, images, or speech. First, because I wanted all words with no limitations, including not needing to translate every word. I didn't want to find an image for each of these words. Second, the biggest restriction I had was time. As a busy executive, I didn't have enough time to do all of these tasks and also use the solution with my kids.

With this in mind, I built an app that generates everything automatically. I just need to specify the type of words I want, for example, "animals" or "vehicles," and everything is created—including the words (both in English and Portuguese), the images, and the speech in both languages.

The app works like this: my kids see an image and an English word. When they click on it, they hear the word in English. If they click on the "card," the word changes to Portuguese, and clicking it again plays the pronunciation in Portuguese. That simple.

It’s a low-cost way to memorize English words while also learning more about AWS services.

Loading Words into the Database

First of all, to use the app, you need to load words into the database.

I created an endpoint that generates words based on what I request using GenAI. Because I personally load these words into the database, a simple REST endpoint is good to trigger the process. A Lambda function receives an invocation from an API Gateway and calls the Bedrock service to generate words in English along with their Portuguese translations, so I get a pair of words—a word and its translation. Basically, I have a prompt that asks Bedrock for a JSON with these words, concatenating the instructions I send in the payload of the endpoint. I'm using the Claude 3 Haiku model from Anthropic for that.

I receive a JSON like this:

{substantivos: [{ 'português': 'mesa', 'inglês': 'table' },{ 'português': 'cadeira', 'inglês': 'chair' }]}

Because I want these words to be generated and saved quickly in my database, I send each word pair as an event to EventBridge. The idea of using EventBridge is leveraging its power to parallelize the generation. Also, I can later have other applications listening to these events, for example, translating into another language (maybe for a future trip with the kids).

Then, I use Step Functions to handle the rest. In that workflow, I create an image for each word as well as speech for both words. Here, I have a classic necessity of doing things step by step. I need to create an image for the word, then generate speech for it, and in the end, save all the data. When I explain this, it’s clear to me that a workflow is necessary. Step Functions is great for that. One good thing was that I could parallelize the generation of images and speech by putting them side by side in my workflow. Once both are finished, I save the data. No fancy controls are needed—just a clean workflow. Easy to build, easy to read, and easy to understand what is happening.

For image generation, I used GenAI through Bedrock. The model is Amazon Titan Image—simple, cheap, and perfect for this use case. No need for complex images, just simple and clean visuals that are easily recognized by a child.

For speech, I used Polly.

Both images and audio files are saved in S3 buckets.

Afterward, all the data is saved in a DynamoDB table. Here’s an important detail: I have two tables. One to save all word data and another to store the number of words available. I do this to easily retrieve a random word in the app. I’ll explain more about that.

With that, I can load as many words as I want into my app.

Now, let’s talk about the app itself.

Here’s the app architecture:

As I explained, the idea of the app is to show random images to my kids so they can memorize and practice speaking each word.

So, I have an endpoint that retrieves a random word from the database and displays it to the user. Since I need to fetch a random word, I use a Lambda function between API Gateway and the DynamoDB table. This Lambda function gets the number of words available and generates a random number based on that. With this number, it finds the word in a DynamoDB table.

I'm serving images and audio from S3 through CloudFront with caching enabled.

Finally, I have a simple Angular page hosted on S3 and served via CloudFront.

You can try it out on our demo website, where everything is running: https://mee-moo.com

The code of this solution you can find in this repository in my GitHub: https://github.com/epiresdasilva/learn-english-with-serverless-genai

Conclusions

I like using challenges from my daily life with my family to demonstrate how we can use these services to solve real problems—usually with low cost and in a quick way.

It’s not different from the challenges we face in our companies. Why not use more of this approach to solve everyday problems? Sometimes, this is the first step in showcasing the value of these kinds of services, which can later be applied to core solutions.

This solution is basically free, running within the AWS Free Tier. Even during development, when I ran multiple tests to improve the solution, I spent no more than 10 dollars.

About Me

This is Evandro Pires. I'm a husband, father of two, but also an AWS Serverless Hero, Serverless Guru Ambassador, CTO, Podcaster, and Speaker.

Serverless Guru thrives on innovation, collaboration, and continuous learning.

Join our team and help transform the digital landscape for companies worldwide!

Husband mission on a Saturday: mass conversion of HEIC images with serverless

Evandro Pires — Tue, 25 Feb 2025 00:12:03 +0000

I was helping my wife, who was trying to print some family photos, but the tool she was using only accepted JPG images, and most of her photos were in HEIC format.

Being the nerd that I am, I wasn't satisfied with just running a local Python script to convert all the photos. I thought: this is a great opportunity to practice creating a serverless application that does this. Using the power of cloud computing, I imagined it was possible to convert all the images almost instantaneously—and I did it!

A serverless way to massively convert HEIC images to JPG almost instantaneously using S3 and Lambda.

Here's how I did it...

The Solution

The idea is simple. S3 is an object storage service where I can store any type of file at a low cost. S3 has an interesting feature called "Event Notifications." With this feature, I can "listen" for different events that occur in a bucket (the location where I upload files).

So, for each file I upload, an event is triggered, which then handles the conversion to JPG. For the conversion, I use a Lambda function. Lambda is a Function-as-a-Service (FaaS) component that allows you to run code without worrying about infrastructure. It’s scalable and you only pay for what you use.

This same Lambda function saves the JPG image to another S3 bucket, where I can download it.

The cool thing is that the conversion happens almost instantaneously. That’s because both S3 and Lambda are serverless services, meaning they automatically scale as needed.

How to use

Clone the following repository: https://github.com/epiresdasilva/heic-to-jpg

To deploy this solution I'll need:

An AWS account properly configured in our workspace
Python 3.9
Serverless Framework

Here is the step by step:

Install python dependencies

pip install -r requirements.txt

Deploy to AWS

sls deploy

Access your AWS Console, go to the S3 session and upload your HEIC photos to the "heic-input-*" bucket.
Go to the "jpg-output-*" bucket and download your converted files.

Results

I was able to convert all the images for my wife in seconds by uploading the files through the S3 upload interface and downloading them from the S3 bucket.

The estimated cost for this is $0.000002293 per image converted.

Curious fact: in 24 hours, without tell anyone, I had 20 clones of my repository.

About me

This is Evandro Pires. I'm a husband, father of two, but also a AWS Serverless Hero, Serverless Guru Ambassador, CTO, Podcaster and Speaker.

Serverless Guru thrives on innovation, collaboration, and continuous learning.

Join our team and help transform the digital landscape for companies worldwide!

Minecraft Server on AWS

Evandro Pires — Wed, 17 Jan 2024 02:08:54 +0000

My 7 years old son is a fan of Minecraft. He started playing last year (2023) and he only talk about that the last 6 months. Now, he want to play with us, me, my wife, my 5 years old daughter, as well with some cousins.

It's available lots of servers on the internet, both paid or free, but those server don't have the security I want to my kid.

It's true that I'm a nerd father, so I had the idea of creating my own Minecraft Server on AWS. A server it will be used only by us.

So, if you want to learn a little about AWS in a fun way or you're a parent wanting to create a Minecraft server to your kids, here a GitHub repository that I created for that: https://github.com/epiresdasilva/aws-minecraft-server

To create this server, we'll use the following AWS services:

If you're not familiar with these services, I recommend to study the basics first, including Security Groups on EC2.

Steps

It's very simple to create a Minecraft server. To do this faster and reproduceble, I create a CloudFormation code for that.

In the repository, you'll find a file called minecraft-server.yaml.

Basically, in this file I create a Security Group to allow only few ports I want to expose to the internet, like SSH and the port 25565 that is the port Minecraft Launcher connects.

  MinecraftSecurityGroup:
    Type: 'AWS::EC2::SecurityGroup'
    Properties:
      GroupDescription: 'Enable SSH and Minecraft server port'
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: 0.0.0.0/0
        - IpProtocol: tcp
          FromPort: 25565
          ToPort: 25565
          CidrIp: 0.0.0.0/0

Another important part is creating the EC2 instance. Basically, you need to choose the Linux image you want, as well the instance type. I choose a t4g.small and it's running very well. I just need to understand if can be a smaller instance yet.

      InstanceType: t4g.small
      ImageId: ami-02cd6549baea35b55
      KeyName: Minecraft Server

The instance type you can find in the EC2 page or using the AWS Calculator, so doing that it's easier to understand how much it will costs.

The image ID you'll find on the AMI Marketplace on the EC2 section on your AWS Management Console.

You need to create a KeyPair also on the EC2 section. After creating, just put the name in the "KeyName" on the YAML file.

Finally, you just need to run the following command:
aws cloudformation create-stack --stack-name MinecraftServerStack --template-body file://minecraft-server.yaml --region us-east-1

Security

Remember, DO NOT create that stack using your root user. Create an especific one to that. On doing that, remember to give only the necessary permissions you need. For instance, I used AmazonEC2FullAccess and AWSCloudFormationFullAccess and worked fine, but maybe can be more restricted yet.

This template doesn't create an advanced security for that server, so if you need to improve security it's important working on new layers of security in that template.

In my server, I made a configuration using Security Group to allow only connections from my IP, so I avoid other users to connect to my server even if they know my EC2 address.

Following it's how you can do that in the AWS Management Console:

Reboot

The script for running the Minecraft will run only for the first time when the EC2 instance is created. So, if your instance reboot the Minecraft Server won't start again.

After creating my EC2 instance, I create a systemd to handle with that, but I didn't add that to my template.

Create a systemd service file:

sudo vi /etc/systemd/system/minecraft.service

Create the content:

[Unit]
Description=Minecraft Server
After=network.target

[Service]
User=root
Nice=5
KillMode=none
SuccessExitStatus=0 1
InaccessibleDirectories=/root /sys /srv /media -/lost+found
NoNewPrivileges=true
WorkingDirectory=/
ExecStart=/opt/jdk-17.0.9/bin/java -Xmx1024M -Xms1024M -jar minecraft_server.jar nogui
ExecStop=/bin/kill -SIGINT $MAINPID

[Install]
WantedBy=multi-user.target

Reload the systemd:

sudo systemctl daemon-reload

Enable the service:

sudo systemctl enable minecraft.service

Start the service:

sudo systemctl start minecraft.service

Check the service status:

sudo systemctl status minecraft.service

Service logs:

sudo journalctl -u minecraft.service

Playing Minecraft

Now, you have your own Minecraft Server and you are able to play with your friends and family.

Could a non IT professional to build a Lambda function?

Evandro Pires — Wed, 23 Jun 2021 02:57:10 +0000

Who knows me, also know I love serverless because of the lead time, and not only because of the technology (but I like it too).
One day, during the pandemics, I was wondering how I can prove serverless is really a good choice for a better lead time. Thinking about that, I asked myself: could a non IT professional to build a Lambda function?

Introducing my wife

My wife is a full-time mother of two kids (they were 1 and 4 years old when the challenge happened). If you have kids, you know that isn't an easy task to care of them the whole day. But, fortunately for me, my wife is crazy enough to accept my challenge. She is an interior designer, and she knows only the basic of a regular user of a computer.

7 days challenge

The challenge was: could she learn the basic enough of a programming language and create a Lambda function on AWS in 7 days?

The study process

First, I suggested for her to study Python as the programming language target. That's because the learning curve of this language is very nice. I also helped with a one hour explain about programming logic.
For her studies, I recommended studying in codecademy.com and use PyCharm as the IDE.

I tried not to interfere in the study process, doing only some mentoring during the days of challenge.

After two days studying, she found some women python community that inspired her to continue the process. She also started to create basic logics with some variables and "if's".

When she reached the fourth day of studies, she falls in the curiosity to understand how Python actually words behind the scenes, and how programming languages are made, how processors work, and so on. At this moment, I needed to put her on the rails because the time box was very short to understand all those things.

Developing a Lambda function

Day 6. She already developed a very simple function that receive a month in number and returns how many holidays it has on that month.
With that development, she was ready to develop her first Lambda function ever.
I made a quick explanation on what is a serverless function and where she could find the documentation for that. I also gave her my AWS credentials.

Deploying the Lambda function

Using the AWS web interface, she put her python code on the Lambda function and ran a test to complete the challenge.
After that, I made only few adjustments to work with API Gateway and I ran a load test to prove that a non IT professional can build a scalable "system".

Conclusion

In 7 days, it is impossible to become a programmer and also a cloud specialist, of course. The idea of this challenge was to prove that we can have a better lead time developing with serverless services. If a non IT professional can create a Lambda function in 7 days (learning a programming language from zero), imagine how much a professional developer can do with serverless.

PS: As the payment of that challenge, I watched Korean series on Netflix and participate of Meatless Monday with her.

Lots of thanks to my wife Madilene.

Cover image by Julia M Cameron on Pexels.

Which programming language in AWS Lambda should I use?

Evandro Pires — Wed, 16 Jun 2021 02:27:42 +0000

One of most question I receive is "which programming language is the best for serverless?". People want to know what's the best choice to create their functions in AWS Lambda. But for me, the answer is not that simple just looking for technical stuffs.

In terms of performance, there are programming languages that perform better than others. The main characteristic that differs to those programming languages is the cold start. If you don't know, cold start is an amount of time that your cloud provider spent to start a new instance of your function. Once your function instance is started, the cold start will not occur for the next execution (until the timeout).

It's known that programming languages based on JVM, like Java, have a higher cold start. But Java has a good performance when the function is warmed up. It's also known that interpreted languages and compiled languages have a better performance in terms of cold start. That's the case of NodeJS and Python. These two programming language have a lower cold start.

So, if we think only technically, the answer is simple: use NodeJS or Python. But, as I said before, it isn't that simple.

For me, developing a serverless application isn't only a technical choose. It's especially about lead time, time to market and a better use of resources.

When I talk about lead time and time to market, that means it's important to care about how much time you need to develop your application. It's common to hear quotes like "faster companies won over big companies" and, because of that, it's important to think about how to build your application faster.

About better use of resources, when we develop our application faster it means we use less development resource. It's also important to think about maintenance, because once launched the application you need to keep that in the air, fix possible bugs, etc.

Thinking on all those things, I decided to create a diagram that help you to choose a programming language for your serverless function.

Choosing a programming language

First of all, I want to clarify that's my own opinion, and it isn't a bullet silver, but I believe it will help you in most cases.

According to the image above, I prefer to use a programming language that the team knows instead of a "better programming language". I did that because I believe in most cases the time to market is more important than the performance. There are many cases when we use functions in an event based architecture and those events are asynchronous. Besides that, even when the function in synchronous, for many times those functions will be warmed up, so we mitigate performance problems.

Using a programming language known by your team, you will develop your application faster (better time to market and less resources), and you will maintain easier because the programming language is in the comfort zone.

If you need to rewrite some function in the future because of performance, it's easy, just because serverless functions are decouple by design.

Conclusion

Of course, if we have an opportunity to use an appropriated programming language in terms of performance it will be great, but I really believe in time to market first.

Cover image by Luis Gomes on Pexels.

Criando a votação do BBB com serverless

Evandro Pires — Wed, 12 May 2021 03:13:31 +0000

O BBB 2021 foi um grande sucesso de audiência e também em participação nas votações para eliminação dos participantes.
A votação funciona de uma forma bastante simples. Num domingo, o Paredão era formado (formação com 3 pessoas candidatas a eliminação) e até a próxima terça-feira, a votação ficava aberta, ou seja, eram cerca de 48 horas para votação.

Durante a edição de 2021 desse programa, fui convidado para palestrar em um evento de TI e para trabalhar no conteúdo eu quis criar algo novo. E foi aí que juntei as duas coisas: BBB e Serverless. Dessa combinação surgiu o SSS - Super Serverless Sample (sim, o nome é horrível mas foi o que consegui pensar para ter 3 "S" no acrônimo).

A provocação que fiz foi: será que é possível atender aos requisitos da votação do BBB usando serverless?

Tivemos divulgação de estatísticas de votação do BBB, pelo time de TI da globo.com, onde foram alcançados números recordes de participação:

1,5 milhão de requisições por minuto no pico
1 bilhão de requisições dentro de 48 horas

Além disso, o resultado da rodada era divulgado 20 minutos após o encerramento da votação.

Serverless

Serverless é um termo usado para aplicações e ferramentas que são gerenciadas pelo cloud provider e que tem precificação por utilização, ou seja, não se paga por tempo ocioso. Além disso, elas têm como padrão a alta disponibilidade, escalabilidade automática e segurança.

Por ter essas características, o Serverless tem bastante sinergia com os requisitos apontados na votação do BBB.

Arquitetura

Com o desafio dos requisitos não funcionais da votação do BBB e tendo o Serverless como a solução para isso, desenhei uma arquitetura para a aplicação.
Foi utilizada a AWS como cloud provider.

Na imagem abaixo, vemos uma arquitetura bastante simples, mas com bastante poder de processamento.

API Gateway: recebimento das requisições através de uma API Rest e enviando de forma assíncrona para processamento, proporcionando um alto throughput
EventBridge: poderoso broker de mensagens que permite a execução paralela de cada mensagem de forma massiva. Alta capacidade de processamento das mensagens no mesmo ritmo que é recebido
DynamoDB: armazenamento dos votos individuais
SQS: envio de mensagens em lotes para processo assíncrono de contagem dos votos. O envio de lotes proporciona uma contagem mais rápida. Ao mesmo tempo, o SQS permite um processamento alto e controlado para não sobrecarregar o banco de dados
RDS (Aurora Serverless): armazenamento da contagem dos votos, permitindo o incremento do valor e emissão de relatórios de forma mais otimizada

Desafio da definição da arquitetura

Esse desenho de arquitetura mostrado anteriormente é a versão final, mas precisei iterar sobre ele para chegar nessas conclusões. Por isso, quero registrar também as escolhas que não atenderam as necessidades.
É importante dizer que serverless te entrega escala sem preocupação, mas isso não significa que você terá a escala necessária para resolver o seu problema. Isso porque cada serviço tem suas característica e apesar de em termos de infraestrutura você ter problema de escala, você pode ainda ter problema de vazão.

API Gateway e SQS

Na primeira tentativa, utilizei o SQS conectado ao API Gateway para receber os votos de forma assíncrona direto do endpoint. Em termos de disponibilidade não tive nenhum problema, mas o consumo dessas mensagens não atendia a velocidade de contabilização de votos que precisava.
Por esse motivo, o uso de um Broker como o EventBridge fez mais sentido.

DynamoDB Stream

Também na primeira versão da arquitetura, ao invés do uso de SQS como Destination da Lambda de registro de votos, eu havia utilizado a Lambda conectada no DynamoDB Stream para ouvir os eventos de cadastro. Em termos funcionais funcionou muito bem, mas assim como o Kinesis, o DynamoDB Stream trabalha com o conceito de shard. Sendo assim, só é possível paralelizar a mesma quantidade de shards configuradas no DynamoDB.
Mesmo tendo a opção de paralelizar e aumentar a capacidade, ainda ficou aquém da velocidade necessária para o problema.

Desenvolvimento

Para realizar o desenvolvimento dessa aplicação foi utilizada a linguagem de programação NodeJS. A escolha foi por conta da simplicidade dos requisitos e também do baixo cold start.
Também teve o fator que eu já queria há algum tempo criar alguma função nessa linguagem. :)

O desenvolvimento todo foi realizado dentro de uma semana, trabalhando somente em dias úteis em torno de 2 horas por dia. Um total de 10 horas de desenvolvimento. Vale ressaltar que nunca desenvolvi com NodeJS, portanto nessa carga horária estão contemplados vários "perrengues" de adotar essa linguagem.

Estatísticas

Teste de carga

Uma parte importante da jornada foi o teste de carga. A característica do requisito era a alta escala de requisições. Por isso, era bem importante validar se a aplicação conseguiria ser um backend viável para a votação do BBB.

Para exercitar algumas requisições com objetivo maior de validar os requisitos funcionais, utilizei o JMeter.
Quando parti para testes de cargas mais massivo, utilizei o Artillery na versão serverless. Essa versão, utiliza funções Lambda para criar a carga. É serverless "contra" serverless.

Abaixo, algumas informações sobre os testes.

Nos testes mais simples: 5k requisições por segundo
- 10 segundos de duração
- 50k requisições no total
Testes de processamento: 20k requisições por segundo
- 60 segundos de duração
- 1,2mi requisições no total
- Tempo de processamento do placar: 25 minutos

Foram vários testes de cargas nessas características, certamente mais de 10 mi requisições no total.

Custos

Os valores abaixo são do intervalo todo de desenvolvimento, portanto esses custos incluem todos os testes realizados inúmeras vezes e não somente o teste final que resultou na estatística citada anteriormente. Alguns custos são contabilizados diariamente, o que poderia ter sido otimizado se usasse menos dias mas com a mesma carga horária.

RDS: US$ 2,90 / dia
VPC: US$ 1,44 / dia
Lambda: US$ 1,00 total
API Gateway: US$ 7,12 total
DynamoDB: US$ 2,46 total
SQS: US$ 0,21 total
Total: US$ 52,57

O que ainda poderia ser feito

O tempo utilizado para desenvolver a aplicação contemplou não só o desenvolvimento, mas também a concepção, desenho de arquitetura e todo o processo de testes. Por isso, o tempo acabou sendo pouco para criar algo mais completo.

Abaixo algumas coisas que poderiam ainda serem feitas no sistema:

Abordagem mais robusta de dados: processar os mais rapidamente
- Near realtime com Kinesis, por exemplo
Pipeline para deploy automatizado
Utilização de SecretsManager: para proteger a credencial do banco de dados RDS

Conclusões

De maneira geral, a aplicação serverless se mostrou bastante viável para ser o backend de votação do BBB. Com pequenas melhorias é possível aumentar ainda mais o poder de processamento, especialmente para processar os votos mais rapidamente e ter o placar de forma mais antecipada.
Com uma carga horária bem pequena, foi criado uma aplicação que consegue processar 1,2 milhão de votos por minuto e entregar o placar em 25 minutos.

Essa aplicação está disponível no GitHub: https://github.com/epiresdasilva/super-serverless-sample

Conheça o podcast Sem Servidor, um podcast dedicado ao tema Serverless com conteúdos em Português: https://semservidor.com.br