5 ways to dramatically speed up your cloud application teams

[Guest Keith Howling]

Working with applications teams and partners developing cloud native apps on Azure, you quickly learn developer time is valuable, enthusiasm & flow state is critically important.

 

 

 

Whenever an application team has to wait for an environment, wait for a access, a service now ticket, a support case, admin access to install tooling, productivity is dramatically effected, projects can be 2x longer and of lower quality.

 

 

 

Equally, it's important to have a designed, governed secure environment when using the public cloud, so your workload teams start right, and stay right! This covers all the normal design pillars of a well architected solution, reliability, security, cost and performance.

 

 

 

Application teams work best when they can select their preferred platform services, tooling, languages and libraries, and most importantly, reduce their dependencies on external requests & constraints that limit their selection of services. To this end, platform teams number one priority should be to work towards a self-service model, removing themselves from the process, constantly unblock friction points.

 

 

 

[HEADING=1]Where Platform teams should focus[/HEADING]

[HEADING=1][/url][/HEADING]

 

You don't need to have everything automated from day 1, nor have tooling for everything, but focusing in these 5 crucial elements will result in more impact for everyone in your organization, while avoiding unnecessary tickets/cases and bottlenecks, something I have seen depressingly way to often.

 

 

 

[HEADING=2]1. Environment Provisioning[/HEADING]

[HEADING=2][/HEADING]

 

When a application team works on a new product, timely access to an environment is important when enthusiasm is high. You should be targeting giving teams access to an environment they can use within 30mins from the initial request. Vending a Resource Groups to the application team with all the access they need to immediatly start deploying their solution designs (more on this later). The resource group naming, tagging, the subscription sharing model and level of access can all be determined base on the environment requested.

 

 

Subscription sharing model can be designed to avoid too much subscription sprawl, based on department, or other organisational commonalities, but subscription separation should be enforced at minimum on workload type and connectivity (more on this below). You then end up with a subscription list that is meaningful and manageable. There are a number of good resources on naming recommendations

 

 

Subscriptions now in Azure can support hundreds of developers, the subscriptions have granular role-based controls, mature cost tracking services, and you can now track

Subscription Limits

& usage very effectively.

We recently had 300 developers across 35 resource groups, deploying resources across the globe, all working happily in a single sandbox subscription.

 

 

 

 

 

 

During the vending process, it will be important to capture:

 

 

 

• Workload Type (e.g. Production vs Sandbox), this drives the policies that are applied to control what can be deployed & levels of access, and keeps the separation between these environments. Keep the separation of any Production and Sandbox environments should be at the subscription level.
  
• Required Networking (e.g. Connected or Non-connected) this determines if private IP connectivity is required by the workload, or if ingress/egress to the workload needs to be privately routed.
  

 

 

 

 

 

The first, simplest, most unconstrained environment you should offer is a Non-connected Sandbox, this allows the application teams the most flexibility to experiment with multiple services, full access to the environment in the portal to allow the team to rapidly get ideas to a POC stage. Here typically, there are no or little restrictions on access or resources that can be provisioned. The most constrained, and complex environment will be a Connected Production subscription, this will have policies to ensure production guardrails are followed, and networking to allow private IP connectivity, and ingress/egress routing controls (if needed).

 

 

 

The new

Subscription Vending Bicep Verified Module

is a excellent starting point to start vending these environments, from the simplest to the most complex with a module & parameter driven approach. You can collect the required information from the application team, then call the vending module directly from the [iCODE]az cli[/iCODE] to start with, or create a pipeline/action in your favourite devops tool, maybe trigger a GitHub workflow from a Issue template:

 

 

 

 

 

 

 

 

 

Hot Take: I'd recommend Bicep over Terraform when automating environment provisioning or application deployment on Azure, even if you are multi-cloud, It's a simple, powerful, performant 1st class experience, without needing the complexities of a state file, as the state is whatever is deployed in azure, and templates can be re-run and only the changes will be deployed.

 

 

 

 

 

[HEADING=2]2. Environment Permissions[/HEADING]

[HEADING=2][/HEADING]

 

So you have vended an environment, the app team tried to provision their first internally authenticated webapp that calls a gpt-4o model using identity based access, deployed using github actions... error error error 4 tickets in 5 minutes, now the team are googling for workarounds, not delivering their projects, wasting valuable time, and enthusiasm. Whats the problem?

 

 

 

• No permissions to create a Role Assignment on the webapp managed identity
  
• OpenAI resource not registered in subscription
  
• Cannot create Application Registration in EntraID
  
• Require Admin consent for application permissions.
  
• Cannot create federated access from github to deploy to Azure
  

 

When building cloud native apps, managed identity and role based access is a crucial part of the application architecture, and 100% the best and most secure way of creating cloud native applications.

 

 

 

Platform teams must provide the appropriate level of access to the application team to allow these solution architectures. I've seen this being the single thing that wastes tens/hundreds of hours of skilled peoples time

 

 

 

[HEADING=3]Recommendation #1[/HEADING]

 

When assigning roles to the application team, [iCODE]Contributor[/iCODE] is not enough to create identity-based solution architectures! Consider providing the team [iCODE]Contributor[/iCODE] & [iCODE]Role Based Access Control Administrator[/iCODE], this role can be scoped to either the resource group , and can be further limited to only assign selected roles to selected principals.

 

 

 

[HEADING=3]Recommendation #2[/HEADING]

 

Ensure resource provider registrations have been done as part of the vending process, and not blocking the application teams from creating their resources.

 

 

 

[HEADING=3]Recommendation #3[/HEADING]

 

Many applications will need users to authenticate, and the best way of doing that is with Entra ID. These apps need application registrations within EntraID, if your organization blocks the self-service creation of new application registrations, and/or has restrictive consent granting. Ensure the team know the process for requesting a new application registration. Also, unless you want a new Service now ticket every time the app team what to add a new callback uri, make then a owner of the app registration in the process.

 

 

 

[HEADING=3]Recommendation #4[/HEADING]

 

Lastly, yes, ensure the use of Identity & Automation for deployments in Production environments, but don’t take away access to the portal from your application teams! Grant your application team corporate identities roles in the environment. Not granting this access, especially in the lower environments will make it much harder for the teams.

 

 

 

[HEADING=2]3. A little less documentation & a little more sample repos[/HEADING]

[HEADING=2][/HEADING]

 

Our environment provisioning provides the application teams a blank slate at this stage, it doesn’t make any assumptions about the application teams solution architecture, this will allow the application team to select the optimal services for their use-cases, that could be a microservices app or a integration workflow, or a simple static webapp. selecting the appropriate service for the use-case will make the best use of the public cloud, optimize your public cloud costs while minimizing the required operation to support your application. Equally, it don’t assume the structure or number of repo's that the application team will use.

 

 

 

However, we should be providing the application teams more support than just a blank canvas, we should be looking to share successful architecture patterns, example applications that have already been approved for use within your organization.

 

 

 

Rather than documents, start to foster a innersource repo of samples, that can be simply provisioned into the vended environment, to show what a static webapp, or a simple microservices app, or an event driven process, or a integration workflow could look like. This can provide new teams a starting point with built in approved patterns to accelerated their journey to production. These examples, with good READMEs can also inform the teams how to structure there application team repos with the infrastructure-as-code, and automation deployment workflows.

 

 

 

Look at the Azure Developer CLI templates us a good example of this, I'm not saying you should use this tool, but [iCODE]azd template list[/iCODE] shows a list of sample application patterns with well documented, structured repos. You can start to create a curated list that demonstrates getting started repos in each of the application solution categories for your organisation, even starting with some of these samples where relevant.

 

 

 

 

[HEADING=3] [/HEADING]

[HEADING=3]Infrastructure-as-code modules[/HEADING]

 

Another thing to notice/adopt, in these samples repo [iCODE]/infra[/iCODE] folders, their main bicep file is just composing a number of modules, these modules represent the 'right' way of configuring each service for your organization, for example, pre-configured with private endpoints and RBAC based access and so on. You can look to build a repo of these modules approved for use in your organization to again, accelerate your application teams. You can also get started by using Azure Verified Modules, or build your own bicep module library, using inner-sourcing, sharing this between the application teams.

 

[HEADING=3] [/HEADING]

[HEADING=3]Kubernetes namespace vending[/HEADING]

This article doesn't cover Namespace vending on a large, shared AKS clusters. I've seen this pattern working very well in organizations with a Kubernetes-first approach to the public cloud, or organizations with a strong will for cloud agnostic solutions, however, this requires additional engineering beyond the scope of this article using AKS + other tooling. There is great session from

2024 Build

on building this service. However, providing example solution patterns for scale-to-zero microservices using

, or for more complex needs,

. These are great to add to your library of solution patterns that can be provisioned by your application teams that keep the complexity low, while providing a example pattern for the most sophisticated of application needs.

[HEADING=2] [/HEADING]

[HEADING=2]4. Tooling / Local loop development[/HEADING]

 

 

 

Application teams experiment in the portal, develop locally, and provision from their local machine, then, add the automation and the managed identity to perform auto deployments via source control to apply in the later environments.

 

 

 

Ensure the teams can install/configure VS code / VS code extensions / command line tools / docker locally, and they have connectivity from these tools to the public cloud APIs they need.

 

 

 

 

 

[iCODE]@azure/identity[/iCODE] libraries are now brilliant! For many dependencies, there is no need any more to use API keys or credentials that need to be stored in key-vault's & rotated periodically, now, just use your EntraID's corporate identity or a Managed Identity with RBAC. Using these identity libraries, If the developer wants to run their code locally, and connect to a database or message service in azure, the locally running app will operate with the local developers corporate identity (obtained through [iCODE]az login[/iCODE]), and as long as the dev has the appropriate RBAC on the database, all good. If they deploy their app to Azure PaaS Service, without any code changes, the code will access the database using the services managed identity. This makes the apps secure and resilient, and can be prompted up to production securely.

 

 

 

Without these tools and access, the application teams will not be writing the most secure way of coding their app.

 

 

 

[HEADING=2]5. Track Metrics[/HEADING]

[HEADING=2][/HEADING]

 

Track anything that causes friction. Anytime the application team is waiting on something, a case, access to a service, resolving a bug, track it, dashboard it, and constantly priorities securely removing friction. Promote the creation of issues on the platform teams repo, keep a prioritized backlog. Hold monthly feedback sessions.

 

 

 

If Application teams are held up, they will try to work around issues to ship their product, this can mean using the wrong environment, or using a less than ideal service or configuration. So removing friction will result in better, more secure use of the public cloud.

 

 

 

[HEADING=1]Wrapup[/HEADING]

 

 

 

Let me know what you think of these recommendations, if you are in a Platform team supporting Azure, I'd love to hear your experiences. If you are in a Application Team deploying to Azure, have a chat with the team providing you the environment, show them this blog, setup a regular call, its important the teams collaborate to get your companies products out the door, security, reliably and on time.

 

Continue reading...