The Deployment Bottleneck No One Talks About
The real bottleneck might not be in your pipeline but rather in the way your application interacts with cloud services.
Mar 3rd, 2025 1:06pm by
Image from treety on Shutterstock.
Nitric sponsored this post.
- Infrastructure management – Developers must provision services separately, often leading to misalignment between application code and infrastructure.
- Cloud-specific dependencies – SDKs tightly couple code to a single provider, complicating many tasks, like migrations, local development, testing and multicloud strategies.
- Long debugging and recovery times – Infrastructure mismatches result in failed deployments that are difficult to troubleshoot and roll back.
Dapr: A Sidecar That Standardizes Cloud APIs
Dapr (Distributed Application Runtime) is a runtime abstraction framework that provides a consistent API for cloud native applications to interact with services like message queues, storage and pub/sub. By acting as a sidecar process, Dapr enables applications to remain cloud-agnostic while simplifying distributed system development.Example: Sending messages with a direct SDK call to AWS
import boto3
# AWS-specific SQS setup
sqs = boto3.client('sqs')
queue_url = 'https://sqs.us-east-1.amazonaws.com/123456789012/my-queue'
def send_message(message):
response = sqs.send_message(
QueueUrl=queue_url,
MessageBody=message
)
return response
- Code is tightly coupled to AWS, which means that switching providers or message brokers/queues requires rewriting the SDK integration.
- Infrastructure must be provisioned in a separate project containing the Infrastructure as Code (IaC) deployment scripts.
- If the queue setup changes, application logic must be updated to match, otherwise there is the risk of infrastructure risk.
Example: Sending messages with Dapr
Instead of interacting with a specific cloud service, applications send messages to Dapr’s publish API, which routes them to the appropriate backend.
import requests
DAPR_PORT = 3500
QUEUE_NAME = "azure-servicebus"
def send_message(message):
url = f"http://localhost:{DAPR_PORT}/v1.0/bindings/{QUEUE_NAME}"
payload = {"data": message, "operation": "create"}
response = requests.post(url, json=payload)
return response.status_code
send_message({"orderId": "12345"})
- Faster development and reduced complexity – Eliminates the need to integrate multiple cloud SDKs or write custom service discovery logic. Dapr provides a simple, consistent API that speeds up development.
- Seamless multicloud and hybrid deployment – Applications remain cloud-agnostic, making it easier to run workloads across AWS, Azure, Google Cloud Platform (GCP), or on-premises without major code changes.
- Built-in resilience and observability – Supports automatic retries, circuit breakers and distributed tracing, improving system reliability and making debugging easier.
- Event-driven and scalable by design – Native support for pub/sub messaging enables developers to build reactive, event-driven architectures that scale efficiently.
- Less operational overhead – Handles service communication patterns automatically, reducing the burden of writing and maintaining glue code for service interactions.
resource "azurerm_servicebus_namespace" "example" {
name = "example-namespace"
location = "East US"
resource_group_name = azurerm_resource_group.example.name
sku = "Standard"
}
resource "azurerm_servicebus_queue" "example" {
name = "example-queue"
namespace_id = azurerm_servicebus_namespace.example.id
}
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: azure-servicebus
namespace: default
spec:
type: bindings.azure.servicebusqueues
version: v1
metadata:
- name: connectionString
value: "Endpoint=sb://example-namespace.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=your-key"
- name: queueName
value: "example-queue"
Automating Infrastructure Based on Application Behavior
Dapr simplifies interactions with cloud services, but developers must still define and provision infrastructure separately. The next logical step is automating infrastructure provisioning based on the application’s resource usage.How this could work:
- Application-defined infrastructure – Infrastructure is inferred from the way the application interacts with cloud services.
- Least privilege access – Permissions adapt dynamically each time the application is redeployed, ensuring that the principles of least privilege permissions are always applied.
Example: Fully Automated Infrastructure Provisioning
A runtime-aware system can automatically provision the necessary resources based on application usage. In this example:- An API is exposed for creating user profiles.
- A key-value store is used to store user details.
- A storage bucket is used for profile picture uploads.
import json
from uuid import uuid4
from nitric.resources import api, kv, bucket
from nitric.application import Nitric
from nitric.context import HttpContext
# Create an API named public
profile_api = api("public")
# Access profile key-value store with permissions
profiles = kv("profiles").allow("get", "set", "delete")
# Define a storage bucket for profile pictures
profile_pics = bucket("profile-pics").allow("write", "read", "delete")
@profile_api.post("/profiles")
async def create_profile(ctx: HttpContext) -> None:
pid = str(uuid4())
name = ctx.req.json["name"]
age = ctx.req.json["age"]
hometown = ctx.req.json["homeTown"]
await profiles.set(pid, {"name": name, "age": age, "hometown": hometown})
ctx.res.body = {"msg": f"Profile with id {pid} created."}
Nitric.run()
Addressing Concerns With Automation
When introducing automation into enterprise workflows, it’s natural to have concerns about security, compliance and governance. Let’s break down these challenges and how they can be effectively managed.Separation of Concerns in Infrastructure Definition
One of the biggest concerns with frameworks that generate infrastructure from application code is the fear that developers will end up defining infrastructure directly. Does this blur the line between application and operations responsibilities? This approach actually strengthens separation of concerns when done right. Instead of manually provisioning resources, developers describe their application’s runtime needs without specifying how they’re deployed. Operations teams retain control over enforcement, security and cost management while reducing friction in translating application requirements into infrastructure. In fact, this reduces misconfigurations and speeds up delivery by ensuring infrastructure always aligns with what the application actually needs.Security Risks in IAM Policies and Provisioning
Could automation inadvertently grant excessive permissions or provision unauthorized resources? The good news is that automation doesn’t mean losing control; it actually strengthens security when done right. By enforcing policies through code, using tools like Open Policy Agent (OPA), AWS SCPs (service control policies) or predefined identity and access management (IAM) templates, organizations can ensure that permissions are consistently applied and reviewed before deployment. In fact, automation reduces human error, which is a common cause of security gaps.Compliance with SOC 2, HIPAA and PCI DSS
Many organizations worry that automation might conflict with strict regulatory frameworks like SOC 2, HIPAA or PCI DSS. In reality, automation is a powerful tool for maintaining compliance rather than undermining it. Regulations emphasize traceability, repeatability and control, all of which automation enhances. Instead of relying on manual processes, which can be inconsistent and error-prone, automated workflows ensure every deployment aligns with compliance requirements. Pre-approved infrastructure configurations can help as well. By defining approved patterns and enforcing them through automation, organizations can ensure that only compliant setups are deployed.Enterprise Workflows and Pre-Approved Configurations
For enterprises, automation must align with structured workflows. It’s understandable to worry that fully abstracting infrastructure provisioning could remove necessary guardrails. Instead of allowing unrestricted provisioning, automation can enforce enterprise-approved configurations. Platform teams still set the rules, defining approved configurations and ensuring consistency across environments.Final Thoughts
Rather than replacing governance and compliance processes, automation can reinforce them by making security and compliance part of the development workflow. With predefined policies, continuous monitoring and standardized configurations, organizations can improve both security and efficiency while maintaining the necessary controls. You can try out this automation approach using Nitric. Here are some tutorials to get you started.
Nitric is the cloud-aware framework that enhances developer productivity and ops confidence, uniting backend and infrastructure code to build and ship cloud apps fast. Devs build your application, Platform determines the right infrastructure and Nitric automates provisioning that works for both.
Learn More
The latest from Nitric
Hear more from our sponsor
YOUTUBE.COM/THENEWSTACK
Tech moves fast, don't miss an episode. Subscribe to our YouTube
channel to stream all our podcasts, interviews, demos, and more.
