The Barrier Between JavaScript Software Engineers and Network Engineers is Broken
When a browser requests a webpage that needs JS scripts to run properly as designed, the host (datacenter, nodes, clusters of web servers, CDN) receiving this request will serve these JavaScript files.
The smart owner of a large-scale web application knows, at that time that these JavaScript files have been requested, the version of the browser that requested them, and the traffic load and pattern that these JavaScript files could probably incur in the next following seconds. Because each of these JavaScript frontend files has a specific traffic pattern that is a function of the number of users and the frontend features that they are assuring. Then the large-scale web application owner could provide this expected traffic information to the network engineering team managing the software-defined network that is supporting the traffic of this web application. They are then able to input these expected traffic data into the software-defined network management API and automatically get the network reconfigured to support efficiently and costlessly these expected incoming and outgoing traffic.
This loop of JS file requests, traffic historical and predictive information sharing and network reconfiguration happens in a matter of seconds or microseconds. It is a loop that never stops making the software-defined network topologically flexible, dynamic and predictive because at each time T, the network engineering team will know the network topology, configuration, and scale that will be needed at T+1.
Another example is when you develop and operate a large-scale web application based on many microservices as backend and many UI event-driven components as frontend. At both the frontend and the backend levels, routing becomes a key lever for your large-scale application to work not just correctly but also faster.
For the frontend part, solutions like Redux and MobX are helping frontend engineers tackle the intercommunication of frontend components by leveraging the DOM and JavaScript engines like V8 or Chakra.
For the backend side DevOps, backend engineer and database engineers are relying on solutions like Kubernetes, NoSQL, Node.js, and others for fragmenting the operational features of the backend stack in small and independent services hostable into a single virtual or bare metal server that has the required amount of computational resources, memory, and storage to run the service. What large-scale intended software engineers, developers, and managers are missing is the important part of network infrastructure, this piece that glues the frontend and the backend and also each microservices all together making them communicate smoothly and transparently through well established or custom network protocols.
The openness and programmability of switches (an example of usage of programmable switches here) and the revolution of software-defined networks put again network infrastructure at the core of making large-scale web applications faster and cheaper to operate at scale. It is now not imaginable and recommendable to design and develop your frontend solution without caring about the routes that the network packets that your frontend will take to reach your backend and how these packets will be processed by the frontend of your network infrastructure in order to make them flow faster the microservices that should process them. Network engineering is at the intersection of backend engineering and frontend engineering and could now be used to make web applications easier to scale and faster. If you want to develop and operate hyper-scale web applications you now should care a lot about network engineering.
These two scenarios above show that the barrier between JavaScript software engineer and Network engineer is broken for all kinds of client-server applications and this is more true for large scale client-server applications for which the application of this traffic pattern and prediction-based network could allow save a huge amount of hosting cost and make the underlying web application faster.
Even if cloud solutions like Microsoft Azure and others make the network stack transparent for the frontend and backend engineers, the reality is large-scale web applications should be engineered right at the beginning with software engineers and network engineers working hand to hand.
I hope that the marketing team also will be involved at this early stage because how you will be cleverly engineering your flexible large-scale application could be narrated with interesting stories that the marketing team could use to make it adopted by tech enthusiasts like me. These stories will narrate how you have built such a flexible and large-scale web application with such dynamic and mutable software-defined network by leveraging the power of team cross-functionality.
If you are a frontend or cackend engineer, it’s time to stop ignoring network engineering because if the application you are building or that you have already built is largely adopted you will for sure face issues at the network stack level due to the scale of traffic and you would have to reengineer both your code and infrastructure like what almost every startup like LinkedIn, Twitter, Facebook did once they got millions of users.
Network engineers have made huge progress by using your skill (software engineer) and by leveraging the revolution of infrastructure virtualization and cloud computing (Kubernetes) for developing software-defined network operating systems. It’s time for us, software engineers, to help these network engineers improve these Network Operating Systems (NOS) that they have developed and use them for making our web applications large-scale-ready by design by getting network engineers involved right at the beginning of our web application project. Because, as I have said in my past article, frontend speed is the next thing and the same is true for the backend.
Please don’t forget your marketing team.
More content at plainenglish.io. Sign up for our free weekly newsletter. Get exclusive access to writing opportunities and advice in our community Discord.