Yeah it's insane. But of course if scaling different parts of the application, I guess micro services are the way to do it. But otherwise one could scale the entire app by just putting more of the entire app on servers. No need for micro services. It just needs to be written to be able to listen to message queues and you can have any number of app instances.
Yeah I agree. With experience you know where to use it and where it really shines, and when not to use it because it will just make everything harder to reason about.
But a lot of devs are not that experienced when they make these decisions. All of us learn from mistakes, and those mistakes stay in the code base. :)
Yes but in practice, companies don't want to replace their entire tech stacks, and specially if it's a large company. It costs an enormous amount of money (because of the time and effort it takes) and means the entire company has to relearn how to work with that stack instead.
It's not impossible and it can happen, but in my experience from working at probably 20 companies now, there is almost always a strong resistence to change.
People don't even change their default search engine or browser most of the time.
I don't think people have a choice. If you join a company where they use kubernetes, you have to use that technology for everything. You can't escape the complexity even if you just want to make a simple program. It still needs to run in kubernetes.
Problem is that companies are using them for all scenarios. It's often their entire tech stack now, with kubernetes.
It's similar to the object oriented hype that came before it, where developers had to write all their programs in a way so they could be extended and prepared for any future changes.
Everything became complex and difficult to work with. And almost none of those programs were ever extended in any significant way where object oriented design made it easier. On the contrary, it made it far more difficult to understand the program since you had to know which method was called in which object due to polymorphism when you looked at the code. You had to jump around like crazy to see what code was actually running.
Now with kubernetes, it's all about making the programs easier to scale and easier to develop for the developers, but it shifts the complexity to the infrastructure needed to support the networking requirements.
All these programs now need to talk over the network instead of simply communicating in the same process. And with that you have to think about failure scenarios, out of order communication, missing messages, separate databases and data storage for different services etc.
