Developers of cloud-based infrastructures live much of their lives on the edge - that critical spot where end users tend to interact with technology.
With IDC predicting the total worldwide cloud market, including, public, private, and hybrid clouds, will more than double to $554 billion by 2021, more attention than ever is being focused on what optimal cloud implementations - and their edges - look like.
One window into the cloud is through names rather than numbers. Because end users interact with names rather than IP addresses, it is possible to use the Domain Name System (DNS), which translates names into resources, to understand the edge. Internet performance management tools and DNS providers that control and optimize cloud services and analyze this DNS-based view can help an organization understand trends in edge services. DNS data gathered from zone files, Web crawl logs and other sources yield data sets of names and associated resource records.
By analyzing those records, five cloud infrastructure deployment archetypes emerge: Acquisitions Without Mergers; Hub and Spoke; Cloud Indigenous; Flux; and "Colony on Mars. Each presents its own set of challenges and benefits.
1) Acquisitions Without Mergers
Picture a business purchasing a competitor and consolidating two businesses into one. In the DNS, however, both namespaces continue to exist. Namespace is maintained because end users still associate it with products and services from the acquired competitor. For example, the parent company mainly uses Amazon Web Services (AWS), and the acquired company uses SoftLayer. Looking at the namespaces of the two companies and the resource records they've configured, it's possible to gain a good understanding of the company's edge. For example, developers might evaluate the namespaces associated with two companies and find different brands using various content delivery networks (CDNs) to deliver content.
From the CFO's perspective, the company might be missing out on negotiating better rates from providers, as multiple contracts issued to individual brands diminish purchasing power. From the CSO's and CISO's perspective, there are multiple sets of credentials for a number of services would need to be monitored and audited. Despite the impact to the bottom line and the risk of more accounts to secure there can be benefits in letting groups / organizations work with whatever providers meet their needs. One CDN might have a feature or additional telemetry that the others lack which provides business value that outweighs the risk.
2) Hub and Spoke
Some corporations grant autonomy to business units to avoid bureaucracy. Imagine, for example, a media company that lets individual brands operate their own infrastructures. In this scenario, each brand is making independent decisions about cloud hosting providers and CDNs, but the parent business may lose centralized purchasing power and favorable pricing terms.
It's a challenge to establish the metadata that ties several namespaces together to form a larger corporate entity. Through visibility into the DNS, it's possible to build out the resources associated with the individual namespaces, but awareness of the corporate entity that owns the namespace is what makes viewing the corporate hub and spoke configuration possible.
3) Cloud Indigenous
Cloud-indigenous developers build their services to leverage the advantages of the "as-a-service" revolution. They invest in developing an "infrastructure-as-code" environment, and their namespace is filled with CNAMEs pointing to cloud-based load balancers, customer service platforms, and marketing tools. Their TXT records contain a manifest of proof of domain ownership entries for different providers and SPF records for their transactional email providers.
Yet even within the Cloud Indigenous category you will see that different priorities result in different decisions. The weary design their applications to be cloud agnostic consuming only raw resources like compute, load balancing and object storage ready to arbitrage costs. Others have focused on getting products and services to market building a foundation on top of featured cloud services. This fork breaks the cloud indigenous into clusters of "compute nomads" or "cloud settlers".
4) Flux
The flux archetype is the signature of a cloud-native company or a company moving to the cloud. A central core of fixed infrastructure in a data center or cloud, and a CDN supports the front door of the business. The rest of the infrastructure moves between providers, driven by cost optimization, customer endpoint colocation/fast connect, or other factors. Time series analysis of a company's namespace reveals a continuous churn of cloud provider CNAMEs and IP addresses, and that can be a source of operational information leakage. Over time, it's possible to watch a gradual increase of subdomains/hostnames to witness growth or a gradual decline signaling some detail about the user base.
5) Colony on Mars
Some businesses own some of their own IP space, keeping most of their core services hosted in their own IP address space but moving their customer-interfacing edge into a cloud infrastructure. The landing page is behind a Web application firewall (WAF), while the Web server farm is in the cloud. They maintain their corporate data center, perhaps because they have yet to find the right cloud provider or because of a long depreciation schedule. In a similar scenario, current services remain in the legacy environment, but all new development happens in the cloud. Observing this infrastructure requires a time series of the namespace to see a steady increase of resource records which resolve to the enterprise cloud provider.
Gaining Meaningful Insights
Companies need to understand what information is available about their infrastructure as a function of their deployment. Having this information will allow business decision makers to have case studies and examples that show the tradeoffs of cost and developer productivity / time to market. Every business wants to succeed, yet there are many different definitions of success. The decisions you make on your infrastructure may depend on whether you prioritize being first to market or cost savings or security or all of those things.
Using the DNS to build a map of a business can be an insightful exercise. Because the DNS provides a service for mapping abstractions to resources, it can be used to steer traffic based on the geolocation of the requestor or on which endpoint will provide the optimal end user experience. Studying the relationships defined in the DNS paints a picture of "who is using what." By looking at the data over time, it's possible to understand and contextualize changes by seeing "who was using what...and when."
Armed with that knowledge, developers can get closer to designing the optimal cloud infrastructure for their business. About the Author: Chris Baker is a Principal of Threat Intelligence at Oracle Dyn Global Business Unit
