Don’t hire a “network complication engineer”: Enterprise IT requires simplicity

The purpose of digital transformation (and I’ve already commented on how I don’t particularly like this phrase) is enabling core business competencies with modern technology. A car company should make and sell cars. A furniture company should make and sell furniture. A widget company should make and sell widgets. None of these companies should be in the business of building complicated network infrastructure—especially when you can easily consume infrastructure in the cloud. 

Unfortunately, most companies build infrastructure solutions internally that use a hub-and-spoke architecture with castle-and-moat security. These systems don’t meet the needs of enterprises focused on critical business agility. Legacy network architectures are defined by complex, custom-built infrastructures framed around data centers (even when employees connect mainly to cloud infrastructure). 

I worked with a network engineer who we christened with the unfortunate title of “Network Complication Engineer.” He built a system that bridged multiple service providers and private peering exchanges in co-location data centers to provide network services to over 900 locations across the globe. He was proud of the unfathomable complexity in his network architecture.   

Meeting today’s business challenges, however, requires simplicity. Solutions that assume everyone is on the internet, know that apps live outside the data center, and use identity instead of networks as the common interconnectivity layer will inherently be faster to deploy, less costly, and easier to scale. Secure Service Access Edge (SASE) and Zero Trust Architecture (ZTA) adhere to those principles and allow organizations to enable network and security simplicity. 

More of the same, please . . .

The impact of the COVID-19 pandemic is a global example of how legacy networks do not handle change well. The hub-and-spoke model that routed all traffic back into corporate data centers couldn’t pivot and scale fast enough to handle all users working from home. VPNs were quickly overwhelmed, productivity suffered, and costs skyrocketed. But this is endemic of a much larger legacy network problem: legacy architectures don’t handle ANY enterprise change well—especially when you factor in cybersecurity. 

But now, the cloud increasingly delivers needed services and applications. More people connect to those services from outside the security perimeter, from any location on personal devices. To contend with these shifts, enterprises need to spin up new infrastructure quickly, cost-effectively, and seize new business opportunities to meet evolving goals. 

The agility bottleneck is often an IT department saddled with a legacy environment. They are asked to go “cloud-first” but still maintain control of the network. In response, their answer is often complex and expensive offsite network builds that don't align to the “cloud-now” mandate expected by the businesses they support.  

While technically these complex environments are in many ways outside of the customer’s physical locations, they aren’t in any real way different than having onsite infrastructure—and they are much more expensive. For instance, most near-carrier-grade colocation data centers don’t solve any of the issues that face enterprises. They are still legacy network infrastructures (with advanced peering and high performance). They are just as anchored in old network thinking: control the network, maintain a perimeter, protect the assets via location. 

A better solution is using the internet as your network and basing security on identity, posture, and context rather than location. 

Debunking common SASE myths

The cries I hear from IT teams when I bring up SASE and the internet as the network are, “We need visibility!” and, “I can’t get a guaranteed SLA from the internet!” These concerns are myths. 

First off, SASE provides more visibility, not less. When the internet is your network, and you have a service acting as a logical first hop out to the internet and last hop back in applying security policy, users get to applications by the shortest path, no matter where either live. Legacy architectures usually force connections through the corporate data center or a private cloud tenant and then back out to applications (in the name of security). 

Why should organizations be focused on building this architecture today when they can consume it? Routing traffic over complex paths strangles performance, costs a lot in backhaul traffic, and limits visibility by reducing user connections to long lists of IP addresses and port numbers. In some cases, traffic flows completely bypass the tools that provide “visibility.” 

On the other hand, Zero Trust Architecture allows access to corporate assets via identity, posture, and context as defined by policies. And it does so without actually putting the user on the network, a concept even I found foreign after managing networks for 20 years. Zero trust means user “A” can access application “B” using device “C.” Period. It doesn’t matter where these three things live, and the connection is visible at per-user, per-app granularity.

Let’s now turn to the second myth: SLAs for connectivity service from major enterprise-grade service providers are misleading. Yes, there is a guaranteed response time, but that doesn’t mean the problem gets fixed in that time. 

To illustrate, I once worked at a company that generated hundreds of thousands of dollars of revenue via call centers. Those connections were of prime importance to my business and built with multiple layers of redundancy, and when the connection went down, I was on the phone with the provider in seconds. They came out immediately (well within the four-hour response time SLA) and then told us they would fix the problem ASAP. It took another five hours. We lost service for an entire business day.   

The business unit leader was livid and told me to hold the Tier-1 service provider to their agreed-upon SLAs and ask for a credit for the lost revenue. We had resiliency and redundancy. Did we get all our money? No, we did not. The service provider gave us credit for a percentage of the monthly service, which came out to roughly $12,000. 

So the idea of an SLA guaranteeing connection is a fallacy. Arguably, commercial internet service is just as good as private network service for most business needs, and its wide distribution allows you to mitigate most outages via the deployment of similar concepts—diverse circuits via multiple providers. Couple that with private network service that delivers additional bandwidth using architectures like SD-WAN means getting 10x the bandwidth for 25% of the cost compared to current solutions. You can have vendor diversity, cost savings, more bandwidth, and a better user experience if you explore options such as leveraging ISP aggregators globally to provide your internet connections. 

What lurks in the shadows

A less visible problem facing enterprises using legacy systems is shadow IT. Shadow IT is any corporate project initiated outside the usual IT approval process. Shadow projects proliferate because IT traditionally has a reputation as the department of “no” (“no you can’t do that, no it’s not secure, no it doesn’t work with the secure and complicated network that we just spent millions of dollars provisioning to support your business”).  

As corporations push for faster outputs and more agile responses to changing goals and crises, people adopt a “get it done” attitude. This attitude usually butts up against slow, legacy IT processes anchored around that complicated network infrastructure.  

For better or worse, shadow IT is easy to do these days. You can click a button and spin up servers in an IaaS platform. You can start whole projects using cloud-based collaboration tools without involving IT. Now you’ve got multiple, untrackable environments populated with users who have access to corporate assets outside the security perimeter - which are all delivered without the use of the complicated network infrastructure your teams are trying to protect. 

SASE is “Simple And Secure Everywhere”

Well, not really. SASE is Secure Access Service Edge—but you get my point. For today’s enterprises, SASE is the present and the future of perimeter-less cloud security.

At my previous organization, we wanted a SaaS tool that would have optimized business processes critical to the core competency of the business and increased value to both our customers and our employees. However, it involved video interviews stored outside the network. Making it secure using our legacy infrastructure would cost $200K per data center above the cost of the service. 

Fast forward to now, where the business is using the internet as the network, and the only question is, “Are you comfortable with storing video with the service in the cloud? Yes? Great, go for it.” IT only worries about providing SASE licenses to users and setting policies to access the service. The decision to use the service is no longer about IT and its hurdles from a provisioning and capacity perspective. Instead, it is strictly a business decision where IT can easily enable the policy if it feels that the service will help achieve its goals. 

SASE and ZTA accelerates cloud adoption by removing network and security friction through the consolidation and simplification of IT services. It offers a seamless and transparent experience for end-users and standardization across locations for  IT teams. It also connects enterprise users securely, quickly, and efficiently to the resources regardless of their location. 

If you are a network leader, prioritize SASE and zero trust, make sure your next hire is not a network complication engineer, and leave the legacy network and security infrastructure gymnastics to the heroes of the past.  

What to read next

Use SASE to simplify your security tools

A novel concept: Enabling companies to do what they’re supposed to do