DEV Community: Florian Lenz

Azure AI Search: The Developer's Secret Weapon Most Teams Ignore

Florian Lenz — Thu, 05 Feb 2026 21:27:23 +0000

Most developers treat search as an afterthought.

You build the core features. You nail the UI. You optimize performance. And then, almost as a checkbox item, you add a search bar that… barely works.

Users type queries. They get irrelevant results. They rephrase. They give up. They leave.

But here’s what surprised me: the problem isn’t that search is hard to build. It’s that most teams are solving the wrong problem entirely.

They think search is about finding keywords.

Modern users expect search to understand intent.

In this post, I’ll show you how Azure AI Search bridges that gap—and why it’s one of the most underutilized tools in the Azure ecosystem. Based on projects I’ve implemented and edge cases I’ve hit, you’ll learn:

Why full-text search is table stakes (and what actually differentiates great search)
The one feature that makes Azure AI Search feel like magic to users
How to avoid the #1 mistake teams make when implementing search services

Let’s start with what most developers get wrong.

The Keyword Trap: Why Basic Search Fails Users

Most search implementations work like this:

User types “affordable running shoes”

→ System searches for exact matches

→ Returns 47 results

→ User scrolls, scrolls, doesn’t find what they want

→ Leaves

Here’s the conflict:

Users don’t think in keywords. They think in problems and intent.

When someone searches “affordable running shoes,” they might actually mean:

“Running shoes under $100”
“Budget-friendly marathon training shoes”
“Cheap sneakers for jogging beginners”

A keyword-based search engine treats these as completely different queries. The result? Frustration before users ever see your best content.

Most teams stop here and accept “good enough” search.

That’s a mistake.

The Intelligence Layer: Natural Language Processing in Action

This is where Azure AI Search separates itself from basic full-text engines.

It includes built-in Natural Language Processing that understands:

Semantic meaning “affordable” = “budget-friendly” = “cheap”
Context “running shoes” vs “running a business”
Synonyms Configurable synonym maps for domain language
User intent What users actually want—not just what they typed

Real Example: E-Commerce Search

I worked on an e-commerce platform where users frequently searched for:

“laptop for students”

With keyword search:

Returned any product with “student” in the description
Missed laptops perfect for students but marketed differently
Surfaced “student discount available” accessories that weren’t laptops

With Azure AI Search + NLP:

Understood intent: affordable, portable, long battery life
Ranked results based on student needs
Surfaced relevant products even when descriptions used different terminology

Result:

📈 34% increase in search-to-purchase conversion

But NLP alone isn’t the real secret.

That comes next.

Customizable Relevance Ranking: The Feature That Changes Everything

Here’s the part most documentation glosses over:

Not all search results are created equal.

Even with perfect intent detection, users still need the right result at the top.

The Problem with Default Ranking

Default ranking usually relies on:

Keyword frequency
Document recency
Basic TF-IDF scoring

That breaks down quickly in real systems.

Real Edge Case: Documentation Search

I implemented Azure AI Search for a SaaS documentation site.

Problem:

Most searched term: “API authentication”
Top result: a 3-year-old changelog mentioning auth
The actual authentication guide? Buried on page 2

The default ranking favored keyword density and recency—not usefulness.

The Fix: Custom Scoring Profiles

Azure AI Search lets you define what relevance actually means for your product.

{
  "name": "docRelevance",
  "text": {
    "weights": {
      "title": 3.0,
      "description": 2.0,
      "content": 1.0
    }
  },
  "functions": [
    {
      "type": "freshness",
      "fieldName": "lastModified",
      "boost": 2.0
    },
    {
      "type": "magnitude",
      "fieldName": "pageViews",
      "boost": 1.5
    }
  ]
}

Why Most Search Features Fail (And How Azure AI Search Fixes It)

Most teams treat search like infrastructure.

Set it up once. Ship it. Forget it.

That’s a mistake — and it’s why users abandon searches, open support tickets, and quietly lose trust in your product.

Here’s what actually works.

What These Changes Do

We made three targeted ranking adjustments:

Boosted title matches 3×

Users searching “API authentication” now see documents with that phrase in the title first.
Considered freshness — without letting it dominate

New content matters, but not at the expense of relevance.
Factored in page views

Popular documents are usually popular for a reason.

Result After Tuning

📈 Authentication guide moved to position #1
🔻 Search abandonment dropped 41%
🎫 Support tickets about “can’t find docs” decreased significantly

The #1 Mistake: Treating Search as “Set and Forget”

Here’s the hard truth most teams learn too late:

Search quality degrades over time.

You launch with perfect indexing and well-tuned ranking. Everything works beautifully.

Then reality sets in:

User behavior shifts
Content grows and changes
New synonyms emerge
Query patterns evolve

What worked on day 1 quietly fails by day 180.

The Solution: Built-In Analytics + Continuous Optimization

This is where :contentReference[oaicite:0]{index=0} quietly shines.

It includes analytics that surface:

Top queries with no results → content gaps
High-abandon searches → relevance problems
Click-through rate by position → ranking effectiveness
Query refinements → UX issues

This feedback loop is what separates good search from great search.

The Implementation Checklist You Actually Need

Most guides stop at:

create service → define index → ingest data → query

That’s not production-ready search.

Before You Start

[ ] Map user intent patterns (not just keywords)
[ ] Identify natural content categories (for facets)
[ ] Define what “relevance” means for your product

During Setup

[ ] Create custom scoring profiles (don’t rely on defaults)
[ ] Configure synonym maps for your domain language
[ ] Set up faceted navigation for top 3–5 attributes
[ ] Enable analytics from day one

After Launch

[ ] Review zero-result queries weekly
[ ] Audit top 20 queries monthly
[ ] A/B test ranking changes
[ ] Update synonym maps based on real user language

The Real Power of Azure AI Search

Here’s what most documentation won’t tell you:

Azure AI Search isn’t just search. It’s an intelligence layer.

It changes how users discover information — from frustrating keyword hunting to intuitive, context-aware exploration.

The difference looks like this:

❌ Users abandoning your app

✅ Users engaging with it
❌ Support drowning in “I can’t find X”

✅ Users self-serving successfully
❌ Maintaining custom search code

✅ Configuring a managed service

The Myth That Holds Teams Back

Most teams assume great search requires:

ML expertise
Months of tuning
Custom infrastructure

The reality:

Azure AI Search delivers production-grade, AI-powered search — if you configure it correctly.

Final Thought

Search isn’t just a feature.

It’s often the difference between users finding value — or giving up and leaving.

The real question isn’t whether you should invest in better search.

It’s whether you can afford not to.

Turn Any REST API into an MCP Server with Azure API Management

Florian Lenz — Tue, 30 Dec 2025 16:05:03 +0000

Unlock the power of your existing APIs — make them AI-agent friendly, discoverable, and usable by intelligent applications with just a few clicks.

Modern applications aren’t just about serving data to front-end clients or backend services anymore. With the rise of AI agents and powerful LLM-driven tools, the expectations for how systems should expose and consume APIs are shifting fast. APIs that once served developers now need to serve AI agents. And that’s where the Model Context Protocol (MCP) comes in.

In this post, you’ll learn why MCP matters, how Azure API Management (APIM) can act as an AI-Gateway, and how you can turn any REST API into an MCP server in minutes, without writing any backend logic.

If you found this useful, I share deeper dives and additional articles on Substack and LinkedIn. Feel free to follow me there for more content.

What Is Azure API Management?

Azure API Management (APIM) is a fully managed service from Microsoft that sits in front of your APIs and acts as a gateway between clients and backend services.

At its core, APIM lets you:

Publish existing APIs without changing backend code
Secure APIs with authentication, authorization, and rate limits
Transform requests and responses (headers, paths, payloads)
Monitor usage, performance, and failures

Traditionally, APIM is used to expose APIs to developers in a controlled, scalable way. But the same gateway capabilities also make it ideal for AI-driven use cases. With APIM, you can shape how APIs are discovered, described, and invoked, without touching the underlying service.

That’s exactly why APIM works so well as an AI Gateway: it already understands APIs at the contract level and can enforce policies consistently at the edge.

What Is an MCP Server?

MCP (Model Context Protocol) is a protocol designed to make tools and APIs natively usable by AI agents. Instead of treating APIs as opaque HTTP endpoints, MCP defines a structured way to expose:

What capabilities are available
What inputs each operation expects
What outputs it returns
How an AI agent should call it safely and correctly

An MCP server is simply a service that exposes these capabilities in an MCP-compatible way. You can think of it like USB for AI tools.

Just as USB provides a standard interface that lets any compatible device plug into any computer without custom drivers, MCP provides a standard way for AI agents to discover, understand, and use tools, databases, APIs, etc. Once an API is available via MCP, AI agents can discover it, reason about it, and invoke it as a tool, without custom glue code or hard-coded prompts.

The key idea is this:

MCP turns APIs into first-class tools for AI agents.

By combining MCP with Azure API Management, you can wrap existing REST APIs and instantly make them AI-ready—without rewriting services, adding new backends, or maintaining custom adapters.

From Zero to MCP in Azure API Management

Now here’s the practical part, how I turned a normal REST API (Star Wars API) into an MCP server using Azure API Management (APIM), then connected it to ChatGPT and verified the calls end-to-end.

If you want to follow along, you only need:

An Azure subscription
Permission to create an API Management instance
A public REST API (I used SWAPI because it’s free: https://swapi.info/)

Step 1) Create a new Azure API Management instance

Go to the Azure Portal → Create a resource → search for API Management.
Fill in the basics
- Resource group: create new (e.g., rg-mcp-demo)
- Region: pick whatever’s closest
- Name: must be globally unique (this becomes part of your gateway hostname)
- Organization name / admin email: required
Choose a pricing tier that fits your demo:
- For experiments, pick a developer-friendly option (but not consumption.
Click Create and wait until the APIM instance is provisioned.

Note: MCP server export is currently not available when using the Consumption pricing tier in Azure API Management.

Step 2) Create a new HTTP API in APIM (using SWAPI)

In your APIM instance, go to APIs → + Add API.
Choose HTTP.
Set:
- Display name: SWAPI
- Web service URL: https://swapi.info/api/
- API URL suffix (optional): something like swapi (this becomes /swapi/... on your gateway)
Create.

Step 3) Add the GET operations you want to expose

Inside your SWAPI API in APIM:

Click + Add operation
Create one operation per resource (GET):
- GET /people
- GET /planets
- GET /species
- GET /vehicles
- GET /starships
Click Save

Step 4) Test the API from APIM

In the operation (example: GET /people), open the Test tab.
Click Send.
Confirm you get a valid JSON response.

Step 5) Create an MCP server from the existing API (APIM → MCP)

In your APIM instance menu, go to APIs → MCP servers.
Click + Create MCP server.
Choose the option to Expose an API as an MCP server.
Select:
- The API you created (SWAPI)
- The operations you want to expose as tools (select all the GET operations you added)
Click Create

APIM will generate an MCP endpoint that describes your tools and supports agent-style invocation.

Step 6) Use the MCP server in an AI host

That’s it! Your API is now MCP-enabled.

You can now use the MCP server in:

ChatGPT
Visual Studio Code
and any MCP-compatible host or agent

The host connects to the MCP server URL, discovers the available tools, and can immediately start calling your API, with no custom prompts, glue code, or backend changes.

Where This Pattern Really Shines

At a glance, turning a REST API into an MCP server might look like a convenience feature. In practice, it’s a shift in how APIs participate in modern systems.

By putting Azure API Management in front of your services and exporting them as MCP servers, you’re creating a stable, contract-driven interface not just for developers, but for AI agents. That matters because agents don’t behave like traditional clients:

They discover tools dynamically
They reason about capabilities instead of endpoints
They chain calls together without hard-coded flows

APIM already solves the hardest parts of this problem: Versioning, security, throttling, observability. MCP simply gives those capabilities a language AI agents understand.

This pattern is especially powerful in a few scenarios:

Enterprise APIs that can’t be easily modified but need to be AI-accessible
Legacy systems where adding agent logic directly would be risky or slow
Platform teams that want a single, governed way to expose tools to AI across the organization

Instead of every team building custom “AI adapters,” you centralize the responsibility at the gateway, where it belongs.

Important Things to Keep in Mind

Before you go all-in, a few practical considerations are worth calling out:

Pricing tier matters: MCP export is not supported on the Consumption tier. Plan accordingly.
Tool design still matters: MCP doesn’t fix poorly designed APIs. Clear operation names, sensible inputs, and predictable outputs make a huge difference for agents.
Security is amplified: AI agents can call tools more frequently and creatively than humans. Rate limits, authentication, and scopes aren’t optional, they’re essential.
Observability becomes critical: MCP makes it easier to call APIs; APIM makes it easier to see who called what and why. Use that data.

Most importantly, treat MCP exposure as a product decision, not just a technical switch. You’re defining how intelligent systems interact with your business logic.

Terraform testing with Open Policy Agent and Conftest: Secure infrastructure through Terraform testing

Florian Lenz — Tue, 02 Dec 2025 09:38:37 +0000

Terraform has established itself as the leading tool for infrastructure as code: modules describe resources, plans show the planned changes, and an apply implements the configuration in the cloud. In practice, however, Terraform configurations are often only checked briefly, perhaps using terraform validate, and the rest of the code relies on peer reviews and good intentions. This is not enough, especially in regulated industries or security-critical projects. Errors such as incorrectly set defaults, publicly accessible resources, or missing encryption can lead to data breaches and high costs. In this article, you will learn about an approach that allows you to consistently test Terraform configurations—without creating real resources. The basis is the JSON output of terraform plan, which is checked against defined rules using Open Policy Agent (OPA) and Conftest.

Why is testing Terraform configurations important?

Terraform defines productive infrastructure. A single configuration error can make a database accessible worldwide, disable encryption, or sabotage cost control due to missing tags. According to recent cloud security studies, 80% of companies were affected by cloud security incidents last year, and Gartner predicts that by 2025, 99% of cloud security failures will be customer-related. This is particularly true for misconfigurations. More than 32% of reported incidents stem directly from misconfigurations. These figures illustrate that infrastructure code must be subjected to the same rigorous testing as application code.

Latent misconfigurations that lie dormant in existing resources are particularly dangerous. For example, an AzureStorage account is publicly accessible by default via the public_network_access_enabled attribute. If this property is not explicitly disabled, the storage account is openly accessible. The same applies to AWS S3 buckets, security groups with open ports, or missing encryption. In large teams with many modules and different environments (Dev, QA, Prod), manually checking plans quickly becomes confusing. That's why we need an automated, repeatable testing approach that takes effect before execution.

Limitations of classic terraform test approaches

Since version 1.6, Terraform has included its own testing mechanism (terraform test). On paper, this sounds appealing—but in practice, weaknesses quickly become apparent. Testing with terraform test is an additional step in the workflow: in addition to plan and apply, another command must be integrated into the CI/CD pipeline, maintained, and understood. Many tests also require resources to be actually created in a test environment. This means additional cloud costs, authorization effort, and potentially long runtimes. In strictly regulated areas, this is often not approvable.
Although efforts are being made to run tests based on the plan, these functions are still in their infancy and offer only limited support for complex compliance rules. The added value compared to a direct evaluation of the JSON plan remains low.

Another disadvantage is that terraform test is closely tied to the Terraform world. The rules are difficult to transfer to other systems, resulting in an isolated solution. For organizations that use Kubernetes manifests, Helm charts, or other IaC formats in addition to Terraform, this leads to fragmented governance approaches. There is no uniform policy level. This is where OPA and Conftest come in.

Policy-as-Code and Open Policy Agent

Policy-as-Code (PaC) is the principle of defining policies as versionable code and enforcing them automatically. Instead of relying on manual checks or written guidelines, rules are formulated in a declarative language. The Open Policy Agent (OPA) is a universal policy engine that evaluates these rules in the Rego language. OPA is used for Kubernetes admission controllers, API authorization, and cloud governance, among other things. Crucially, OPA is data-driven: it accepts any JSON and returns a decision.

The core of the approach is simple: instead of just checking the planned changes, we validate the complete future state of the infrastructure before resources are created. Terraform provides everything we need for this. With terraform plan -out=tfplan, we generate a binary plan and then convert it into a machine-readable JSON file with terraform show -json. This JSON contains both the current state and the planned changes and the resulting end result – including modules, defaults, and dependencies.

Conftest is a CLI wrapper around OPA that is specifically designed for checking structured files such as JSON, YAML, or HCL. A policy in Rego format is stored in a policy/ folder. When running conftest test against the JSON plan file, Conftest evaluates this policy and reports violations. This allows policies for Terraform, Kubernetes, and other formats to be bundled into a single tool.

Pipeline integration

In a typical CI/CD pipeline, the process looks like this:

Create plan: terraform plan -out=tfplan.binary generates a binary plan file.
Convert plan: terraform show -json tfplan.binary > tfplan.json converts the plan to JSON.
Evaluate policies: conftest test tfplan.json executes the Rego rules against the JSON. Each deny rule results in an error in the pipeline job.

This approach has several advantages. First, there are no cloud costs because no resources are built. Second, the test can be run early in the pipeline—even before merge requests are accepted. Third, the same policies can also be used for other technologies.

Example: Azure Storage Account without public access

A concrete example illustrates the method. Suppose that every Azure Storage account must disable public network access. In the Terraform module, we see a resource of type azurerm_storage_account:

resource "azurerm_storage_account" "this" {
  name                     = var.storage_account_name
  resource_group_name      = var.resource_group_name
  location                 = var.location
  account_tier             = "Standard"
  account_replication_type = "LRS"

  public_network_access_enabled = false
}

The following Rego code defines a policy that ensures that public_network_access_enabled is set to false for every scheduled azurerm_storage_accountResource change:

package main

deny[msg] {
  some rc in input.planned_values
  rc.type == "azurerm_storage_account"
  rc.change.actions[_] == "create"
  val := object.get(rc.change.after, "public_network_access_enabled", null)
  val != false
  msg := sprintf("%s: public_network_access_enabled muss false sein, gefunden %v", [rc.address, val])
}

When you run conftest test tfplan.json, the plan is checked against this rule. If public_network_access_enabled is not defined or is true, the test fails and outputs a clear error message. This prevents an insecure storage account from being accepted in the plan at all.

Extension to the entire future state

The above example only checks for resource changes. However, in many projects, it is important to validate the entire future state. Existing resources that remain unchanged in the current plan may still be non-compliant. The JSON object planned_values describes the final state after apply. A policy that recursively runs through all modules and checks every azurerm_storage_account in the future state looks like this:

package terraform.azure.storage

# All storage accounts in planned state
storage_accounts contains sa if {
  # walk runs recursively through the entire object
  some path, node
  walk(input.planned_values.root_module, [path, node])

  # We are only interested in resource objects of type Storage Account
  node.type == “azurerm_storage_account”

  sa := node
}

# Violation if public_network_access_enabled is not exactly false
deny contains msg if {
  some i
  sa := storage_accounts[i]

  # Read value (null if not set)
  val := object.get(sa.values, “public_network_access_enabled”, null)

  # Anything other than false is prohibited (true or null / not set)
  val != false

  msg := sprintf(
    “Azure Storage Account ‘%s’ has invalid public_network_access_enabled value: %v”,
    [sa.name, val],
  )
}

This rule runs through all modules, collects every storage resource, and checks the properties in the future state. This allows latent misconfigurations to be detected, even if the resource in question is not changed in the current plan.

Integration into the CI/CD pipeline

A solid pipeline should include the following steps:

Code analysis & formatting: Use tools such as terraform fmt and tflint.
Security scanners: Tools such as tfsec, Checkov, or Regula can perform static analyses based on known best practices.
Policy checks with OPA/Conftest: Run the plan through OPA/Conftest before applying and block merge requests in case of violations. Be sure not to version the JSON file in the repository, but to generate it temporarily in the pipeline job.
Drift detection: Use terraform plan regularly, even in production environments, to detect deviations between the code and the actual state. A comparison with OPA can indicate whether resources have been changed retrospectively.

With this type of multi-stage pipeline design, you can combine code quality, security scanning, and policy enforcement. When choosing tools, compatibility and maintainability should be taken into account. OPA and Conftest can be integrated into GitHub Actions, GitLab CI, Jenkins, Azure DevOps, or Terraform Enterprise and generate machine-readable reports.

Conclusion

Infrastructure as code offers many advantages, but also carries risks. Traditional testing in Terraform is either too closely tied to the ecosystem or requires the creation of real resources. By combining terraform plan, Open Policy Agent, and Conftest, infrastructure plans can be reviewed early on, cost-neutrally, and comprehensively. This approach validates not only changes, but also the entire future state – a decisive advantage for audit and compliance requirements. At the same time, misconfigurations continue to be cited as one of the main causes of security incidents. That's why testing Terraform with OPA should be integrated into every modern DevOps pipeline. This turns “infrastructure as code” into “infrastructure with guarantees” – secure, compliant, and traceable.

FAQ

What is the difference between terraform validate and OPA/Conftest tests?
terraform validate only checks the syntax and basic structure of the code. OPA/Conftest, on the other hand, enable semantic checks: they detect whether certain attributes are set correctly, tags are present, or security requirements are met. This allows compliance rules to be enforced automatically before resources are created.

Do I have to apply the plan for OPA tests?
No. The big advantage of OPA/Conftest is that you can export the Terraform plan as JSON and check it without cloud access. No resources are created, so there are no costs. The plan represents the future state against which the policies are evaluated.

How do I integrate OPA into my pipeline?
You can integrate OPA/Conftest into any CI/CD tools. In GitHub Actions, all you need is an additional job that runs terraform plan, terraform show -json, and conftest test. GitLab CI and Azure DevOps have similar mechanisms. It is important that the job aborts the build if conftest reports a violation.

Can the same policies also be used for Kubernetes or other tools?
Yes. OPA is not limited to Terraform. The policies check any JSON or YAML structures, such as Helm charts, Kubernetes manifests, or CloudFormation templates. This allows you to create a uniform governance layer across different platforms.

What happens if my Terraform modules change?
Since the test is based on the JSON plan, it doesn't matter how your modules are structured internally. As long as the resources appear in the plan, they will be checked. For new modules, you may need to define additional rules to cover new resource types.

How do I deal with complex rules?
Rego is a powerful language, but it also allows for complexity. For complex rules, it is recommended to build policies in a modular way, use helper functions, and write your own tests for the policies. The OPA Playground and community rules (e.g., for Kubernetes) offer helpful examples.

Azure Landing Zone Deployment: Private VNETs, Self-Hosted Agents & Service Connections

Florian Lenz — Sun, 13 Jul 2025 19:35:48 +0000

Security plays an important role in most cloud projects. A central component of this is the so-called landing zone, which serves as the basis for all other workloads. An essential security aspect in such setups is to only grant public access in exceptional cases. But this is precisely where a challenge often arises: How can I continue to carry out deployments with Azure DevOps from a private network?

Without public access, external tools such as Azure DevOps have no access to the resources in the private network.

In this article, I will show you step by step how this problem can be solved. After reading it, you should be able to implement a similar architecture yourself.

Initial situation: No public access, no deployment?

If we set up a private virtual network (VNET) in Azure and block public access, this initially means that no connections from the Internet to the resources are permitted.

Publicly accessible endpoints always pose a security risk: They can potentially be reached by attackers from the internet, making attacks such as port scanning, brute force attacks or exploits against vulnerabilities possible. For business-critical applications or sensitive data in particular, it is therefore common practice to reduce the attack surface as much as possible by avoiding public access.

A virtual network (VNET) in Azure is a logical isolation within the Azure cloud, comparable to a separate network segment in a traditional data center. You can place resources such as virtual machines (VMs), databases, app services or other services in a VNET and allow them to communicate with each other via private IP addresses.

Network security groups (NSGs), private endpoints and your own routing rules can be used to precisely control which data traffic is permitted and which is not. The VNET acts like a security fence around all the resources it contains.

If we consistently do without public access, services such as Azure DevOps initially face an insurmountable hurdle: by default, pipelines use Microsoft-hosted build agents that run outside our Azure environment. These agents cannot simply “reach into” our private VNET, as they have no access to the private IP addresses and no route into the internal network.

As a result, deployments to private subnets, internal databases or protected API endpoints would fail - even though these resources are actually our target.

We therefore need a way to carry out deployments without compromising the security approach. The solution: We bring the agent into the private VNET, i.e. to where our resources are located. In this way, we can carry out deployments internally and at the same time take full advantage of the benefits of an isolated network.

Step 1: Set up self-hosted agent in the private VNET

Even if the agent is located in the private network, it must be able to connect to Azure DevOps in order to execute builds and download artifacts. To do this, specific exceptions must be allowed in the firewall.

Before you install the agent yourself, your VNET must be prepared accordingly. To do this, you should create your own subnet in which the VM for the agent will later be operated. This subnet should be configured in such a way that it has suitable security guidelines and is cleanly separated from the rest of the network. A Network Security Group (NSG) regulates incoming and outgoing traffic here. Outgoing traffic is primarily relevant for the self-hosted agent, as it has to communicate with Azure DevOps. Incoming traffic usually only requires management access (e.g. via SSH or Azure Bastion) so that you can reach and maintain the VM in the event of an error.

When creating the VM itself, it is important to choose a suitable size and image. In many cases, a medium-sized standard VM, such as the Standard_D2s_v3 type, is sufficient. You can choose between Windows Server or Linux (e.g. Ubuntu) as the operating system, depending on which tools and build environments you require. It is crucial that you mount the VM directly in the prepared subnet and do not assign a public IP address. This ensures that the VM is only accessible internally and does not offer any unnecessary attack surfaces to the outside world.

In order for the agent to be able to communicate with Azure DevOps, it must be allowed to reach certain destinations on the internet despite the private network. This requires specific releases in the firewall or in the NSG. The VM requires access to at least:

Only through these approvals can the agent register builds, download artifacts and send status messages back to Azure DevOps.

Step 2: Install agent on the VM

As soon as the VM and the firewall rules are in place, you can install the agent in the VM. To do this, download the agent package from Azure DevOps and register the agent via a personal access token (PAT) or via OAuth.

Before you start the actual installation, you should make sure that the VM has a working connection to the internet and that the URLs mentioned in step 1 are accessible. In addition, the operating system must be up-to-date and PowerShell should be installed on Windows systems and an up-to-date shell environment on Linux systems. In many cases, the .NET Core Runtime is also required, especially for newer agent versions.

To authenticate the agent to Azure DevOps, you first create a personal access token. This token is required later so that the agent can connect to your Azure DevOps tenant. You can find the creation in the Azure DevOps portal under your user account (top right), there under Personal access tokens. When creating the token, assign a name, select the desired validity period and specify the required authorizations, in this case mainly agent pools (read & manage). After creating the token, copy it and keep it safe, as it is only displayed once.

The next step is to download the appropriate agent package. To do this, go to the project settings in Azure DevOps, open the Agent Pools section and select the pool in which the new agent should appear. If no pool exists yet, you can also create a new one here. After clicking on New agent, select your operating system and download the ZIP archive provided. Unzip this package into a local directory on the VM, for example C:\azagent on Windows or /opt/azagent on Linux.

Then open a console with administrative rights on the VM, change to the unpacked directory and start the configuration script. Under Windows, this script is called config.cmd, under Linux or macOS config.sh. When you start it, you will be guided through a series of questions: First, enter the URL of your Azure DevOps server (e.g. https://dev.azure.com/mein-unternehmen). Then select the PAT authentication method and insert the previously created token. In the next step, select the agent pool in which the agent is to be registered and assign a name for the agent itself, such as private-vnet-agent-01. Optionally, you can define tags with which you can address the agent later in pipelines.

After the wizard has run, you will be asked whether the agent should be set up as a service. You should definitely confirm this option, as the agent will be started automatically each time the VM is restarted and will remain permanently available. After completing the configuration, you can activate the service on Windows with .\svc install and .\svc start, on Linux accordingly with sudo ./svc.sh install and sudo ./svc.sh start.

Once all steps have been successfully completed, you can check in the Azure DevOps Portal whether the agent is displayed as online in the selected pool. From this moment on, the agent is ready for use, can accept build and release jobs and has access to internal resources via the private VNET without these having to be publicly accessible.

Step 3: Create app registration and service connection

What we are still missing is authentication against Azure. So far, we have only created the agent that runs in the private network and executes our pipeline steps locally. However, in order for this agent to be able to create, change or delete resources in Azure - for example, deploy an app service instance or configure a database - it needs authorizations. This is exactly where the service connection comes into play.

At this point, it is important to clearly understand the difference between agent and service connection: The agent is the “worker” that does the actual work, i.e. performs builds, tests and deployments. The service connection, on the other hand, is the “key” that gives this worker access to Azure resources. Without this key, the agent could theoretically issue commands, but would not have any rights to change anything in Azure.

The service connection is based on an app registration in Microsoft Entra ID (formerly Azure AD). This app registration provides a technical identity that is secured by a secret. It enables Azure DevOps to log in securely to your Azure tenant without having to use a personal user or insecure access data.

To create the app registration, first navigate to Microsoft Entra ID in the Azure portal and select the App registrations section. There you create a new app registration, assign a descriptive name, for example devops-service-connection, and register the application. In most cases, you can leave the options for supported account types at “This organization directory only”; a redirect URI is not required for this use case.

After registering, you must create a secret that serves as the password for this technical identity. Under the menu item Certificates & secrets, you create a new secret, enter a description and select a suitable validity period. After creating it, you will receive a value, which you must copy immediately and save securely, as it will not be displayed again later.

In addition to this secret, you will need two other IDs from the app registration: the application ID (client ID) and the directory ID (tenant ID). Both can be found directly in the app registration overview. Together with the secret, they form the access data that is later stored in Azure DevOps.

In order for the App Registration to actually be allowed to manage resources in Azure, it must be assigned the appropriate authorizations. To do this, you can either go to the entire subscription in the Azure portal or - if you want more granular control - to the respective resource group. Under Access Control (IAM), assign the Contributor role to App Registration. This role allows you to create, change and delete resources. In some cases, it may make sense to choose a more restrictive role or even define a custom role, depending on how exactly you want to restrict the authorizations.

Once the app registration and authorizations have been prepared, the next step is to set up the service connection in Azure DevOps. To do this, open your project in Azure DevOps, go to the project settings, then to the Service connections section and create a new connection of the type Azure Resource Manager. Select the Service principal (manual) option here.

In the next step, enter all previously saved information: the subscription ID, the name of the subscription, the application ID (client ID), the secret and the directory ID (tenant ID). After saving, Azure DevOps automatically checks the connection. If everything is configured correctly, you can then name the service connection, for example Azure-Prod-Connection, and save it.

From this point on, your pipeline has an authorized connection to Azure.

Bottom line

By using a self-hosted agent in a private VNET, a secure and controlled deployment architecture can be set up that does not require public access. The combination with a cleanly configured service connection via an app registration offers the necessary flexibility for builds and deployments.

Even if the initial outlay is somewhat higher, a considerable increase in security and stability is achieved in the long term - a decisive advantage for companies with high security requirements or compliance specifications.

Serverless for greenfield projects: How data-driven architectures are revolutionizing your software development

Florian Lenz — Thu, 02 Jan 2025 19:26:35 +0000

tl;dr

Serverless architectures are the ideal basis for greenfield projects. They allow a quick start, minimize costs thanks to the pay-per-use model and adapt dynamically to changing requirements. No user data yet? No problem: serverless helps you to gather valuable insights and optimize your infrastructure in a data-driven way. Instead of starting with an oversized architecture, you can rely on the KISS principle (“Keep it Simple, Stupid”) and save time and resources. Should your architecture need to change, the majority of your code remains reusable. Serverless offers flexibility, efficiency and a clear future perspective.

The growing demands on developers

Software development teams are faced with an almost paradoxical challenge: they are expected to bring innovative products to market in ever shorter timeframes while making do with limited resources. However, the reality is often different. Developers lose valuable time administering the infrastructure, while unused resources put a strain on the budget due to overprovisioning. This situation not only leads to frustration, but also inhibits innovation. The question we need to ask ourselves is: How can we get rid of this ballast and concentrate fully on the essentials - creating added value?

The role of the software developer has changed considerably in recent years. It is no longer just about writing code. Developers have to deal with a variety of additional tasks that used to be left to the operations teams.

These include infrastructure management, setting up CI/CD pipelines, security monitoring and scaling applications, and these tasks often come at the expense of the actual development work. Studies show that developers can only spend around 40% of their time developing new functions. The rest of the time is spent on administrative tasks and maintenance. As a result, innovation falls by the wayside and projects are delayed.

Serverless the solution

Serverless represents a new type of infrastructure management. It is not just a technical concept, but a completely new operating model that allows developers to focus on their core tasks. An illustrative example of this is Coca-Cola, which added a mobile application to its Freestyle vending machines during the COVID-19 pandemic.

Coca-Cola Freestyle

The Coca-Cola Freestyle machines offer consumers the opportunity to create their own individual drink from over 100 flavors. But with the pandemic came a new challenge: customers were afraid to touch the machines' touchscreens. To solve this problem and create an innovative customer experience at the same time, Coca-Cola developed an app that allows users to operate the machines touch-free via their smartphone.

The app had to be developed quickly as the pandemic required an immediate solution. Coca-Cola opted for a serverless approach to save time and costs. Using services such as AWS Lambda and API Gateway, the company was able to deploy a working solution within a few weeks, and the pay-per-use model allowed Coca-Cola to pay only for actual usage.

This was particularly important as it was not clear at the outset how many customers would actually use the app. Serverless ensured that no resources were wasted and no bottlenecks occurred. The speed to market and flexibility of the serverless architecture was crucial to regaining customer trust while delivering an innovative digital experience.

The perfect solution for greenfield projects

Serverless architectures are ideal for greenfield projects: They give developers the freedom to get started immediately without having to carry the burden of a complex infrastructure. Instead of investing weeks in setup and maintenance, teams can get straight down to the real work - developing features and innovations.

The first advantage is obvious: cost control. With the pay-per-use model, you only pay for what you actually use. No idle time, no wasted resources. At the same time, the architecture adapts flexibly - be it to a sudden rush of new users or to times of low demand. Serverless ensures that your infrastructure scales with your project.

Comparison of resource allocation models: Over-provisioning, under-provisioning and pay-as-you-go

But as is so often the case in software development, changes are inevitable. Requirements change: suddenly more users than expected, new features or unexpectedly high traffic peaks. This is exactly where serverless comes into its own - at least at the beginning. As soon as your data and metrics mature, it becomes clearer whether serverless is still optimal or whether a new architecture is necessary.

And that's the crucial point: just because your requirements might change later, you shouldn't choose an oversized infrastructure from the outset.a key advantage of serverless is that it enables data-driven development of your architecture. In the initial phase of a project, there is often a lack of precise data on user behavior, load distribution and other critical factors. With serverless, you can gather initial insights without time-consuming preparations or investments in oversized infrastructure.

Monitoring of a serverless application with important information on access numbers, response times and load distribution (https://www.asserts.ai/blog/monitoring-aws-lambda/)

As your project grows, you generate more and more valuable data and metrics. This data helps you to optimize your architecture in a targeted manner and make well-founded decisions. If it turns out that serverless is no longer optimal for your specific scenario, you can flexibly migrate to a new architecture - and reuse most of your code and logic in the process.

The “KISS - Keep it Simple, Stupid” principle applies here: start simple. A lean serverless architecture not only reduces complexity, but also minimizes risks. It is better to start small and grow dynamically than to waste valuable time and resources with an oversized solution. Serverless is the perfect way to get started, giving you the flexibility to focus on the essentials while being prepared for the future, and the best part?

If your requirements change at some point and a different architecture becomes necessary, migration is often easier than you think. Most of your code and logic is retained and can be easily integrated into the new architecture. This is also confirmed by Allen Helton, who switched from a serverless architecture to a monolithic architecture with the Amazon Prime Video/Audio Monitoring Service:

Conceptually, the high-level architecture remained the same. We still have exactly the same components as we had in the initial design (media conversion, detectors, or orchestration). This allowed us to reuse a lot of code and quickly migrate to a new architecture.

Serverless is therefore more than just a technical model - it is a way of thinking that enables teams to work faster and more agile, drive innovation and react flexibly to market changes.

Azure Durable Task Scheduler advantages for Durable Functions

Florian Lenz — Thu, 21 Nov 2024 21:46:30 +0000

Managing complex, long-running processes is often a challenge in software development. Frameworks such as the Azure Durable Task Framework or Azure Durable Functions can help to orchestrate complex processes. Until now, however, they have only offered limited options for monitoring and analyzing processes. With the introduction of the Azure Durable Task Scheduler, significant progress has been made that considerably simplifies the development and monitoring of such workflows.

Challenges in the orchestration of workflows

The orchestration of workflows is a central component of modern software development, especially when it comes to complex, long-running processes. Although many frameworks offer solutions, there are often practical hurdles that lead developers to pursue alternative approaches.

Complexity of process control

Controlling workflows quickly becomes a challenge as complexity increases. Processes must connect different services and systems and often take dependencies or conditional logic into account. Durable Functions promised to cope with this complexity, but in practice we often came up against limits, especially when it came to the traceability and control of processes.

To get around this problem, I relied on choreography patterns in almost all projects. Instead of using a central orchestration component, we had the individual services communicate with each other via event mechanisms such as Azure Service Bus or Event Grid. This led to greater modularity and decoupling of the services, making the processes more flexible. However, this approach also had disadvantages: without central control, we had to develop additional tools and logic to maintain an overview.

Error handling and recovery

Errors are one of the unavoidable challenges in workflow orchestration. Network problems, service failures or unforeseen error sources can bring any process to a standstill. Durable Functions promised a theoretical remedy here too, but in practice it was often unclear how a workflow could be cleanly restored without losing data.

To overcome this challenge, we also relied on dead letter queues. Faulty messages or events were stored in special queues, analyzed and reprocessed if necessary. Although this approach generally worked well, it required careful planning and high-maintenance implementations. It was also difficult to make the entire process traceable.

Monitoring and debugging

An often underestimated problem in workflow orchestration is monitoring. The ability to analyse running processes and quickly identify errors is crucial for maintenance and optimization. With Durable Functions, you often felt “blind” in this respect. There was a lack of integrated dashboards or tools to gain a transparent insight into the status and processes of the workflows.

The challenges of orchestrating workflows are many and varied, and there is rarely a perfect solution. While Durable Functions addressed many of these problems in theory, in practice questions of transparency, control and monitoring often remained unanswered. Alternative approaches such as choreography patterns offered more insight, but led to increased development & infrastructure effort. The new Azure Durable Task Scheduler promises to eliminate many of these weaknesses - a real game changer for long-running workflows.

Azure Durable Task Schedulers

With the introduction of the Azure Durable Task Scheduler, Microsoft has taken a major step to fundamentally improve the way you work with Azure Durable Functions and complex workflows. This new, fully Azure-managed backend provides developers with a robust platform to orchestrate long-running processes without having to deal with the previous limitations.

The Azure Durable Task Scheduler is specifically designed to solve the challenges of state management, error handling and scaling for Durable Functions.

With the Durable Task Scheduler, error handling is significantly simplified. The system can automatically reset processes to the last saved state so that workflows can continue to run seamlessly. This is particularly valuable for long-running processes where consistency and reliability are important. The robust recovery mechanisms reduce the effort that previously had to go into implementing custom solutions.

By moving the storage and process logic to a specially developed backend, workflows benefit from significant performance improvements. The Task Scheduler automatically scales to cope with high loads while ensuring consistently high availability. Developers can rely on their processes remaining stable and performant regardless of the system load.

One of the biggest new features of the Durable Task Scheduler is the Task Hub Dashboard, an integrated monitoring tool that revolutionizes workflow monitoring and analysis. This dashboard offers developers the opportunity to

Gain live insights into running workflows, including all intermediate steps and statuses.
Quickly identify errors and take targeted measures to rectify them.
Analyze process metrics to identify bottlenecks or inefficient steps.

Where previously manual workarounds and external tools were often necessary, the dashboard provides a central point of contact for debugging and monitoring - directly integrated and easy to use.

The Azure Durable Task Scheduler brings many improvements that are directly tailored to the needs of developers. It combines the advantages of a managed backend with a modern monitoring solution and a scalable architecture. For anyone who has struggled with the limitations of Durable Functions or had to develop their own solutions such as event-based choreographies, the Durable Task Scheduler offers real added value.

Task Hub Dashboard

With the Task Hub Dashboard, Microsoft has introduced a long-awaited functionality that finally gives developers the transparency they need about their workflows. While Durable Functions have always been powerful, debugging, monitoring and tracking processes has always been a challenge. The Task Hub Dashboard solves this problem with an intuitive user interface that provides insight into all running, completed or faulty workflows.

The dashboard serves as a central point of contact for everything to do with managing and analyzing Durable Functions. It provides developers with comprehensive information about:

The current status of all workflows, including running, completed and failed instances.
Detailed logs and events documenting every step of the process.
Lead times, bottlenecks and other important metrics for optimizing workflows.

The dashboard makes work much easier, especially when troubleshooting. Instead of having to fight your way through confusing logs or external tools, it provides all relevant information at a glance.

The timeline view of the Task Hub Dashboard is a real highlight and sets new standards in the traceability of workflows. It displays the entire process history of an individual workflow instance as a timeline. This visualization offers several advantages:

Chronological overview: Every step, every event and every action is displayed in the order in which they were actually executed. This makes it easy for developers to follow the course of the process.
Duration analysis: In addition to the sequence, the timeline also shows the duration of each step, which helps to identify bottlenecks or inefficient parts of the workflow.
Troubleshooting made easy: Erroneous steps are highlighted directly so that developers can quickly identify where and why something went wrong.

Another function of the Task Hub Dashboard is the sequence diagram overview. While the timeline offers a chronological perspective, the sequence diagram visualizes the logical sequence of interactions within the workflow. This view is similar to classic UML sequence diagrams and offers numerous advantages:

Transparency over interactions: Developers can see how the different parts of the workflow - including external services or sub-processes - interact with each other.
Visualization of dependencies: Complex relationships between different process steps are clearly displayed, which helps with planning and optimization.
Structure-level debugging: If a step fails, the diagram shows not only the error, but also the affected downstream steps that depend on it.

When developing the dashboard, Microsoft took care to create a user-friendly interface that remains clear even for complex workflows.

Conclusion

With the Azure Durable Task Scheduler and the associated Task Hub Dashboard, Microsoft has delivered a crucial update for working with Durable Functions. These innovations directly address the weaknesses that have often led developers to avoid Durable Functions in the past or to resort to complicated workarounds.

With these innovations, Azure Durable Functions is taking a big leap forward. The Durable Task Scheduler is an indispensable tool, especially for projects with complex, long-running processes or high transparency and scalability requirements.

Would you like to try out the new features straight away? You can apply for early access here: https://aka.ms/dts-ignite-signup

Resources

Automated deployment slots in Azure with GitHub Actions: Testing pull requests in live environments

Florian Lenz — Fri, 27 Sep 2024 23:22:53 +0000

Continuous Integration and Continuous Deployment (CI/CD) are already standard in many companies. However, development teams are constantly looking for ways to work more efficiently and ensure that code is tested in a real-world environment before it goes live. The ability to test pull requests (PRs) directly in a ‘live’-like environment can significantly improve code quality and detect bugs early.

Azure Deployment Slots offer an elegant solution to this by creating isolated test environments. In combination with GitHub Actions, you can automatically deploy and test PRs in these slots before they are merged into the ‘main’ branch. In this article, I'll show you how to set up PR-specific deployment slots and use GitHub Actions for this automation.

What are Azure Deployment Slots?

Azure App Service Deployment Slots are separate deployment environments within an App Service instance. They allow you to host multiple versions of your application simultaneously. Main advantages:

Zero-downtime deployments: New versions can be deployed and tested in one slot before going live
Easy rollback: In the event of problems, you can simply switch back to the previous slot.
Isolated environments: Each slot has its own configurations and connection strings.

GitHub Actions and Pull Requests

GitHub Actions is a tool for automating software workflows directly in your GitHub repository. It allows you to create CI/CD pipelines that can react to various events such as pushes, pull requests or time-based triggers. In combination with Azure, you can automate your entire development and deployment process

The idea: Branch-specific deployment slots

Imagine that every pull request automatically creates its own deployment slot. This enables:

Live-like testing: Test changes in an environment that is close to production.
Early detection of errors: Testing in the deployment slot allows problems to be detected before they reach the main branch.
Automation: Slots are automatically created and removed through integration with GitHub Actions.

Step-by-step guide

1. Set up workflow for pull requests

To automatically create and manage deployment slots for each pull request, we'll set up a new GitHub Actions workflow that responds to pull request events.

Folder structure: Create a .github/workflows folder in the root directory of your repository if it doesn't already exist.
Create workflow file: Create a new file called pull_request_deployment.yml in this folder.
Configure workflow: Use the following YAML code that extends your existing pipeline to manage deployment slots for PRs.

name: PR Deployment CI/CD

on:
  pull_request:
    types: [opened, synchronize, reopened, closed]

jobs:
  build:
    if: github.event.action != 'closed'
    runs-on: windows-latest

    steps:
      - uses: actions/checkout@v4

      - name: Set up .NET Core
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.x'

      - name: Build with dotnet
        run: dotnet build src/WebApplication/WebApplication.csproj --configuration Release

      - name: dotnet publish
        run: dotnet publish src/WebApplication/WebApplication.csproj -c Release -o ./deploy

      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v4
        with:
          name: .net-app
          path: ./deploy

  deploy:
    if: github.event.action != 'closed'
    runs-on: windows-latest
    needs: build
    environment:
      name: 'PR-slot-deployment'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
    permissions:
      id-token: write # This is required for requesting the JWT

    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v4
        with:
          name: .net-app

      - name: Login to Azure
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          client-secret: ${{ secrets.AZURE_CLIENT_SECRET }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: Create Deployment Slot
        run: |
          $SLOT_NAME="pr-${{ github.event.number }}"
          az webapp deployment slot create --name prdeploymentwebapp --resource-group prdeployment --slot $SLOT_NAME

      - name: Deploy to Azure Web App
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v3
        with:
          app-name: 'prdeploymentwebapp'
          slot-name: 'pr-${{ github.event.number }}'
          package: .

  cleanup:
    if: github.event.action == 'closed'
    runs-on: windows-latest
    environment:
      name: 'PR-slot-deployment'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
    permissions:
      id-token: write # This is required for requesting the JWT

    steps:
      - name: Login to Azure
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          client-secret: ${{ secrets.AZURE_CLIENT_SECRET }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: Delete Deployment Slot
        run: |
          $SLOT_NAME="pr-${{ github.event.number }}"
          az webapp deployment slot delete --name prdeploymentwebapp --resource-group prdeployment --slot $SLOT_NAME

Explanation:

Trigger: The workflow is triggered by pull request events such as opened, synchronise, reopened and closed.
Build Job: Builds and publishes the application, uploads the artefact for the deploy job.
Deploy Job: Creates a deployment slot with the name pr-(PR number), deploys the application to this slot and provides the URL of the live environment.
Cleanup Job: Is only triggered when the pull request is closed (merged or rejected). Deletes the corresponding deployment slot.

2. Create pull request

The pipeline will start automatically as soon as the pull request has been created.

3. perform tests in the ‘live’ environment

After the application has been deployed to the deployment slot, you can perform both manual and automated tests in this environment. The URL of the slot is usually:https://prdeploymentwebapp-pr-12.azurewebsites.net

Manual tests:
Open the above URL in your browser and perform the necessary tests.

4. Clean up the deployment slots

After closing a pull request, the slot is automatically removed. This ensures that no legacy data remains available for an unnecessarily long time.

Best practices and pitfalls

Number of deployment slots

Cost control: Each slot consumes resources. Limit the number of concurrent slots, especially in large projects with many parallel pull requests.
Clean up: Make sure that temporary slots are deleted after use to avoid unnecessary resources.

Dealing with many pull requests

Limits in Azure: Azure has limits on the number of slots per App Service Plan (up to 20 slots by default). Plan accordingly to avoid bottlenecks.
Scaling: Resources could become scarce if the PR volume is high. Consider scaling the App Service Plan or optimising automated slot deletions.

Workflow optimisation

Parallel jobs: Use the parallelism of GitHub Actions to speed up workflows.
Fast deployments: Minimise the number of steps and optimise build processes to reduce deployment times.
Automated testing: automated deployment of the application also allows E2E testing to be performed using Cypress, for example.

Rollback strategies

Automatic rollback: implement mechanisms to automatically roll back to the previous slot in the event of failed deployments.
Monitoring and alerts: monitor deployments and set up alerts to respond quickly to issues.

Conclusion

With these customisations to your GitHub Actions Pipeline, you can effectively use Azure Deployment Slots to test pull requests in isolated, live-like environments. This increases the quality of your code and significantly reduces the risk of errors in the production environment.

Summary of customisations:

PR-specific slots: Each pull request gets its own deployment slot, which is automatically removed once the PR is complete.
Automated slot management: creation and deletion of slots automated by GitHub Actions.

These measures help to streamline the deployment process, increase efficiency and improve the reliability of your applications.‍

Resources:

arc42 for your software architecture: The best choice for sustainable documentation

Florian Lenz — Sun, 18 Aug 2024 14:34:55 +0000

It is a huge challenge for teams in today's software development to design complex systems efficiently and to document their architectures clearly and sustainably. Well-structured and comprehensible documentation is often underestimated. This can lead to communication problems, maintenance issues or unexpected costs later on. This is where arc42 comes into play. This proven template for architecture documentation offers a systematic and practice-oriented solution for mastering these challenges and ensuring the long-term success of your software projects.

What is arc42?

arc42 is a comprehensive and field-tested template that has been specially developed for the documentation of software architectures. It offers a structured and modular approach to documenting all relevant aspects of a software architecture efficiently and comprehensibly. The template is flexibly customizable and suitable for projects of any size and complexity.

arc42 was developed by experienced software architects and has been used successfully in numerous projects worldwide. It covers all important areas, from basic decisions to system contexts and detailed architecture views. Thanks to its clear structure, arc42 enables transparent communication between all parties involved and ensures that the architecture remains maintainable and expandable in the long term.

With arc42, you can ensure that your software architecture is not only based on solid foundations, but is also documented in such a way that it remains understandable and accessible to all stakeholders - a decisive advantage in a constantly evolving technology world.

The individual areas of arc42 documentation

arc42 divides the documentation of a software architecture into several clearly defined areas. Each of these areas has a specific purpose and helps to document the architecture comprehensively and comprehensibly. In the following, we will look at the most important areas and explain why they are essential.

1. Introduction and objectives
Purpose: This section describes the motivation and overarching objectives of the system. It explains why the system is being developed in the first place and the key requirements it must fulfill.
Importance: A clear definition of the objectives is crucial to ensure that all stakeholders understand the direction of the project and that the architecture is aligned with it.

2. Constraints
Purpose: Constraints are the specifications and framework conditions that restrict or influence the architecture. These can be of a technical, organizational or legal nature. Examples include certain technologies that must be used, standards that must be adhered to or legal regulations that the system must fulfill.
Importance: Understanding and documenting constraints is crucial, as they can limit the freedom of architectural decisions and anticipate certain design decisions. They help to define the scope of the architecture and ensure that all requirements and regulations are met.

3. Contexts & Scope
Purpose: This section describes the various contexts of the system, how it interacts with external systems and which external interfaces exist.
Importance: Understanding the system contexts is important in order to recognize dependencies on other systems and their effects on your own architecture.

4. Solution strategy
Purpose: The solution strategy provides an overview of the basic technical and architectural approaches chosen to meet the requirements. It describes how the architecture will achieve the objectives and how the key challenges will be addressed.
Importance: A clearly formulated solution strategy is essential to ensure that all stakeholders understand and support the key architectural decisions. It serves as a guide for the more detailed elaboration of the architecture.

5. Building block view
Purpose: The building block view describes the internal structure of the system by showing the most important building blocks (modules, components) and their relationships to each other.
Importance: This view makes it possible to clearly understand the internal structures of the system and to ensure that the architecture remains scalable and maintainable.

6. Runtime view
Purpose: The runtime view shows how the system components interact at runtime and which communication flows exist between the components.
Importance: An understanding of the runtime view is essential for analyzing and optimizing system performance and identifying potential bottlenecks.

7. Deployment view
Purpose: This section describes how the various components of the system are physically distributed, for example on servers, cloud instances or devices.
Importance: The distribution view helps to understand the infrastructure requirements and ensure that the system runs efficiently and reliably in different environments.

8. Cross cutting concepts
Purpose: Cross cutting concepts include overarching concepts that run through different parts of the system and are not limited to a single component. This includes aspects such as security, error handling, logging, persistence, authentication and authorization, or even performance optimizations.
Importance: The documentation of these overarching concepts is important as it ensures that these central aspects of the system are implemented consistently and uniformly. A well thought-out cross-cutting concept can significantly improve the maintainability and expandability of the system and ensure that important requirements are taken into account system-wide.

9. Architecture decisions
Purpose: This section documents the important architectural decisions that were made and the reasons that led to these decisions.
Importance: The documentation of architectural decisions is crucial for traceability and makes it easier to make well-founded adjustments or extensions in the future.

10. Quality requirements
Purpose: The quality requirements for the system are described here, e.g. performance, security, reliability and maintainability.
Importance: Understanding the quality requirements is crucial to ensure that the architecture meets these requirements and that the system can be operated successfully in the long term.

11. Risk assessment and technical debt
Purpose: This section documents the potential risks and technical debt of the system, as well as strategies to mitigate them.
Importance: A conscious examination of risks and technical debt enables proactive measures to be taken to minimize negative effects on the project.

12. Glossary
Purpose: The glossary contains definitions and explanations of important terms used in the project.
Importance: A common understanding of terms and concepts is essential to avoid misunderstandings and ensure effective communication within the team.

The advantages of arc42: argumentation for its use

The use of arc42 offers numerous advantages that can significantly improve software projects. The most important reasons why arc42 should be used in every development project are listed below:

Traceability and comprehensibility: arc42 ensures that all architectural decisions are clearly documented and comprehensible. This enables every team member to quickly familiarize themselves with the architecture, regardless of whether they were involved from the beginning or joined later. The uniform structure of arc42 promotes a common language within the team, which makes collaboration and understanding much easier.
Maintainability and flexibility: Software projects are constantly evolving and the architecture needs to be adapted to new requirements. A well-documented architecture ensures that these changes can be implemented efficiently and without risk. arc42 offers a flexible documentation structure that makes it possible to plan and implement architectural changes without jeopardizing existing functionality.
Efficient communication with stakeholders: The architecture of a software project is not only relevant for the development team, but also for customers, managers and other stakeholders. arc42 makes it possible to document the architecture in a way that is understandable for non-technical stakeholders. This promotes transparency and trust in the project and facilitates the communication of decisions and progress.
Saving time and increasing efficiency: Using arc42 saves a lot of time, as the template provides a proven structure and methodology for documentation. There is no need to reinvent the wheel, allowing the focus to be placed on developing and improving the software. arc42 provides the tools to make documentation efficient while ensuring high quality.

Why arc42 is the best choice

arc42 is not the only tool for architecture documentation, but it is the best choice for several reasons:

Proven framework: arc42 was developed by renowned software architects who have brought extensive practical experience to this template. It is based on best practices and has proven itself in a wide range of projects and industries.
Flexibility and adaptability: Regardless of whether you are working on a small start-up project or a large corporate project, arc42 is flexible enough to adapt to specific requirements. The individual modules of the template can be used or adapted as required, making it suitable for a wide variety of projects and teams.
Standardization and consistency: arc42 creates a standardized documentation structure that is consistent for everyone involved. This not only facilitates the maintenance and further development of the project, but also the induction of new team members. Standardized documentation leads to fewer misunderstandings and promotes efficient collaboration.
Expandability and future-proofing: arc42 is designed to grow with the project. It enables step-by-step expansion and adaptation of the documentation, which is particularly invaluable for long-term projects. This means that the architecture remains well documented and easy to maintain in the future.

Call to action: Investment in the architecture

The decision to use arc42 in projects represents an investment in the future of software architecture. A well-documented architecture is the key to success - it not only makes the project more transparent and maintainable, but also ensures that it remains sustainable in the long term. arc42 should be used to take documentation to the next level and ensure that the project is still successful and scalable years from now.

Arc42 in action

DokChess is a sample project that demonstrates the use of the arc42 template to document a software architecture. It is a chess application whose architecture was structured and documented with the help of arc42. The project shows how the different areas of arc42 - from building blocks to runtime views to quality requirements - can be used in a real software project to create a clear, understandable and maintainable architecture.

For more information, you can view the project here: https://www.dokchess.de/

Conclusion

arc42 offers a structured, tried-and-tested and flexible method for documenting software architectures. The advantages are clear: traceability, maintainability, efficient communication and consistent, standardized documentation. The use of arc42 ensures that the architecture is not only optimally equipped for the current project, but also for future developments. An investment in arc42 is an investment in the sustainability and long-term success of software projects.

Resources & Sources

https://www.florian-lenz.io/blog/arc42-fur-ihre-softwarearchitektur-die-beste-wahl-fur-nachhaltige-dokumentation
https://dev.to/arc42/brief-introduction-to-arc42-1c0l
https://www.arc42.de/
https://entwickler.de/software-architektur/architekturdokumention-arc42-template
https://github.com/BrutalHack/Arc42AzureDevOpsWiki

Standardized Error Messages in .NET REST APIs - Implementing RFC 7807 Problem Details

Florian Lenz — Wed, 17 Jul 2024 10:49:45 +0000

The Silent Killer: Unhandled Exceptions

Imagine an application fetching user data from an external API. If the API is unavailable and exceptions aren't handled, the application can crash, leading to poor user experience and frustration for developers and users alike.

The Importance of Good Error Messages

Good error messages are crucial for efficient troubleshooting and for helping clients understand what went wrong. Without clear error messages, issues such as confusion, extended development cycles, poor user experience, increased support requests, and loss of trust can arise.

HTTP Status Codes and Error Handling

Understanding and correctly using HTTP status codes is key to effective API error handling. They help communicate the status and nature of the error to the client, enabling targeted troubleshooting.

2xx Success

200 OK: Request was successful.
204 No Content: Request was successful, but no content to return.
202 Accepted: Request accepted, processing not completed.

4xx Client Errors

400 Bad Request: The request was invalid or cannot be processed.
401 Unauthorized: Authentication is required and has failed or not been provided.
403 Forbidden: The server understands the request but refuses to authorize it.
404 Not Found: The requested resource could not be found.

5xx Server Errors

500 Internal Server Error: A generic error for unexpected server issues.
502 Bad Gateway: Invalid response from an upstream server.
503 Service Unavailable: The server is currently unavailable.
504 Gateway Timeout: The server didn't receive a timely response from an upstream server.

Domain-Driven Design (DDD) and Error Handling

It's important to distinguish between domain errors (business logic) and application errors (technical problems). This distinction helps in choosing the correct status codes and clearly communicating where the problem lies.

Domain Exceptions
Domain exceptions occur when business rules are violated and should typically return 4xx status codes. Examples include:

ValidationException: Invalid data sent by the client.

{
  "type": "https://example.com/probs/validation",
  "title": "Invalid request parameters",
  "status": 400,
  "detail": "The provided data is invalid. Please check the following fields.",
  "instance": "/api/bookings",
  "errors": {
    "startDate": "The start date must be in the future.",
    "endDate": "The end date must be after the start date.",
    "roomNumber": "The specified room number does not exist."
  }
}

EntityNotFoundException: The requested entity does not exist.

{
  "type": "https://example.com/probs/entity-not-found",
  "title": "Entity not found",
  "status": 404,
  "detail": "The booking ID '98765' was not found.",
  "instance": "/api/bookings/98765"
}

BusinessRuleViolationException: A business rule was violated.

{
  "type": "https://example.com/probs/business-rule-violation",
  "title": "Business rule violation",
  "status": 409,
  "detail": "The booking cannot be created as the room is already occupied for the specified period.",
  "instance": "/api/bookings"
}

Application Exceptions

Application exceptions relate to technical problems or unexpected errors in the application code and should return 5xx status codes. Examples include:

TimeoutException: A timeout occurred, e.g., in a database query.

{
  "type": "https://example.com/probs/timeout",
  "title": "Request timeout",
  "status": 504,
  "detail": "The request timed out. Please try again later.",
  "instance": "/api/bookings",
  "timestamp": "2024-06-30T12:34:56Z"
}

IOException: An I/O error, e.g., accessing the file system.

{
  "type": "https://example.com/probs/io-error",
  "title": "I/O error",
  "status": 500,
  "detail": "An error occurred while accessing the file system. Please try again later.",
  "instance": "/api/files/upload",
  "timestamp": "2024-06-30T12:34:56Z"
}

DatabaseException: A database connection or query error.

{
  "type": "https://example.com/probs/database-error",
  "title": "Database error",
  "status": 500,
  "detail": "An error occurred while connecting to the database. Please try again later.",
  "instance": "/api/bookings",
  "timestamp": "2024-06-30T12:34:56Z"
}

Why This Distinction Matters

Distinguishing between domain and application exceptions is crucial for clear communication and efficient error handling:

Accurate Error Diagnosis: Specific status codes and error types help clients understand whether the problem is on their side (4xx) or the server side (5xx).
Targeted Error Resolution: Domain exceptions provide clear guidance on what inputs or business rules need adjustment. Application exceptions indicate technical issues requiring server-side fixes.
Improved User Experience: Clear and precise error messages enable users and developers to react and resolve issues more quickly.
Efficiency and Stability: Accurate error handling improves the efficiency of development and support teams and enhances overall application stability.

Implementing ProblemDetails for Error Handling in .NET Core
After understanding the importance of HTTP status codes and the distinction between domain and application exceptions, let's see how to implement these principles in a .NET Core application.

Define Domain Exceptions

In a Domain-Driven Design (DDD) architecture, it's useful to define specific domain exceptions that inherit from a generic DomainException. These exceptions can then be processed correctly in middleware and transformed into standardized HTTP responses using the ProblemDetails class.

Step 1: Define Domain Exceptions
Create a base class DomainException and specific domain exceptions that inherit from it:

public abstract class DomainException : Exception
{
    protected DomainException(string message) : base(message) { }
}

public class ValidationException : DomainException
{
    public IDictionary<string, string[]> Errors { get; }

    public ValidationException(string message, IDictionary<string, string[]> errors) : base(message)
    {
        Errors = errors;
    }
}

public class EntityNotFoundException : DomainException
{
    public EntityNotFoundException(string message) : base(message) { }
}

public class BusinessRuleViolationException : DomainException
{
    public BusinessRuleViolationException(string message) : base(message) { }
}

Step 2: Create Middleware for Error Processing
Create a middleware class that catches these domain exceptions and transforms them into ProblemDetails responses:

public class ExceptionMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<ExceptionMiddleware> _logger;

    public ExceptionMiddleware(RequestDelegate next, ILogger<ExceptionMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext httpContext)
    {
        try
        {
            await _next(httpContext);
        }
        catch (DomainException ex)
        {
            _logger.LogError($"A domain exception occurred: {ex.Message}");
            await HandleDomainExceptionAsync(httpContext, ex);
        }
        catch (Exception ex)
        {
            _logger.LogError($"An unexpected error occurred: {ex.Message}");
            await HandleExceptionAsync(httpContext, ex);
        }
    }

    private static Task HandleDomainExceptionAsync(HttpContext context, DomainException exception)
    {
        ProblemDetails problemDetails = exception switch
        {
            ValidationException validationEx => new ValidationProblemDetails(validationEx.Errors)
            {
                Title = "Invalid request parameters",
                Status = StatusCodes.Status400BadRequest,
                Detail = exception.Message,
                Instance = context.Request.Path
            },
            EntityNotFoundException => new ProblemDetails
            {
                Title = "Entity not found",
                Status = StatusCodes.Status404NotFound,
                Detail = exception.Message,
                Instance = context.Request.Path
            },
            BusinessRuleViolationException => new ProblemDetails
            {
                Title = "Business rule violation",
                Status = StatusCodes.Status409Conflict,
                Detail = exception.Message,
                Instance = context.Request.Path
            },
            _ => new ProblemDetails
            {
                Title = "Domain error",
                Status = StatusCodes.Status400BadRequest,
                Detail = exception.Message,
                Instance = context.Request.Path
            }
        };

        context.Response.ContentType = "application/problem+json";
        context.Response.StatusCode = problemDetails.Status ?? StatusCodes.Status400BadRequest;
        return context.Response.WriteAsJsonAsync(problemDetails);
    }

    private static Task HandleExceptionAsync(HttpContext context, Exception exception)
    {
        var problemDetails = new ProblemDetails
        {
            Title = "An unexpected error occurred",
            Status = StatusCodes.Status500InternalServerError,
            Detail = exception.Message,
            Instance = context.Request.Path
        };

        context.Response.ContentType = "application/problem+json";
        context.Response.StatusCode = StatusCodes.Status500InternalServerError;
        return context.Response.WriteAsJsonAsync(problemDetails);
    }
}

Step 3: Register Middleware
Register the middleware in your Startup or Program file:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseMiddleware<ExceptionMiddleware>();

    app.UseRouting();
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });
}

By following these steps, you can implement standardized error messages in your .NET Core application, improving both developer and user experience by providing clear and actionable error information. This approach not only enhances communication but also aligns with the principles of Domain-Driven Design (DDD) and ensures your application adheres to the RFC 7807 Problem Details specification.

Resources

Blog

Why serverless? Advantages and disadvantages of serverless computing explained

Florian Lenz — Wed, 03 Jul 2024 16:02:40 +0000

Nowadays, companies want to improve their IT infrastructure. One option is serverless. This allows developers to create and operate applications without having to worry about the server infrastructure.

Well-known services such as Azure Functions from Microsoft Azure and AWS Lambda from Amazon Web Services (AWS) are examples of how developers can run their application code serverless. However, these services are only part of what serverless offers. In addition to the ability to run code, databases, message brokers and API gateways can also be run serverless.

Serverless is an umbrella term for services that do not require their own server administration, scale automatically and are billed on a usage basis. These features make serverless an attractive option for companies that want to optimize costs, increase scalability and shorten time-to-market.

What is serverless?

Serverless is a term that can be misunderstood. Serverless does not mean that there are no more servers. There are still servers on which your applications run. The difference is that you no longer have to take care of the servers. As a developer, you don't have to buy, deploy or maintain a physical server. You write your code, deploy it and the cloud provider takes care of the rest.

And that rest can be a lot. If you currently run your applications on-premise, you may be familiar with the following situations:

You need new hardware and have to order it.
The hardware needs to be installed.
You have to make updates and keep the servers secure.
If a server goes down, you need to know what to do. This list can go on and on. With serverless, you don't have to worry about anything.

Serverless means:

No server management: you no longer have to worry about the servers.
The resources are automatically adjusted so that there is always enough capacity available.
You only pay for the resources you use.

These features have advantages and disadvantages. Let's assume an HTTP endpoint is only called ten times a month. In this case, it is better to run serverless. You only pay for the ten calls. This is cheaper than running a server all year round.

The pay-as-you-go cost model is not always the best solution. If your requests are constant and highly predictable, it may be cheaper to run a fixed number of servers.

Whether serverless makes sense for your application depends on your specific needs and usage patterns. In later sections, I will explain how to do the evaluation.

Comparison of on-premise vs. IaaS vs. CaaS vs. PaaS vs. FaaS

Switching from traditional on-premise models to modern cloud solutions can be a big improvement for many companies. To better understand the different models, here is a comparison:

On-Premise

With this model, the server is located in the company's own data center. All tasks, from hardware procurement, installation and maintenance to scaling and security updates, are the responsibility of the company. This costs a lot of money and requires many employees.

Infrastructure as a Service (IaaS)

The first step into the cloud. Here, the cloud provider takes care of the hardware and virtualization. You no longer have to order or install physical hardware. Instead, you can set up virtual machines with just a few clicks. However, you still have to manage the operating system, scaling and application.

Container as a Service (CaaS)

Container as a Service is a further development of IaaS. The cloud provider takes over the management of the container orchestration system, such as Docker or Kubernetes. This makes it easier to manage and scale containerized applications, but the company still has to maintain the container infrastructure and applications.

Platform as a Service (PaaS)

The cloud provider also takes care of the operating system and the runtime environment. Developers only have to take care of the application, its scaling and configuration. PaaS does a lot automatically and relieves the IT department. Nevertheless, you can still do a lot yourself.

Functions as a Service (FaaS)

FaaS stands for "Functions as a Service". The cloud provider takes over the management of the entire infrastructure. You only take care of the application code and functions. Scaling takes place automatically and is scaled up or down as required. Billing is based on actual usage (pay as you go). This is particularly good for applications with irregular or unpredictable loads.

Each model has its advantages and is suitable for different requirements and usage patterns. Serverless or FaaS is good if you are looking for a flexible, affordable and fast solution. Then you can focus on development and business value instead of worrying about infrastructure.

Load distribution: a decisive factor for the choice of serverless

Serverless is a sensible architecture if the load distribution is right.

Let's imagine an application that has an even load from 7 am to 7 pm. In this case, serverless does not make sense. The load is even and predictable. It is not necessary to adjust the performance automatically. If each execution is billed individually, it does not make sense in terms of costs.

The situation is different for applications with unpredictable loads. Let's take an application that receives many requests at different times. Sometimes there are few requests, sometimes many. This pattern shows that serverless could be a good solution. Serverless automatically adapts to the current demand. You only pay for the resources you use.

You need to know what your application needs and how it is used. A precise analysis shows whether serverless is the right choice. Serverless is good for applications with fluctuating loads. It scales automatically and is billed according to consumption.

If your application has a stable and predictable load, a traditional cloud solution might be better. For irregular and unpredictable loads, serverless is better because it adjusts automatically and is cheaper.

Conclusion: Serverless - an innovative solution with clear advantages and some challenges

Serverless is a technology that makes the management of servers superfluous. It ensures that applications can be developed and provided faster and more cost-effectively.

Serverless has the following advantages:

No server management: developers can concentrate on the code without having to worry about the infrastructure.
Serverless applications scale automatically as more or fewer users access them. This is particularly practical when user numbers fluctuate greatly.
Cost optimization: You only pay for the resources you use. This is particularly cost-efficient when the number of users is low.
The time-to-market is shorter because developers can concentrate on developing new functions.

Serverless also has disadvantages:

You are dependent on one provider. If you want to switch, it can be difficult.
Companies have less control over the hardware and operating system.
If there is little use, it takes longer for functions to start. The instances are then scaled down to zero. However, some providers have already developed solutions for this.

Serverless is particularly suitable for applications that are used a lot or a little. The automatic scaling and usage-based billing are very advantageous in such scenarios. For applications with a stable and predictable load, traditional cloud models such as IaaS or PaaS are often more favorable.

Get the Serverless Cheatsheet now!

Are you ready to utilize the full potential of your software? Our cheatsheet gives you an overview of the differences between IaaS, PaaS and FaaS and helps you find the best solution for your next application. Don't miss out on this valuable resource to help you make informed decisions and optimize your IT infrastructure.

References

Future-proof software development with the Azure Serverless Modulith

Florian Lenz — Mon, 10 Jun 2024 20:39:36 +0000

When developing modern software solutions, architects and developers are faced with the challenge of designing systems that are scalable, maintainable and cost-effective. Traditionally, monolithic architectures offer the advantage of simplicity in development and deployment, but often reach their limits in terms of scalability and maintainability. Microservices solve many of these problems, but bring their own challenges such as increased complexity and difficult coordination.

What is a monolith?

Monolithic architectures are characterized by the fact that all components of an application are closely linked and provided as a single unit. This can simplify development and deployment, but leads to difficulties in scalability and maintainability as the application grows.

Modularity in the monolith

Modularity allows a monolith to be divided into clearly delineated modules. These modules can be developed and maintained independently of each other, which improves maintainability and enables more targeted scaling of individual modules.

The Serverless Modulith: an innovative solution

The Serverless Modulith combines the advantages of modularity with the strengths of serverless computing. Each module is provided as an independent serverless function, which offers several advantages:

Scalability: each module can be scaled independently, based on specific requirements and load.
Cost efficiency: Thanks to usage-based billing, companies only pay for the computing time they actually use.
Reduced complexity: Developers can focus on the business logic as the cloud provider manages the infrastructure.
Faster time-to-market: Individual modules can be developed and deployed independently, which speeds up the introduction of new functions.

Architecture overview

A serverless modulith with Azure Functions consists of a structured and modularized application. Each functional unit is provided as an independent serverless function. Here is an example of such a structure:

API Gateway: An Azure API Management Gateway serves as a central point for all incoming requests and forwards them to the corresponding Azure Functions. It handles authentication, authorization and rate limiting.
Logic: Each module of the application is implemented as a separate Azure Function. These modules can perform tasks such as data processing, API endpoints, background tasks or event-driven processes.
Communication: The modules communicate with each other via Azure Service Bus or Azure Event Grid to enable loose coupling and asynchronous processing.
Database: Azure Cosmos DB, Azure SQL Database or Azure Table Storage can be used as central databases that the individual modules access.

Challenges when using serverless moduliths

Although the serverless modulith offers many advantages, there are also challenges that need to be considered:

Vendor lock-in

When using cloud-based serverless services such as Azure Functions, AWS Lambda or Google Cloud Functions, a certain degree of vendor lock-in is unavoidable. Architecture and implementation depend heavily on the specific services and APIs of the chosen cloud provider. However, it is important to emphasize that vendor lock-in is not inherently bad. The use of standard software solutions such as Office 365 or Teams also leads to vendor lock-in. It is crucial that companies carefully consider whether this dependency could be problematic in the future.

One approach to minimizing risk is to use hybrid solutions such as Docker containers in a serverless environment on Azure. These containers can be operated in different cloud environments or even on-premises, which increases flexibility and reduces the risk of lock-in.

Cold starts

Cold starts are another common problem with serverless architectures. These occur when functions are reactivated after a period of inactivity and cause additional latency. Modern hosting plans such as the Azure Functions Premium Plan or AWS Lambda Provisioned Concurrency offer solutions that significantly reduce this problem. These plans make it possible to keep a certain number of instances warm, which minimizes request latency and improves response times.

Conclusion

The Serverless Modulith is an innovative solution for modern software development requirements. It combines the advantages of modularity and serverless computing and enables companies to work more flexibly, cost-effectively and scalably. At the same time, the complexity of infrastructure management is reduced. Despite the challenges, such as vendor lock-in and cold starts, the advantages outweigh the disadvantages, especially if suitable strategies are implemented to overcome these challenges.

Ressources:

How to create a globally distributed Azure App incredibly easy - high availability and low latency included!

Florian Lenz — Mon, 20 May 2024 11:13:41 +0000

With digitalization and globalization, where users are distributed worldwide, it is essential to develop applications that are both fast and reliable, regardless of where the user is located. A globally distributed Azure app enables exactly that: it ensures that your application is not only available anywhere in the world, but also offers low latency and fast response times. In this article, I show how such an app can be deployed incredibly easily and what benefits this brings.

Why a globally distributed application makes sense

Low latency: If an application is used by users on different continents, the physical distance can lead to high latency, which affects the user experience. Distributing the application across multiple Azure regions ensures that data is processed as close to the user as possible, significantly reducing latency.

High availability: A globally distributed architecture increases the application's reliability. If one region fails or is overloaded, data traffic can be automatically redirected to other regions. This ensures that the application remains available at all times, which is particularly important for business-critical applications.

Low costs: Thanks to Azure Functions and other serverless services, the costs for a globally distributed application can be controlled and optimized. Azure Functions enables automatic scaling of resources based on actual demand, so you only pay for the resources you use. This results in an efficient cost structure that makes it possible to operate a globally distributed application without incurring significantly higher costs compared to an application in a single region. The pay-as-you-go model of Azure Functions ensures that costs remain low, even if the application is distributed globally.

By using Azure services such as Azure Cosmos DB, Azure Functions and Azure Front Door, these benefits can be easily realized and applications can be optimally tailored to the global needs of users.

Basic concepts and tools for a globally distributed Azure app

Before a globally distributed Azure app can be deployed, it is important to understand the basic concepts and tools involved. Here are the essential Azure services used for global distribution and optimization of an application:

Azure Cosmos DB: Azure Cosmos DB is a globally distributed, multimodal database service that can be seamlessly distributed across multiple regions. It offers guaranteed low latency and high availability as well as the ability to automatically replicate data and keep it consistent. This is particularly important for applications that need to access real-time data worldwide.

Azure Functions: Azure Functions is a serverless service that makes it possible to scale applications quickly and efficiently. With Azure Functions, you only pay for the resources you use, which minimizes operating costs. Automatic scaling ensures that the application runs smoothly even with high data traffic.

Azure Front Door: Azure Front Door provides global load balancing and accelerated application delivery by acting as a global HTTP/HTTPS load balancing service. It optimizes traffic, increases resiliency and ensures fast response time regardless of where users are located. Azure Front Door also improves security with built-in DDoS protection mechanisms and Web Application Firewall (WAF) capabilities.

These services work together to ensure that the application is globally available, fast and cost-efficient. The next section describes in detail how these tools can be configured and used in a few steps to deploy a globally distributed Azure app.

Steps to deploy a globally distributed Azure app

The following steps are necessary to deploy a globally distributed Azure app.

Create and configure the Cosmos DB

To lay the foundation for a globally distributed Azure app, setting up and configuring Azure Cosmos DB is a crucial step. Start by logging into the Azure portal and creating a new Azure Cosmos DB instance. Choose the API model that best suits the requirements of your application - be it SQL, MongoDB or Cassandra.

Once the instance has been created, it is important to configure the global replications. You can do this by adding the desired geographical regions in which your data should be replicated. This configuration ensures that your data is available worldwide and stored close to the users, which significantly reduces latency. In addition, the multi-region write function ensures high availability and consistency of the data, as it enables write operations in several regions.

In the Azure Cosmos DB settings, you will find options for managing the consistency levels and configuring the replication strategies. Here you can select the desired level of consistency that best suits the requirements of your application - from strong consistency to eventual consistency.

A major advantage of Azure Cosmos DB is the ability to add additional regions after the initial deployment. The Azure Cosmos DB instance can be opened via the Azure portal and the "Add regions" option can be selected in the "Replication" area. After selecting the desired regions, the process is completed by clicking on "Save". Azure Cosmos DB replicates the data to the new regions automatically and without downtime. This allows the database's reach and availability to be expanded flexibly and seamlessly.

Setup and configuration of Azure Functions

After setting up Azure Cosmos DB, the next step is to configure Azure Functions to use serverless functions that can scale automatically and interact efficiently with globally distributed data.

First, a new Azure Functions app is created in the Azure portal. A serverless plan (Consumption Plan) that supports automatic scaling is selected. A separate Azure Functions app is created for each desired region to ensure that the functions are executed close to the users and therefore offer low latency.

Once the Functions apps have been created in the respective regions, the desired functionality can be implemented. This ensures that the functions interact efficiently with Azure Cosmos DB to perform data operations. The code for the functions can be written directly in the portal or deployed from a local development environment.

Once the functions are implemented, they must be deployed to all Functions apps created in the respective regions. This ensures that the application is available in every region and that the benefits of low latency and high availability can be utilized.

Azure Functions uses automatic scaling to ensure that the application runs smoothly even with high data traffic. The serverless architecture means that you only pay for the resources you actually use, which keeps operating costs low.

Configuration of the Azure Front Door

After setting up Azure Cosmos DB and Azure Functions, the next step is to configure Azure Front Door to ensure global load balancing and optimization of application deployment.

A new Azure Front Door instance is created in the Azure portal. The Azure Functions endpoints created are added as backend pools. In the Azure Front Door settings, load balancing methods can be configured to distribute traffic based on the geographical location of users. This ensures that user requests are routed to the closest or most available data center, minimizing latency and improving the user experience.

Routing rules are set up to define specific requirements and priorities for data traffic. This includes routing requests to specific backend pools based on URL paths or other criteria.

In addition, security features such as the Web Application Firewall (WAF) can be activated to protect the application from threats. Azure Front Door also offers integrated DDoS protection mechanisms that help secure the application from attacks and ensure availability.

After all configurations are completed, Azure Front Door is tested to ensure that traffic is distributed correctly and the application is available in all regions. This configuration allows the global reach and performance of the Azure app to be optimally utilized.

Security configuration for Azure Functions

To ensure that only traffic from Azure Front Door is allowed and thus security mechanisms cannot be bypassed, appropriate settings must be made in Azure Functions. This configuration increases the security of the application by ensuring that all requests are routed through Azure Front Door and checked.

The Azure Functions app is opened in the Azure portal and the "Network" -> "Public network access" area is opened in the settings. Here, the access restriction is configured by adding a rule that only allows the IP range of Azure Front Door. Azure Front Door uses a specific set of IP addresses that are updated regularly. So that not all IP addresses have to be entered, the type "Service Tag" can be selected and then the service tag "AzureFrontDoor.Backend". This now configures that only traffic via Azure Front Door is allowed through to the Azure Function. Additional protection is provided by checking the X-Azure-FDID header. This is set by Azure Front Door and ensures that traffic is only allowed through from your own Azure Front Door.

These measures help to protect the application from direct access by only allowing validated and verified requests. This ensures that security features such as the Web Application Firewall (WAF) and DDoS protection mechanisms configured in Azure Front Door cannot be bypassed and the application remains protected from potential threats.

Price considerations

One of the most attractive features of a globally distributed Azure app is its cost efficiency. With a high number of requests, for example 100 million globally distributed requests per month, the total cost for such an application is only about 353 USD. This estimate includes the use of Azure Cosmos DB, Azure Functions and Azure Front Door.

Azure Functions offers a serverless billing model where you only pay for the resources you actually use. This means that costs are dynamically adjusted to demand, avoiding unnecessary expenditure. Azure Cosmos DB charges for usage based on the operations performed and the amount of storage required, while Azure Front Door takes care of managing global traffic and optimizing application delivery without incurring additional infrastructure costs.

The ability to automatically scale and efficiently utilize resources contributes significantly to cost efficiency. By only paying for actual consumption, companies can achieve high performance and global availability at a fraction of the cost of traditional infrastructure models. This price flexibility and transparency make Azure an excellent choice for deploying globally distributed applications.

Best practices and tips for optimization

In order to exploit the full potential of a globally distributed Azure app, some best practices and tips for optimization and management should be followed:

Select consistency model: Select the most appropriate consistency model for your application in Azure Cosmos DB. Strict consistency ensures data integrity but can increase latency. Eventual consistency offers higher availability and lower latency, but with possible data inconsistency.

Efficient data partitioning: Ensure that your data is partitioned efficiently. Good partitioning in Azure Cosmos DB improves scalability and performance by preventing certain partitions from being overloaded.

Caching strategies: Implement caching strategies to speed up frequent data accesses and reduce the load on the database. Azure Redis Cache can be a useful addition here.

Use serverless architectures: Take advantage of serverless architectures like Azure Functions to scale automatically and save costs. Make sure to design functions so that they are short and precise in order to minimize execution costs.

Optimize load balancing: Configure Azure Front Door to optimally distribute traffic. Use geo-routing and other load balancing algorithms to achieve the best performance.

Security measures: Ensure that your application is protected by appropriate security measures. Enable the Web Application Firewall (WAF) in Azure Front Door and use Azure Security Center to detect and remediate potential threats.

Automated scaling: Use the automatic scaling of Azure Functions and Azure Cosmos DB to dynamically adapt resources to current demand. This helps to optimize costs while ensuring high availability.

Regular review and adjustment: Carry out regular performance reviews and adjust configurations if necessary. Regularly review metrics and reports from Azure Monitor and Application Insights to identify bottlenecks and optimization opportunities.

By implementing these best practices and tips, the performance and efficiency of the globally distributed Azure App can be significantly improved. Continuous optimization and management ensures that the application meets changing requirements and functions optimally.

Summary

Deploying a globally distributed Azure app offers significant benefits in terms of performance, availability and cost efficiency. By using Azure Cosmos DB, Azure Functions and Azure Front Door, an application can be deployed quickly and securely worldwide. With just a few configurations, new regions can be added and security mechanisms implemented to ensure the protection of the application. In addition, the application remains cost-efficient, even with high data traffic. The combination of these powerful Azure services makes it possible to meet the demands of a globalized and digitized world while providing an optimal user experience.