DevOps absolutely existed when the author started as a developer. It was just called systems administration back then. There's been a focus on developer-specific systems administration over the past decade, and a particular developer-focused role has been carved out and labeled "DevOps", but make no mistake: it is systems administration. Just a niche within it.
When I mention "systems administration" to younger coworkers, they look at me like I'm a crusty old relic out of touch with modern engineering. People have no sense of history and little understanding of where the devops role came from and what it really means. I had a CTO tell me he hadn't heard the term "system administration" in ten years.
What were our devops people doing? Running web servers, managing networks, configuring DNS, managing backups, configuring cloud services. Absolutely none of it in support of the dev team I was on. The developers were responsible for managing their own CI/CD pipeline and deployments. The people called the "DevOps Team" were responsible for managing production. In this case, they were systems administrators and were not in any way a devops team, but the terminology is so skewed now that they were labeled as such, and I was labeled an out of touch old greybeard.
This isn't to demean devops in any way; it's a valuable role, an evolutionary step in software team organization, but by no means is it new and by no means is systems administration a dead role.
When I hear systems administration I assume it's pets not cattle, and that you're administering individual named servers with bash scripts rather than administering a mesos cluster with chef or puppet or whatever.
I'm not sure where I picked up this impression from.
I know that "DevOps" is one of those terms that can mean whatever the user wants it to mean (like "agile" and "REST" and so on), but at least with DevOps, I've mostly only seen 2 types of common definitions:
1) "DevOps teams" are just rebranded operations teams
2) "DevOps teams" are teams that are responsible for both development and operations for their app
I think the first one is the one you're frustrated with, and I agree it's a completely useless label when used like that, but it's not definitely not the only way it's used.
Being a "Build-Release Engineer", essentially the sysadmin of the development tool chain, has existed since at least the 90's.
But the roots can be traced to the 70's (the PDP-11 had the compile-link process).
If you were really smart and could program in Assembler they called you a "Systems Programmer".
In the 80's, the PC revolution fostered debates over how much centralized control IT should have.
There was a long-standing debate in computing as to where the software should live (that is on a server or at the client level).
This debate was settled when Google invested heavily in making the browser a powerful and stable platform (think about Javascript in the 90's vs. today).
So the modern situation is server=cloud and client=browser. This creates a demand for people who understand how software is built/deployed/maintained in this environment.
So we slap the Devops label on it and pretend we understand what's going on.
But it's really a debate about how long the current status quo will last before it's subsumed by something else.
1. Developers learning that running code is not the same thing as reliable code. Certain things must be put in at design time to allow for operations.
2. Operations people supporting development by formalizing/streamlining the deployment process to have changes occur faster, safer, and more often.
3. Aligning goals and attitudes in such a way that prevents conflict between teams. Development doesn't get to shift the costs of outage prone unmaintainable code onto an ops team. Or that ops doesn't roadblock/veto all changes.
In the bad old days, it was common for developers to act with little care for operational outcomes. The responsibility was far removed, and bugfixes didn't win many accolades. Managers want wish fulfillment and pushed developers to toss new features into the mix as fast as possible, resulting in tremendous pressure against ops teams to deploy despite increasingly crufty and debt laden code bases causing unpredictable problems. Ergo, ops teams who blocked all changes for trivial issues because they were judged only based on outages, not feature delivery.
Yes, devops is not one person, but team is devops. It comes from standards, that developers should not have access to production data, so you need ops. But on the other hand you don't want to have dev and ops team people who throw shit over the fence.
So basically it comes to having devs, test, ops, sec, persons in one team with common goal of delivering featuers.
Because most friction was on boarders like dev | test | ops | security, all those people being on role specific teams would do what is important for their team. So test people would blame devs, sec people would blame ops, test or devs. When you are in one team that has common goal of delivering feature X and you are measured by delivering feature X, everyone is willing to take pragmatic approach instead of "code has to be perfect", "tests have to be perfect", "security has to be perfect".
I read somewhere "magic happens if you seat testers and developers in the same room", I belive it was "Project Phoenix" book. But I despise from the start having those devs vs test people or test people beeing happy about finding bugs. They should be sad because what matters is delivering feature, so they should be happy when they don't find anything. That said, thay should do all they can to find bugs, because we have common goal: "working software".
This article was frustrating to me. When it started out in the mid-90s (which is when I started my career also), I thought our experiences would be more aligned. However, I've never worked with an operations team.
In all the places I've worked I've been expected to do everything from setting up servers (originally physical servers, later cloud servers), hardening them, installing software, optimizing the software, installing and optimizing the database, creating database schemas and related objects, writing untold number of sql queries, writing server side code, writing front end code, etc.
I was hoping that the article would explain what devops really means today and how I can jump on the devops wagon to hopefully make my job of doing all of the above easier.
That’s the dream… the reality in my experience is that you have to describe, in detail, the exact steps that you would perform if you were doing it yourself so that somebody else can perform them, verbatim. But you have to describe those steps, exactly, without any access to the target platform where they’ll be performed.
And its also written from a very recent perspective, arguably I was formally working in devops in the 80's
I was hired as development team member partially as I was a sysadmin on the hardware we were using, our team both wrote the code but also the entire JCL infrastructure that managed the compilation linking, deployment and the running of code across the cluster of 16 or 17 systems.
On of my friends, an IBM guy from the operations side was shocked that we as developers where allowed to deploy and run our own code.
My background is more like yours. For me it’s likely a difference in size and type of companies worked for.
> I was hoping that the article would explain what devops really means today and how I can jump on the devops wagon to hopefully make my job of doing all of the above easier.
1. Use AWS Fargate for all of your backend services. Keep the architecture simple enough that complicated service discovery issues etc don’t come up. If you need coordination between services, do it through Redis or similar.
2. Use RDS unless you really need to save money or use unavailable extensions.
3. Use terraform for initially provisioning the above
4. Set up CI/CD such that merges to master automatically update your services. (I like CircleCI’s aws-ecr and aws-ecs orbs for this.)
Pretty simple recipe, but it means no setting up servers, no hardening servers, no installing or optimizing software (other than by adding it to the Dockerfile), no installing or optimizing the database.
This recommendation reflects what modern devops means to me; opinions differ. To me it means:
- Infrastructure as code (terraform rather than clicking buttons in the AWS console then later forgetting which buttons you clicked)
- Immutable infrastructure (aka cattle not pets). Never SSHing into a server again.
- Automated testing and deployment cleanly integrated with existing dev workflow
Obviously there’s a scale at which you have to do something more complex, but I’d say that’s the scale at which you previously would have had an operations team.
Getting rid of the “writing server side code” and “writing front end code” parts is beyond the scope of devops, but you can skip a lot of the “writing server side code” part by using PostgREST. In exchange you may have to write an even-more-untold number of SQL queries, depending on your current practices.
Edit: Someone helpfully pointed out that I forgot to mention anything about logging or monitoring, which is a pretty glaring omission. On that front I strongly recommend Honeycomb. To set it up with Fargate you may need to run it in a sidecar container, but it’s fairly straightforward.
The article is lost on me too. ~15 years professional experience as a software developer and I never had to deal with an "Operations" team. My understanding is that it's the people that would be doing Amazon's job if you were trying to not use AWS or some other cloud service?
"Devops" means not fighting with those people??? haha
Personally I think DevOps is like religion. It means whatever someone wants it to mean. Some companies think DevOps means having an automated pipeline for building, testing, and shipping code. Other companies think it means micro-services. Others think it means making developers do DBA / SysAdmin work.
All of these things are fine for companies to do. How you run your org is on you. But I wish companies would go deeper than "DevOps" when putting up job posting requirements.
That's like saying they do "security". There's a lot of different ways that can be interpreted. I (as an applicant) only know a handful of those interpretations really well, so it's important that companies clarify these terms in their job descriptions. This way they have the right candidates applying.
As long as no-one is knocking on my door asking if I have five minutes to discuss Agile development methodologies.
I could reasonably defend most of what people attach to the "DevOps" buzzword as sane practices most of us were already doing before the hoopla.
Agile (with a capital A) is the absolute worst thing that has ever happened to the software industry. Kill off that cult and you can DevOps my work with containerized OWASP Gitflows until the end of days for all I care.
Snark aside, Dave Thomas makes a compelling argument for trying to choose terms that are as hard as possible for others to co-opt for selling snake oil (anecdotally, I encounter people on a weekly basis who are self-described Agile or DevOps experts, but have no technical background whatsoever).
my bar for "DevOps" on my (SaaS) team is that the engineers responsible for the platform the product runs on are involved in the discussions about the product we build.
everything that comes after that: pipelines, testing, release engineering, migrations, post-mortems, whatever -- it's all a result of your infrastructure engineers having a stake in the thing your company is building. I have yet to see a definition of DevOps that invoked some sort of tech stack that made any sense to me. the processes and tools emerge from a cooperation between stakeholders and a shared responsibility for the delivered product.
DevOps is the channel in slack I check when my code didn't update. That the directs me to somewhere else where I just sort of randomly click things until it works or gets worse.
But yeah I'm with you on the wild definitions, it can be anything from some overnight IT grunt, to something far more respected and involved depending on how the company did things.
> But I wish companies would go deeper than "DevOps" when putting up job posting requirements.
I am not sure this problem is limited to DevOps. Once I applied for a job thinking I understood the job description. During the interview, I had to find out that they put only half the job in the description (the good parts).
Afterward, I took a look on the job description again asking myself if I misinterpreted the description but came to the conclusion that they just didn't want to write about the downsides of the job (not even in management speak like 'You love a challenge?').
> Others think it means making developers do DBA / SysAdmin work.
I've been in that spot many times. In my last job, I did engineering (networking, server, etc) / support for 7 data centers. We started to support of 3rd party "cloud" products, and then they dropped the DCs they gave me the title of DevOps Engineer IV. When they did that, I didn't have any Dev or Ops responsibilities.
People can’t agree what devops is, sure. But I feel like it’s extremely easy to tell what devops isn’t. If you don’t have any confidence in your releases before you’ve done extensive ad-hoc manual probing you aren’t doing devops. If your using oracle and Delphi even though none of the developers would chose it because “that’s what management decided” you are not doing devops.
The rest of the story is just about the tooling and management decisions that support getting out of those pits. You use micro services because it allows developers to use whichever tools they want as long as they solve the task. You use automated tests and deployment pipelines so the team and organizational procedure to be confident in releases shifts from becoming “talk to Tom and get his blessing after he’s spend a week probing everything” to “well if it passed all tests and deployed then it’s a go.
It’s not like the technical issues suddenly disappear. You need to set up your tests to a level where you are confident in the pipeline. You still need to spend the time and resources making sure your microservice infrastructure is working.
But at the end of it you’ve removed the power of the gits who where previously controlling the techs allowed and the releases, and your letting teams move forwards through proving their work rather than constant audiences with individuals who are gatekeepers because they spend 20 years in the same organization and feel that everything invented in the last decade is scary.
I also got a chance to work in such an organization in the 00's, where dev and ops closely aligned with each other's work to produce truly reliable, repeatable, fast, quality products, often. It was fantastic. Nobody would say "oh but you can't do that, that's not Infrastructure as Code!" They would say, "what can we all do to make this better?"
In the 90's and 00's I was responsible for maybe 20-30 servers, now I am responsible for somewhere around the 2000 mark..
While "oh but you can't do that, that's not Infrastructure as Code!" sounds lame, and your co-worker should learn to be a better communicator, things need to be reproducible when working with more complex systems and that calls for more rigorous review practices.
Please consider this: It's our pagers that go off at 3am when your code fails..
I found this line interesting, everything else considered:
DevOps is NOT…easily achieved nor implemented
Debatable, at least IMO. DevOps isn't easily achieved nor implemented if you're trying to implement ALL THE THINGS to say you did and check-off a series of "We did DevOps thing x" boxes as so many companies appear to want-at least from reading various DevOps-y job descriptions lately.
It is easier implemented if, like Gene Kim tells us in "The DevOps Handbook"-we start our DevOps transformations with a small, sympathetic team and iterate outward.
In 1997, when my first code I wrote went live, they gave me a pager and said "Welcome to Ops." Each time the code in production had an abnormal end, I got an email. I was expected to fix it. Managers and directors discussed these metrics.
The change in job description from just "operations" to "developer operations" over the past decade is best captured by the growing number of systems that must be managed per person, often larger by a factor of 10 times or more (e.g. going from 10 systems per person to 100+).
I appreciate the self-reflective views on this "new" job role, but they often seem to miss the rather basic market forces at work. More systems, more automation, new skills and demands.
Sidebar: does anyone else get the feeling that infrastructure as code is just cloud vendor lock-in by another name? Especially since the output of the code ends up being wild unstructured JSON/YAML files with no spec or discernible schema.
My favorite is how in the Microsoft toolchain you can build a CI pipeline in a visual UI on the right that automatically updates the YAML file on the left. “We know you don’t want YAML, but we also know your boss says you need infra-as-code...”
Infra-as-code is mainly just a method to force people to write things down, rather than the default of nobody writing anything down, and people just manually making changes that nobody else knows about, making it really difficult to manage changes. Even a bash script that creates an ec2 instance is infrastructure-as-code.
OTOH, I kind of hate Terraform now, because you can use it in a way that will surprise you and blow up, leaving a mess that you have to clean up manually. It's more "infrastructure as code" than Ansible, but Ansible will at least attempt to fix things that aren't "right". So everything that has a certain label is not by definition superior to all alternatives. (I actually hate both tools for different reasons, but they have their uses)
You might want to look into Terraform [1], which works across multiple cloud vendors, with pluggable open-source "providers" facilitating the communication with the backend cloud platform.
You’re using a cloud provider; you’re already locked in. But you’re also locked in like you’re locked in by your OS or your programming language or your ISP, which is to say: the whole point of cloud providers is to abstract away a certain set of things. You can look at it as lock-in, or as using a platform that enables you to solve the problems you care about. You can look at your OS as lock-in, or a tool that enables you to solve the problems you care about. If your goal is to provide cloud infrastructure quickly and easily and without building a data center, then lock-in doesn’t really matter. And if it does, there are more expensive, more appropriate options.
If you mean in terms on Kubernetes, the idea is identical JSON would work on AWS, GCP, Azure, Digital Ocean. If you want to go cloudless, you can run k8s on your own infrastructure. And if you want to run on your own infra, the need for configuration doesn't go away. Given how open the specification is for the JSON documents, I find it difficulty in characterizing it as lock-in. The configuration JSON is highly reusable in variety of contexts, with the examples I gave above.
How is the opaque visual UI better? IaC doesn't unlock you from a vendor but at least you have a reproducible config file you can check in and version.
I tried Terraform this weekend and it was awesome to use. Spinning up a new ec2 instance was very quick. Almost just as quick when you spin up multiple instances.
It supports "providers", which are interfaces to the different vendors (aws, foogle cloud, etc), and "provisioners", which are frameworks for configuring a running instance (chef? Docker? Zookeeper?)
means, the sysadmin/sysops/ops guy now has to know things about development to center his daily-doing around code (ideally the code dictates what is going on [Infrastructure as Code]).
a very simple example to this:
back then the ops guy or sysadmin did everything by hand. today, he uses code to get things done. bash vs. a HTTP JSON API. manually by hand vs. ansible [markup language yaml], etc.
so many people just dont know or understand what devops means. but it is so easy.
it is the fusion of development and operations.
thus, while you need two people back then, now you only need one person to do the same job.
a devops is a sysadmin who ideally knows how to code.
a devops is a developer who evolved into a sysadmin or is doing both because he learned it.
devops is development/operations.
it has nothing to do with agile, waterfall or a "mindset".
It certainly did exist when I started my career a decade earlier than this guy. It was called the integration team, which was responsible for coordination of the release. In the 80ies.
It was also responsible for the build servers, the SCM, and checking and prioritizing all the different parts and fixes of the various dev teams, and checking back with the PM and testers. Only hackers did cowboy coding, companies preferred processes and best practices. That's it was called "Software Engineering" and not hacking.
I heard Margaret Hamilton coined that term in the 60ies for the Apollo project, which she managed.
[The (or any) Internet didn't exist when I started as a developer]
DevOps is about how CTO organizes engineering.
Is there an Infra team that supports everyone, maybe a separate Ops/security/etc teams that supports everyone. Then a bunch of App/Service dev teams. This is not devops.
Or is there only* a bunch App/Service teams, each wholly self-supporting and independent. Each doing their own infra, dev, ops. Maybe some teams' "Service" is used by only other internal teams (point being you can break up scope as fine grained as you want). The key is teams are self-supporting, taking care of the entire life-cycle of an App/Service.
Most "devops" sort of isn't or fails cause it's not "deployed as an organizational system, top-down (from CTO) across the whole organization.
All the things people typically bike shed over re: devops don't matter. Are you independent and self-contained? Are you responsible for entire life-cycle of Product/Service/App/Etc? Does the buck stop with you? Then you are devops.
In which case DevOps as it exists in the real world is roughly on a par with 'agile' practices in the real world. Nothing like they were originally conceived, and nothing like the wildly optimistic descriptions of them that are shared amongst practitioners.
Generally Ive found tight feedback loops to be incredibly productive. Whether its for product, release, design, development. Having the ability to make modifications with feedback from customers, systems, business partners and colleagues changes everything.
One could argue that it still doesn't exist today at most companies. I think whatever most people call DevOps is an evolution of Sys Admin role in the era of Cloud Computing.
Lots of things people think of as crucial today didn't exist when I started. And the overall ratio of successful work to unsuccessful work was just as high then as it is now.
The goal of DevOps is to get code as developed to testing, staging, production. The deeper objective should be transfer of context- what is being deployed? do we know how? does it work as tested? and the who. As much DRY to reduce surprises and increase precision all through dev to deploy cycle.
Some of the best open source projects have CI included- thats the right approach to DevOps -- its not an alien, bolt-on after the fact practice, its code that takes care of code.
[+] [-] caymanjim|6 years ago|reply
When I mention "systems administration" to younger coworkers, they look at me like I'm a crusty old relic out of touch with modern engineering. People have no sense of history and little understanding of where the devops role came from and what it really means. I had a CTO tell me he hadn't heard the term "system administration" in ten years.
What were our devops people doing? Running web servers, managing networks, configuring DNS, managing backups, configuring cloud services. Absolutely none of it in support of the dev team I was on. The developers were responsible for managing their own CI/CD pipeline and deployments. The people called the "DevOps Team" were responsible for managing production. In this case, they were systems administrators and were not in any way a devops team, but the terminology is so skewed now that they were labeled as such, and I was labeled an out of touch old greybeard.
This isn't to demean devops in any way; it's a valuable role, an evolutionary step in software team organization, but by no means is it new and by no means is systems administration a dead role.
[+] [-] strken|6 years ago|reply
I'm not sure where I picked up this impression from.
[+] [-] sunaurus|6 years ago|reply
1) "DevOps teams" are just rebranded operations teams
2) "DevOps teams" are teams that are responsible for both development and operations for their app
I think the first one is the one you're frustrated with, and I agree it's a completely useless label when used like that, but it's not definitely not the only way it's used.
[+] [-] RichardCA|6 years ago|reply
But the roots can be traced to the 70's (the PDP-11 had the compile-link process).
If you were really smart and could program in Assembler they called you a "Systems Programmer".
In the 80's, the PC revolution fostered debates over how much centralized control IT should have.
There was a long-standing debate in computing as to where the software should live (that is on a server or at the client level).
This debate was settled when Google invested heavily in making the browser a powerful and stable platform (think about Javascript in the 90's vs. today).
So the modern situation is server=cloud and client=browser. This creates a demand for people who understand how software is built/deployed/maintained in this environment.
So we slap the Devops label on it and pretend we understand what's going on.
But it's really a debate about how long the current status quo will last before it's subsumed by something else.
[+] [-] noknownsender|6 years ago|reply
[+] [-] johngalt|6 years ago|reply
1. Developers learning that running code is not the same thing as reliable code. Certain things must be put in at design time to allow for operations.
2. Operations people supporting development by formalizing/streamlining the deployment process to have changes occur faster, safer, and more often.
3. Aligning goals and attitudes in such a way that prevents conflict between teams. Development doesn't get to shift the costs of outage prone unmaintainable code onto an ops team. Or that ops doesn't roadblock/veto all changes.
In the bad old days, it was common for developers to act with little care for operational outcomes. The responsibility was far removed, and bugfixes didn't win many accolades. Managers want wish fulfillment and pushed developers to toss new features into the mix as fast as possible, resulting in tremendous pressure against ops teams to deploy despite increasingly crufty and debt laden code bases causing unpredictable problems. Ergo, ops teams who blocked all changes for trivial issues because they were judged only based on outages, not feature delivery.
[+] [-] ozim|6 years ago|reply
So basically it comes to having devs, test, ops, sec, persons in one team with common goal of delivering featuers.
Because most friction was on boarders like dev | test | ops | security, all those people being on role specific teams would do what is important for their team. So test people would blame devs, sec people would blame ops, test or devs. When you are in one team that has common goal of delivering feature X and you are measured by delivering feature X, everyone is willing to take pragmatic approach instead of "code has to be perfect", "tests have to be perfect", "security has to be perfect".
I read somewhere "magic happens if you seat testers and developers in the same room", I belive it was "Project Phoenix" book. But I despise from the start having those devs vs test people or test people beeing happy about finding bugs. They should be sad because what matters is delivering feature, so they should be happy when they don't find anything. That said, thay should do all they can to find bugs, because we have common goal: "working software".
[+] [-] eternalban|6 years ago|reply
[deleted]
[+] [-] irrational|6 years ago|reply
In all the places I've worked I've been expected to do everything from setting up servers (originally physical servers, later cloud servers), hardening them, installing software, optimizing the software, installing and optimizing the database, creating database schemas and related objects, writing untold number of sql queries, writing server side code, writing front end code, etc.
I was hoping that the article would explain what devops really means today and how I can jump on the devops wagon to hopefully make my job of doing all of the above easier.
[+] [-] commandlinefan|6 years ago|reply
That’s the dream… the reality in my experience is that you have to describe, in detail, the exact steps that you would perform if you were doing it yourself so that somebody else can perform them, verbatim. But you have to describe those steps, exactly, without any access to the target platform where they’ll be performed.
[+] [-] walshemj|6 years ago|reply
I was hired as development team member partially as I was a sysadmin on the hardware we were using, our team both wrote the code but also the entire JCL infrastructure that managed the compilation linking, deployment and the running of code across the cluster of 16 or 17 systems.
On of my friends, an IBM guy from the operations side was shocked that we as developers where allowed to deploy and run our own code.
[+] [-] nbouscal|6 years ago|reply
> I was hoping that the article would explain what devops really means today and how I can jump on the devops wagon to hopefully make my job of doing all of the above easier.
1. Use AWS Fargate for all of your backend services. Keep the architecture simple enough that complicated service discovery issues etc don’t come up. If you need coordination between services, do it through Redis or similar.
2. Use RDS unless you really need to save money or use unavailable extensions.
3. Use terraform for initially provisioning the above
4. Set up CI/CD such that merges to master automatically update your services. (I like CircleCI’s aws-ecr and aws-ecs orbs for this.)
Pretty simple recipe, but it means no setting up servers, no hardening servers, no installing or optimizing software (other than by adding it to the Dockerfile), no installing or optimizing the database.
This recommendation reflects what modern devops means to me; opinions differ. To me it means:
- Infrastructure as code (terraform rather than clicking buttons in the AWS console then later forgetting which buttons you clicked)
- Immutable infrastructure (aka cattle not pets). Never SSHing into a server again.
- Automated testing and deployment cleanly integrated with existing dev workflow
Obviously there’s a scale at which you have to do something more complex, but I’d say that’s the scale at which you previously would have had an operations team.
Getting rid of the “writing server side code” and “writing front end code” parts is beyond the scope of devops, but you can skip a lot of the “writing server side code” part by using PostgREST. In exchange you may have to write an even-more-untold number of SQL queries, depending on your current practices.
Edit: Someone helpfully pointed out that I forgot to mention anything about logging or monitoring, which is a pretty glaring omission. On that front I strongly recommend Honeycomb. To set it up with Fargate you may need to run it in a sidecar container, but it’s fairly straightforward.
[+] [-] dogprez|6 years ago|reply
"Devops" means not fighting with those people??? haha
[+] [-] SamuelAdams|6 years ago|reply
All of these things are fine for companies to do. How you run your org is on you. But I wish companies would go deeper than "DevOps" when putting up job posting requirements.
That's like saying they do "security". There's a lot of different ways that can be interpreted. I (as an applicant) only know a handful of those interpretations really well, so it's important that companies clarify these terms in their job descriptions. This way they have the right candidates applying.
[+] [-] headmelted|6 years ago|reply
As long as no-one is knocking on my door asking if I have five minutes to discuss Agile development methodologies.
I could reasonably defend most of what people attach to the "DevOps" buzzword as sane practices most of us were already doing before the hoopla.
Agile (with a capital A) is the absolute worst thing that has ever happened to the software industry. Kill off that cult and you can DevOps my work with containerized OWASP Gitflows until the end of days for all I care.
Snark aside, Dave Thomas makes a compelling argument for trying to choose terms that are as hard as possible for others to co-opt for selling snake oil (anecdotally, I encounter people on a weekly basis who are self-described Agile or DevOps experts, but have no technical background whatsoever).
[+] [-] n42|6 years ago|reply
everything that comes after that: pipelines, testing, release engineering, migrations, post-mortems, whatever -- it's all a result of your infrastructure engineers having a stake in the thing your company is building. I have yet to see a definition of DevOps that invoked some sort of tech stack that made any sense to me. the processes and tools emerge from a cooperation between stakeholders and a shared responsibility for the delivered product.
[+] [-] duxup|6 years ago|reply
But yeah I'm with you on the wild definitions, it can be anything from some overnight IT grunt, to something far more respected and involved depending on how the company did things.
[+] [-] arendtio|6 years ago|reply
I am not sure this problem is limited to DevOps. Once I applied for a job thinking I understood the job description. During the interview, I had to find out that they put only half the job in the description (the good parts).
Afterward, I took a look on the job description again asking myself if I misinterpreted the description but came to the conclusion that they just didn't want to write about the downsides of the job (not even in management speak like 'You love a challenge?').
[+] [-] JMTQp8lwXL|6 years ago|reply
This seems to be the most common interpretation, but I largely agree with you on no hard and fast rule here.
[+] [-] xellisx|6 years ago|reply
I've been in that spot many times. In my last job, I did engineering (networking, server, etc) / support for 7 data centers. We started to support of 3rd party "cloud" products, and then they dropped the DCs they gave me the title of DevOps Engineer IV. When they did that, I didn't have any Dev or Ops responsibilities.
[+] [-] nabdab|6 years ago|reply
The rest of the story is just about the tooling and management decisions that support getting out of those pits. You use micro services because it allows developers to use whichever tools they want as long as they solve the task. You use automated tests and deployment pipelines so the team and organizational procedure to be confident in releases shifts from becoming “talk to Tom and get his blessing after he’s spend a week probing everything” to “well if it passed all tests and deployed then it’s a go.
It’s not like the technical issues suddenly disappear. You need to set up your tests to a level where you are confident in the pipeline. You still need to spend the time and resources making sure your microservice infrastructure is working.
But at the end of it you’ve removed the power of the gits who where previously controlling the techs allowed and the releases, and your letting teams move forwards through proving their work rather than constant audiences with individuals who are gatekeepers because they spend 20 years in the same organization and feel that everything invented in the last decade is scary.
[+] [-] peterwwillis|6 years ago|reply
I also got a chance to work in such an organization in the 00's, where dev and ops closely aligned with each other's work to produce truly reliable, repeatable, fast, quality products, often. It was fantastic. Nobody would say "oh but you can't do that, that's not Infrastructure as Code!" They would say, "what can we all do to make this better?"
[+] [-] jascii|6 years ago|reply
[+] [-] nickstinemates|6 years ago|reply
We need more of this.
[+] [-] dvtrn|6 years ago|reply
DevOps is NOT…easily achieved nor implemented
Debatable, at least IMO. DevOps isn't easily achieved nor implemented if you're trying to implement ALL THE THINGS to say you did and check-off a series of "We did DevOps thing x" boxes as so many companies appear to want-at least from reading various DevOps-y job descriptions lately.
It is easier implemented if, like Gene Kim tells us in "The DevOps Handbook"-we start our DevOps transformations with a small, sympathetic team and iterate outward.
[+] [-] lanstin|6 years ago|reply
[+] [-] aodin|6 years ago|reply
I appreciate the self-reflective views on this "new" job role, but they often seem to miss the rather basic market forces at work. More systems, more automation, new skills and demands.
[+] [-] abjKT26nO8|6 years ago|reply
[+] [-] Roboprog|6 years ago|reply
Good thing it was a non public app instead of a blog
[+] [-] zwkrt|6 years ago|reply
My favorite is how in the Microsoft toolchain you can build a CI pipeline in a visual UI on the right that automatically updates the YAML file on the left. “We know you don’t want YAML, but we also know your boss says you need infra-as-code...”
[+] [-] peterwwillis|6 years ago|reply
OTOH, I kind of hate Terraform now, because you can use it in a way that will surprise you and blow up, leaving a mess that you have to clean up manually. It's more "infrastructure as code" than Ansible, but Ansible will at least attempt to fix things that aren't "right". So everything that has a certain label is not by definition superior to all alternatives. (I actually hate both tools for different reasons, but they have their uses)
[+] [-] JBerlinsky|6 years ago|reply
[1]: https://www.terraform.io/
[+] [-] journalctl|6 years ago|reply
[+] [-] JMTQp8lwXL|6 years ago|reply
[+] [-] jayd16|6 years ago|reply
[+] [-] kovek|6 years ago|reply
It supports "providers", which are interfaces to the different vendors (aws, foogle cloud, etc), and "provisioners", which are frameworks for configuring a running instance (chef? Docker? Zookeeper?)
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] k__|6 years ago|reply
[+] [-] omani|6 years ago|reply
devops means Developer/Operations.
means, the sysadmin/sysops/ops guy now has to know things about development to center his daily-doing around code (ideally the code dictates what is going on [Infrastructure as Code]).
a very simple example to this: back then the ops guy or sysadmin did everything by hand. today, he uses code to get things done. bash vs. a HTTP JSON API. manually by hand vs. ansible [markup language yaml], etc.
so many people just dont know or understand what devops means. but it is so easy.
it is the fusion of development and operations.
thus, while you need two people back then, now you only need one person to do the same job.
a devops is a sysadmin who ideally knows how to code.
a devops is a developer who evolved into a sysadmin or is doing both because he learned it.
devops is development/operations.
it has nothing to do with agile, waterfall or a "mindset".
[+] [-] auslander|6 years ago|reply
https://kevin.burke.dev/kevin/circleci-is-hopelessly-insecur...
[+] [-] rurban|6 years ago|reply
It was also responsible for the build servers, the SCM, and checking and prioritizing all the different parts and fixes of the various dev teams, and checking back with the PM and testers. Only hackers did cowboy coding, companies preferred processes and best practices. That's it was called "Software Engineering" and not hacking. I heard Margaret Hamilton coined that term in the 60ies for the Apollo project, which she managed.
[+] [-] sytse|6 years ago|reply
1. Waterfall is a cycle time of weeks
2. Agile is a cycle time of days
3. DevOps is the same cycle time as agile but delivering the the user instead of just showing a demo at the end of a sprint.
[+] [-] njharman|6 years ago|reply
DevOps is about how CTO organizes engineering.
Is there an Infra team that supports everyone, maybe a separate Ops/security/etc teams that supports everyone. Then a bunch of App/Service dev teams. This is not devops.
Or is there only* a bunch App/Service teams, each wholly self-supporting and independent. Each doing their own infra, dev, ops. Maybe some teams' "Service" is used by only other internal teams (point being you can break up scope as fine grained as you want). The key is teams are self-supporting, taking care of the entire life-cycle of an App/Service.
Most "devops" sort of isn't or fails cause it's not "deployed as an organizational system, top-down (from CTO) across the whole organization.
All the things people typically bike shed over re: devops don't matter. Are you independent and self-contained? Are you responsible for entire life-cycle of Product/Service/App/Etc? Does the buck stop with you? Then you are devops.
[+] [-] Nursie|6 years ago|reply
In which case DevOps as it exists in the real world is roughly on a par with 'agile' practices in the real world. Nothing like they were originally conceived, and nothing like the wildly optimistic descriptions of them that are shared amongst practitioners.
[+] [-] thinkingkong|6 years ago|reply
[+] [-] suyash|6 years ago|reply
[+] [-] gdulli|6 years ago|reply
[+] [-] shipit|6 years ago|reply
Some of the best open source projects have CI included- thats the right approach to DevOps -- its not an alien, bolt-on after the fact practice, its code that takes care of code.