DDI & Infrastructure Software Architecture

You are convinced about the interest of the Infrastructure As Code approach. But you don’t really know how to take best advantage of the code that will be produced. The principles used in software architecture and known as the abstraction layer can be applied to infrastructure. This layer will hide the complexity of the infrastructure and allow other functional programs to manage infrastructure components through high-level API services.

In the context of building such an abstraction layer with automation capabilities for the infrastructure, the DDI (DNS, DHCP, IPAM) solution should be one of the first to plug to and consume data from. DDI is well known to be the central repository for all network-related information, so has the ability to help most network’s services through automation. DDI can offer both the information and the repository to store these, as well as enhancements through metadata addition. But DDI is also a great automation tool that has excellent knowledge of what happens on the IP network. These valuable events can therefore be shared, almost in real-time, with all other interested solutions.

DDI in the Abstraction Layer

Starting an automation abstraction layer allows you to think about how to present the infrastructure to consumers via the northbound-exposed set of APIs. Do we really care about what a subnet is, or is it better to think about a network with capabilities and associated with IP addressing? Just take a look at how big public cloud players have built their abstraction layer to get some good ideas on how to proceed.

The DDI solution is “hidden” at the bottom of the layer and will probably not be consumed directly by IT applications. It can be interesting to build a set of generic functions that would be easier to use. This will allow all the infrastructure components plugged on the southbound endpoints of the abstraction layer (e.g. firewall, network device, SD-WAN appliance) to consume IP and core networking functions without having to specifically know the grammar of the DDI solution used. This abstraction can also help in proofing the data and actions performed on the DDI, for example validating that an object created is coherent and present in all the repositories that require it. This decoupling can also provide the ability to add some technical meta-data for better tracking of changes and link back to change management components.

Raising Operational Efficiency

With the IPAM repository as well as DNS and DHCP core services bound to the automation abstraction layer, all components of the infrastructure and all the clients of the layer can take advantage of the data and the automation. You can then plug in the other services by usage priority and always maintain a link towards the IPAM for storing valuable information. Think about the virtual machines correctly stored in the Device Manager, and the VLANs in the VLAN manager, they could then be used by any other component. The result is simplified integration between IT tools, faster code deployment, and an overall improvement in operational efficiency.