Cloud DNS:  IP address provisioning without compromise

Cloud development teams generally don’t think about Domain Name System (DNS) infrastructure used by their cloud platform.  That’s half the reason for being in the cloud in the first place – it’s so easy to stand up and tear down compute that you barely have to think about details like what DNS service you’re using, who’s keeping track of DNS records, or what the DNS zones look like.

But what happens when that agility and flexibility has negative consequences?  Are there times when an enterprise approach to network infrastructure is actually faster than what you’d stand up in the cloud?  As you may have already guessed, we believe the answer to both of these questions is yes.

If you’re provisioning a new cloud area, it’s likely that you’ll use one of two processes.

Provisioning through a cloud team

In this process, the cloud team decides to manage DNS on its own.  It determines which blocks of IP addresses to use, which subnets will be attached to each cloud tenant, and which IP addresses will be associated with the compute the team is standing up.

Cloud teams like to provision their own resources and stand up their own DNS servers because they can do it on their own schedule and at their own pace.  They have control over what happens, and changing it is as easy as asking another member of your own team.

There are significant downsides to this approach, however:

  • It takes too much time.  Determining which networks you’re going to use to stand up tenants is a manual process, and most cloud teams would rather put that time into actual development work.
  • It creates autonomous areas of compute completely unknown to the network team.  That can cause major problems down the line when IP conflicts arise, potentially causing outages.  That may also result in areas of the network that may be inaccessible to on-prem networks.
  • It leads to orphaned network data.  When assets are deprovisioned by cloud teams, they tend to just sit there, either taking up IP space which could be used elsewhere, or leading to conflicts down the road when network teams assume that the IP itself or the entire network is no longer in use.

Provisioning through a network team

Some cloud teams rely on their network colleagues to provision compute on their behalf.  In this process, the cloud team usually submits a service desk ticket and waits for a response.

The emphasis here is on “wait”.  Most network teams are overwhelmed with service desk tickets, around 30% of which are probably DNS-related.  Until the ticket is adjudicated, the cloud team sits on its hands, disrupting the agile development process which is supposed to be the advantage of going to the cloud in the first place.

While cloud teams tend to look down on this option, from the network team’s perspective, this is the ideal scenario.  When provisioning goes through a single source of truth, it avoids the risk associated with IP conflicts which lead to downtime.  Most network teams would rather be accused of being slow than bear responsibility for bringing down the network (and trying to bring it back up).

Network teams which have spent the time and energy needed to migrate to a unified DDI solution also get miffed when they find autonomous, free-standing areas of compute in the cloud.  Suddenly the advantages of a single source of truth for DDI data are diluted, and with it the network team’s ability to provide quality core services across the enterprise.  All of those gains of moving away from Microsoft and BIND (not to mention the IP address spreadsheet associated with them) start to feel elusive again.

An inherent tradeoff?

There appears to be a fundamental tradeoff between these two approaches.  Either you let the cloud team provision on the fly and risk a network outage, or you let the network team manage provisioning risk at the cost of slowing down the cloud development process.  Whichever way you slice it, there doesn’t seem to be a way to provision in the cloud that saves time and reduces risk.

It shouldn’t be any surprise that neither cloud nor network teams seem to be satisfied with how cloud resources are provisioned.  It’s amazing that there isn’t more shadow IT floating out there in the cloud, pieced together by DevOps teams who simply can’t wait for the network people to act.  On the other hand, it’s also shocking how many cloud teams are allowed to run free, provisioning resources in the cloud without accountability for the downstream consequences.

Automated cloud provisioning

This is where DDI automation saves the day, giving both cloud teams and network teams what they need.  If you have a single source of truth for DNS, DHCP, and IPAM data with BlueCat, that allows you to roll out self-service provisioning in the cloud through our automation platform.

What cloud teams see is a simple portal which allows them to request and receive DDI resources immediately.  If you want to add a host record, you just select a configuration, view, and zone.  When you select an IP address, the system automatically checks the system to see if it’s available.  Once you submit the form, the system provisions the IP address automatically.  Here’s an example of what it looks like in Microsoft Azure – it would look very similar when working with Route 53 in AWS or Google Cloud DNS.

The network team has the ability to set parameters, role-based permissions, and available IP address blocks.  All of this ensures that nobody on the cloud team can bring down the network by inadvertently creating an IP conflict.

With automated self-service provisioning, cloud teams get the resources they need, without the annoyance of spinning up those resources themselves.  Network teams get to manage DDI resources, ensuring that they know what’s going on across the enterprise.  Shadow IT is no longer necessary.  The migration to a centralized DDI management system isn’t compromised.  Everybody wins.

An avatar of the author

BlueCat provides core services and solutions that help our customers and their teams deliver change-ready networks. With BlueCat, organizations can build reliable, secure, and agile mission-critical networks that can support transformation initiatives such as cloud adoption and automation. BlueCat’s growing portfolio includes services and solutions for automated and unified DDI management, network security, multicloud management, and network observability and health.

Related content

Detect anomalies and CVE risks with Infrastructure Assurance 8.4 

The Infrastructure Assurance 8.4 release features an anomaly detection engine for outliers and a CVE analysis engine to uncover device vulnerabilities.

Read more

Get fast, resilient, and flexible DDI management with Integrity 9.6

With Integrity 9.6, network admins can get support for new DNS record types, architect and configure multi-primary DNS, and automate IP assignments.

Read more

Deepen your security insight with Infrastructure Assurance 8.3

BlueCat Infrastructure Assurance 8.3, with an enhanced analytics dashboard, including interactive widgets and top 10 alerts, is now available.

Read more

Security, automation, cloud integration keys to DDI solution success

Only 40% of enterprises believe they are fully successful with their DDI solution. Learn how to find greater success with new research from EMA and BlueCat.

Read more

Our commitment to Micetro customers and product investment

From CEO Stephen Devito, a word on BlueCat’s ongoing commitment to supporting Micetro customers and Micetro’s evolution as a network management tool.

Read more

Seven reasons to rethink firewall monitoring and boost automation 

With BlueCat Infrastructure Assurance, you can better protect your network with automated alerts and suggested remedies for hidden issues in your firewalls.

Read more