Environment management

Note

Please read about environments in general first.

Note

This page uses Azure terminology, but the principles and best practices can be applied to other cloud providers (e.g.: GCP, AWS) as well.

Implementing proper environment management enables teams to work on parallel activities, improves security, and quality, and also reduces time to market.

Deploying and managing environments in cloud are fairly simple, with all the supported methods of automation, but there are still lot to consider to have consistent and secure environments.

At OSB, usually, we work with four environments per project, unless the customer demands otherwise: development, test, pre-production, and production.

Best Practices

To ensure consistency across environments and implement proper security measures follow below best practices.

Security

• Use environment specific resource groups, use one resource group per environment.
• Divide resource groups into at least two subscriptions. One subscription for lower (development and test), and one other for higher environments (pre-production and production).
• Manage access to resources by RBAC assignments and ensure least privileges principles.
• Rely on PaaS offerings as much as possible.
• Use Managed Identities to secure communication between services.
• Store and manage secrets, keys and certificates in Key Vault.

Consistency

• Incorporate Infrastructure as code practices to ensure that environments are as close as possible to each others.
• Deploy environments and application versions with CI/CD pipelines.
• Implement quality and approval gates.

Infrastructure as code (IaC)

Infrastructure as code is the managing and provisioning infrastructure through code. IaC uses DevOps methodology and versioning a model to define an infrastructure.

Declarative vs. imperative approaches

There are two ways to approach IaC: declarative and imperative.

Imperative

Imperative approach defines specific commands needed to achieve the desired configuration and their order which they have to be executed.

Declarative

Declarative approach defines the desired state of the system, including resources and their properties and IaC tool will decide how to achieve this state. It also keeps track of the current state of the infrastructure in order to support incremental deployment.

Imperative vs. Declarative

Declarative approach is preferred over imperative approach.

It requires less maintenance. Declarative files are not impacted by command line interface changes (e.g.: renaming a subcommand). Current and desired states are managed by the deployment tool, so developers don't have to implement such logic themselves.

IaC on Azure

Azure provides native support for IaC via Azure Resource Manager. Declarative templates can be defined by ARM templates, that specify the infrastructure required to deploy solutions. Azure natively supports ARM templates created in JSON and Bicep. Several third-party platforms like Terraform is also supported.

Bicep

While working on Azure it is highly recommended to use Bicep to implement IaC. Bicep is a domain specific language that uses declarative syntax to deploy Azure resources.

• It supports all resource types and API versions from day 0
• Simple syntax
• Fully fledged support by VS Code
• Modular
• State is managed by Azure
• Free and open source