Cloud DNS: Addressing the visibility challenge

Being in the cloud means moving fast.  Cloud and DevOps teams are constantly standing up new compute, tearing it down, and moving assets around.  For developers, this is a pretty exciting situation to be in.  The entire cloud environment is built to give them what they want, when they want it.

When all of this innovation is happening in the cloud, the consequences on core network infrastructure are usually an afterthought.  Cloud and DevOps teams simply use the resources provided by cloud providers.  Or they stand up their own DNS servers.  They often don’t know what that means for the rest of the network, and they probably don’t care.  They just want to keep moving, no matter what happens on the infrastructure side.

Network administrators, on the other hand, care deeply about the infrastructure consequences of the cloud.  They’re the ones who have to deal with the back-end chaos that results from everything the cloud and DevOps teams do.  Cloud and DevOps teams expect all this stuff to “just work”.  Network teams have to make it work.

Unfortunately, network administrators usually have precious little insight into what’s going on in the cloud.

The cloud visibility challenge

It’s an architecture issue.  Cloud environments come with their own network infrastructure systems, but the cloud environment needs to be integrated into on-prem resources for access, as well as workload transit to and from the cloud.

That lack of integration and visibility can cause serious problems on the network:

Cloud coordination with on-prem networking:  Whenever cloud/DevOps teams stand up networking components of the cloud, they assign IP space to those areas.  In the absence of a single source of truth for assigning IP space across environments, those IP ranges may already be assigned to another area of the on-prem network.  These conflicts cause network outages which reduce productivity (and profitability) to zero for as long as they persist.

DNS routing challenges:  All the data and compute created in the cloud connects to something else.  When data and compute constantly shift between clouds and even to on-prem environments, maintaining those connections can get tricky.  Dealing with this rat’s nest of routing and forwarding rules can quickly become a full time job, sucking resources away from more important things.

Creeping fragmentation of DDI management:  Maintaining centralized visibility and control over core infrastructure resources is critical to error-free, rapid delivery of network services across the enterprise.  When the cloud creates autonomous areas of the network with their own DDI resources, that centralized system begins to erode, and with it the ability to deliver services efficiently and effectively.

Security and compliance:  If you can’t see what’s going on in the cloud, how are you going to secure it?  Just as importantly, how will you know that it’s secure when the compliance assessors come knocking?  Maybe there’s a way to cobble that data together on the fly, but security is something that should be there all day, every day.

Cloud and DevOps teams almost never get blamed when these things happen.  When network teams try to establish some order to the chaos by creating a system for DDI management, they’re often faulted for “slowing things down”.  It’s a classic problem of network admins having all the responsibility but only some of the authority over network infrastructure.

Finding visibility and control in the cloud

How can network teams find the cloud visibility and control they need without disrupting the pace of innovation?

Establish a consistent approach to DDI:  All of your DDI should speak the same language and draw from a single source of truth, regardless of where it sits.  Operating network infrastructure with different tools and configurations without a single source of truth to pull from prevents full visibility across the enterprise and quickly leads to downtime-inducing conflicts.  This sort of best practice is relevant even without the cloud, but the reach and complexity of the cloud makes it even more imperative.

Extend or integrate DDI systems:  Implementing a consistent DDI solution means one of two things – either extending core DDI infrastructure into the cloud, or integrating it with cloud-native core resources such as Amazon DNS, Amazon Route 53, Azure DNS, and Google Cloud DNS.  This isn’t necessarily an either/or decision, and there are several strategies which offer different paths to the same goal.  Suffice it to say that at some level, all of your DDI resources should flow seamlessly across the enterprise to create the visibility and control network teams require.  (Also, not everything that’s put in the cloud stays there – you’ll want a consistent approach if those assets are moved back on-premises.)

Deploy network automation and orchestration tools:  Once a single source of truth for DDI is in place, cloud and DevOps teams can operate quickly at scale by calling on those DDI resources with network automation tools and orchestration platforms.  Self-service provisioning connected to an automated DDI infrastructure is a prime example of the value that fully integrated infrastructure can provide to cloud and DevOps teams, giving them the power to get the resources they need quickly without creating more problems for their network infrastructure colleagues.

Enter Adaptive DNS

At BlueCat, our mission is to reduce the complexity caused by inefficient, disconnected network services in the cloud through an approach we call Adaptive DNS.  Our core DDI products already manage some of the largest and most critical networks on the planet.  As those networks shift into hybrid environments, we’re maintaining that single source of truth which is the foundation of a dynamic, open, scalable, secure, and automated enterprise architecture.

When it comes to implementing DDI in the cloud, there’s no single architecture that works for everyone.  Every network is different, and the goals supported by every network vary widely.

That’s why we have a flexible approach which doesn’t rely on boxes, or on-device agents, or heavy-handed architectures which force everything through the core.  That’s why we integrate with the cloud-native tools you’re already using, but can also replace those tools with BlueCat.  That’s why we operate with a lighter touch, giving you the ability to deploy DDI everywhere – in the cloud, at the network edge – through a pricing model that won’t lock you in to a particular kind of deployment.

Maybe you’re at the beginning of your cloud journey, and hoping to implement an architecture that works for the network team just as well as it works for the cloud and DevOps teams.  Maybe you’re already neck-deep in the cloud but lack the visibility and control you need.  Maybe you’re just trying to optimize your environment, and see DDI as low hanging fruit.

Whatever stage of the cloud journey you happen to be in, we’d love to chat.