Resisting the Urge to Innovate for the Sake of Innovation

So 05 Juli 2020 | tags: tech

I have been listening to a lot of tech-podcasts lately. The problem with tech podcasts is the same as with following trendy blogs. As a consumer of such media, I tend to find the new stuff totally awesome and I can't wait to try this feature or product at work.

Usually, this hype builds up to the point where I realize that it does not make any sense to use this new feature. While showering, I think of using this feature or new tech, but once I have time to think about everything I realize that things are the way they are because of two major reasons:

  1. Because they are legacy and everyone is used to them
  2. Because they are actually good for their use-case

Differentiating between the two is quite difficult if you are in the typical hyped up mindset after listening to a podcast. I often catch myself thinking that $technology would certainly improve upon things, but after thinking more about it, I see that it has just the same problems as our current solution or does not solve any of the problems our current solution is already solving.

So, before trying to innovate because all the cool people out there are doing it, try to reflect why the current solution is used and what the new solution would improve upon the existing one.

Some of the topics I am talking about:

  • Kubernetes: we don't have enough devs and do not need to scale to levels where we have to think about microservices
  • Hierarchical Loadbalancers: we don't need to scale this much. Our current hardware can easily handle everything.
  • Switching config management: We don't have enough resources to force this. We have been operating heavily intertwined where developers were always able to modify the configs. Ops was always there to fix things, but if a developer was up to the task they could always take matters in their own hands. Our current config management can already handle all the daily tasks we have. We will switch in the future as bcfg2 is running out of everything.
  • Infrastructure as code: We are not a cloud based organization. The university is largely federated, up to the point where we are doing PaaS, SaaS and IaaS (lite) depending on the customer. For our SaaS and PaaS solutions we already have a complete life-cycle management and config management, so there is no need for improvement. And why improve the IaaS if the customer is paying us to keep their stuff running? We will only step in if there is a security issue.

social