I think the distinction ought to be made between ‘Using Kubernetes’ and ‘Setting up your own Kubernetes cluster’.
The former is pretty easy, and depending on your choice of provider can make deploying complex applications more straightforward than it would have been in the past. You get some degree of HA/redundancy for free by going this route.
As for setting up and maintaining your own cluster, that’s a totally different proposition, Kubernetes itself is a beast, and deploying and maintaining it will take up a heap of your time.
I completely agree. For developers, using kubernetes makes deployment and configuration a (relative) breeze , but maintaining and upgrading a kubernetes cluster is just as much work as maintaining physical servers, and it’s not always obvious what to do as kubernetes has SO MANY moving parts (for better and for worse).
On the other hand, many developer forget buildpack based deployment (aka heroku-like) that makes it even more a breeze.
I think they mostly forgot about it because it’s not hype anymore… It offers less flexibility, but offers great comfort that is very valuable to many projects. In addition, you’re not that tighten to the provider since buildpacks are widely supported.
I think both has merits. There are start-up costs associated with both (creating the definitions, what goes where, lots of YAML for kubernetes), but once it’s running it Just Works™.
The upside of kubernetes, in my personal opinion, is that you can define a lot of things together (services, containers/pods, disk provisioning, etc.) in one push and expect it to work given the cluster has enough resources. Buildpacks are focused more on a single application.
I’m not familiar with deploying to Heroku, but I recently worked on a small app that started life on Google App Engine, which I believe deploys similarly?
The issue we ran into was when we wanted to run up external dependencies that the provider didn’t offer natively, a Redis instance to support a Celery worker for example. It’s these sort-of-external deps that kubernetes makes really easy to deploy.
Can someone explain to me why this article is getting so many upvotes since this is basically only telling to think about before introducing kubernetes?
The article links to another article of hers, Building Container Images Securely on Kubernetes, which is way more interesting in my opinion.
Basically, having one of the highest authorities on containers say that people are overthinking how they approach containers is a nice thing to hear, particularly as people have to fight overgrown infrastructure.
Although I’m about separation architectures, I did like her write-up listing many security practices that container tech are using with a nice, little chart. I saved it in case I ever wanted to follow-up on them to use as extra layers, do work improving them from high-security perspective, or (most likely) share them with anyone using containers who could benefit. Just an example supporting your point.
I would like to read more about creating your own derivations. Preferably with some good examples of nontrivial stuff, such as adding static assets and configuration files.
I think the distinction ought to be made between ‘Using Kubernetes’ and ‘Setting up your own Kubernetes cluster’.
The former is pretty easy, and depending on your choice of provider can make deploying complex applications more straightforward than it would have been in the past. You get some degree of HA/redundancy for free by going this route.
As for setting up and maintaining your own cluster, that’s a totally different proposition, Kubernetes itself is a beast, and deploying and maintaining it will take up a heap of your time.
I completely agree. For developers, using kubernetes makes deployment and configuration a (relative) breeze , but maintaining and upgrading a kubernetes cluster is just as much work as maintaining physical servers, and it’s not always obvious what to do as kubernetes has SO MANY moving parts (for better and for worse).
On the other hand, many developer forget buildpack based deployment (aka heroku-like) that makes it even more a breeze.
I think they mostly forgot about it because it’s not hype anymore… It offers less flexibility, but offers great comfort that is very valuable to many projects. In addition, you’re not that tighten to the provider since buildpacks are widely supported.
I think both has merits. There are start-up costs associated with both (creating the definitions, what goes where, lots of YAML for kubernetes), but once it’s running it Just Works™.
The upside of kubernetes, in my personal opinion, is that you can define a lot of things together (services, containers/pods, disk provisioning, etc.) in one push and expect it to work given the cluster has enough resources. Buildpacks are focused more on a single application.
I’m not familiar with deploying to Heroku, but I recently worked on a small app that started life on Google App Engine, which I believe deploys similarly?
The issue we ran into was when we wanted to run up external dependencies that the provider didn’t offer natively, a Redis instance to support a Celery worker for example. It’s these sort-of-external deps that kubernetes makes really easy to deploy.
I think it’s similar yes.
On Heroku you have the add-ons that provide many other softwares that you can use along your instances: https://elements.heroku.com/addons
The main problem with Heroku that people have is that it become very expensive very quickly compared to other solutions.
Can someone explain to me why this article is getting so many upvotes since this is basically only telling to think about before introducing kubernetes? The article links to another article of hers, Building Container Images Securely on Kubernetes, which is way more interesting in my opinion.
Edit: formatting
The author is respected for their knowledge in this area and has done a lot for the community.
Basically, having one of the highest authorities on containers say that people are overthinking how they approach containers is a nice thing to hear, particularly as people have to fight overgrown infrastructure.
^ This
Although I’m about separation architectures, I did like her write-up listing many security practices that container tech are using with a nice, little chart. I saved it in case I ever wanted to follow-up on them to use as extra layers, do work improving them from high-security perspective, or (most likely) share them with anyone using containers who could benefit. Just an example supporting your point.
You might not need Docker, either? NixOS!
On Atlassian Marketplace, we use both!
I would like to read more about creating your own derivations. Preferably with some good examples of nontrivial stuff, such as adding static assets and configuration files.
Not sure why static assets and configuration files are non trivial? But sure, I really want to write about nixos tbh.
I feel like there’s the opportunity for a trolling flow chart where almost all branches lead to “Nope. You really don’t need k8s.”