Total visibility key to tame DDI hybrid cloud challenges

While hybrid cloud adoption brings rapid innovation and agility to your enterprise, it also comes with a host of challenges for network management.

When mid-to-large-sized enterprises adopt cloud strategies that weave together on-premises and cloud environments, a particular set of pitfalls consistently crop up for DNS, DHCP, and IP address management (together known as DDI).

During a recent ONUG webinar moderated by Zeus Kerravala, Founder and Principal Analyst at ZK Research, BlueCat Chief Strategy Officer Andrew Wertkin unpacked four critical DDI challenges that come with hybrid cloud adoption and used an example application to illustrate their impact. Futhermore, he delved into how total visibility is the key to taming these complexities and implementing effective automation to manage them.

“Understanding this world that’s becoming increasingly dynamic and increasingly distributed, trying to manually manage these things is going to lead to failure. It’s going to lead to scale problems. It’s going to lead to reliability problems,” Kerravala says. “Automation of these things does become important.”

If you missed it, this post will cover the highlights. You can also access the entire webinar here.

The four critical DDI challenges that come with cloud

DDI teams have zero visibility into or control of cloud networks and DNS

The team that’s responsible for DDI management often has no visibility into or control over what’s happening with DNS on cloud networks. Some of that is the result of shadow IT. Fast-moving cloud or DevOps teams circumvent IT and implement their own IP space in the cloud.

“But even post that, even in the world where that’s governed and orchestrated, there’s still this lack of collaboration between those teams generating this zero visibility,” Wertkin says.

Cloud and on-premises DDI are silos, threatening network performance, zone conflicts, errors, and outages

The lack of visibility creates silos between cloud and on-premises. The result is not only the fragmentation of IP space but also overlapping IP space or the underutilization of large swaths of network space. Non-contiguous use of IP across cloud and on-premises can result in network performance issues, DNS zone conflicts, errors, and outages.

The inability to automate and orchestrate rapid change slows innovation

Enterprises can implement change rapidly with the use of automation. But effective network automation is impossible without a single source truth for all DDI activity in your hybrid cloud environment.

“You can’t change something unless you can assert some sort of source of truth. Like you’re automating against something,” Wertkin says. “And if that something is inaccurate or lacks critical information, then your automation will not be successful.”

A growing tangle of DNS forwarding rules to manage hybrid resolution creates complexity, consuming resources and impacting the end-user experience

Thanks to cloud service provider DNS, the current cloud environment comes with additional areas to create DNS. Things can get complicated in a hurry.

One particular challenge is private endpoints.

For public DNS, zones work like a charm. They’re reliable and scalable. But deploying cloud service provider zones ends up creating islands of DNS that stand alone.

The only way to connect them to the rest of your network is to create stub zones or conditional forwarding rules. These assume that, for that specific zone, there’s only one place to go. However, often in the cloud, more than one cloud or virtual network will use the same zone.

Private endpoints, which allow organizations to access a platform service from a cloud service provider or a third party through a private IP address, are often the solution. But they are “excruciatingly difficult” for any client outside of the virtual network to resolve to, Wertkin noted.

“That’s not how DNS works, that’s not how stub zones are supposed to work, that’s not how conditional forwarding works,” he added.

Applications: A breeding ground for hybrid cloud challenges

Cloud applications can have complex dependencies on DNS. To illustrate them, Wertkin custom-built an e-commerce application that we’ll call Cool App (no, really).

Deployed in AWS, Cool App needs to connect to the company’s order entry system in the on-premises data center. And it needs to go out to the internet to reach its shipping partner. Further, it needs to get to two regions of Amazon Web Services (AWS): the product catalog on AWS US-East-1 and the customer database on AWS US-East-2. And the person working using the application works out of a home office in Toronto.

In this example, the application is not set up to resolve anything in private DNS. This leaves it unable to access the order entry system in the data center (illustrated by the red border).

Meanwhile, the yellow border illustrates the product catalog as a database-as-a-service, which is available on both public and private sides.

But, again, the application can’t resolve to private DNS. As a result, instead of accessing the product catalog securely through a private network in the cloud, Cool App is resolving it via a public IP address. Egress and ingress through the public internet come with both security risks and cost implications.

This example of using different authorities—such as the internet, traditional private DNS, and two different networks within a cloud service provider—happens often. The question is, how do you resolve all of it? Manual configuration or creating a mess of conditional forwarding rules isn’t the answer.

The answer: Total visibility

Your networking stack should understand that cloud deployment can query across different zones, including internal private networks. It should interpret different hosts for the same zone deployed in different places. And if a later version of Cool App comes along, it should adjust to, say, the addition of another order entry system in the data center.

Furthermore, it should be able to segment with security in mind. It might monitor activity when your application queries the DNS record of something new that’s never been queried before. Or, if Cool App begins querying known malicious domains, it should block them.

Visibility is crucial

Ultimately, visibility is crucial as DNS resolves across multiple places.

“We need to be able to see every single DNS query—whether it was resolved, how it was resolved, where it was resolved from—so that any issues with any resolution can be rapidly identified and any specific configuration issues can be resolved,” Wertkin says.

Discovery is core to the cloud, he continued. The solution can’t be that everything that happens in the cloud goes through manual configuration to work.

“There has to be an assumption that DNS itself, which is used for service discovery, can be discovered so that we can drive this harmony in the way DNS is being used,” Wertkin says.

Get a single source of truth for automation

Collaboration between cloud and network teams is essential. In fact, research conducted for BlueCat shows that dysfunctional relationships between cloud and network teams put cloud strategies at risk. Including the cloud in the broad view of DDI management allows network teams to know everything that happens in the enterprise and to effectively automate against it.

“Single source of truth is necessary to drive any level of automation with success,” Wertkin says. “It’s easy to create APIs to automate stuff; it’s hard to automate correctly. In order to automate correctly, you need that source of truth.”

Learn more about how BlueCat’s platform can give you a single source of truth for your DDI, helping you to automate your network and manage your hybrid cloud environment.