Working with Software Engineers as DevOps/Cloud/SRE Engineer: Technical Words

Today, I’ll be writing to feed the temptation of always trying to correct technical terms whenever I jump on cross team calls; sprint planning, show and tell, reviews, working session et al. As a DevOps Engineer, and generally as a software engineer that has worked in cross teams, there is need to tone down the use of technical words whenever you’re in a joint meeting. Which can be challenging on its own, but having to listen to someone who isn’t grounded in your field use the wrong technical words? Now that’s challenging. Challenging because as a team geared towards continuous learning, I always feel it is my duty to correct the person. And for posterity sake, I don’t want the person passing the terms to other team members.

Before I continue, I’d like to say I’m also guilty of these things from the core software development perspective, especially when it comes to Language domain. One time I kept asking a Java developer to use Struct or Channels because well, I had just finished a spell in Golang based company. Another time I pronounced Chai (A nodejs testing tool originally pronounced as Kai) as Chai, a Nigerian slang that is somewhat synonymous to, “I am finished.” This and many more that I may not have an idea of. But scratch that, if I’ve ever worked with you, you can write your version of this article. Going forward, I’d be quoting sentences that’s been used by team members, then go ahead to explain why it’s wrong. Oh! I’ll try as much as possible not to use many technical words.

“We need those Docker Images in our elastic container registry.” It is Container Image, not Docker Image. Docker is a container build tool, which happens to have a remote/private image repository for storing images. First off, for this team, there was nowhere in our development cycle that we were using Docker. We had two different build tool, Buildah and Kaniko, and we stored our images in Google Container Registry. Even the Kubernetes cluster wasn’t using Docker as container runtime. A lot of people tend to miss these things up, but again, it is container image.

“We will use Terraform to deploy the application.” Terraform is an IaC (Infrastructure as Code) tool, not a CD (Continuous Deployment) tool. Like, it has absolutely nothing to do with the codebase of the application itself. Well, except you are in an immutable deployment environment with a bunch of EC2/GCE instances to manage. Which was not the exact case for this scenario. Terraform is a tool used to provision infrastructure, mostly in the cloud. It does not deploy your application — as in software code — but rather provisions the resources you need to deploy it.

“It is severless, it should scale effortlessly.” This one right here was in a COE meeting for scalability on RDS Aurora serverless. Yes, Aurora serverless scales automatically, but you’ve got to know that before it scales, it finds a scaling point. And if after 5minutes, the scaling point is nowhere to be found, it times out and remains at that same capacity. I’ll write more about my experience with Aurora Serverless in coming days, let me just say that serverless computing is not magic, they are basically servers that you just don’t have access to, slapped with sexy names.

“CI/CD is almost similar to GitOps.” No, you didn’t! One of the most tasking thing I have ever done is setting up GitOps in a Kubernetes environment. Like I did it, and I knew straight up that it was not in anyway CI/CD. GitOps is basically saying, “Yo! I want every single thing in code. Your resource, your identity access management, your network, your application, your metrics, logs, everything… I want them to have a single source of truth.” CI/CD on the other hand is like, “Yo! I really don’t care where you put other codes. Just come, I’ll test you and if you good, I’ll deploy you.”

“We need the DevOps guys to help us out with AWS Firehose and Glue[Insert any cloud resource you have never worked with]. It is an emergency.” AWS has over 200 service offerings. And honestly, I’ve not used up to 50 of these services. While I might seem to be the Cloud guy, you still need to give me time to actually read the documentation of a service I am not familiar with, even if I worked with it previously.

Okay, it is getting too long. I believe I have treated the top on my lists. Would you want to add to it? The comment is opened…