DevOps Engineer "is a" pipeline Engineer

A cloudnative SRE’s take on DevOps Engineering

DevOps Engineer "is a" pipeline Engineer
Tldr
A Software Engineer is an application engineer. Likewise, a DevOps Engineer is a CICD pipelines engineer. A Full Stack Engineer is probably both. But, one got to be crafty in either one, if not both. Have a nice day!

And, I repeat: a DevOps Engineer is a CICD pipelines engineer. The craft relies on how an application is continuously integrated and deployed continuously. Like they say, DevOps is not about mastering a variety of pipeline tools and frameworks out there in the market; it’s all about culture, agility & revenue, blah, blah, blah, blah.

But, we need tools to build a house, not just a map or a concept, and that lays a foundation of the culture of people dwelling there. The DevOps tools and frameworks define a pattern and hence building a culture. If there was no “iPod”, we would’ve probably never had the “iTunes” culture. Same with the app store culture enabled by the smartphones after the “iPhone”. Side note: I am an Android fanboy, or at least used to be at one point in time. Now, I just use Pixel phones out of habit!

What goes into a DevOps Pipeline should only aim to reduce (if not, completely remove) the friction between traditional Devs and Ops, potentially by bringing SLI/KPI to the table, ie. “Let's review the metrics for both infra & application before blaming one or consequently improving the culture.” Main reason for the friction: Humans and Human emotions. Let’s get that out, we have the DevOps culture enabled.

Now that we have an OpenGitOps standards overseen by a GitOps Working Group, I’d like to call them a “GitOps Engineer” instead!

to summarize in {{ GoLang }} syntax

DevOpsTools := [3]string {
    "frameworks to foster/enforce DevOps culture and automated security",
    "automated pipelines (less human factors and human emotions)",
    "enable GitOps"
}

Observability := [2]string {
    "gather mertics around the infra & apps -to- verify that friction between dev and ops is infact lowering",
    "simultaneously improving the UX & increasing the revenue"
}

Metrics := map[string]string {
    "SLI" : "set up service level indicators to analyze",
    "SLO" : "what's our SLI objectives and what should be a happy customer's!",
    "SLA" : "how are we delivering to our customers"
}

SRE :=  [3]string {
    "is a DevOps Engineer at the core",
    "brings observability to the metrics gathering infra events, app logs, and metrics for all",
    "proactively, enhances the site's reliability"
}

CPT := map[string]string {
    "Cloud Platform Team" : "cloud version of traditional Infrastructure teams [ICS]",
    "Cloud Operators" : "are the new System Administrators",
    "Cloud Engineer" : "is the new Systems Engineer",
    "IAC" : "bash scripts"
}

On that note:

💡
“Developers are always developers”. Now! they may be a full stacker ones, mainly due to a plethora of DevOps frameworks available in the market or a little help from their DevOps Enablement teams and/or so called “Internal Development Platforms” built by their IDP Engineering teams and/or Networking & Security Engineers [NoC/SoC]. And, kinda relevant here(maybe): Containerization is simply “running microservices in their own containers, and should be shippable as a container”. And, hence "containerization" is a required component for the CloudNative Applications.

fully opinionated by,

Mr. Pramode