If you want to be successful in the cloud-native world, here's what you need to know:
- Cloud and virtualization
- Operating systems and networking
- CICD
- Coding
- Security
- Application development workflows
- Architecture
A thread 🧵
- Troubleshooting
- Containers and orchestration (Kubernetes or another orchestration system)
- Observability/monitoring
Yeah, it's a long list... let's break it down.
Cloud and virtualization are around the idea of running infrastructure workloads and services that aren't purely bare-metal. Virtualization like ESXi or Hyper-V is great, and a lot of big organizations will still have this. Cloud is also important (cont)
(can't go wrong with knowing AWS, GCP, and Azure), especially in the startup space. New companies aren't buying datacenter space anymore unless it's needed.
Operating Systems and networking are at the forefront of everything you do. If you're deploying a server, you're working with an OS. If you deploy a Kubernetes cluster, you're working with an OS. (cont)
If you're doing literally anything behind a keyboard, you're working with networking. You don't have to be a network expert, but go through the CompTIA Network+ just to get the knowledge (you don't have to actually sit for the exam).
CICD is all about taking an application or infrastructure/service and deploying them. First, you have your CI process, which packages up your code and turns it into an artifact. This code can be Terraform, application code, anything. Then, it gets deployed to it's destination.
To get by in today's cloud-native world, you need to know how to code. You don't have to build the next Twitter, but you do need to know how to automate processes. Go, Python, and Terraform are good choices.
If you aren't thinking about security when you first do something, you should. Good security practices are the make or break between an organization getting hit hard and mitigating as much risk as possible.
You don't have to be a principal developer, but you should understand application dev workflows. Understanding how and why an app is designed in a certain way helps you troubleshoot it and deploy it later.
Architecture, as in, understanding the "how" something should be built before you build it will save you a ton of time in the development phase.
Troubleshooting will be a good portion of your job. That doesn't mean you have to be SSH'd into a box. Troubleshooting could be "how can I automate this workflow". Figuring stuff out is our jobs as engineers.
Containers and orchestration are increasing in popularity for a good reason. Making deployment environments and deployment times faster, along with a smaller footprint and giving developers an easier way to test their code is key to a future of success.
Observability, as in, logs, traces, and metrics, will be the key to your troubleshooting if something ends up happening in your environment. Without a proper observability strategy, you'll be grasping for straws.
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.
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