It's possible that I'm just getting very pessimistic, but at this point I'm fairly confident that companies love it because it makes it way easier to attract candidates and describe one set of responsibilities/position in an interview process, and then bait-and-switch it into what is effectively a systems administrator role.
The work also really isn't the same. Unless you're stuck in the 90's we aren't building servers, installing operating systems, installing applications and installing patches anymore.
When I read this though, I just think about how much time your developers are not actually developing because they're doing operational-side work.
I have the situation where my developers do this stuff, then things break or need debugging and they don't really know how to dig into any of this stack in any meaningful way, so the problems tend to compound. Meanwhile, they're not writing code. The cadence of development seems massively slower to me (coming from a traditional background where they're writing to a clear Ops-set target environment).
The logical outcome is to hire someone who is an expert in all this infrastructure stuff to help manage it - ostensibly, a "DevOps" person, but really, a classic Operations person, just for cloud.
Cool. Cool cool cool.
Now instead of doing these things that first time takes a few days, second time a few hours and after that are barely noticeable you dev your thing, then it goes to an Ops queue, which (hopefully next day) comes back with a big fat "heute leider nicht" because you did not understand how the queue works or something. You fix your thing, it goes back to a queue, etc etc.
So your flow is still messed up and yout Time to First Eyeball has increased quite a bit as you have high latency round-trips with external parties.
Obviously there is a tradeoff somewhere, does the dev know all the opsy things or does she know enough to only need to ops when the paved road is not enough or is it the good old "over the wall it goes".
This is pretty much a waterfall vs. iterations discussion where the reality is that the world doesn't stop moving while you're working.
If a product team needs to deliver something (i.e. "allow users to select a delivery window for an order"), they might update their microsite with the components and API calls to do this, and then update their API microservice to exchange that information based on the customer's identity (so they can only update their own order delivery data). None of that knowledge is going to exist in a classic ops team, nor should it be if such a team were still relevant.
At the same time, that team might need to take into account that there might be order peaks during the day and they have to collect and act on the right metrics to know how well their code works, how many resources they are consuming and what their scaling policy should be. None of that has anything to do with ops either.
Then, at the end of the day, they'll use all of this information and domain specific knowledge to decide:
- is the feature complete
- can users make proper use of it
- do we need to invest time and effort in code optimisations
- do we need to extract this feature into a separate scalable entity to prevent disruptions to neighbouring features
What ops (or devops enablers) would be doing in this case is:
- make sure metrics aggregation is working as expected
- make sure scaling is working as expected
- make sure deployments and configuration updates are working
- construct new deployment options if needed
- construct new metric aggregation systems if needed
- construct new scaling and traffic management systems if needed
- notify the teams/owners if they are using deprecated resources or features for too long
A developer isn't just a 'writes some code, clocks out' type of value to a company. If it was that simple, robots could do it, and there would not be a shortage of skilled people. There are many more dimensions to work, and unless you work at a very large scale company, or a very restrictive company, it's highly unlikely that you'll be isolated from the world and just write a bit of anonymous source code with no idea of what happens before or after.
> small feature-owning teams build and maintain their features, devops people enable many small teams to do their work by providing shared systems.
So I don't think I get your point. The stuff you've listed here just looks like stuff straight old Ops would do, set the parameters for Dev, and then things would just roll on. Saying "ops (or devops enablers)" like that is confusing me because the whole point of the original article (I thought) was to note that DevOps has basically become Ops, so what have we actually achieved?
i.e., that as soon as you distinguish between "devs" and "devops" people, you've basically already drawn a line between traditional dev and ops roles.
DevOps doesn't become ops, and devs don't become ops either. The only ops left is perhaps contract management that really doesn't have anything to do with the developers.
DevOps can mean the practise of intersecting tasks that classically would be categorised as either development or operations, but it can also mean the people with enough skills to understand the needs of the developed features as well as the requirements of a useful infrastructure.
Take a very dated example:
- Operations might request new server hardware purchase orders
- Then they rack it, install an OS
- Someone else, say, application management, installs Jenkins on it
- Someone else yet again configures Jenkins so Developers can use it
- A developer now logs in to Jenkins, and clicks build on their product or entire project
- Operations gets a fax from Jenkins about a new build being ready to be installed
- Operations sends the build to a different application management person
- Different application management installs the new build
- Developer can finally see the end result
Instead of all that we have new tools, and new grouping of activities which run in parallel:
DevOps-enabling person:
- Notices a shared CI system would benefit everyone (developers, customers, finance)
- Proposes such a system and perhaps presents a demonstration
- Configures a virtual or container system from any XaaS provider to provide this CI system to anyone who wants it
- Adds integration with SCM
- Tries out a few builds to test SCM lifecycle
- Writes code, commits to SCM
- SCM fires a CI pipeline
- Developer can see the end result
- Makes additional modifications, immediately sees the result again because nobody else is required to perform those tasks
- Maybe additional CI options are needed, create commit with CI changes and update CI to have those extra options available
- Instant results yet again
Operations is dead, unless you are still playing datacenter at the office. The closest remaining thing is the service desk and perhaps desktop management for end-users that are locked into some Citrix hell. But we were talking about DevOps which is the intersection of Development tasks and Operational tasks, not end-users and office equipment ;-)
I guess I am stuck in the 90’s then, I absolutely do all of the those still.
Not every thing is “sever less” you know.
There's a long path from that to ansible and terraform on SCM.
Another big difference I have experienced: we used to literally celebrate server uptime (I mean as a celebration, I have a distinct memory of gathering around an IBM "fridge" to celebrate the uptime birthday of a particular RS/6000) while now a piece of infra with too much uptime is a red flag about potential vulnerabilities.
What does largely remain the same, I think, are the skills needed to be good at this. Then, and now, we need people who don't mind reading manuals, searching online (this was already a thing when I started, I guess you'd have to go back to the mid 90s for this to not be the case?) , who can keep track of where they've been during a debugging/troubleshooting session, that sort of thing.
Another thing that changed is that in the past some people considered it a badge of honor to be assholes to others not in sysadmin, even more to others not in IT (remember those "select * from users where clue > 0" t-shirts, or the BOFH stories?), while now that's typically frowned upon and quite a few companies are explicit about a no assholes policy in their hiring material (or perhaps I've just been lucky with my teammates and smarter when picking where to work at than when I was younger).
I meant at a very high level. The basic responsibilities haven't changed.
* Deploy/configure infrastructure
* Deploy applications into infrastructure
* Monitor/Secure/Maintain infrastructure
* Scale infrastructure as needed
You can call it "Sys Admin", "DevOps", "Site Reliability Engineer", or whatever, these are all largely the same "Make sure the infrastructure works, is secure, scalable, and help deploy to it." Even with with "cloud managed" things, you still need to setup, config, and secure it. You can have "cloud managed" k8s, it isn't going to stop developers for using bad practices, like running containers as root, and not having a standard deployment process (because each dev is just doing their own thing).
The biggest tip off - any company with a "DevOps" group or dept isn't doing DevOps. Yet there's a ton of DevOps departments out there
Building out and automating cloud infrastructure so your simple code can work is way more complex than most things you do every day. But ya, keep telling yourself how smart you are as your write "connect to database, return a value" for the 1000th time.