With a cloud networking solution that works across multiple providers, network teams can design self-service capabilities that allow cloud and DevOps teams to build and manage networks without compromising security.
Public cloud migration long ago wrested control over digital infrastructure from network and security teams, but now is the time for those groups to retake the initiative. Cloud operations and DevOps groups will never cede ground, but they will welcome self-service networking and security solutions that provide guardrails that protect them from disaster. Cooperation between traditional infrastructure teams and cloud teams is even more important as enterprises embrace multi-cloud architecture, where complexity and risk are increasing. In fact, my research has found that security risk, collaboration problems, and complexity are the top pain points associated with multi-cloud networking today.
Now is the time for cloud guardrails, because disasters are happening regularly. One network architect told me that his company’s DevOps team moved a critical ecommerce application into the public cloud, but they ignored his advice on PCI DSS compliance. Because of this, the migration ultimately failed. A network engineer told me that he can’t properly manage capacity on his company’s direct connections from his data centers into multiple cloud providers because his cloud teams refuse to give him any visibility. When cloud traffic spikes, he has no warning. This hampers his ability to proactively provision more bandwidth when cloud application usage trends upward.
Provide cloud guardrails, not speedbumps
Network engineers and architects often tell me that their cloud and DevOps counterparts resist or ignore their efforts to impose architectural rigor in the public cloud. Cloud and DevOps teams believe that networking and security groups are too old-fashioned and get in the way of cloud-driven innovation. These infrastructure folks slow things down at a time when cloud and DevOps want to fail fast and iterate.
However, times are changing. With multi-cloud complexity mounting, some network infrastructure pros tell me that they’ve devoted significant time and resources over the last couple years to installing cloud guardrails. Often this involves stepping away from the networking solutions offered by individual cloud providers and adopting a cloud networking solution that works consistently across multiple cloud providers. Network and security teams can define guardrails in these multi-cloud networking solutions and allow cloud and DevOps teams to build and manage networks within them.
The key is to ensure that the technology implemented is actually providing a guardrail and not imposing a speedbump or roadblock. Network and security teams need to provide infrastructure and services that are programmatic and easy to use. For instance, DevOps should be able to request IP addresses, spin up secure DNS services, request changes to firewall policies, or adjust transit routing with a couple clicks. If approvals are required from network and security teams, those approvals should be automated as much as possible.
This drive toward programmatic services is apparent in my research at Enterprise Management Associates (EMA). For instance, I recently surveyed 351 IT professionals about their multi-cloud networking strategies for the report “Multi-Cloud Networking: Connecting and Securing the Future.” (Check out EMA’s free webinar to learn more about what we found in that research). In that report, 82% of respondents told us that it was at least somewhat important for their multi-cloud networking solutions to have open APIs. More than 60% said they used these APIs to integrate their multi-cloud networking solutions with IT service management (ITSM) platforms. This integration enables automation of network change tickets, which removes speedbumps. Also, 52% use these APIs to directly enable cloud orchestration and automation tools for true self-service networking and security.
This need for self-service networking and security is also apparent in how today’s infrastructure teams are thinking about multi-cloud connectivity. EMA asked research respondents about their plans for connecting applications together in a multi-cloud environment. Did they plan to provision that connectivity at the IP layer (Layer 3) or at the application layer (Layer 7)? Layer 3 would imply that the network is in control. Layer 7 implies that the cloud and DevOps teams are in control with limited guardrails. Only 11% said they are focusing on Layer 3 and only 29% said they are focusing on Layer 7. The rest (61%) envision a future where they are provisioning application connectivity at both Layer 3 and Layer 7. This means that network teams are building guardrails. They are imposing controllers at the network layer, but they’re giving programmatic control over connectivity at Layer 7 to cloud and DevOps teams. This is the future of cloud networking.
Our research found that 93% of IT organizations are interested in adopting an end-to-end multi-cloud networking solution, but they have some barriers to overcome first. They are especially interested in solutions that can provide them a consistent, programmatic approach to network security, secure ingress/egress, and transit routing across multiple clouds. However, there are some challenges that inhibit their adoption of such solutions. First, 41% say network complexity is getting in the way and 36% say that budget is a major issue. Finally, 27% say they’re struggling with cross-team decision making. In other words, network, security, cloud, and DevOps teams are not on the same page. It will fall to IT leaders to bring these groups together and get multi-cloud networking and security back on track.
