The idea of DevOps — short for developer operations — being a discrete role in Software Development doesn’t make a whole lot of sense to me. As I have had quite a few conversations about this in the past few weeks I felt it might be useful to get my thoughts written down.
The original concept of DevOps as a culture of continuously automating, improving and monitoring all stages of the Software Engineering process is great, and I believe it will only become more important as businesses move toward using a whole host of micro services rather than singular monolithic systems.
However, in recent years the term has been, in my opinion, bastardised to describe a new type of job role which sits somewhere between a Software Engineering generalist and a SysAdmin. What does the day-to-day responsibilities of a “DevOps Engineer” consist of? It’s somewhat hard to say because, as is usually the case in technology job titles, there is no hard-and-fast definition (What’s a code wizard again and how is that different from a code ninja?). However, in my experience and from what I have read online in job listings they usually develop and manage deployment pipelines and cloud/local hardware infrastructure as well as monitoring services and applications for errors and performance issues.
I have always felt that one of the markings of a good Software Engineer is their ability to understand the entire lifecycle of their application, from developer experience at the time of initial development through to deployment and ongoing monitoring & maintenance. Looking at any one stage of the lifecycle in isolation means that easy wins are missed; for example writing code so that it is easier to maintain in the future or selecting a stack which can be bought to life quickly to enable more fine-tuned scaling. In the worst cases that I have personally witnessed developers have created a fragile, complex mesh of services and infrastructure rather than simplify and improve things knowing that it will never be them that is woken at 3am to fix it — it’ll always be the DevOps guy.
In short, the most obvious issue with having DevOps as a discreet role is that it encourages, and in some cases mandates, “chucking things over the fence” — in other words solving problems by making them someone else’s. That’s no way to run an effective engineering team and means that the DevOps engineers often get the short straw.
Software Engineers are in the rare and enviable position of being able to produce their own tools — most farmers can’t build their own tractors and most pilots can’t build their own planes — and are the people who know exactly what tooling and processes would enable them to work faster and smarter in their day-to-day roles. They should use this position to enhance their own productivity and build & maintain better services.
One downside of requiring all engineers to understand the operations aspect of their code is that the knowledge of what tools and best practices are available needs updating frequently as the industry moves forward at an ever-faster pace, but this is true of all aspects of our jobs as Software Engineers. The correct solution is to make each engineer the master of their own destiny regarding deployment and maintenance and provide them with time to learn and develop their skills in this regard.
I originally started this blog post intending to write about something else, so I hope this will at least be of use to someone (even if it is just me referring back to it at some point in the future)
Today was pretty good, and set me off on hopefully a very fruitful project!
The day started as most days do for me, with a mad rush to catch the bus to get to my first period lecture on time, which today was an IT and Professionalism Module Test, unfortunately that proved to be a waste of time as a design fault in the IT system (somewhat ironically…) stopped us from being able to log into the test page we needed on eBridge, so after 30 minutes of twiddling our thumbs the test was abandoned.
I then had an hours wait till an entertaining programming lecture with Rob Miles, followed by a Operating Systems lectures, followed by IT and professionalism — a busy 3 hour stretch.
After another hours wait in Sanctuary (the Hull Student Union bar) I headed to meeting room 4 of Student House for a seminar provided by the Oracle Education Foundation. Oracle is a huge multinational software company which owns a 42% share of the database market around the world. It is estimated that 80% of working people will have used at least 1 Oracle product today, a massive figure!
I don’t usually look favourably upon Oracle for the issues that have occurred with MySQL since Oracle aquired MySQL AB, however this seminar was absolutely fantastic and gave great insight into the technology sector job market and globalisation as a whole. Essentially due to previously undeveloped countries, such as India, suddenly becoming big in the technology coupled with remote employment (people working from home, anywhere in the world, with some “teams” spanning multiple continents) the amount of people applying for each Computer Science role has increased, meaning more competition — because of this each of us has to have as strong a list of skills and CV as possible.
Oracle therefore offer a competition to allow people to acquire and hone their skills and add to their CV, its called ThinkQuest as you may have assumed from the title. The outline of the competition is that you have a team of 1 – 6 as well as an adult (usually lecturer) team leader to guide you and you outline an issue that you feel needs solving, e.g. “children’s rights” and then develop a solution (either an application or website). The team who last year chose “children’s rights” as an issue created a website and games to raise awareness of the issue and came in second place.
Its a competition so it has prizes! These include
- Trips to San Francisco to meet top Oracle Developers for a week
- Money for your uni
- Chance to apply for a PAID internship