The Operations Developer

In an earlier post, I outlined why I think that there is value in enterprise developer specialization.  I concluded that there are four emerging classes of developers: User FacingMobile, Business Logic and Data, and Operations.

In the past, operations was a separate role and often team working outside the development team.  The DevOps movement led many developers to acquire operations skills and move that work back into the development cycle.  When this amounted to a build-migrate-deploy cycle, it was reasonable for full-stack developers to do this work.  Now, the operations landscape is sufficiently complex that a skill class has emerged.  Operations Developers (and yes, they are developers) concern themselves with deployment scripts, infrastructure automation and cloud technologies.  They do not maintain build scripts or Continuous Integration implementations; those are the domain of the other developer classes.  Instead, they provide “infrastructure as a service” (IaaS) to the other developers and concern themselves with secure and stable scaling of that infrastructure.  Puppet, Chef, AWS, Azure, OpenStack and Docker are some of the relevant technologies.

Like the User Facing developers, the technology landscape in this space is relatively new and rapidly changing.  Migration from data centers to the cloud has been under way for some time, but still few best practices exist for making that transition.  New models including containers like Docker and PaaS offerings like Elastic Beanstalk are moving further from the lift-and-shift into the cloud into a fundamentally new way of managing scaling and deployment.  Other emerging techniques, like optimizing for minimum-time-to-recovery over mean-time-between-outage are pushing the robustness of instance creation, deployment and database sharding.  Multiple regional availability zones for application performance improve the user experience but greatly complicate handling data.

Success in this space requires a voracious appetite for learning and experimentation.  It also requires a thick skin; when things go wrong these developers are often blamed, regardless of the real root cause.  These roles are critically important but often undervalued; institutional memory of past inefficient operations groups sets a bias that these roles are not really for developers.  Understanding that this is a misconception and that “configuration as code” is a real model is important.  This is the easiest developer space for system administrators to transition into, and the future for data center technicians.

Author: Kevin Hickey

I have been a professional software engineer for over fifteen years. I currently work at Intuit as an architect. I have written bootloaders, ported the Linux kernel and Android to new platforms, written CPU diagnostics, developed control software for CPU manufacturing and worked on enterprise web sites. As both a developer and program manager I have been helping software organizations become more agile for over a decade. I am passionate about helping teams deliver world-class software solutions to interesting problems. My current focus is on pragmatic agility for the enterprise. When I’m not behind a keyboard I enjoy spending time with my wonderful wife Amanda, rock climbing and hanging out with my dog Tex. In the summer you can find me in my pool or climbing something. In the winter I count the days until summer returns to Texas (I never have to count too long).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s