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.