DEV Community: OSVALDO ALVES

The Era of Engineers: Is Code Becoming a Commodity?

OSVALDO ALVES — Sat, 28 Mar 2026 11:57:51 +0000

TL;DR: 🚀 In the age of GitHub Copilot and Cursor, generating code is becoming a commodity. The real value is shifting from writing code to designing solutions. We are entering the Era of Engineers, where architectural thinking and technical curatorship are the ultimate competitive advantages.

The Era of Engineers

Over more than two decades leading software projects, I have witnessed languages being born, paradigms shifting, and productivity tools jumping from simple text editors to complex AI-powered ecosystems.

However, for a long time, one truth seemed immutable: a developer's direct impact was measured, invariably, by their ability to deliver functional code.

Code was the goal. Today, it is merely the means.

🧠 The Senior’s Silence vs. The Junior’s Rush

Anyone who has lived the daily routine of a software house knows this scene: faced with a complex problem, the senior developer often spends more time staring at a whiteboard (or into space) than at the keyboard. They seek to understand flows, anticipate flaws, and design the solution. When they finally start typing, the code flows naturally and assertively.

On the other hand, junior professionals often have an urgent hunger to "open the IDE." For them, code is the discovery tool. But this "exploratory coding" frequently ignores business nuances, leading to costly rework and "course corrections" later in the project.

The shift? This "rush" now has a powerful—and sometimes deceptive—ally: Generative AI.

🌊 "Vibe Coding" and the Commoditization of Syntax

We are fully entering the age of Vibe Coding. With tools like GitHub Copilot, Cursor, and Antigravity, the technical barrier to "writing something that works" has dropped drastically.

If AI can generate the code, where does our value reside? It has moved from doing to designing.

The Big Shift: We have officially moved from the Era of Programmers to the Era of Engineers.

In this new phase, the differentiator is no longer syntax or mastering a specific framework, but:

Problem Decomposition: Breaking down the "what" before the "how."
Resilient Architecture: Building systems that don't crumble under change.
Context Engineering: Providing the right mental model to guide the AI.

🛡️ Curatorship: The New Technical Depth

This isn't a threat to those starting their careers—it's a clarion call. There is a false sense of security in simply knowing how to "operate" an AI.

AI is an excellent co-pilot but a poor captain. The new software engineer must be, first and foremost, a curator. To challenge the quality of an AI-generated artifact, you need an even more solid technical foundation than before. You must understand if that code is scalable, if it respects security principles, and if it isn't creating unpayable technical debt for the future.

🚀 The Future: Fewer Builders, More Architects

I have no doubt that we will increasingly be judged not by "how many lines we delivered," but by "how well-structured our solution is."

For managers and executives, the challenge is to recalibrate success metrics. For developers, the path is a return to the fundamentals: systems analysis, software design, and a deep understanding of the business.

The Era of Engineers is not about the end of code; it’s about the supremacy of thought. Ultimately, valuable software isn't just the one that runs—it's the one designed to solve the right problem in the smartest way possible.

What do you think? Are we becoming "AI Orchestrators," or is the fundamental role of an Engineer still the same? Let's discuss in the comments! 👇

The Architect’s Dilemma — Ep. 1: CAP Theorem in the Real World

OSVALDO ALVES — Mon, 24 Nov 2025 12:03:49 +0000

Most seasoned architects have been through something like this:

a tense meeting, several stakeholders at the table, deadlines tight — and suddenly someone asks:

“But why can’t the system be consistent and available at the same time?”

It’s in moments like this that we’re reminded that architecture is, above all, about making difficult decisions under non-negotiable constraints.

It’s about trade-offs. It’s about giving things up.

And this series exists to explore exactly these dilemmas.

In the next episodes, we’ll dive into choices that shape modern systems: microservices vs. monoliths, CQRS, event-driven architectures, caching, idempotency, organizational scalability, and more.

Always from a practical, real-world perspective — far from pretty slides and close to the problems that actually hurt.

So let’s begin with a classic.

CAP Theorem in the Real World

The CAP Theorem is no longer an academic curiosity. Introduced by Eric Brewer in 2000, it states that a distributed system cannot simultaneously guarantee all three properties:

Consistency
Availability
Partition Tolerance

In practice, it shows up when your system grows, traffic increases, and non-functional requirements become harder. Suddenly, you’re forced to choose which type of pain you prefer.

The CAP Theorem isn’t theoretical — it manifests every time you need to decide what happens when the network fails.

And networks always fail.

1. Context: When This Dilemma Appears

CAP becomes relevant whenever you have:

Distributed data (replication, multiple nodes, multi-region)
Requirements for high availability
Pressure for low latency
Users operating from multiple locations
Concurrent write operations

Common triggers:

Traffic growth requiring replicas
Geographic expansion requiring multi-region
Increased availability requirements
Non-centralized persistence

This leads to the big question:

Which pillar are you willing to relax — consistency, availability, or partition tolerance?

2. The Options: What Each Alternative Means

CAP defines three properties, but you can only guarantee two in the presence of network failure.

C — Consistency (Strong Consistency)

All nodes see the same data at the same time.

A — Availability

The system always responds, even if with outdated data.

P — Partition Tolerance

The system continues operating even if communication between nodes is broken.

⚠️ In real-world systems, Partition Tolerance is mandatory.

So the choice becomes:

➡️ CP vs. AP

3. Trade-offs

CP (Consistency + Partition Tolerance)

Advantages

Strong consistency
Predictability in sensitive domains
Avoids critical data errors

Disadvantages

May reject requests during partitions
Higher latency
Lower availability perception

AP (Availability + Partition Tolerance)

Advantages

Keeps responding even with failures
Lower latency
Great for real-time UX

Disadvantages

Eventual consistency
Conflict resolution required
Higher cognitive complexity

4. Decision Factors

4.1. Nature of the data

Critical → CP
Approximate → AP

4.2. UX latency expectations

Can wait → CP
Must be instant → AP

4.3. Geographic distribution

Single region → flexible
Multi-region → often AP

4.4. Acceptable latency

Low latency → AP

4.5. Team maturity

Less experience → CP
Higher expertise → AP

4.6. Business impact

Errors are costly → CP
Errors are tolerable → AP

5. Use Cases

Choose CP when:

Financial transactions
Critical inventory
Process orchestration
High auditability

Choose AP when:

Social networks
Counters, metrics, likes
Read-heavy catalogs
Global low-latency apps
Recommendations

6. Warning Signs of a Wrong Choice

In CP:

Slowness complaints
Traffic spikes compromising nodes
Replication bottlenecks

In AP:

Inconsistencies generate rework
Write conflicts become frequent
UX fluctuation (data “jumping”)

7. How to Evolve Between Models

From CP → AP:

Prepare models for divergence
Add conflict resolution
Implement read-repair
Reduce transactional boundaries

From AP → CP:

Identify critical domains
Centralize degree of truth
Use event logs
Reduce distributed surfaces

Architecture is about balance, not extremes.

Conclusion

The CAP Theorem is a practical reminder:

There is no perfect distributed system.

There is only the system that best fits your context.

Architecture is about choices — and every choice has a cost.

If this helped clarify a decision, leave a like and share your experience in the comments.

Let’s learn together.

Cloud App Journey: Ep. 5 — Cloud Security: Protecting APIs, Credentials, and Data on Azure

OSVALDO ALVES — Tue, 11 Nov 2025 19:08:05 +0000

In the previous chapters of the Cloud App Journey series, we explored deployment, containers, scalability, observability, and performance optimization. Now it's time to face one of the most critical topics in any distributed cloud application:

Security.

Here are a few questions you’ve probably asked yourself at some point (or should have):

How can I ensure that only authorized users can access my APIs?

How do I store sensitive secrets (like connection strings) without exposing them in code or config files?

How do I prevent leaked credentials from compromising the entire production environment?

In this episode, we’ll walk through how to address these challenges in Azure using .NET, with practical examples for modern microservices.

1. How do we ensure that only authorized users can access the API?

The standard approach today is to protect APIs using OAuth 2.0 + OpenID Connect, with Azure Entra ID as the identity provider.

The flow is straightforward:

The user (or another application) obtains a JWT token from Azure Entra ID.
The token is sent in the request header:

Authorization: Bearer <token>

The API validates that token and determines whether the request should be served.

Example: API requiring a specific Role

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/reports")]
public class ReportsController : ControllerBase
{
    // Only users with the role "admin.app" can access
    [HttpGet("financial")]
    [Authorize(Roles = "admin.app")]
    public IActionResult GetFinancialReport()
    {
        return Ok("Sensitive financial report...");
    }
}

If the token does not include the admin.app role → access is automatically denied.
No manual if checks
No duplicated logic
No custom middleware hacks

How does the API validate tokens?
appsettings.json (or environment variables in containers):

"AzureAd": {
  "Instance": "https://login.microsoftonline.com/",
  "TenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "ClientId": "api://my-backend-id"
}

Program.cs:

builder.Services.AddAuthentication("Bearer")
    .AddJwtBearer("Bearer", options =>
    {
        var azureAd = builder.Configuration.GetSection("AzureAd");
        options.Authority = $"{azureAd["Instance"]}{azureAd["TenantId"]}/v2.0";
        options.Audience = azureAd["ClientId"];
    });

builder.Services.AddAuthorization();

Once configured → your API now only responds to identities recognized and authorized by Azure.

2. How do we securely store sensitive data for microservices?

A common example:
Production database connection strings should not be stored in:

appsettings.json
.env files
repository code
manually copied configurations

The standard solution is:
Azure Key Vault → secure secret storage.
You store secrets in Key Vault and your application consumes them without exposing the values directly.

Example: Accessing Key Vault secrets in .NET

Program.cs:

using Azure.Identity;

var builder = WebApplication.CreateBuilder(args);

var keyVaultName = builder.Configuration["KeyVaultName"];
var uri = new Uri($"https://{keyVaultName}.vault.azure.net/");

builder.Configuration.AddAzureKeyVault(uri, new DefaultAzureCredential());

Now your connection string can be used like this:

var connectionString = builder.Configuration["DbConnectionString"];

No secrets in code, repository, or pipelines.

3. How do we deliver secrets to containers in production?

When your API is deployed to Azure Kubernetes Service or Azure App Service, Key Vault can be integrated seamlessly using:

Managed Identity (automatic identity for the resource)

No passwords, no keys, no tokens.

What happens:

The service identifies itself to Azure automatically.
Azure checks whether it has permission to read from Key Vault.
Secrets are retrieved securely, without being exposed at any point.

This eliminates:

.env files leaking in logs
secrets embedded in build pipelines
hardcoded credentials

And strengthens:

Security
Auditability
Governance

Conclusion

When it comes to cloud applications, security is not just about “enabling HTTPS.”
It’s about protecting identity, authorization, and secrets consistently across environments.

The good news is:
With .NET and Azure, this strategy can be clear, robust, and maintainable.

Security becomes part of the architecture, not an afterthought.

Cloud App Journey: Ep. 4 — Boosting Performance with Redis Cache on Azure

OSVALDO ALVES — Tue, 21 Oct 2025 12:41:31 +0000

When an application grows and the number of users increases, so does the number of database queries.
What once worked perfectly can suddenly become a bottleneck — APIs slow down, response times increase, and performance starts to deteriorate.

At that point, one question becomes inevitable:

How can I make my application faster and more efficient without rewriting the entire codebase?

That’s where caching comes in — one of the most effective and elegant solutions for improving performance in cloud applications.
And in this seventh episode of the App in the Cloud series, we’ll explore how to use Azure Cache for Redis to boost your app’s performance and efficiency.

⚡ The Role of Caching in Application Performance

Every time an application retrieves data from a database or external service, it consumes resources — CPU, memory, and time.
If the same information is requested repeatedly, it makes little sense to fetch it from the source every time.

Caching allows us to temporarily store frequently accessed data in memory, so subsequent requests can be answered almost instantly.

In practice, caching can:

Reduce latency in API calls

Decrease database load

Improve scalability and resilience

Lower operational costs

In cloud environments, caching becomes even more strategic: it helps maintain performance consistency, even when demand spikes.

☁️ Azure Cache for Redis: What It Is and Why It Matters

Azure Cache for Redis is Microsoft’s managed Redis service — fully compatible with the open-source Redis engine, but with all the scalability, monitoring, and security features that come with Azure.

With it, you can:

Store and retrieve data in-memory at lightning speed

Cache session state or frequently accessed objects

Implement distributed locks or queues

Scale elastically according to your workload

And the best part: you don’t have to worry about managing infrastructure, nodes, or clusters — Azure handles that for you.

🧩 Example: Integrating Redis Cache in a Java Application

If you have a Spring Boot application, connecting to Azure Cache for Redis is quite straightforward.

@Configuration
public class RedisConfig {

    @Bean
    public LettuceConnectionFactory redisConnectionFactory() {
        return new LettuceConnectionFactory("your-redis-name.redis.cache.windows.net", 6380);
    }

    @Bean
    public RedisTemplate<String, Object> redisTemplate() {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(redisConnectionFactory());
        return template;
    }
}

Once connected, your application can use RedisTemplate to store and retrieve data — without constantly hitting the database.
You can cache anything from small objects to entire API responses, depending on your use case.

🚀 Best Practices for Efficient Caching

When caching is used wisely, it can drastically improve both user experience and system stability.
Here are some best practices to keep in mind:

Define appropriate expiration times (TTL):
Never keep data in cache longer than necessary.

Cache only what’s stable:
Avoid caching data that changes frequently or is highly dynamic.

Use eviction policies:
Redis supports policies such as Least Recently Used (LRU) and Least Frequently Used (LFU) — choose the one that fits your needs.

Monitor your cache performance:
Pay attention to metrics like hit/miss ratio — it reveals how effective your caching strategy really is.

Plan for elasticity, not just scalability:
Your cache should not only grow when demand increases but also shrink when it drops.
That’s what defines a truly elastic architecture.

🧠 Redis Stack: Beyond Simple Caching

Redis has evolved a lot over the years, becoming much more than just a key-value store.
With Redis Stack, available in Azure Cache for Redis Enterprise tiers, new capabilities expand its use cases:

Feature Description Use Case
RedisJSON Store and query JSON documents directly APIs and microservices using structured data
RedisSearch / Vector Search Full-text and semantic search AI, chatbots, and recommendation systems
RedisStreams Event stream management Real-time data pipelines and message processing
RedisTimeSeries Time-based data storage Monitoring, analytics, IoT metrics

These features make Redis a real-time data layer capable of supporting event-driven and intelligent applications — far beyond simple caching.

💬 Wrapping Up

Performance is not just about writing fast code — it’s about making smart architectural decisions.
Redis helps you do exactly that: reduce latency, offload your database, and create a smoother experience for users.

And when combined with the scalability and reliability of Azure, it becomes a powerful foundation for modern applications.

Cloud App Journey - Ep. 3: Publishing my Backend in Containers exploring the Cloud

OSVALDO ALVES — Mon, 25 Aug 2025 12:27:24 +0000

If you've been following the previous episodes of our "App na Cloud" series, you've already seen how easy it is to start deploying applications to the cloud—whether it's authentication with Azure services, publishing full-stack applications via App Service, or deploying lightweight and cost-effective frontends.

Now it's time to talk about a very relevant topic in a developer's daily life: containers.

Why Containers?

Containers are one of the most flexible and portable ways to package and distribute applications today. With them, we can:

Ensure the application runs the same way in any environment.
Quickly deploy new versions without configuration headaches.
Take the same image to different clouds or even run it locally.

In other words, if you have a backend API, for example, you can package it into an image and run it exactly the same on your laptop, an on-premises server, or any cloud.

Where to Store My Images?

Before publishing containers on Azure, we need an image repository. Here are some options:

1. Docker Hub (Free and Popular)

By creating an account on Docker Hub, you can upload your images and use them from anywhere.
Ideal for personal projects, prototypes, or when you don't need fine-grained security control.

Example of publishing an image:

# Build the image
docker build -t my-user/my-backend:1.0 .

# Login to Docker Hub
docker login

# Push to the repository
docker push my-user/my-backend:1.0

2. Azure Container Registry (ACR)

Microsoft's private image repository on Azure.
Offers security, integration with Active Directory, and can be used in corporate scenarios.

Creating an ACR via Azure CLI:

az acr create --resource-group my-group \
  --name myacrregistry \
  --sku Basic

Logging in and pushing the image:

# Login to the registry
az acr login --name myacrregistry

# Tag for ACR
docker tag my-backend:1.0 myacrregistry.azurecr.io/my-backend:1.0

# Push
docker push myacrregistry.azurecr.io/my-backend:1.0

Now your image is securely stored in Azure.

Publishing Containers on Azure

Once we have the image, we need a service on Azure to run it. Here are some alternatives:

Azure Container Apps (Recommended for Simplicity)
Serverless service for containers.
Automatic scaling, and you only pay for usage.
Great for backends and APIs.

Quick creation example:

az containerapp create \
  --name my-backend-app \
  --resource-group my-group \
  --environment my-env \
  --image myacrregistry.azurecr.io/my-backend:1.0 \
  --target-port 8080 \
  --ingress external

Your backend will now be available at a public endpoint.

2. Azure Container Instances (ACI)

Still a valid service, focused on simplicity.
Allows quickly running a single container without much configuration.

It's like a "docker run" in the cloud.

Example:

az container create \
  --resource-group my-group \
  --name my-backend-aci \
  --image myacrregistry.azurecr.io/my-backend:1.0 \
  --ports 8080

3. Azure Kubernetes Services (AKS)

More powerful and comprehensive, but also more complex.
Suitable for scaling and high availability scenarios.

Not the focus of this article, but worth noting as the alternative for robust production scenarios.

Which Path to Follow?

Personal project / study → Docker Hub + Container Apps or Container Instances
Simple corporate project → ACR + Container Apps
Larger-scale production → ACR + AKS

Conclusion

We've reached the end of another episode of the "App na Cloud" series. Today, we saw that deploying backends in containers can be much simpler than it seems—whether using a public repository on Docker Hub or exploring the power of Azure Container Registry combined with Azure App Service or Azure Container Apps.

But publishing is just the first part of the journey. The real challenge begins when your application needs to run in production in a stable, secure, and observable manner. This is when monitoring practices and services come into play, ensuring you truly know what's happening with your app, whether it's consuming many resources, handling failures, or serving thousands of simultaneous users.

In the next episode, we'll delve into these monitoring practices and tools.

Cloud App Journey - Ep. 2: Publishing My Frontend to the Cloud

OSVALDO ALVES — Mon, 18 Aug 2025 12:52:30 +0000

🚀 Welcome to the second episode of our Cloud App Journey series!
After learning how to authenticate with Azure services and how to publish our backend, today we’ll focus on the frontend.

If you’re building a Single Page Application (SPA) with frameworks like React, Angular, or Vue, you’ll see that publishing your app on Azure is simpler and cheaper than you might think.

🌐 Choosing the Best Hosting Option
When publishing SPAs in Azure, you might think about using App Service (the same one we used for the backend).
But here’s the trick: SPAs don’t need a full backend hosting environment.

Instead, the most efficient and cost-effective way is to use Azure Storage Static Website Hosting.

Why?
✔️ Incredibly cheap (we’re talking cents per month).
✔️ Extremely simple to configure.
✔️ Built-in high availability.
✔️ Integrates seamlessly with Azure CDN, for global distribution if needed.

📦 Step 1: Preparing Your Build
If you’re using React, Angular, or another SPA framework, the first step is to build the production version of your app.

For example, in Angular:

ng build --configuration production

In React:

npm run build

This will generate a folder (usually called dist or build) with all the compiled static files (HTML, CSS, JS, and assets).

☁️ Step 2: Creating a Storage Account
In Azure Portal:

Search for Storage Account.

Create a new account (standard performance is usually enough).

Go to the Static Website menu (inside the storage account).

Enable it and configure the index document (e.g., index.html) and error document (e.g., index.html as well, if you’re using SPA routing).

This will generate a public URL for your website, something like:

https://<your-storage-account>.zxx.web.core.windows.net

📂 Step 3: Uploading Your Files
There are different ways to upload your SPA build to the storage account:

Azure Portal: upload files directly in the browser.

Azure Storage Explorer (a free Microsoft tool).

Azure CLI:

az storage blob upload-batch \
  --account-name <your-storage-account> \
  --destination '$web' \
  --source ./build

⚡ Step 4: (Optional) Adding a CDN
If your users are spread across different regions, you can easily integrate a CDN to ensure your frontend loads faster worldwide.

In the storage account:

Go to Front Door and CDN.
Create a new CDN profile.
Link it to your static website endpoint.

That’s it — now your SPA is globally distributed! 🌍

🎉 Wrapping Up
Publishing your frontend in Azure doesn’t have to be complicated or expensive.
With just a Storage Account, you get a secure, highly available, and low-cost hosting solution for your SPAs.

👉 In the next episode, we’ll explore how to publish containerized App, front and/or backend apps.

💡 Have you already tried publishing a frontend in Azure? What challenges did you face? Share your experience in the comments!

Cloud App Journey — Ep. 1: Deploying your Backend to Azure — The Easiest Path

OSVALDO ALVES — Wed, 06 Aug 2025 13:23:02 +0000

Welcome to the first article of our new series App na Cloud — designed to help software developers who are taking their first steps with cloud development on Azure.

In this series, we’ll go hands-on with common use cases, best practices, and practical guidance on how to run your apps in the cloud — with real examples using Azure services.

We’ll focus on how to deploy, secure, and scale your backend applications — with minimal friction.

What Are We Building?
Every modern application needs a backend running somewhere. Azure offers several options to host and run your backend, but we’ll start by covering the three most practical and beginner-friendly options for developers:

✅ Azure App Service
✅ Azure Container Apps
✅ Azure Functions

Each one will be covered in its own article. Today, we begin with the Azure App Service, one of the simplest ways to deploy REST APIs and web applications to Azure.

What is Azure App Service?
Azure App Service is a fully managed platform for building, deploying, and scaling web apps and APIs. It takes care of the infrastructure so you can focus on your code.

You can deploy .NET, Node.js, Java, Python, and more — and benefit from built-in scaling, SSL support, custom domains, staging environments, and easy CI/CD integration.

Step-by-step: Publishing a .NET 9 Web API on Azure App Service
Let’s go through how to publish a basic REST API built with ASP.NET Core (.NET 9) using Visual Studio.

🔹 Step 1 – Create an App Service on Azure
In the Azure Portal:
Go to Create a Resource > App Service.

🔹 Fill in the basic settings:
Resource Group
App Name (e.g. my-api-demo)
Runtime Stack: .NET 9 (LTS)
Region: Choose one close to your users

🔹 Step 3 – Create your Web API Project
In Visual Studio:
Create a new ASP.NET Core Web API project.
Choose .NET 9 as the target framework.
Add a simple controller like this:


[ApiController]
[Route("[controller]")]
public class HelloController : ControllerBase
{
    [HttpGet]
    public string Get() => "Hello from Azure!";
}

🔹 Step 4 – Publish from Visual Studio
Right-click the project > Publish.
Choose Azure > App Service (Windows).
Sign in, select your subscription and App Service.
Click Publish — and you're live!

Your API will be publicly available at a URL like:
https://my-api-demo.azurewebsites.net/hello

✅ Why Use Azure App Service?

No infrastructure management
Built-in DevOps support (GitHub, Azure DevOps, etc.)
Automatic scaling and high availability
Easy integration with Azure AD, Blob Storage, SQL, and more

What’s Next?
In the upcoming articles, we’ll explore:
Azure Container Apps — perfect for containerized apps and microservices
Azure Functions — ideal for serverless and event-driven architectures
Stay tuned and follow the series to keep learning how to build modern cloud-native backends using Azure! 🚀