The word utopia was coined from Ancient Greek by Sir Thomas More in 1516. “Utopia” comes from Greek: οὐ (“not”) and τόπος (“place”) which translates as “no-place” and literally means any non-existent society, when ‘described in considerable detail’. However, in standard usage, the word’s meaning has shifted and now usually describes a non-existent society that is intended to be viewed as considerably better than contemporary society
I opened the article with the definition of “Utopia”, for two reasons.
Just like DevOps, people could have a better understanding of the original term — coined by Thomas More a long time ago. 2nd reason is that many of us think that implementing this badly define term would turn their companies into Utopian places.
What’s my angle?
My name is Yair Etziony; I am DevOps Lead Germany for Polar Squad in Berlin. What’s Polar Squad and what is our main business you might ask? We are a Finnish company with offices in Helsinki, Berlin, and Tampere. In Polar Squad, one can find some of the best people who are experts in the business of DevOps, we even sometimes claim to be the best DevOps company. But what is DevOps you might ask? Well, grab your self a nice cup of tea and let me tell you a story.
Historical Background
A long time ago, we used to ship and maintain our software in a different way. We used to install it on a hardware server, it sounds weird now when you can have as many servers as you want with a blink of an eye, but sometimes it took more than a month before we received those machines.
Some of the software was installed from CDs or disk images that were somewhere on a remote storage device. Writing software took a lot of time, and the developers used to send us the artifacts as binaries with some scripts around it. We used ancient methods such as V-Model and waterfall to work on software, and it was slow and far removed from being efficient.
But due to many changes in the way we think and work on software, we had to start to apply Agile computing to our processes; we understood that teams could release software that is better and in much smaller intervals of time.
Tools such as containers, infrastructure as code, version control, and the public cloud gave us better options to work in a fast, automated and reliable way.
Still, we had this problem between developers (those who write the code), and the operators (those who maintain the code).
Why, should you ask? Aren’t we all just one big happy team trying to win the same game?
By nature, an operator will always prefer the stability of his environment; he does not like it when his systems are unstable. On the other side, the developers will push as many changes as possible, since usually, they don’t have a responsibility for the systems. Of course, any change will increase the chances of instability.
All over the industrial world, there was a need for an Agile sysadmin or (drum roll) DevOps!
What is DevOps?
I think it’s not an easy definition, but many would agree on the following:
“An approach to producing software which prioritizes minimizing the cycle time from planning to release and back, through the process, automation, and collaboration.”
What are the benefits of using DevOps?
Improve the efficiency of your delivery process
Reduce time to the market
Bring people, process, and tools together
enable continuity in the entire delivery life-cycle
Some people use the “Calms” conceptual framework to visualize DevOps.
Culture — DevOps creates and encourages an environment where engineers are responsible for QA, writing and running their tests to get their code out to customers.
Automation — Automation is about creating reliable and efficient systems.
Lean — A lean process comes without the extra features that make no difference to the customer experience.
Measurement — Putting a focus on the effective metrics, that would lead the team forward.
Share — DevOps exists to bridge the gap between developers and operations teams. A big part of that process is to ensure shared responsibility.
What is Not DevOps?
DevOps is not bound to any specific tools or technologies. It’s not Kubernetes, serverless or cloud-native. You can be doing DevOps methodologies using those technologies, but they are not coupled in any way.
“But we have a great DevOps engineering team”
When I talk to customers and friends in Berlin and Tel Aviv about DevOps consultancy, I usually hear the following answer: “But we have a great DevOps engineering team”. That’s a great start, but may I say that what you most likely have, are some experts in CI/CD, infrastructure and automation. What you might miss is a more profound understanding of what we try to achieve when we use DevOps.
For example, if you have a DevOps engineering team in your organization, you most likely have another silo. They might use some hot new tech (hello Terraform, Kubernetes and Helm). Still, if they just build infrastructure for developers without so much of communication, then I would say — Those fine lads are not into the business of DevOps!
DevOps Engineer is a problematic role; I would argue that most of those DevOps engineers are mainly sysadmin or system engineers with some new tools (hello Terraform, Kubernetes, Helm). If you want to change the culture of your organization, why do you hire a team of sysadmins? I mean, I was a sysadmin, we are a grumpy bunch of coffee drinkers, but what does bash get to do with pushing a change in culture?
DevOps is about culture
But what is this DevOps culture? let us try and use the 3 Pillars of DevOps succeeds:
Collaboration and trust
Automation and measurement
Continuous improvement
If you ask me the 3 pillars are a good start for a DevOps culture for your organization. From all of those, most job offerings for DevOps engineers in the market point to only the 2nd statement.
To formalize the notion of culture, we can use one term that is barely used. It's a process or idea, that can help push the technical side to a better place.
One example is the term lead time which can be defined as “The latency between the initiation and completion of a process”. For example, the lead time between the placement of an order and delivery of new cars by a given manufacturer might be between 2 weeks or 6 months, depending on various particularities.
In the world software development, lead time means the time it takes from an idea or feature to be deployed to production.
Culture is not your friend!
Let me add that some factions in the DevOps movement are getting addicted to the cultural side of things and are slowly neglecting the technological side of the equation. As i see it, both sides need to be ready for the change, and the change should be understood by the management and the workers, if both are not committed and aligned on the DevOps transformation, it will fail.
Another goal would be to make developers take responsibility for their code. They should share the on-call duty with the infrastructure team (a new and better name of the good old grumpy sysadmin team). The people who should start and push this change can be DevOps experts, maybe even DevOps consultants.
Yeah, of course, some DevOps consultants can do lift and shift work (moving your old infrastructure to the cloud), but since we established some time ago, that DevOps is not coupled to tools, its sure ain't coupled with any cloud providers nor with Kubernetes. This line of work is more connected to being infrastructure or cloud experts and its normally done with some fancy tools (hello Terraform, Kubernetes, Helm). Lifting and shifting containers from here to the cloud is a damn fine job, it got some connections to the DevOps principles, using smart infra and tools makes things easy (not always cheap), but it's only half of the job.
Site Reliability Engineering and DevOps
Last but not least, Google had their own way of dealing with the same problems that DevOps wanted to solve. They called it Site Reliability Engineering. Using some very interesting concepts they were able to leverage monitoring and automation to become a somewhat more accurate tool.
For me, SRE is a well-defined part of the whole DevOps movement. Yet again, Google has very specific needs, the whole discourse they use is fitting their special needs. If you would just copy-paste their ideas into your organization without thinking about it, and doing some adjustments your SRE endeavor will fail.
But where the DevOps?
So i guess you ask, where is the DevOps? all those hot words you see when you talk about people like me? CI/CD, GitOps, Cloud Native, Infrastructure as code? Well, this blog spot might turn into a series and i would like to explain each and every one of them in person.
Do you need some help? feel free to contact me or anyone at our team at Polar Squad, Empathy is one of our values, and now might be a good time to start doing some first steps in the realm of DevOps transformation, feel free to drop us an email or Linkedin message! maybe we can help you, or guide you in the right direction.
Top comments (1)
Well, this blog spot might turn into a series --> Well, I already create a series about DevOps at here: dev.to/iilness2/how-s-devops-engin...
Bottomline is I agree with you in outline. Nowdays, Devops have so much meaning, interpretation, definition, etc. What I am afraid if this continues for a long time is Devops term will become the term to play down the role of other expertise without everybody feels the benefit from it.