Kubernetes or React — Which is Complex?
I know what you are thinking — WTF — this is not even a valid comparison. It’s like comparing apples with oranges. And that is my point exactly.
Let me provide some context to why I am even writing this post. I was recently a part of a panel at my workplace to determine which of the many teams (who work for different customers) have been doing a fantastic job of delivering the goods. Kind of like a rewards and recognition program. There were various parameters on which we were evaluating them — one of them being the tech stack that the team was working on and their demonstration of expertise on that tech stack. So among the teams that we were evaluating, of interest to this blog post are three —
- A team of green front-end engineers who built a fairly non-trivial UI with constantly changing requirements (customer had to demo it at a conference and UX and design were constantly in flux — the funding to the project hinged on how well the demo went) in React and Redux.
- A team of senior front-end engineers who built a significantly complex UI with interactive visualizations (Angular & D3) and had been delivering on time every time for 9 straight sprints without piling on any technical debt. (This is as much a testament to our customer’s understanding of agile methodologies as it is to our engineer’s technical forte).
- A team of senior QA engineers who came up with a way of automating the testing of container resiliency on Kubernetes (pretty cool, innit?)
No prizes for guessing — the third team scored the maximum points for the tech stack and the demonstration of expertise on that tech stack. Also, you guessed it right, the teams that worked on the front-end scored significantly less on this parameter. But why?
I get that Kubernetes is a beast in itself and it requires a rather steep learning curve. It’s one thing to deploy a pre-baked nginx container image returning a ‘Hello World’ page. It is a completely different thing to put your neck on the line while testing a production cluster. Understanding containers, scheduling, discovery, micro-services, a bit of networking, etc. I can see how it can get complex.
I can also see how modern front-end engineering can be complex. It’s one thing to create a hello world app using React. It’s a different thing trying to build a maintainable, performant, responsive front-end using React. You’d need to have a decent understanding of at least webpack, babel, functional programming, state management, component oriented design and whatnot (not to mention browser and network fundamentals).
But can’t you just bootstrap a react app with create-react-app you ask? Well, you can bootstrap a kubernetes cluster on any of the cloud providers as well. But with React/Angular all you gotta do is call some APIs. Kubectl — hello! But doesn’t kubernetes have a higher business impact because — you know — higher utilization of hardware resources, more efficient release cycles, etc? It definitely has a business impact, won’t argue with that. There have been entire start-ups that are catering to making kubernetes adoption easier. But you can’t discount the business impact of a well-engineered front-end. Your customers see your front end. For most users (who happen to be non-technical and don’t give two hoots about which database you use, which front-end framework you pick or how mature your CD pipeline is), your entire app/business is the web/mobile front-end.
I’m not trying to start a flame war (the javascript world has enough of those already) neither am I trying to make little of other parts of the tech stack. What I’m trying to convey is that each specialization of software engineering has a part to play. Just because someone works on kubernetes and deals with containers does not mean their role is somehow more technical than a front-end engineer’s role.
We (we here refers to the collective — in my experience) inherently perceive DevOps skillset as being ‘cool’ and FrontEnd as being ‘meh — can be picked up anytime I want’. This perception has to change.
Bottom line — any tech/tool/discipline can be as complex as you want it to be. Peace out.
