Kubernetes has complexity for a reason. It's trying to solve complex problems in a standardized and mature manner.
If you don't need those problems solved then it's not going to benefit you a whole lot.
Of course if you are using docker already and are following best practices with containers then converting to Kubernetes really isn't that hard. So if you do end up needing more problems solved then you are willing to tackle on your own then switching over is going to be on the table.
The way I think about it is if you are struggling to deploy and manage the life cycle of your applications... fail overs, rolling updates, and you think you need some sort of session management like supervisord or something like to manage a cloud of processes and you find yourself trying to install and manage applications and services developed by third parties....
Then probably looking at Kubernetes is a good idea. Let K8s be your session manager, etc.
There isn't any generation 4. The functionality of the software is ubiquitous by that point. Nobody cares anymore except when they absolutely have no other choice. By that point even if you generated a brand new implementation you would struggle to give it away unless it was just one small part of a new innovation.
It's normal and expected evolution of protocols and software.
Generation 1: New idea, new implementation. As people become comfortable with the new idea it gains in acceptance and hype. Try to keep it simple and fast, but it's a exercise in exploration and it gains technical debt faster then it gains new features.
Generation 2: Widespread acceptance and commercialization. Groups inside large corporations, and sometimes entire businesses, spring up around the new idea. They re-implement the idea to reduce technical debt and add flexibility. Features are piled on to make it marketable. Eventually becomes heavy and unwieldy.
Generation 3: Hype train dies down and people have learned what really matters and what really should be focused on. Third generation is lean, fast, and 'correct'. It becomes ubiquitous, people stop caring about it and people stop paying for it. It becomes just something that is always there and ends up little more then a building block for the next new idea.
> Honestly I think the future of mobile will just be... mobile websites.
This.
Having to install software on my phone to use a service is cringy as hell and is a huge red flag for me. Like when trying to order food from a restaurant or shop somewhere.
It's almost always going to be a automatic no. I just don't trust them. They always want permissions to access things on my phone, which is just pure nonsense.
It's going to take a while for businesses to realize that in order to get a wide audience for the software they are paying for the last thing they want to do is force people to jump through hoops in order to use it.
For every one of 'google maps' there is going to be ten thousand other apps that simply have no benefit from being 'native'.
If you don't need those problems solved then it's not going to benefit you a whole lot.
Of course if you are using docker already and are following best practices with containers then converting to Kubernetes really isn't that hard. So if you do end up needing more problems solved then you are willing to tackle on your own then switching over is going to be on the table.
The way I think about it is if you are struggling to deploy and manage the life cycle of your applications... fail overs, rolling updates, and you think you need some sort of session management like supervisord or something like to manage a cloud of processes and you find yourself trying to install and manage applications and services developed by third parties....
Then probably looking at Kubernetes is a good idea. Let K8s be your session manager, etc.