Managing Azure networks with Pulumi 3.0

Spread the love

Pulumi’s infrastructure-as-code application receives a significant update, with Azure at the core.

The Pulumi IaC (infrastructure-as-code) framework takes an unusual approach to cloud infrastructure delivery. Instead of using a domain-specific language like Bicep or declarative configurations like Azure’s ARM models, it provides a way to define and programmatically build infrastructures using an open source framework.

You write code in your prefered editor, using common language software for code formatting and linting, and it is run against the Pulumi engine, which delivers virtual infrastructures and configures service endpoints ready for your code. Since Pulumi files are only basic C#, Python, JavaScript, or even Go files, they can be handled alongside the application code and used in any IDE project.

Build infrastructure in your code editor

It’s a strong approach; you don’t need to learn any foreign languages, and you can use control flows in ways that a declarative, domain-specific language cannot. As a consequence, a single line of Pulumi code will describe all of the tools used by any project in your company. It is essential to use flow control elements to deploy groups of servers and set up software-defined networking while calling the code.

The same unit testing software that you use for programming can be used for infrastructure, running code to see what will be implemented in a live environment. You can prevent misconfigurations and bugs by checking infrastructure definitions and programming before going online. Deploying a small programme on a massive Azure server may be an expensive error that is easy to miss in the absence of hands-on operations support.

Pulumi offers tools for architects and operations teams to apply architectural and policy standards to infrastructure. You can set limits on the servers being provisioned or the levels of service being used, as well as define different characteristics for development, test, and production. Using architectural standards like this puts guardrails around your Azure deployments in the same way Visual Studio can enforce coding standards.

READ ALSO:  Microsoft open-sources fuzzing test framework

Native support for Azure

Pulumi’s first update was a cross-cloud tool. Pulumi code could deliver infrastructure on any cloud provider’s platform. However, you were restricted to only using services that could run on any cloud; you couldn’t use it to create Azure-specific apps that relied on Azure services and APIs.

Over the past few releases, Pulumi has started introducing support for what it’s calling native providers, with Azure the first to go into general availability as part of the recently released Pulumi 3.0. Microsoft has been investing heavily in documenting and adding metadata to its APIs, with Azure providing data for its REST APIs. This allows Pulumi to generate a new version of its Azure native provider nightly to keep up with new features and updates.

This doesn’t mean that the APIs and calls you use need to change at the same rate. Pulumi’s tools support all versions of an Azure API, so your code and infrastructure don’t need to change until Azure deprecates the version you’re currently using. If a new service arrives that you want to use in your applications, it will be available as soon as Azure publishes the API. The same API automatically generates documentation, with new versions for each supported language.

It’s a useful tool, and Pulumi clearly is proud of what it can do. As the company notes, it’s made 279 different builds of the native provider, adding 166 new Azure infrastructure APIs.

Infrastructure budgets as code

Those APIs include governance and billing APIs, so you can wrap controls around your infrastructure to manage spend and security. Infrastructure code can include consumption budgets to help you track costs and tie resources to specific accounts. Budgets can be measured per month, per quarter, and per year. Budgets can also be usage based, with notifications automatically sent to email addresses when quotas or thresholds are exceeded.

READ ALSO:  A Closer Look at Angular’s ngMessages Module

Cost management on Azure can be complicated, and this strategy can assist you in establishing sufficient protections for infrastructure and service use. This platform may not cover anything, but you should be able to get a sense of how much your programmes are costing you and how you can invest more efficiently, maybe by reprovisioning on lower-specification servers.

Automating infrastructure with code

One of the more interesting features in Pulumi 3.0 is its Automation API. This allows you to embed Pulumi functions inside your own applications as a tool for managing cloud infrastructures. It’s a fascinating approach that’s flexible enough to be used in many different ways.

Building it into an internal platform for self-service technology implementations is one clear choice. Instead of providing access to the Azure portal to all of the engineers, an internal service can be filled with supported server photos and other technology components. Engineers in need of a temporary test or construction environment can choose the tools they require and have them instantly deployed without the need for operations support. When a test is over, the service will reclaim resources, reducing billing.

Alternatively, a set of Pulumi scripts for an application-specific infrastructure can be kept in your choice of repositories. An application build in Azure Devops would not only compile, build, and package code, but a pipeline action could be used to trigger the Pulumi Automation API and deploy an Azure infrastructure ready for the code.

READ ALSO:  When AIops tools outsmart you A

Having an API for infrastructure management enables you to begin writing your own management code, consuming data from Azure’s management APIs and using it in combination with resources such as the Cognitive Service prediction APIs to proactively deploy additional application infrastructure elements in response to shifts in load or signs of failure in an already operating instance. Through installing technology only when it is needed, you can keep costs down while ensuring that the apps stay sensitive and reliable.

The concept of writing code that can handle itself is appealing, particularly in organisations with limited operational resources. Self-managing systems must be thoroughly tested before deployment, and a strong devops culture is required to use these methods effectively, with applications operations personnel capable of monitoring an entire suite of applications and tools.

This is a significant update to a platform that is becoming increasingly useful. Building dynamically on top of Azure’s ARM APIs means that the infrastructure still has access to the most up-to-date resources. Your apps will begin building on them as soon as they are published, while also benefiting from a hands-off, streamlined architecture in your prefered language. Pulumi is still focused on introducing additional languages to its toolbox, with Ruby and Java now in the works.


Leave a Reply