If you’re like me and have spent the last 20+ years building and supporting enterprise networks, then what I’m about to say isn’t a surprise. The tasks assigned to us in our role as network engineer can make it hard to stay afloat. There are projects and team meetings to attend, global networks to support, and routers and switches to configure. Not to mention the “vendor‑neutral” environments with all of their nuances and CLIs. It’s a full‑time job and depending on the stability of your infrastructure, it can certainly spill over into long nights and weekends.
Now for the kicker. We also have to keep abreast of technology trends that relate to our network and career goals. Enter the application programming interface (API), which is supposed to make your job easier through automation and rapid presentation of information from multiple data stores. The API is changing the way network engineers think about their jobs, from day-to-day management to network architecture decisions. Where do you find the time to learn this tech when you’re already pressed for time, and where do you begin?
The Language of Programming
The API is essentially a way for applications to communicate with each other. From simple things like checking the weather app on your Android phone or placing your dinner order on the touch screen at your table, the interaction driven by the software is using API calls. In the network disciplines, you’ve likely heard of SOAP, RPC, and REST (or RESTful) APIs, so the concept likely isn’t new. The way we need to think about them is.
As a network engineer, you don’t necessarily have to write API procedures – unless you’re in a NetDevOps role – but you do need to understand how they operate and why API calls are so important. The job of the network engineer is to provide application access and move data from one side of the world to the other in the most efficient way possible. This becomes even more important when you deal with real‑time APIs.
Just as the name implies, when these APIs are called, they have to deliver the answer to the request within milliseconds even when the data in the answer comes from multiple platforms on the backend. A very familiar example is a ride‑sharing application. When you consider the intricate interactions between all the moving parts – dynamically generated maps, overlays of traffic congestion, information about the driver and passenger, real‑time tracking of their current locations, and so on – you may be amazed that the system works as well as it does. It’s all powered by real‑time API calls and they’re critical to meeting end‑user expectations. Without them, the driver and passenger may miss each other, even though they are on the same block.
Don’t Trip on Packets to Make a Call
With this type of application functionality, consider how complex and tightly controlled network services need to be. Latency across the network – Internet and corporate network paths included – becomes increasingly important. Network engineers and architects have to design the data and control planes to minimize delay and convergence time so that the APIs can be processed and delivered immediately.
In another blog post, NGINX recently discussed the challenges of API integration. Depending on your business requirement for real‑time data retrieval, you may get away with API call‑processing times of 50–60ms; but what if your application needs 40ms? How can you meet that requirement? Your challenge as a network engineer is to (a) work with your business units to figure out the latency requirements for the application system, including the overlooked API, and (b) move that data as quickly as possible in a repeatable, supportable, and monitored way.
This means that you have to become familiar with technologies like API controllers and gateways so you can gain visibility into how APIs operate. The controller secures, analyzes, and reports on (among other things) the different components of your API infrastructure. Leveraging the API gateways, the controller can direct the programmatic calls to a variety of facilities from on‑premises data centers to multi‑cloud availability zones.
If you find yourself working in an environment that is beginning to develop business applications that use APIs, and you’re unfamiliar with the technology, it’s time to get started. But, where do you start learning, and how do you carve out time from your already packed schedule?
Gotta Start Somewhere
If you have never worked with an API, start with some hands‑on experimentation. Many modern network vendors include an interface to programmatically grab and post data. Use a tool like Postman to help you learn-by-doing the underlying technology you support for your business units. I don’t suggest making any PUT calls to a production database, but a GET can give you a sense of accomplishment when the expected values are returned. Better yet, try mocking up systems in a lab environment, especially if you’d like to avoid being involved in a “resume generating” event.
Next, really dive into the language of coders. You don’t necessarily need to run out and learn Python, but start to learn the terms used in common speech. Like learning a foreign language before going to visit that country, this means you can communicate with those in the know. You’ll be able to ask questions and show your peers that you want to be better at your job by understanding theirs.
Finally, read every vendor whitepaper you can on the subject. It’s becoming well known that all businesses are becoming “high tech” to one degree or another. What used to be a ledger entry now requires systems, networks, and applications under continuous development to meet increasing user demands. Vendor papers can introduce you to the concepts, give you an understanding of proper deployment, and when you’re ready, help you move into advanced methods. Think of this as semi‑free training. It’s free because the OEM wants its customers to understand its products, but it isn’t free because it takes your time and willingness to learn.
There are several resources NGINX provides that I recommend. O’Reilly and NGINX teamed up to produce API Traffic Management 101: From Monitoring to Managing and Beyond by Mike Amundsen. This book is an excellent 83-page primer for APIs. For many network engineers, this book is just the resource to get you into the pool and it is a smaller time investment.
I had mentioned all of the time constraints earlier in this write‑up. The enormous pressures on not only network engineers, but throughout all IT operations, is a very real issue not likely to be fixed any time soon. It’s easy for all of us to grouse about not having time to do something. One excuse I used to use was, “Sheesh, I’ve already been at the office all day. The last thing I want to do is stare at another computer or book about computers tonight”. Shifting your perspective to make the time commitment to learn, even when the excuses are yelling at you to quit, will pay dividends over the long run. The hard work up front means you can lighten your load through understanding, and maybe later on with a few scripts.