You can't just rename your IT Ops team and call it DevOps
datree.io
datree.io
I've upvoted bad articles because the discussion they triggered was very interesting.
"Why isn't this a blog post?!"
Someone writes a short blog post, and...
"That was basically a verbose tweet."
️
No, sorry. They were sysadmins. DevOps is valuable role, and I'm glad there's a focus on supporting developers and their needs, and in empowering developers to manage their own build and deployment infrastructure. In a larger organization, having a dedicated person or team working closely with developers on software build, test, and deployment automation is great.
But if your job is maintaining production hardware, network, operating system, DNS, SSL certificates, firewalls, backups, etc., then you're a sysadmin. It's not a pejorative term. In a small organization, or within a team, that may be combined with a DevOps role. You may even have one person who maintains all your infrastructure for production and development, and even doubles as a developer. That still doesn't mean you label the entire role DevOps.
I was hired as a dual Sysad/developer years ago as an explicit DevOps role (before devops was a thing)
The team (telecoms billing systems) was also uncertain that the actual ops team could provide the required service.
If you're working with Linux systems and automating stuff, make yourself a favor and call yourself a DevOps.
Whether you want it or not, sysadmin is left to designate the low end of the market, namely desktops and windows administration work, sometimes all the way to helpesk. Devops simply evolved as a separate term to designate the higher end of the market around linux and automation.
Maybe in the silicon valley every company is a tech company looking for linux sysadmins and developers, but in the rest of the world "sysadmin" will usually get one into windows or low end roles.
(In fairness, I think Google brought this on themselves by reusing SRE as both the job title and the philosophy.)
Sorry despite what IT Managers and HR would like to believe, DevOps is not a role at all, it is a management style.
DevOps is an Organizational Structure, no one should be a "DevOps Engineer" or anything like it.
DevOps teams can have SysAdmins.
The word “irregardless” also got misused long enough that it became acceptable.
irregardless irregardless /ˌɪrɪˈɡɑːdləs / ▸ adverb non-standard regardless: the photographer always says, irregardless of how his subjects are feeling, ‘Smile!’ irregardless, the song is a fine piece of work. – ORIGIN mid 19th century : probably a blend of irrespective and regardless. Irregardless means the same as regardless, but the negative prefix ir- merely duplicates the suffix -less, and is unnecessary. The word dates back to the 19th century, but is regarded as incorrect in standard English.
Why not? What should you call someone who spends most of their time writing code to do with CI/CD, infrastructure provisioning, logging/alerting etc.?
Most sysadmins focus on keeping things running. They are usually taxed to the point that they don't have the luxury of sitting around and writing code to be more efficient.
System Administrator
Systems Engineer
SRE (Site Reliability Engineer)
Just to name a few,
Whatever your conceit, that's in fact what the term means in practice.
Programming is a subset of skills within the sysadmin role.
You'd be surprised. A large chunk (say, more than 50%) of the sysadmin job market are guys that can set up a Windows LDAP and/or some Cisco and Wi-Fi equipment, but no more.
It's why the 'DevOps' moniker was invented, to differentiate the old-school Unix sysadmins from the LDAP-and-Exchange guys.
That was one reason that Perl became so popular among sysadmin back in the early 90's: it was a really useful language in which you could do much the same as you could with (and had a syntax which was similar to) shell scripting, sed, and awk, which were tools that were popular among sysadmins up 'till then.
Its not like they ran the backups at midnight manually.
One type writes a script to back up systems. Depending on their level of expertise they may also include error checking and tie it into the monitoring/alerting system so we know when the backups don't run correctly.
Another type buys backup software, and configures it to back up their systems.
Each type has pros and cons, and each may feel superior to the other. However the ones who haven't coded may find themselves ill-suited to moving to a job where they are expected to be more of the first type, the coding sysadmin.
When interviewing prospective sysadmins, I've tried to tease out whether they are a "maker" or "doer" type of person. The makers tend to be more scarce, and the doers may be ignorant of how much they could be learning and experiencing if they widened their horizons a little.
It may sound like I'm very dismissive of the doers. I'm not, a good team is going to have a mix and have different levels of expertise too.
It's bridging the gap between software developers and sysadmins where devops falls into place. Taking applications and optimizing their environments, rollouts, versioning, reliability of deployments, reduction of downtime, automating server provisioning, etc.
IMO the best devops are software devs with some sysadmin experience.
To me DevOps: One must understand the build system, stack, and the minutiae related to maintaining that build stream. It's a lot of work and at least in the past was more of a developer responsibility and not a "System Admin" type responsibility.
System Administration: Security, User Accounts, Policy, Backups, Network Configuration, Automation, Reliability.
Sure there is some overlap but these used to be completely separate functions and with good reason there was a lot to understand about each workflow.
Modern workflows (K8s, AWS, Docker, VMs, Jenkins, CI, TDD) have mostly take the "System" out of system administration while improving reliability and speeding development while (I think) suffering security. But that's another post or maybe I will write an article about it.
No separate job title, though. But similar things are happening in e.g. architecture and fields like mechanical and civil engineering. Used to be that you would have separate draftsman but nowadays you could say “an architect is a draftsman” and it would be about as accurate as saying “a software engineer is a programmer”.
I'm the 'not feature code' director at a company that manufactures companies. Meaning 20% of my time is what you describe above.
This is along side security work, occasionally feature code for one aspect of our moonshot that I have more experience than everyone else on, architecture work for all the properties to make sure they can talk to each other (while still maintaining enough separation that we could sell any of them at any time), building out a small manufacturing facility, and managing their transition to docker (which they only pursued because I pushed it). I also manage 2 other people (one of whom is a remote contractor) who do bits and pieces of the same and yes, a little endpoint laptop crap.
If they had billed the position as a sysadmin I wouldn't have taken it. Sysadmin pigeonholes you into a very specific role in many peoples eyes, whether it's true or not. Labels matter.
Its not enough to just rename your IT guys devops. However, When you're a stickler about titles its also counterproductive to the goal of removing the wall between dev and ops.
For my money, the crux of DevOps isn't specifically about who does what task with code, it's about vertical alignment. The notion that your build pipeline and infrastructure are as much a part of product development as the coding, design and everything else and everyone up and down the stack is aligned to the same goals.
Ops people come from a background favoring stability, security, and connecting components.
Developers come from using new and great tools... Writing the connections between their own systems, and following API docs of their partners.
Ops people usually have less CS training, and developers frequently don't understand security aspects of running systems or containers. You should merge the teams, not drop additional responsibility's on one side or the other that are outside their training/experience
I agree that cross-training and shared responsibility for both success and support are critical for success -- regardless of labels put on people and teams.
[1] If you haven't heard it, there's a joke:
Q: What's the difference between a data analyst and a data scientist?
A: The data scientist lives in San Francisco
This and
>DevOps is about avoiding the, "Just throw it over the wall," mentality, not making one person handle the whole thing.
this are why it's now part of my interview process when I'm interviewing for a new role "how does your company/team define DevOps?" and I listen very closely for things that sound like 'over the wall-Ops'. Admittedly having the fortune at this point in life to be quite judicious about the answers given.
Ostensibly, if I'm applying for a 'DevOps' role, I shouldn't have to do this if the job description is written well enough, yet even then this has become a learned behavior even when coming across the rare well-articulated job req.
Having devops teams and engineers isn’t the same as practicing devops, but once you scale up your org, you’re going to end up with them, anyway.
For example, someone who is good with ci/cd pipelines, infra as code and just generally in automation and observability, as opposed to someone who is strong with linux internals or JavaScript
You can tear down silos all you want, but everybody can’t know everything and people will always specialize.
The organizational question is whether the ops folks are (physically/organizationally) colocated with developers on dev teams, or colocated with themselves on an overarching ops team.
Do we really need a new term for this?
It just sounds like common sense.
The thing is, I am not gifted in the area of system administration. I am not too shabby at it in Windows, quite pathetic in Linux, but being a sysadmin was a role I had escaped for a reason. And suddenly I am back in it. I am a very low-tooling programmer. Just let me stick my hands in the data and go away. I have great respect for people who are system administrators but it is a job where my talents lie below my meager skills, and my inclination far below that.
Meanwhile, the true system administrators, who had been doing that for quite some time, had been denied the actual title for some time, were going to be moved over just as ... bodies, I guess, to elsewhere. All just ... DevOps now or whatever.
What a trainwreck.
I was going to use a sarcasm tag, except that is pretty much what my last employer did...
My greatest achievement in that job was making production a git repo so that we could regards against production before pushing. A sufficiently low bar you'll trip over it.
It's pretty sad.
Azure Devops Services: https://azure.microsoft.com/en-gb/services/devops/
Since there can't be a successful software delivery method that doesn't involve releasing software, the act of releasing software _cannot_ be new and unique to "DevOps".
IMO the new factor is in closing the feedback loop with the final link from live Operations back to Development, therefor if part of your cloud stack _must_ be singled out as the "DevOps" part, it's probably the logging / metrics / observability / alerting piece that does this, and not the good old CI and deploy pipelines.
The most common name used to be sysadmin. That could be development or operations or anything down to running a Windows Active Directory or HelpDesk.
At least with DevOps, there is no doubt that it's about Linux systems and automation.
Is that what you understand by the term "Devops" ? That "it's about Linux systems" ? Really??
That definition is a new one on me, and you very much should doubt it since "it's about Linux systems" is neither necessary nor sufficient. The confusion is even worse than I thought.
All the DevOps roles I've ever seen are Unix based. In my experience sysadmin roles were more likely to be a windows administration or a helpdesk role than that.
I think it's pretty good devops got split into a distinct title. It's not a great experience walking into a sysadmin interview only to find out they are looking for an exchange administrator.
No, I'm saying the the DevOps ideas have nothing to do with OS choice. You could use them in linux or Windows or in any other OS; or you could ignore them in linux or Windows or any other OS.
Windows Server still exists and maintains some market share. Automated, continuous delivery, and monitoring of web applications to Windows Server machines is DevOps in the exact same sense that it is with Linux machines.
The essence of DevOps is that there's no fence. The same team that writes the code deploys and monitors it. This essence remains unchanged regardless of the hosting platform - Linux, Windows, or even proprietary platforms like AWS lambda.
If we take the 50 thousand or so other blog posts about the definition of devops and glue them together - it means whatever you want. Ops teams doing some code, devs building CI/CD infrastructure, whatever.
I think that devops (like agile) will have a definite meaning, but uncovering that is mostly a process of examining the early history of it - who first used it and when? The definitions used, the problems that it aimed to solve, and the methods used to solve them.
However, like "agile" it can and often is abused to mean everything and nothing. This does not make it inherently meaningless, though.
Up next chefs will be food engineers, tailors will be clothing engineers, and because I changed the oil in my Toyota once, I’m now a Toyota engineer; specializing in fluids.
Words mean literally nothing anymore (ha). Titles in tech are hilarious at almost every level, especially from the outside looking in.
“DevOps” is at least ill-defined from the very start, so if we have arguments about what “DevOps” means, at least I can learn something.
1. understanding important engineering principals like queuing theory
2. understanding the system in question well enough to modify it to emit relevant metrics for applying stuff like queuing theory
3. collecting this data into timeseries form
4. applying statistical tests to them, e.g. for normality.
5. deciding between a variety of possible anomaly detection algorithms
Another portion involves capacity planning and datacenter design, which requires a certain amount of electrical engineering knowledge, as well as forecasting. A different part of my job simply involves writing software, testing it, and signing off on changes.
Overall it sounds fairly engineery, even if the powers that be would rather prefer it if the term be reserved those who pass an internship and test (but then refuse to expand said test to include new domains).
Probably going to be ridiculed for this, but "clothing engineer" actually sounds "cool" in a very mature market, in my eyes.
It’s an unfortunate state of the industry that we put value and prestige into ill defined labels.
They said it was admittedly not the best, clearest of the names, but the important thing is that DevOps should be shared, not owned. As a dev, it made a lot of sense to me
That jibes with my experience, where there has generally been one or more groups that build and maintain infrastructure to enable dev teams to build, deploy, monitor, etc. But what do you call it? It's not a DevOps role per se, nor really an Ops role, but it enables DevOps. We called it Platform, but said we were hiring DevOps engineers.
In short: it's a mess. :-)
If you must call it "DevOps", it is "Devops enablement team", i.e. supplying a platform to enable dev teams to better Develop, build, deploy, monitor, Operate what they make, themselves - enabling others to do DevOps by supplying tools.
See:
https://martinfowler.com/articles/talk-about-platforms.html
https://www.thoughtworks.com/radar/techniques/platform-engin...
https://hackernoon.com/how-to-build-a-platform-team-now-the-...
And with ModelOps, DevSecOps, AIOps, GregOps, and GitOps recently entering the lexicon brace yourself for lots of confusion and "xOps explained" articles ahead.
By the way, one of those xOps isn't real, but who can even tell?
* vegan optional
With these things, the ambiguity ramps up over time. e.g. "Agile" used to be well-defined. Now it means almost anything, or nothing.
I hadn't heard this term until very recently when SaltStack started pushing their enterprise suite hard in the security direction, and I facepalmed.
They're useful if you have an organization that pays a specific rate for a specific job title, and they're useful in a hierarchical sense (e.g. managers, CTOs, etc). That's about it.
I install and maintain servers and desktops, databases, run backups, build infrastructure, source control servers, do low level programming, high level programming, frontend, backend, ... etc, it's too long to even enumerate.
As far as I'm concerned that's just being a (non-junior) software developer. It's all ultimately the same thing with different names to me, barely anywhere really needs people who are at the forefront in a tiny niche (i.e. _real_ specialists).
You can call me whatever you want as long as you're paying the bills.
out: DevOps
in: SRE
Yet, this is one of the most common scenarios I've seen. "Oh, this guy/gal started devops at Xyz company.".
> You can't just rename your IT Ops team and call it DevOps
Someone who administers systems is a system administrator and someone who develops is a programmer.
And in my 30+ years in the business I haven't seen a single BSD or Linux system administrator who couldn't also program in C or some other language.
Audit - the idea that your developer doesn’t have access to production systems and data is a challenge to DevOps. The idea that one person codes and one deploys can be a challenge. Some organizations like management visibility and an audit trail to prove it - this can challenge automation and frequent deployment. This is not just a DevOps issue, audit expectations for business requirements and QA signoff can be just as bad. Admittedly some of the audit rules are relics of the past but the need to be addressed in order for DevOps practices (and really for agile teams to be agile.
In organizations where IT is a supporting function of the business there is a view point that it’s a cost center only and doesn’t produce value and should be cost controlled and managed to ultimate efficiency. I’ve reminded CIOs that the work the IT team does is not “a factory” as they sometimes insist on calling it - no one in technology that I’ve ever met (except management) really wants to think they work in a factory.
The efficiency mindset rank orders roles with QA and analysts at the bottom, devops slightly higher, developers relatively high, architects at the top of the skilled food chain and management of course at the top. To some degree these functions can be centralized so they can be optimized and made efficient. Centralizing typically means you work for management rather than a particular business mission. Your job is to make management look good and keep everything running smoothly (remember you work in a factory). Management generally looks good when quality is achieved at a lower price point. Along with that tends to be a higher level of off shoring at the lower end of the skill rank where larger numbers means more efficiency at lower cost. Here lies the problem - the premise of DevOps is that the role is integrated in the team. When DevOps is a function reporting to management then their goals aren’t aligned to the development team. They might not even sit with the team and they might have their own orders. They might be in a 12-20 hour time zone offset.
To me the larger issue is management structures aligned by function instead of business. This leads to misalignment if goals and ultimately lack of integration in functions. It’s a bigger problem than DevOps and it’s a bigger problem than IT. I think the companies that get management reporting right will win in the end. I am curious to see how Google and Amazon respond to these issues at their scale. The pizza team doesn’t work when everyone has different goals.