How NGINX makes my life, as an SRE, easier!
In the past years, as an SRE (Site Reliability Engineer), I had to solve many problems. For some of those problems I could rely on a reliable and versatile tool also known as NGINX. Coming from a network engineering background, I have worked with many IT Solutions from a variety of different vendors. Back then, all large enterprises were using vendor specific appliances. Each appliance adds its specific functionality to the network stack. At first glance, this seemed to work great. This way to manage networks was wildly perceived to be “The Way.”
Purchasing appliances that each solve a part of your problem might seem great from a managerial point of view. You can tick all the right boxes when it comes to your requirements, and you can more easily predict the costs for many years to come. But what was it like from the Network Engineer point of view? What was it like to manage a variety of proprietary technology appliances across the globe? In my experience, it was initially great. It allowed me to learn a lot. This soon changed as I found myself stuck. It took me a while to find the time to step back and look at the whole picture. Then I realized that what we were doing was counterproductive. We were only applying and re-applying duct tape instead of seeking permanent solutions to a wide range of issues that were causing outages. Stuck as a firefighter who is continuously putting out fires.
This realization prompted me to look for different ways for managing my day-to-day work. My aim was to put out these fires permanently. I did my reconnaissance and read about SRE by Google. I was inspired to find out I was not alone in my pursuit to permanently put out fires. Or even better, preventing them from happening in the first place! No more 3 AM outage calls that could have been prevented. No more 12-hour working days to try and fight fires whilst (understandably) obliging to business demand. Together with the DevOps movement and its best practices, SRE principles allowed me to discover who I truly was. It allowed me to see that reactively solving a problem quickly does NOT make me a good Engineer or a company Hero. A true company Hero puts all the effort into proactively preventing problems in the first place.
One thing that we as SRE’s find ourselves doing is eliminating toil. Toil usually consists of boring, manual and mostly repetitive work. Time spent on toil prevents you from doing other work. I initially tried to work with vendors, asking them when they would allow for configuration over API or to assist in allowing me to use tooling such as Ansible. To no avail. Meanwhile, I found myself leaning more and more towards tooling that allowed me to automate the hell out of IT. NGINX was one of those tools for me! Some people might frown upon the statement that NGINX is a “Swiss Army Knife.” All because “you can do a million things with it.” But to me? That is the source of its power! Think big, act small. Even if NGINX is considered a “Swiss Army Knife”, it does not mean you have to pull out all the tools at the same time either.
NGINX was not a hardware appliance that needed to be requisitioned, racked, patched, tested and finally used. It had been gaining traction over the years. It was a software-based toolbox that allowed me to create business value whenever needed. And the only thing I needed to be able to utilize NGINX at the time was a virtual machine. Using the fluidity of virtual machines, I was able to build and subsequently tear down NGINX load balancers, webservers or reverse proxies at a fast pace. Obviously, NGINX does not solve all the problems you encounter as an SRE. But for me, NGINX was one of the first tools that allowed me to automate toil. Allowing me to focus on the more complicated issues and innovation instead.
NGINX has been around for a while. Long before I even knew it existed. Its adoption has grown since its birth in 2004. Since then, NGINX offered commercial support starting from February 2012. And published a NGINX Plus version available by paid subscription in August 2013. Most websites across the world use NGINX and many different vendors rely upon and have built their own solutions on top of NGINX. See the screenshot below as an example when it comes to widely adopted API-GW solutions.
In 2019 NGINX was acquired by F5. Many believe this to be the end of Opensource NGINX, but this was not the case. NGINX has been able to diversify even further. One example is the birth of NGINX Unit, a polyglot app server, a reverse proxy, and a static file server, available for Unix-like systems. It was built by NGINX team members from scratch to be highly efficient and fully configurable at runtime. Other examples are NGINX Ingress Controller, a widely used Ingress technology with more than 50 million Docker Hub pulls. It is high‑performing, scalable and secures modern apps in production.
As you might have noticed by now, NGINX is a little bit special to me. As for me, it is not just an abstract proven technology. It opened my eyes! There were other ways of doing things. It allowed me to get comfortable with the thought of software defined infrastructure (SDN) and the use of opensource solutions in Production. Today NGINX allows me to bridge gaps within hybrid environments. From monoliths to cloud, from hardware to software defined networking. Utilize NGINX to beef up your network security by utilizing JWT tokens to authenticate your users, upgrade to TLS 1.3 or use it as an API-GW. Either use all or some of this green Swiss Army Knife called NGINX.
What is in the future of NGINX? I hope to see further integration of the NGINX API and to be able to write NGINX configuration files using .yaml would be great. I hope this blog has piqued your interest in NGINX. If so and you would like to talk or discuss NGINX, feel free to give me a call. Because this is the way!
Wil je meer weten over het onderwerp SRE? Jan Buurman en Benoit Schipper schreven een boek over SRE voor de Nederlandse markt. Bestel hem hier gratis!
