Turn Deployment Environments into Commodities with Azure
When you think about cloud services for developer productivity, the emphasis is usually on the local development environment, where you can reduce hours of work to a few seconds of setup. Even using scripts to get up and running, it used to take new employees at GitHub half a day to get a local instance of GitHub.com ready to work on, and then another 45 minutes every time they wanted to move to a branch with new dependencies, or help a colleague with a coding problem in a different branch. CodeSpaces gets that down to a few seconds for working on repos in Visual Studio Code (Google Cloud Workstations offers similar with various JetBrains IDEs) and Microsoft Dev Box gives you an entire preconfigured developer workstation in the cloud.
But when it comes to deploying the complex environments that applications run in, which might require multiple cloud services and subscriptions and need to be set up multiple times for test, staging and production as part of a build pipeline, there’s a tension between making it fast and easy for developers and keeping resources secure and managed.
Azure Deployment Environments
The new public preview of Azure Deployment Environments, announced today at the Microsoft Ignite conference, allows developers to spin up on-demand app deployment environments using a catalog of Infrastructure as Code templates with policies and subscriptions pre-configured by the infrastructure management team. The deployments use managed identities and developers don’t need to have access to the subscriptions and resource groups that applications will use (so they’re not tempted to save the credentials or hard-code them into scripts).
Azure Deployment Environments apply the right mix of policy to app environments and give developers the permissions they need at different stages of development and deployment; Image via Microsoft.
The templates also improve the security of the environments the applications run in, Anthony Cangialosi, who works on developer tools and services at Microsoft, told The New Stack.
“One of the concerns and challenges we hear organizations talk about is when we give developers access to a subscription, it’s like the wild west. We don’t know that they’re configuring these environments in a secure way. We don’t know if they’re configuring them consistently in the way the application was designed to work. So, when changes get submitted into the main branch, we often find issues as it gets rolled out.”
Azure Deployment Environments allows infrastructure and operations teams to create standard definitions for an application runtime environment. Developers can deploy them from the developer portal, from the CLI or as part of the CI/CD pipeline.
What Will It Be Used for
Unlike Azure DevTest Labs, where the advanced configuration and cost control features focus on VMs, templates built using Azure Resource Manager can configure and deploy any service in Azure. DevTest Labs has only basic options for spinning up PaaS resources using ARM templates and it creates all resources in the same subscription, so it’s only really useful for the development and test scenarios the name suggests. Deployment Environments are useful all the way through to production deployments.
Bicep and Terraform support is on the roadmap for Azure Deployment Environments and maybe Pulumi, Ansible and other infrastructure-as-code frameworks further down the road.
Different policies can apply to the templates for sandbox, dev, test, staging, pre-prod and production environments — like automatically turning a test environment off after it’s been used, or giving a developer more permissions in the development or test environment than in production.
“Being able to define different templates for production, pre-production, and testing and staging allows teams to define here is what an application needs to run correctly at the right sizing to manage cost for these different stages and to ensure that they’re configured securely and correctly, giving the developer the flexibility to rapidly create these without having to take on the burden of learning how to do that,” Cangialosi explained.
“It gives teams the confidence that they’re working with consistent environments. Now a developer can publish their changes into a deployment environment before they submit a PR, allowing a team to collaborate on the actual changes running in an instance that is representative of how it’ll run in production, with the actual services, not just the isolated component running on your local workstation.” Even with containers and mocking you can’t replicate the entire delivery environment on a developer laptop.
Security and Productivity
This isn’t about locking down developer environments or limiting what they can do. “There’s often this tension between the IT organization, as it is trying to manage security and compliance and governance, and developers looking for flexibility and control. These services help balance and give developers a greater degree of flexibility within the constraints.”
Being able to define and standardize app environments gives developers and infrastructure teams a way to work together and experiment with the impact of different configurations, he suggested.
“They can collaborate on changes; you can deploy them in a separate environment for developers to try out to see whether or not they’ll support the product, what impact they might have on performance, perspective, scalability, [and] any functional issues that might happen before they’re deployed broadly in pre-production or production environments.” Templates are stored in repos with versioning and pull request processes, just like any other code.
Azure Deployment Environments show up in the same Developer Center as Dev Box instances, which gives infrastructure teams one place to manage permissions and shared authorization. “As you have a development team that’s working on a common project, you can define the developers that have permissions to set up the developer workstation through Dev Boxes, as well as deployment environments that are predefined for them, that they can create in the same service.”
For developers, the appeal of Dev Box is getting to work faster. Like Azure Deployment Environments, it makes it easier to switch between roles like development and test or data engineering (or different clients, for consultants and contract staff), he pointed out. “You don’t have to have a separate laptop. You don’t have to worry, as you’re taking on different tasks, about potentially poisoning your existing environment with configurations that might make it difficult to rebuild your environment as you bring in new tools and SDKs that might reset or regress where you are.”
Right-Sizing
Developers also get the benefit of hardware upgrades without the disruption that usually means, and the economics are appealing to enterprises for the same reasons they adopted IaaS. “When you’re sending a physical workstation, you have to size for the maximum of what developers need, even though they may not be using that all the time.” Like any other cloud service, Dev Box can scale up and down as required. “As you move these workstations into the cloud, you have so much more elasticity to work with. You can right-size for a particular task or a particular role or project and as those roles and needs change, you can also change the hardware and the capacity that a developer has available to them.”
That matters more than ever for hybrid and remote work. “The last couple of years have taught us a lot about the need for more flexible, managed development and production environments,” RedMonk analyst James Governor told the New Stack. “Onboarding and offboarding new employees and contractors, for example, and finally bringing development environments fully into the cloud era. Guardrails are the watchword, as we balance developer productivity and developer experience with the needs of the business in terms of security and compliance. Dev Box allows a Windows shop to turn developer workstations into fully managed cloud services. Azure Deployment Environments should help enterprises standardize management of workflows from dev to production.”
The private preview has been especially popular in the financial services industry, where many organizations require developers to reimage their machines every two to four weeks for compliance reasons. But even without those somewhat extreme policies, Cangialosi pointed out, “You are a new developer in a new space at different points in your career, even when you don’t leave your current job.”