From CCIE to Google Cloud Network Engineer: four things to think about

To stay relevant and wanted in the high-tech job market, it’s important to keep abreast of new technologies—and get certified in them! Google Cloud offers a number of professional certifications, including the new Professional Cloud Network Engineer. Currently in beta, certifications such as this can make you a valuable asset in a multi-cloud world.

If you’re coming from a traditional on-premises IT environment, there are some things that are helpful to know up front when studying for the Cloud Network Engineer certification. Personally, I spent nearly two decades working in mainstream IT operations settings, and have made the switch to cloud. As a former Cisco Certified Internetwork Expert, i.e., CCIE, I’ve had to let go of the past and open up to seeing and learning new things in a slightly different way. Here are some things to understand before you start studying. The sooner you see the difference between networking in the cloud and on-prem, the more successful you'll be.

1. Focus on workflows, not packets.

Figure 1 is a common network diagram that shows the data flow between two endpoints over a simple network. Data originates in applications on Endpoint 1 and flows up and down the TCP/IP network stack across the devices in the network, until it finally reaches the applications on Endpoint 2. Before a large chunk of data is sent out of EndPoint-1 it is sliced up into smaller sized pieces. Protocol headers are then prepended to these pieces before they are sent out onto the wire as packets. These packets, and their associated headers, are the atomic unit in the networking world.

As a network engineer though, you typically focus on the network devices in between the endpoints, not the endpoints themselves. As you can see in Router-1, the majority of traffic flows through the router; it comes in one interface (the so-called “goes-inta” interface), and passes out the “goes-outta” interface. Only a relatively small amount of traffic is destined to the router itself. Data destined for the network device, meanwhile, includes control-plane communications, management traffic, or malicious attacks. This “through vs. to” traffic balance is common across all networking devices (switches, routers, firewalls, and load balancers) and results in a “goes-inta/goes-outta” view of the world as you configure, operate, and troubleshoot your network devices.

Once you step into the cloud engineer role the atomic unit changes. Packets and headers are replaced with workflows and their associated datasets. Figure 2 shows this conceptual change through a typical three-tier web deployment. The idea of the network as you knew is it abstracted and distributed. The traffic pattern now inverts, with the majority of traffic either sourced or destined for a cloud service or application that resides on a cloud resource, rather than the network devices between them.

You can see this when you look at how to configure the firewall rule named http-inbound. Even though you configure the rule in relation to the VPC, you now have to identify a target using either the --target-tags or the --target-service-accounts=[IAM Service Account] gcloud arguments. In addition, depending on the ingress or egress direction of the traffic, you only configure either a source or destination filter, not both. This is because half of the information is considered to be the target itself. In other words, the focus is on the data that enters and leaves the specific cloud service.

2. Realize your building blocks have changed.

As you move from on-premises to the cloud don’t get hung up trying to fit all the networking details you already know into the new solutions you are learning. Remember that your new goal is to enable workflows.

In the old networking world there were tangible building blocks such as switches, routers, firewalls, load balancers, cables, racks, power outlets, and BTU calculations. The intangible building blocks were features and methods defined by IETF RFCs and vendor-proprietary protocols with their ordered steps, finite-state machines, data structures, and timers. You physically assembled all these things to build inter-connectivity between the end users and the applications they used to make your business run. Implementing all this took days and weeks. In addition, as the network grew, the associated management and cost to operate it also grew disproportionately larger for your business.

Cloud solutions treat this complexity as a software problem and add a layer of abstraction between end users and workloads, removing or hiding many of the complex details associated with the old building blocks. Your new building blocks are cloud-based services and features like Google Compute Engine, Cloud SQL, Cloud Functions, and Cloud Pub/Sub. You assemble these new resources based on your needs to provide IaaS, Paas, SaaS, and FaaS solutions. Your deployment schedule shrinks from days and weeks to seconds and minutes as you connect your enterprise network via Cloud VPN or Cloud Interconnect and deploy VPCs, Cloud Load Balancing, and Docker containers with Google Kubernetes Engine. You minimize management complexity through tools like Deployment Manager, Stackdriver, and Google Cloud’s pricing tools. You no longer simply build connectivity between end points but rather enable virtualized environments by treating infrastructure as code.

3. Understand the power of a global fiber network.

Many cloud providers’ infrastructure is made up of large data center complexes in geographical regions across the globe, with each region subdivided into zones for service redundancy. Connectivity between these regions, for the most part, happens over the public internet.

The benefit of this approach is that the internet provides ubiquitous connectivity. Looking at Figure 3 though you can see that there are several downsides:

• Management complexity. As your cloud footprint grows and you need your “island” VPCs to communicate over various peering options across regions, you inherit additional configuration, operational, and troubleshooting complexity
  
• Unpredictable performance. You have no control over jitter, delay, and packet loss in the public Internet.
  
• Suboptimal routes. The number of hops your traffic must transverse across the internet is most likely not optimized for your business—you are at the mercy of network outages and carriers’ BGP policies.
• Security risks.  The internet is where the good people are (your customers), but it’s also unfortunately where the bad people are. While you can encrypt your traffic in transit, you still run a risk when sending inter-region communications over the public Internet.

Google Cloud’s’ Premium Network Service Tier, now generally available, changes the game. As shown in Figure 4, the public internet sits outside of your global VPC. The core of your network is now Google’s own private fiber network.

This improves your situation in several ways:

• You no longer have a cloud footprint made up of isolated geographic VPC islands—your infrastructure is one large homogenous cloud network. This network can be regional to start and grow to a global footprint when you are ready, with minimal headache.
  
• The issues of packet loss, delay, and jitter are mitigated significantly as compared to the public internet.
  
• The number of hops between endpoints is significantly minimized. Once your traffic enters the Google network it rides across its optimum path as opposed to through various Internet carrier networks.
  
• By utilizing global load-balancing and anycast addresses, traffic hops onto and jumps off of Google’s network at the closest point to your end users.
  
• Inter-region and private access traffic is automatically encrypted, transparently to the application, and sent across the private fiber backbone.  Because it doesn’t ride over the Internet, that traffic is never exposed to the bad guys.

Of course, if these advantages aren’t as compelling as lower bandwidth costs, Google Cloud also offers a Standard Networking Tier that routes traffic over the public internet for a lower price point.  

4. Embrace the flexibility of the API, Client Libraries, SDK, and Console.

Sure, some networking devices have GUI-based management programs or web consoles, but if you’re like me, you’ve probably spent most of your career in the CLI of a networking device. This is because GUIs tend to make the basic stuff easy and CLIs make the hard stuff possible‚—they’re your go-to place for configuration, operation, and troubleshooting.

CLIs do have their limitations though. If you want new features you have to upgrade software, and before you upgrade you have to test. That takes time and it’s expensive. If the CLI’s command structure or output changes, your existing automation and scripting breaks. In addition, in large networks with literally hundreds or thousands of devices, lack of software version consistency can be a management nightmare. Yes, you have SNMP, and where SNMP fails, XML schemas and NETCONF/YANG models step in to evolve things in the right direction. All this said, it’s a far cry from the programmatic access you are given once you step into the cloud.

From a configuration, operation, and troubleshooting standpoint, the cloud has a lot of roads to the proverbial top of Mount Fuji. Figure 5 shows the different the different paths available. You are free to choose the one that best maps to your skill level and is most appropriate to complete the task at hand. While Google Cloud has a CLI-based SDK for shell scripting or interactive terminal sessions, you don’t have to use it. If you are developing an application or prefer a programmatic approach, you can use one of many client libraries that expose a wealth of functionality. If you’re an experienced programmer with specific needs you can even write directly to the REST API itself. And of course, on the other end of the spectrum, if you are learning or prefer to use a visual approach, there’s always the console.

In addition to the tools above, If you need to create larger topologies on a regular cadence you may want to look at Google’s Cloud Deployment Manager. If you want a vendor agnostic tool that works across cloud carriers you can investigate the open-source program Terraform. Both solutions offer a jump from imperative to declarative infrastructure programming. This may be a good fit if you need a more consistent workflow across developers and operators as they provision resources

Putting it all together

If this sounds like a lot, that’s because it is. Don’t despair though, there’s a readily available resource that will really help you grok these foundational network concepts: the documentation.

You are most likely very familiar with the documentation section of several network vendor’s websites. To get up to speed on networking on Google Cloud, your best bet is to familiarize yourself with Google’s documentation as well. There is documentation for high-level concepts like network tier levels, network peering, and hybrid connectivity. Then, each cloud service also has its own individual set of documentation, subdivided into concepts, how-tos, quotas, pricing, and other areas. Reviewing how it is structured and creating bookmarks will make studying and the certification process much easier. Better yet, it will also make you a better cloud engineer.

Finally, I want to challenge you to stretch beyond your comfort zone. Moving from network to the cloud is about virtualization, automation, programming, and developing new areas of expertise. Your journey into the cloud should not stop at learning how GCP implements VPCs. Set long term as well as short term goals. There are so many new areas where your skill sets are needed and you can provide value. You can do it; don’t doubt that for one minute.

In my next blog post I’ll be discussing an approach to structure your Cloud learning. This will make the learning and certification process easier as well as prepare you to do the cloud Network Engineer role. Until then, the Google Cloud training team has lots of ways for you to increase your Google Cloud know-how. Join our webinar on preparing for the Professional Cloud Network Engineer certification exam on February 22, 2019 at 9:45am PST. Now go visit the Google certification page and set your first certification goal! Best of Luck!