I'm going to voice an extremely unpopular opinion.
One that could even get me "cancelled"...
There are quite a few different research firms out there, and we all know the big names.
A thread ๐งต
When you peel back the curtain, it's typically not real research that goes into it.
It looks like the following at a high level:
- There's a paper that needs to be written based on demand.
- You pick X amount of vendors to go into the paper.
(cont)
- You chat with all of them for about an hour. They show you a PowerPoint presentation/sales pitch about the product.
- You take that and write about it.
So, in short, a lot of these papers that are written are nothing more than more marketing.
They aren't practitioner-led. They aren't engineering-led. They are a long-winded sales tool to hopefully get a product bought.
I believe the days of this type of "research" are going to be behind us very quickly.
We need industry-led research for organizations to make actual, valuable decisions.
Engineers need research that'll show them what platforms to actually use, and CTO's need research to show them the actual benefit.
There needs to be practitioner -led research. Research that comes from real data in the field.
There are too many platforms, tools, and products for engineers and CTO's to make decisions on based on more marketing papers.
From unit tests to mock tests to integrations tests and the list continues.
But with Kubernetes Manifests, there aren't a lot of tests going on.
A thread ๐งต
There's a lot that can go wrong with a Kubernetes Manifest which includes :
- Using out-of-date APIs.
- Policies that your organization set aren't being used.
- Bad practices used like using the latest version of a container image.
And when tests do occur, they aren't done in a repeatable process, which is a problem in itself.
There's a way to solve these issues, and that's by scanning Kubernetes Manifests.
GitOps is the equivalent of a Kubernetes Controller
A Kubernetes Controller, which runs on the Kubernetes Control Plane, ensures that the observed state of the cluster matches the desired state
A thread ๐งต
A Kubernetes Controller, which runs on the Kubernetes Control Plane, ensures that the observed state of the cluster matches the desired state
For example, the Deployment Operator (like a Deployment spec in a Kubernetes Manifest) watches fo ensure that all of the applications running as a Kubernetes Deployment are in the desired state
When you're putting any application on Kubernetes, you have to confirm a few things if you want a successful deployment.
A thread ๐งต
A few things to keep in mind are:
- Is the Pod healthy
- Is the Pod running as expected
- Does Kubelet know when to restart a failed/unhealthy container
- Should a Pod receive requests
- Should Kubelet start accepting traffic
and A LOT more
Check out my latest video on how you can implement the above with Liveness and Readiness Probes