When applying for a job, usually you can find two types of similar jobs: Sysadmin Engineer and DevOps Engineer.
Both of them deal with server configuration and ensure the reliable operation of computer systems. It can be hard to tell the difference between the two. What are the main differences between them?
Mainly DevOps is not a role (when used as such it's more a buzzword than a real role).
DevOps is roughly an organization pattern aiming at breaking the silo between developers and sysadmins.
The main goal is to build teams with devs and sysadmins (along with testers usually) responsible for a product (application) from its definition, architecture decisions up to the maintenance in run of this product.
Each member of the team will be part of the decision on the whole life-cycle of the product, a dev will do some sysadmin tasks in production, and a sysadmin will participate in the design phase of the product to avoid caveats from the infrastructure perspective for example.
At ideal, a sysadmin would also be part of the development team for the product, in real world sysadmin code more on the configuration around the product and monitoring solutions, but being able to voice concerns to other members of the team avoid a lot of misunderstanding on the deployment process.
DevOps a combination of organisational culture, Agile/Lean ways of working and software automation that when applied to Systems Administration and Operations allows these functions to operate with the same level of Agility as Agile or Lean Development Teams.
The ideas behind DevOps came out of the Systems Administration, Operations and Agile communities, specifically, Patrick Debois gave a presentation at Agile2008 entitled 'Agile Infrastructure' where he highlighted the disparity between the way the three functions within an organisation operate:
Debois' proposal was to unify the three ways of working together, specifically moving Systems Administration teams and Operations teams from a Waterfall Model to an Agile Model. To that end, Debois setup DevOpsDays 2009 in Ghent, Belgium inadvertently coining the phrase DevOps.
The idea of DevOps resonated with the Authors of the VisibleOps series of books: Gene Kim, George Spafford and Kevin Behr; who went on to write The Phoenix Project and The DevOps Handbook. Both books explore how Agile and Lean can positively impact Systems Administration and Operations teams.
As a DevOps Engineer coming from an Operations background, you will have moved from building and deploying servers and software manually to scripting the installation of software onto your servers with the likes of BASH, PowerShell, Python etc. After a while, you would realise how cool scripting is and start to explore more sophisticated ways to automate deployment.
Eventually, you would have settled on a Chef, Puppet, Ansible or other configuration management tool to help manage the state of your fleet of systems. As your skills with the automation of application deployment and system management matured, along with your tools, you have more recently moved into the realm of 'Infrastructure as Code' and use it to not only automate the deployment of software but the infrastructure and environments required to drive the software during the business's shift to the Cloud.
Now you are cooking with gas. Over time you have been introduced to the benefits of using developer centric tooling such as source control to manage the modules, recipes and templates that make up your arsenal of deployment and management tools.
When you shifted into the DevOps team you were exposed to the software development life cycle and the concept of continuous integration. Boy those developers were releasing changes quickly and to keep up you found yourself working more closely with the devs! You experienced the urgency placed on the development team to change things ALL-THE-TIME which grates against the old operational paradigm of "if it ain't broke, don't fix it". No more bragging about system uptime anymore, you are into disposable infrastructure.
You noticed that the move to DevOps was more than working with the devs, or using new tools and techniques, but there was a distinct cultural shift in the team, one that permeated through the organisation at large. You were working as a close-knit team with shared responsibilities, shared tooling and shared goals.
You took your skills in automated deployment and massaged them into the "CICD" pipeline being orchestrated by a "continuous integration server" like Jenkins, Bamboo or Code Pipeline. Now, when the developers push new code, your scripts, tools and templates stand up new environments on demand, trigger testing frameworks to do their thing and tear down the pre-production environments after the green lights are lit on the release, adhering to the ideas of "continuous delivery".
As the new code snakes its way through the CICD stages, you, the developers and the business gain confidence that the update will not break when released to production. There is some way to go before the team gets to "continuous deployment", you still need to settle on the finer points of automating the blue/green deployment capability, and the decision is mostly a business one. For the time being you are content that the number of calls at 3am have subsided and the sev-1's and sev-2's dwindle.
Even if you do get a sev-1, you are not pulling all-nighters any longer with the managers breathing down your back - you can easily release the previous version through the CICD pipeline and get the system online again in short order. The business has noticed that the stability of the IT systems has improved despite the velocity of changes.
You marvel at the way you manage the resources needed to drive the software in your business, especially when you think back to how it used to be and amount of blood you left behind on rails in the datacenter...
Sysadmin vs. DevOps (personal view)
Some companies talk about Dev, Ops and Test. If something needs to be tested then they say: "Test should do that". If something needs to be developed, Dev will do that and if software needs to be deployed, Ops will do that.
In my opinion and what I have experienced at several companies is that this results in a "throw it over the wall" mindset that results in friction between people and teams. Personally, I sometimes feel that people work individually and say this is what I did, I have nothing to do instead of working as a team.
According to me DevOps means that everybody in a team is responsible and busy with development, testing and operations. There is no I in a team and no separate departments. Everybody should release. Of course there are specialties, but in my opinion everybody should be able to do at least 25% of some work in every area. E.g. if someone was a Developer back in the day then one should be able to change some configuration management code, e.g. chef and deploy software.
References
Sysadmin
According to Wikipedia:
A system administrator, or sysadmin, is a person who is responsible for the upkeep, configuration, and reliable operation of computer systems; especially multi-user computers, such as servers.
The system administrator seeks to ensure that the uptime, performance, resources, and security of the computers he or she manages meet the needs of the users, without exceeding the budget.
To meet these needs, a system administrator may acquire, install, or upgrade computer components and software; provide routine automation; maintain security policies; troubleshoot; train or supervise staff; or offer technical support for projects.
DevOps
According to Wikipedia:
DevOps (a clipped compound of "development" and "operations") is a software development and delivery process that emphasizes communication and collaboration between product management, software development, and operations professionals. It supports this by automating and monitoring the process of software integration, testing, deployment, and infrastructure changes by establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.
A system administrator is responsible for maintaining and configuring servers and their responsibility is to ensure the user with the performance, uptime and security that they are looking for. Defining the role of a DevOps engineer is a little more difficult since there is no formal career path and DevOps itself can have many forms.
A DevOps engineer can be, for example, a developer who is interested in network and deployment operations or a system administrator who has a passion for coding and scripting. The transition from system administrator to DevOps engineer is not very difficult, in fact, this article does a very good job describing the process.
Many people would even argue that this transition from system administrator to DevOps engineer is essential since the position of system administrator will become obsolete in the future. Even though there are plenty of legacy servers that need maintenance and system administrators possess a lot of “tribal knowledge” the sysadmin position will become more scarce in the future.
There is going to be servers which you do not hear running in data centers. Everything is going to be software. Storage, network, systems, security, data centers; SDN, firewalls, NFV, storage, servers, etc. Sysadmins without a software development background, SDLC experience (I don't even mean scripting Perl, Powershell, etc) will probably vanish. Distributed, scalable and virtualized environments, which is mostly cloud, grow horizontal not vertically.
I dare to say Sysadmins grow vertical, DevOps (or OpsDev) grow horizontal. You can see the same pattern how microservices evolved from monoliths. I would rather choose DevOps engineer from software team not from operations/system team.
Because operations/system team just runs what software team builds.
Sysadmin start working after CI/Continuous Delivery/Deployment ends.
And if you break and assign Deployment/Delivery, it could be a broken pipeline
the software team is the creator system/operations team are the runners/caretakers mostly.
It sounds like there is no server/system to administer, no sysadmin need.
Serverless computing is a cloud-computing execution model in which the cloud provider acts as the server, dynamically managing the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity Serverless computing
Someone from the software team already knows how to build, maintain even how to code (SRE vs DevOps/OpsDev).
I wonder why it is called DevOps but not OpsDev? is it related to the direction between the two?
*In the middle of nowhere, I did not start writing about software-defined storage, this is in reaction to a now deleted comment about it *
Software-defined storage (SDS) is a marketing term for computer data storage software for policy-based provisioning and management of data storage independent of the underlying hardware. Software-defined storage
EMC announced its first ever open source product: Project CoprHD. CoprHD is a Software Defined Storage automation and management controller, and EMC’s recent decision to open source it is at the crux of our strategy for delivering greater value to global businesses as we enter into an area of growth and extreme change. As the world’s leader in storage and information management, it behooves EMC to lead the way on Software Defined Storage (SDS).
CoprHD is an open source software-defined storage controller and API platform. It enables policy-based management and cloud automation of storage resources for the block, object and file storage providers CoprHD
