What exactly is DevOps and what’s the learning roadmap.
In: 25
[deleted]
[deleted]
[deleted]
While software developers focus on building software – like adding features and fixing bugs – DevOps specializes in deploying software and keeping it running smoothly.
For example, let’s say you’ve got a website. It runs on a server in the cloud along with a database.
The DevOps person sets up a load-balancer to spread out the load between multiple web servers. Maybe they adjust the number of servers running based on the time of day.
They set up daily database backups, and monthly they do a practice database restore so they’re confident they could recover if a bug in the code accidentally deleted important rows from the database.
They set up security monitoring software.
They keep up with security vulnerabilities and patch the server OS. They push the developers to upgrade libraries the software uses to new versions when there’s a new vulnerability.
They respond to emergencies, like if the site is offline.
The job used to be called SysAdmin. The name DevOps is a more modern take that recognizes that this role is still a developer – you still need to be good at programming – it’s just a different focus / specialty than developing software.
For example, the best way to keep the site running smoothly is not to be there 24/7 to respond every time something goes wrong, but to write code that automatically handles common failures and automatically fixes them.
[https://roadmap.sh/devops](https://roadmap.sh/devops) has a good roadmap!
While software developers focus on building software – like adding features and fixing bugs – DevOps specializes in deploying software and keeping it running smoothly.
For example, let’s say you’ve got a website. It runs on a server in the cloud along with a database.
The DevOps person sets up a load-balancer to spread out the load between multiple web servers. Maybe they adjust the number of servers running based on the time of day.
They set up daily database backups, and monthly they do a practice database restore so they’re confident they could recover if a bug in the code accidentally deleted important rows from the database.
They set up security monitoring software.
They keep up with security vulnerabilities and patch the server OS. They push the developers to upgrade libraries the software uses to new versions when there’s a new vulnerability.
They respond to emergencies, like if the site is offline.
The job used to be called SysAdmin. The name DevOps is a more modern take that recognizes that this role is still a developer – you still need to be good at programming – it’s just a different focus / specialty than developing software.
For example, the best way to keep the site running smoothly is not to be there 24/7 to respond every time something goes wrong, but to write code that automatically handles common failures and automatically fixes them.
[https://roadmap.sh/devops](https://roadmap.sh/devops) has a good roadmap!
While software developers focus on building software – like adding features and fixing bugs – DevOps specializes in deploying software and keeping it running smoothly.
For example, let’s say you’ve got a website. It runs on a server in the cloud along with a database.
The DevOps person sets up a load-balancer to spread out the load between multiple web servers. Maybe they adjust the number of servers running based on the time of day.
They set up daily database backups, and monthly they do a practice database restore so they’re confident they could recover if a bug in the code accidentally deleted important rows from the database.
They set up security monitoring software.
They keep up with security vulnerabilities and patch the server OS. They push the developers to upgrade libraries the software uses to new versions when there’s a new vulnerability.
They respond to emergencies, like if the site is offline.
The job used to be called SysAdmin. The name DevOps is a more modern take that recognizes that this role is still a developer – you still need to be good at programming – it’s just a different focus / specialty than developing software.
For example, the best way to keep the site running smoothly is not to be there 24/7 to respond every time something goes wrong, but to write code that automatically handles common failures and automatically fixes them.
[https://roadmap.sh/devops](https://roadmap.sh/devops) has a good roadmap!
It used to be a standard operating model at software companies that the people who actually *write* the software, write new features, fix bugs, etc. and the people who actually *run* the software as a service once its done, are separate people on separate teams.
Once the software was “done,” and launched as a live service, it was a different team who kept that software running, got paged and woken up if there was an issue, had to be “on-call” to fix outages, run the actual data centers and the servers in them, etc.
One problem with this model is that writing software is a lot sexier than running software. No one wants to be “on-call” and woken up at 3am because the data center had a power outage, or the database exploded, or the network had a routing problem. It’s not a fun job.
This often led to a two-tiered system of highly paid software developers who wrote software, and less highly-paid and second-class software/IT people who actually had to deal with that software when it crashed or otherwise had an operational problem.
It also led to crappier software. When the people who write software don’t have to deal with the woken-up-at-3am consequences of it crashing, then those people tend to write less stable software with more bugs over time. After all, it’s not their jobs to keep it going.
So in the last 10-15 years, there’s been a turn towards unifying writing (“developing” / “dev”) software and operating (“ops”) into “DevOps.” Basically, all it means is that the same people who write something are also the ones that keep it running in a live environment.
These days it’s getting increasingly rare to find a company with a dedicated “operations” team. Most companies, especially big tech companies, expect their developers to also be on-call and fix any problems in production that the code they wrote might create.
This means jobs that “developers” usually didn’t have to worry about because other teams handled them: network rules, storage, redundancy, testing, on-call, build and deploy, etc. are now considered to be part of the job for a lot of software development roles.
It used to be a standard operating model at software companies that the people who actually *write* the software, write new features, fix bugs, etc. and the people who actually *run* the software as a service once its done, are separate people on separate teams.
Once the software was “done,” and launched as a live service, it was a different team who kept that software running, got paged and woken up if there was an issue, had to be “on-call” to fix outages, run the actual data centers and the servers in them, etc.
One problem with this model is that writing software is a lot sexier than running software. No one wants to be “on-call” and woken up at 3am because the data center had a power outage, or the database exploded, or the network had a routing problem. It’s not a fun job.
This often led to a two-tiered system of highly paid software developers who wrote software, and less highly-paid and second-class software/IT people who actually had to deal with that software when it crashed or otherwise had an operational problem.
It also led to crappier software. When the people who write software don’t have to deal with the woken-up-at-3am consequences of it crashing, then those people tend to write less stable software with more bugs over time. After all, it’s not their jobs to keep it going.
So in the last 10-15 years, there’s been a turn towards unifying writing (“developing” / “dev”) software and operating (“ops”) into “DevOps.” Basically, all it means is that the same people who write something are also the ones that keep it running in a live environment.
These days it’s getting increasingly rare to find a company with a dedicated “operations” team. Most companies, especially big tech companies, expect their developers to also be on-call and fix any problems in production that the code they wrote might create.
This means jobs that “developers” usually didn’t have to worry about because other teams handled them: network rules, storage, redundancy, testing, on-call, build and deploy, etc. are now considered to be part of the job for a lot of software development roles.
It used to be a standard operating model at software companies that the people who actually *write* the software, write new features, fix bugs, etc. and the people who actually *run* the software as a service once its done, are separate people on separate teams.
Once the software was “done,” and launched as a live service, it was a different team who kept that software running, got paged and woken up if there was an issue, had to be “on-call” to fix outages, run the actual data centers and the servers in them, etc.
One problem with this model is that writing software is a lot sexier than running software. No one wants to be “on-call” and woken up at 3am because the data center had a power outage, or the database exploded, or the network had a routing problem. It’s not a fun job.
This often led to a two-tiered system of highly paid software developers who wrote software, and less highly-paid and second-class software/IT people who actually had to deal with that software when it crashed or otherwise had an operational problem.
It also led to crappier software. When the people who write software don’t have to deal with the woken-up-at-3am consequences of it crashing, then those people tend to write less stable software with more bugs over time. After all, it’s not their jobs to keep it going.
So in the last 10-15 years, there’s been a turn towards unifying writing (“developing” / “dev”) software and operating (“ops”) into “DevOps.” Basically, all it means is that the same people who write something are also the ones that keep it running in a live environment.
These days it’s getting increasingly rare to find a company with a dedicated “operations” team. Most companies, especially big tech companies, expect their developers to also be on-call and fix any problems in production that the code they wrote might create.
This means jobs that “developers” usually didn’t have to worry about because other teams handled them: network rules, storage, redundancy, testing, on-call, build and deploy, etc. are now considered to be part of the job for a lot of software development roles.
Ask ten people, and you’ll get at least fifteen definitions of what DevOps is. The only universal trait to all definitions is that involves somse sort of crossover between the Developer skill set and the IT Operations skillset. Some recurring ideas involve:
* No writing code then throwing it “over the fence” and letting operations worry about deploying to your servers. Developers should be involved in the day-to-day management and operation of their own software. This leads to things like reliability, monitoring, etc being baked directly into applications.
* Systems administration/operations was historically a largely manual process, with maintenance and configuration changes being performed by hand, but manual processes are slow, tedious, and error prone, and an all-around waste of precious engineering time. Instead, you use development skills to automate everything.
Latest Answers