Automating Cloud IPAM by Example

Automation is a hot topic within IT organizations these days, as well it should be. Automation offers tangible benefits in terms of reducing costs, increasing agility, diminishing manual efforts and minimizing human errors while performing a process. I recommend considering IP address management (IPAM) tasks within your automation design as I proposed in a prior post, given IPAM's tentacles menacingly reaching into virtually every IP device initialization, movement or decommissioning process. But how does one go about designing automation?

Consider that you can automate a process if it consists of a repeatable set of discrete tasks required to perform a function or unit of work. Some tasks may be performed in parallel with others and most tasks require input values provided by or derived from prior tasks to begin. Documenting the tasks required and the sequence or flow of tasks, i.e., as a workflow or flowchart, is a prescribed first step. Once you've laid out the basic flow, identify which organization and systems are responsible for performing, approving and tracking each task. Then determine the set of information required to execute a given task within the flow. Of course this information must be either produced during the execution of the flow or provided as input parameters to the overall flow, so be sure to tabulate the source for each task's input parameters.

In general, the more tasks, management systems and organizations involved within the workflow, the more complex it is. Sometimes in documenting a flow, one may notice a more expeditious sequence of tasks, which affords a potential side benefit to documenting your processes. Complexity generally results in a longer time to complete the overall workflow and a greater need for overall process coordination. This is especially true when task hand-offs between organizations or process owners within the overall workflow are required. In many cases, these hand-offs have traditionally been conducted manually, communicated via phone, email, or process review meetings as necessary. These forms of communications are typically ad hoc in nature and add additional time and variability to the defined tasks within the workflow, so it's advisable if possible to attain approval from involved parties to the extent possible before initiating the overall workflow to eliminate interruptions and delays.

 Let's consider a simple workflow example to illustrate these concepts: I'd like to automate the provisioning of a subnet from my private address space to my virtual private cloud (VPC) with my public cloud service. Since I'm provisioning a subnet from my own private address space, my IPAM system should be authoritative for the assigned subnet. (This is unlike the case when I instantiate a virtual machine, where typically the cloud service is authoritative for address assignment. The point is to maintain flexibility in defining your workflows). So my basic subnet provisioning flow comprises checking my IPAM system for an available subnet relevant to my address plan, allocating the subnet within my VPC using my cloud provider's console, then synchronizing any cross-referential information such as cloud-assigned metadata for the subnet back in my IPAM system. Sounds simple enough.

Next, let's drill down one layer and map out these steps along with inputs and outputs as illustrated in the figure below. To begin the process, I need to know where within my VPC I need to provision a subnet and of what type (IPv4/IPv6) and CIDR size. I can login to my IPAM system and determine what subnet block(s) is/are available depending on how your IPAM system represents your cloud address space, e.g., by availability zone (AZ) for AWS. Most Diamond IP customers represent VPCs and AZs (and analogous cloud system structures for other cloud providers) using containers within our IPAM system, IPControl. Navigate to the given container for example and simply click the add child block menu to allocate a block of the desired type and size automatically, or enter the subnet address manually (though this blog is all about automation!).



Once you've identified and reserved the automatically-allocated subnet address, you can swivel to your cloud console and provision the subnet of the given address within the corresponding cloud structure. The cloud system may assign a subnet ID and other meta data for the subnet, so it's a good idea to track this in your IPAM system for cross-referencing purposes. So you can log back into your IPAM system and update the subnet information. The process then completes with the successful provisioning of a subnet of the desired type and size within the cloud system, all tracked in your IPAM system.

Now that we've mapped out the basic process, another pass with an added layer of detail is likely required to specify individual parameters mapping to system-supported API calls for each step. Once you've documented your workflow to this level, you need to define how to orchestrate the flow, accepting outputs from one system, mapping them into and adding parameters for calls into the next. 

At Diamond IP, we recognize the benefits automation brings, particularly with setting the foundation of your services with IPAM. We can help you automate and orchestrate your IPAM related workflows using our Cloud Automation Appliance's (CAA's) drag-and-drop graphical user interface based on NodeRed. We supply primitives for our API calls as well as those for several public cloud providers that you can drag onto your workflow palette to define your own flows specific to your particular processes. 

You can also install published NodeRed modules to incorporate interfaces and interactions with other systems to expand your automation to other critical IT systems and functions. You can even incorporate base flows into broader flows, automating more complex multi-system flows. This code reuse saves time in creating flows, provides consistency in how flows perform given actions, and reduces maintenance by retaining a single place to apply fixes.

This figure represents our simple cloud subnet allocation flow example as managed using our CAA. As you can see, the graphical flow interface maps to our earlier flowchart and is relatively easy to digest, edit, and communicate. We supply several API primitives natively for our IPControl IPAM system as well as for other cloud systems, and  we also supply a set of sample workflows you can tweak to your desired flows. Please contact us for a free demo and to learn more.

Comments

Popular posts from this blog

Handy AAAA filter in BIND 9.8

Inglorious DDI

BIND 9.8.0 Adds DNS64 Support - Part 2 - How is it configured?