A developer's guide: Networking in the age of hybrid cloud

As with everything in IT operations, networking is complicated. It requires training and mastery of a specialized skill set. Configuring a network and connecting to the cloud should not be something that developers take on.

Yet they do, and when they call me for help, there’s much we have to undo and reconfigure. It’s not that developers aren’t intelligent and creative. They are. But most don't have the network engineering knowledge to orchestrate all that’s necessary for secure, maintainable networking—especially in hybrid cloud architectures.

As networking becomes more complex in the age of the hybrid cloud, networking and development engineers must understand each other's roles and work together in a DevOps manner. That will make the IT organization—and the business—more agile.

Here are just a few examples of things my company sees regularly that show the need for greater developer understanding of the networking domain. These problems aren't always the fault of developers, of course; network engineers have some learning to do as well.

Hybrid Cloud: New Challenge For Monitoring Solutions

Know the basics of IP numbering

Every server and every virtual machine in a network is identified with an IP address. In Amazon Web Services (AWS) parlance, the virtual private cloud (VPC) is almost like a data center in the cloud. A small company may need only one VPC, or perhaps two—one for development, and one for production. Larger companies may have dozens of VPCs in production.

But no matter how many VPCs you deploy, it will take trained networking engineers to come up with an IP numbering scheme. Why? Consider all of the networking elements in AWS (which my company uses more than any other provider). In the cloud, networking is at Layer 3 of the OSI Reference Model, just above Ethernet. If you must make changes later, and your networking elements are not well-numbered, then network address translations (NATs) become extremely difficult. And it’s likely that the NATs will increase the complexity of inter-VPC communication.

I frequently see situations where a developer who's unfamiliar with this territory has rolled out multiple VPCs that either have overlapping IP spaces or exist entirely within the same IP space. Network engineers know this is not a good idea; developers may not.

These may seem like small things, but ensuring that all areas of your infrastructure are easy to maintain is essential. With all the load balancers that are required, and with all that NAT necessitates, it’s hard to know how to configure a network and deploy apps in a secure way unless you have the right background. And now that security is top of mind for CIOs, that networking expertise is more critical than ever.

Understand infrastructure-as-code best practices

If you as a developer don't follow proper infrastructure-as-code best practices, whether you use Ansible, Puppet, or some other tool, you’re headed for trouble downstream. If someone accidentally deletes a VPC, for example, how are you going to rebuild it?

Unless you have checked the VPC into a Git repository as code, you’ll have to rebuild it manually. And what if, by making tweaks to a container or a VM on the fly (another networking faux pas), you’ve created what in the server world is called a snowflake—something that isn’t easily reproduced?

Here’s what happens when you lose that VPC: Security and operations take a hit. It means that if you make changes outside the established infrastructure-as-code methods you’ve agreed to use, and you don’t know if there’s routing or activity between different portions of the VPCs, then you can’t know what is or what isn’t being protected.

Connecting to the cloud: Collaborate first

Our clients either are migrating to the cloud, are in the process of doing so, or are at least talking about it. And although software-defined networking (SDN) is in the news these days, our customers aren’t talking about it or SD-WAN; they’re just trying to build basic connectivity.

And they’re puzzled by other networking requirements, such as setting up IPsec tunnels or deciding whether there’s an advantage in direct connectivity over using a private line. 

When a company is already connected to the cloud, we’re called in to help it optimize and sort out its configurations. It may need help with a security audit or a network audit. Sometimes we find that it has a thousand subnets defined in AWS, for example, but it doesn’t know which ones it's actually using. It might have 15 versions of what should be a single security group.

Often, that inefficiency is the result of a developer-led series of migrations from on-premises to cloud-based apps. The lesson here: Loop in your network engineers early in the process.

The developer's role

Developers should be involved with migrations and optimizations once the IT organization is in the cloud. But, unless you have a solid background in networking, you should not be solely responsible for deciding how to connect sites, how data centers connect to on-premises resources, or which of those connect in turn to the cloud.

Don't assume that the network’s latency is minimal, or even constant. Your apps must take into account that network topology can change and that momentary or persistent packet drops can occur. Essentially, you need to understand what goes into a data networking architecture.

As a developer, you know how to squeeze performance out of an app and how to set up the right load balancing and the correct connection to a specific database. And, as someone who knows how to do things programmatically, you can certainly contribute to cloud and network connectivity. There’s a place for that know-how in the cloud with regard to leveraging virtual networking inside public cloud services.

Get complexity out of the way

Go into most suburban areas of the US, and you’ll find many businesses, from banks to gas stations to pharmacies, that have hundreds of connected sites throughout the country. If you need to connect to 100—or 1,000—of those sites and interconnect them in a way that accesses the Internet and the public cloud, and do all that securely, you need to be talking to a networking professional.

Professionals can help by showing you where to start. The setup in this situation is far more complex than having one or two offices with infrastructure in the cloud. When you have hundreds of offices that all need access to workloads in the cloud, how do you do that?

This is what networking engineers do. But they can’t do their jobs without more awareness from the development and other IT teams that need those capabilities.

Network engineers want their work to be invisible, like household plumbing. To paraphrase AWS architect James Hamilton, our goal is to get the network out of the way. We understand: People using the network shouldn’t have to think about it. But getting the network out of the way requires a solid design, a structured plan, and not just a willy-nilly attitude that says, “Let’s try this!”

To build top-notch cloud-based apps, developers should collaborate with network engineers. You need a network that’s capable and optimized for your apps. When it comes to putting out lots of subnets and load balancers, the development team faces something new. Yes, AWS has been out since 2006, but you'll need guidance and direction from your network engineers to fully understand what’s needed for the cloud.

What network engineers need to learn

Getting all members of the IT team to work together more effectively means that the networking team needs to step up, too. Networking professionals need to understand what developers are trying to accomplish and translate that into networking requirements.

Networking professionals don't have to become programmers. But they should learn data transfer and serialization languages such as JSON and YAML, and they should know Git. While the value of Cisco CCIE or Juniper JNCIE certification won't evaporate, network engineering is evolving beyond mastery of a router's command-line interface.

Network engineers must talk to developers in terms they understand, meaning the API. That’s rare today. They don’t need to know how to write an API client, or write any kind of code per se, but they need to be familiar with how APIs work.

At a minimum, a subset of the networking team needs to serve as a liaison with developers. Eventually, you won’t have people banging things out on the command-line interface, where changes are very error-prone. That will eventually be replaced with API calls, and that will free up network engineers to focus on higher-value tasks.

The future will be automated...

Many organizations are still manually provisioning cloud connectivity on-premises, but that practice will eventually fall by the wayside. If you have workloads in AWS, you’re probably manually configuring IPsec to the cloud, but you need to find an easier way.

The hurdles that currently exist in quickly instantiating network connectivity must frustrate the engineers at the major cloud providers. At re:Invent last year, AWS announced several new simplifications for networking, such as inter-region VPC peering, and we’re looking forward to learning and implementing these technologies.

The move toward automation will continue. While the current manual methods are error-prone, network automation techniques have matured over the past five years. And more reliable open-source software means there’s a role for developers in automating network configurations and tasks using event-driven techniques that allow automatic reaction to network issues that need remediation. Going forward, collaboration between networking and development teams will be key.

Hybrid Cloud: New Challenge For Monitoring Solutions