Over the last year I have had a number of adventures, some good and some bad – but all of them experiences. Last month I read about a term for the 1st time that really spoke to me, it encapsulated a concept which had been brewing in my head for a while – a DevOp, Developer Operator.
In November last year I was in Madrid attending SAP TechEd, and you could not move for people talking about various platforms and Developers being the new kingmakers – being an Basis guy specialising in infrastructure it may have been boring for many people, but for me the lightbulb was turning on. I was very interested in how to connect technologies together, not just how to build the infrastructure and let other people worry about that stuff.
These thoughts fermented a little more, I continued to experiment with Ruby, C# and my Microsoft Kinect – gaining some more skills as time would allow. At Teched I met the excellent James Governor and Tom Rafferty, two analysts from Redmonk who I have a great deal of time and admiration for. After following them on Twitter for a while, I found out about Monkigras, a developer conference in London. I glanced at the attendee list and booked my ticket, paying for it myself as I figured “why would my employer pay for me to go to something so far outside my day job”, took 2 days leave and arranged to stay at my friend’s house.
Despite knowing only 1 other attendee, Monkigras would turn out to be an amazing conference, I heard lots and lots of new words, understood perhaps about 20% of them and had to make copious notes of the others. The thing that I took away from it the most was the developers and APIs are the future, infrastructure is a commodity that just needs to exist – the real value is in the data and it’s manipulation. “It always has been” I hear you cry – well that is correct but instead of putting it into Excel and making stupid graphs or putting it into PowerPoint, lets use applications to perform transformations, link it to other data attributes from another data set through an API and turn it into something amazing – this link is from a speaker who used GitHub and LastFm to create a music map of developers
For me my true love is not code, I like the idea of it and messing with it, but if you tried to get me to write as a job, one of us would be dead in about a week – so I thought some more about what the perfect balance would be. My good friend Simon McCartney came to mind, an exceptional infrastructure administrator and someone who is comfortable working with code, he calls himself a digital carpenter, Hugh MacLeod would call him a digital crofter. The ability to continue to work as an infrastructure person along with the ability to work with scripts and code is a powerful combination which provides a great deal of value to your business and the team.
We are uncovering better ways of running
systems by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes over tools
Working systems over comprehensive documentation
Customer and developer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more
There are a number of reasons why I am drawn to the way of the DevOp, most of them are encapsulated above, and perhaps I will explore these personal areas in more detail in public and risk the wrath of various people, then again perhaps not. The one of the main attractions being that with shorter life cycles and products becoming easier to deploy, a multi-talented person who is a solid ‘all-rounder’ will be in greater demand than the 2 or 3 niche people you would have hired previously, as software lifecycles are shorter – living with your mistake is not as long as it used to be.
Another thing I like about development, it the ability to do really smart things with data like this visualisation of Facebook relationships – how totally cool is that picture which is derived from the most basis data which can be queried form the Facebook social graph
So for now I am going to continue down the road of becoming a DevOp, taking every opportunity to deploy a code or script solution to improve my effectiveness and provide increased value for my clients.
Ultimately I want to build things, real, virtual and data based. I want those things to mean something, to me and my clients – As Hugh MacLeod would say – I have the Hunger and I am damn well going to use it
Brilliant, Chris! I’ve always maintained that good admins know how to write code and, more importantly, how to troubleshoot and tune code. I have frequently written code for tasks that were simple, or that I could not obtain tools for, e.g.: my SCN blog series on using perl and python (which doesn’t show up under my userid anymore – an issue I’ve been wrestling with ever since the SCN upgrade, unfortunately)
http://scn.sap.com/people/community.user/blog/2009/06/19/perl-and-sap-adventures-part-1
I’ve also enjoyed writing code for many trivial but fun tasks similar to the mapping one you mention, and others. Because, in the end, it’s good to produce something every now and again, not just to fix things when they break. :)
Cheers,
David.
Well said. Basis admins and Infrastructure folks can greatly benefit from coding skills. When I see my basis friends repeat similar task 100s of times and use a lot of monitoring transactions (repeatedly), I always thought a combination of basis and development skills will go a long way in making their life easy. One e.g. is custom CCMS routines in the SAP world.
Cheers
KK
David,
I have never been a massive coder, sure I can take 2 or 3 scripts that do most of what I want and create a working chimera – but with the opportunities that available currently it is possible for people to create something great in a short space of time with few resources. Great to me is not necessarily life altering, but something that make your world and the world of those around you better in some way. It could be an automated installation script or a monitoring script that identifies when a service goes down and allows you to bring it back up remotely.
Thanks for the comment mate
Chris
KK –
I really could not agree more, I get so frustrated with people who are happy performing repetitive tasks, we were given brains and intelligence to work out better ways of doing things. I would rather spend 55 mins of a repetitive task to automate a way to do it so it takes 4 minutes. It leaves me 1 minute better off that time, but it leaves me 56 minutes better off the next time – hell even if it takes me 2 hours to automate it I’m still better off. I can then blog about it and put it out in the world so others can benefit from it.
Thanks for your comment
Chris
I agree completely. I started out life as a programmer rather than as a systems admin. More than that, I did a Computer Science degree that taught me not only how to program but also how the machines work under the covers. I’ve found that knowledge immensely helpful when writing code, and similarly knowing how to write code helps when setting up and administering the systems than run that code.
The analogy I’ve always used is that of driving. You don’t need to know how a car, and in particular its engine, works in order to drive and get from A to B. To drive really well, though, such knowledge is indispensable. In the extreme, for example, Formula 1 drivers know is great detail how their cars work. They can’t do their job without that knowledge.
In the SAP world I would take this one step further. I started out doing Basis admin, but very easily branched out into ABAP programming based on my previous programming experience. From the point of view of understanding what is going on on an SAP system, though, what helped me more was functional understanding. I taught myself first how to use the various functional areas – post POs, journals, etc. – and then how to configure them. I’m certainly no expert in any functional area, but I can get by and in an emergency I have been know to fix the odd problem. Understanding how data flows around the system, and what is going on in each transaction, I find a big help.
In essence, the more you know about what the systems do and how they do it, at all levels, the better you can set up and run the technical infrastructure.
@BoobBoo
Those examples can be life-altering, too. Especially if you’re the one on call and you catch things before they lead to downtime.
That was exactly my case when I started implementing monitoring functionality with perl. We couldn’t get money for monitoring tools, so I wrote what I needed, and it turned out to be a life-saver, indeed!
@KK – perfect example of CCMS custom monitoring routines, too!
@Steve – I remember working at my University wondering why they didn’t even have Unix admins, until I realized they did, but their title was “system programmer.”