Worked with k8s for like 6 or even more years, even used Docker Swarm, Rancher Cattle before. Right now working as IC software engineer, so I don't do much ops and infra. But for personal projects still using k8s a lot. It's kinda backed into my brain already and pretty easy to manage all my side-projects in one cluster. As for a day job I would also not use k8s for deployments when it's early stage project or small team working on it. Even if you have k8s skills it will be hard to find someone to replace you. It can easily become a nightmare when you are the only one that can make changes on infra or fix things. So the one and only k8s engineer get burnout or quits and then company has noone to replace him - project is dead. 😂
I just hope in the future more people learn k8s. I still think this is the best way to setup and manage infra. Software becomes completely independent from cloud providers and makes it easy to migrate between them or even migrate to your own metal.
I’ve found it doesn’t become independent. People implement Controllers that tightly couple the cluster to the Cloud provider - integrating IAM with K8s for example.
And about microservices... well... it's tricky. I prefer monoliths or large component separation like landing, api, app, worker, etc.... But sometimes microservices are helpful when completely rewriting old code in small chunks. It's best to merge them at the later stage after completing rewrite.
@@MichaelCrilly We usually used Vault so did not encounter this problem. We would only use managed services from cloud for db, mq and cache. If infra uses postgres, kafka, redis then it's pretty easy to migrate out. Actually, we also had whitelabel version that clients would take and deploy themselves. One single helm chart worked for all AWS, GCP, Azure & DO. It only required separate terraform projects for each cloud provider but those configs were small.
It all depends on the use case. Setting up a VM and doing a periodic snapshot does do the work. But setting up the VM (so you don't have to worry about updates) with Packer + deploying the code to it with Ansible (or any other config management) or having the code as a docker containers gives you slightly easier maintenance. Kubernetes outside of the additional tons of complexity gives you my favourite feature - it utilizes your VM (node) in the best possible manner. Of course if your developers are proper engineers not apes and they know how to handle memory and cpu utilisation. CI/CD can be a painful topic regardless which option you use. Updating a VM is a far easier than doing everything around kubernetes. But it depends - on the needs, scale and maturity of the organisation.
I understand that you want to insert yourself as a person into videos and not just have them be an information transfer but the emphasis on the coughing is very off putting
Microservices yes. All monoliths should be focusing on splitting services because different parts of the monolith may require or use more or less resources compared to each other. different message queuing needs, etc. so yes, split them out in micro services style and thence enable proper scaling and high availability with more attention to the parts that actually need is vs those that dont.. Kubernetes has always been no. I'm making 180k rn and mostly working with Consul and Nomad.
I think the point of not blindly going to Kubernetes is quite a good point. Many times a simpler solution works well enough.
Worked with k8s for like 6 or even more years, even used Docker Swarm, Rancher Cattle before.
Right now working as IC software engineer, so I don't do much ops and infra. But for personal projects still using k8s a lot. It's kinda backed into my brain already and pretty easy to manage all my side-projects in one cluster.
As for a day job I would also not use k8s for deployments when it's early stage project or small team working on it. Even if you have k8s skills it will be hard to find someone to replace you. It can easily become a nightmare when you are the only one that can make changes on infra or fix things. So the one and only k8s engineer get burnout or quits and then company has noone to replace him - project is dead. 😂
I just hope in the future more people learn k8s. I still think this is the best way to setup and manage infra. Software becomes completely independent from cloud providers and makes it easy to migrate between them or even migrate to your own metal.
I’ve found it doesn’t become independent. People implement Controllers that tightly couple the cluster to the Cloud provider - integrating IAM with K8s for example.
And about microservices... well... it's tricky. I prefer monoliths or large component separation like landing, api, app, worker, etc.... But sometimes microservices are helpful when completely rewriting old code in small chunks. It's best to merge them at the later stage after completing rewrite.
@@MichaelCrilly We usually used Vault so did not encounter this problem. We would only use managed services from cloud for db, mq and cache. If infra uses postgres, kafka, redis then it's pretty easy to migrate out. Actually, we also had whitelabel version that clients would take and deploy themselves. One single helm chart worked for all AWS, GCP, Azure & DO. It only required separate terraform projects for each cloud provider but those configs were small.
Very cool.
It all depends on the use case. Setting up a VM and doing a periodic snapshot does do the work. But setting up the VM (so you don't have to worry about updates) with Packer + deploying the code to it with Ansible (or any other config management) or having the code as a docker containers gives you slightly easier maintenance. Kubernetes outside of the additional tons of complexity gives you my favourite feature - it utilizes your VM (node) in the best possible manner. Of course if your developers are proper engineers not apes and they know how to handle memory and cpu utilisation.
CI/CD can be a painful topic regardless which option you use. Updating a VM is a far easier than doing everything around kubernetes. But it depends - on the needs, scale and maturity of the organisation.
Why do I have to do a 10 min job once manually when I can spend 5 hours automating it?
oh agree with the bandwagon thing there is a particular set of situations where kubernetes shines but it's overkill for a lot of use cases.
I am a nomad Fans 😜
so what your saying is I'm worth more because I run kubernetes at home :)
I understand that you want to insert yourself as a person into videos and not just have them be an information transfer but the emphasis on the coughing is very off putting
Microservices yes. All monoliths should be focusing on splitting services because different parts of the monolith may require or use more or less resources compared to each other. different message queuing needs, etc. so yes, split them out in micro services style and thence enable proper scaling and high availability with more attention to the parts that actually need is vs those that dont.. Kubernetes has always been no. I'm making 180k rn and mostly working with Consul and Nomad.
Kubernetes bandwagon lol