It is the year 2021 and by now you have decided to deploy infrastructure in the public cloud. You may be leveraging the cloud for development, customer-facing apps, or disaster recovery. Regardless of how you use it, the cloud has become ubiquitous in our daily lives. Even if you are one of the rare organizations that has not deployed a single workload to an external cloud, Microsoft likely forced your hand in decommissioning local Exchange servers in favor of O365. Even at home the cloud is all around you: Alexa, mobile apps, and streaming media are all served from public cloud infrastructure. You can run from the cloud, but you cannot hide.
For those of us with years in network and security, what you have found out is that the workflows required to deploy cloud infrastructure effectively and securely are far more complex than provisioning address space and policy within a local datacenter. You may have had to add some routes but, in today’s modern DCs, it is unlikely that was a concern. Security policy definitions and approvals were probably the longest part of the process in making the new resource available on the network.
In the cloud though, everything works and moves differently. Many organizations are trying to replicate what they have done for years in building their private clouds but, now in external, public clouds. If your organization has years of knowledge and expertise in building and securing networks using physical routers, switches, and firewalls why would you not take the same approach when establishing and maintaining connectivity between your network and the cloud? Because it is wrong.
Developers are now leveraging containers to minimize resource utilization in deploying application workloads. Kubernetes then enables individual containers to become highly distributed, highly decentralized applications. Developers can take this a step further in the cloud by going “serverless.” It is all part of an effort to achieve maximum agility and availability with the lowest possible resource consumption. That is a fancy way of saying, “I still want everything, but your budget is being reduced by 7% this year.”
The challenge that many organizations are now facing is that while application engineering has moved on, network and security have not. This statement should not be seen as an indictment or organizational failure; the cloud did not suddenly appear fully formed. We all have had to change and adapt as public cloud matured.
What is happening now is that while public cloud has been “OK,” organizations are realizing that by extending their L3 operations stack into the cloud – enthusiastically encouraged by their vendors that provided them with virtual equivalents of the monolithic appliances they’ve been selling for years – they are not enjoying the benefits promised by the cloud. Instead, they are having the same headaches and, potentially, paying more to have them in public cloud. While IP addressing still exists across resources, there are multiple, overlapping address space that can exist within a cloud infrastructure. That complexity can scale exponentially when you start to deploy application infrastructure across one or more clouds.
The military has a saying: “Ounces equals pounds, pounds equals pain.” In cloud, L3 routing and security equals complexity, and complexity equals pain. The pain that organizations are feeling is a two-fold problem: a siloed approach to implementing connectivity has resulted in poor quality of life for operations teams because users are bombarding them with complaints about bad application experience. The best-of-breed product approach and the associated, organizational silos it has created has resulted in Engineering receiving a star for ticking all the requirement check boxes but, Operations then spends their lives troubleshooting and tuning the network in an effort to make their applications perform as they should.
While all resources maintain an IP address, the cloud – like Kubernetes – use namespaces, not IPs to reach resources. Deploying virtual routers and firewalls in the cloud-native architectures – regardless of public or private cloud – only act to decelerate organizational agility through multiple, management control planes. Kubernetes has broken network paradigms, but organizations and their “box” vendors are still trying to solve this. New vendors are emerging who are looking to solve this problem but, they are simply obfuscating the complexity by automating traditional L3 routing schemes while still requiring that you bring a virtual firewall to the party. This is not cloud-native networking.
Going back more than a few years, I had to use five different remote controls just to turn on and consume entertainment on my home theater system. At some point I broke down and bought a programable remote where I was able to consolidate all of those individual remotes into one. I did not have to physically pick up more than one remote control but, I was still pushing the same number of buttons. Over time I learned to automate some of the button pushing but, I had to use an external app to create the automation. If my TV or my smart remote received a firmware update, I sometimes had to reprogram the remote because things were not working quite right. I had achieved some relief in turning on my TV but, it was still not a great experience. Does this sound familiar?
Eventually, I bought a smart TV that detected and controlled my external sound system as well as provided – natively – all of the media apps I use including Apple TV. I had one remote that did everything and the system now worked together seamlessly while eliminating some boxes at the same time. I was able to connect and start having the experience I wanted to have immediately without having to manage the complexity of multiple control planes. This is the promise of cloud and cloud-native networking.
When looking at connectivity solutions for your organization, it is important to qualify the outcome. Are you achieving the appearance of simplicity while still carrying the same level of operational risk? Will the business be more agile or will legacy workflows – extended into the cloud – only act to slow time-to-market and innovation? If your developers are solving application complexity using cloud-native methods, your network and security should be taking the same approach. Go to the cloud, but leave your L3 stack at home.
