Everyone is painfully aware that as technologies improve and evolve it becomes harder to deliver new features with quality to demanding customers. With new social and mobile applications customers have become trained to having their requests fulfilled within days and weeks versus the more traditional months and even years that we have seen in the past. So as many folks have done you have turned towards DevOps as the savior to help you deliver features faster. However to really adopt DevOps, one needs to introduce tools that promote good behaviors but you also need to make necessary cultural changes.
With the introduction of DevOps into an organization it is not unlike Sniff, Scurry, Hem and Haw having their cheese (success and happiness) moved within the maze of life in the great book Who Moved My Cheese? by Dr. Spencer Johnson. Before the introduction of DevOps within an IT organization, teams were content with slow processes which ensured quality but reduced the organization's ability to be lean and agile. The operations team has full control over all IT processes and changes to environments. They rely on older automation technologies (or manual processes) with little to no management of the changes. Folks were content during these times. It may be slow but no one cared that much as long as the work was done. This is the time in the book when Hem and Haw became content and arrogant because they had a seemingly endless supply of cheese.
Then the world began to change...
The cheese was moved...DevOps principles and tools were adopted.
Now Hem is annoyed, "Who moved my cheese?" The introduction of DevOps principles and tools has changed the game for how changes to environments are defined, managed, and delivered. Thus roles within the organization will need to change and/or emerge to deal with DevOps.
We are going to focus on four roles and the changes we are seeing due to DevOps.
- Release Engineer
- Application Developer
- Infrastructure Specialist
- (new) Infrastructure Developer
Before we jump into each role I wanted to call out two quotes that I believe are appropriate here. First, a quote from Haw that he chiseled on a wall within the maze:
Generally a Release Engineer
is concerned with the compilation, assembly, and delivery of software components. Often the role is responsible with defining and managing the Release Plan
, which includes the streams and iterations for the release. When folks talk about a Release Engineer they almost immediately think of the person that is responsible for setting up the build process to build the software components.
With DevOps we are seeing that the role of the Release Engineer is expanding to include the delivery process as well as the build. With new tools such as IBM SmartCloud Continuous Delivery, a Release Engineer is responsible for owning and automating the release process to build, package, deploy, and test software changes. The Release Engineer does not work in a vacuum. She must work with architects across the organization (e.g., Application, Operations, Test, etc.) to define which components are involved in a release, what test environments will be required for testing, what standard cloud patterns need to be used for testing, etc. The Release Engineer is the goto person for release process and is responsible for encoding (automating) the release process using DevOps inspired lifecycle process tools.
Everyone knows that the Application Developer is responsible for software development that involves the development of application code that will be built into software components. Application Developers are generally multi-lingual which is to say they are skilled in the development of multiple languages (e.g., Java, .Net, Ruby, etc.) and most developers today have some understanding of Agile development principles. These principles include iterative planning and development, test-driven development, module software components, self-documenting code, etc. A problem with many Application Developers is that they have little to no understanding of the operational environment that their code will be deployed which dramatically increases the potential for problems due to invalid assumptions and/or down right ignorance.
With DevOps the changes to the Application Developer role vary across organizations. Based on my observations the Application Developer continues to be primarily responsible for the coding and delivery of software components, but the developer cannot work in a vacuum. First the architecture of the application must be defined, readily accessible, and easily understood by everyone on the team (developers, testers, release engineer, operator, etc.). You don't need to have formal UML training to document your application architecture (but it doesn't hurt). Even creating a sketch of the architecture that is accessible to everyone would be a great first step. The importance of documenting the architecture is to understand the key components to be deployed and to document the assumptions the components make on the environment. This will help to drive development in the correct direction and avoid costly architectural mistakes that are not caught until late in the release. As you look towards tools, keep your eyes open for tools that allow you to document the architecture directly within code that is ultimately executed by programs to setup and configure environments (note we are exploring options in our SCCD project).
A second change in the Application Developer role is expanding his knowledge of the operational environment. Granted you will always have specialized developers that live in a vacuum but these will be few and far between moving forward. With DevOps it becomes much more important that Application Developers become operationally aware as they take on more responsibility for the quality of the deployed application and not simply the code. We are seeing that new technologies that are much more intermingled is a driving force for the Application Developer to be more aware of the operational environment. For example a COBOL developer will probably not care about the operational environment as much as a developer who uses Ruby, CSS, HTML5, JSP, Java, .NET, etc. It's this up-skilling on the front end that forces greater awareness of how things fit together. Application Developers generally do not want to be ignorant (I'm an application developer so I can say this). We want to learn and be more productive. What I have seen that works well is to team up application developer with a person from the Operations team that is responsible for reviewing software designs and operational skill transfer.
The Infrastructure Specialist is traditionally responsible for provisioning and configuring the infrastructure used for test and production environments. Provisioning of environments involves the setup of machines and networks and generally a standard operating system configuration. The Infrastructure Specialist's key responsibility is to ensure that an environment remains functioning at an acceptable level of quality usually captured as service level agreements (SLAs) in some form or fashion. Speed is generally not as important as stability and quality.
With the emergence of DevOps the Infrastructure Specialist role changes to be more useful to the business by providing services to request infrastructure on demand. Cloud is often introduced into the equation to provide self-service and dynamic, programmable infrastructure (Infrastructure as a Service). That is to say that Cloud (or another virtualized platform) provides APIs to quickly and easily provision new virtual machines. The Infrastructure Specialist is also responsible for implementing standards within the virtualized platform such as standard Operating Systems, networking, and storage that encapsulate organizational requirements. The Infrastructure Specialist further increases their value to the business by moving beyond just providing Operating Systems to creating standard platform images (e.g., Application Server, Database, etc.) and even in some cases standard virtual patterns (see IBM SmartCloud Provisioning) which is often referred to as Platform as a Service (PaaS). The standard images and patterns are not created in a vacuum. Just as an Application Developer collaborates on the definition of the application architecture, the Infrastructure Specialist collaborates on the creation of standard virtual patterns to be used by the development teams.
And now we come to a new role called the Infrastructure Developer but before we can describe this new role we have to discuss Infrastructure as Code. The idea of Infrastructure as Code has been around for a few years within the DevOps community. Carlos Sanchez has a blog simply titled Infrastructure as Code that does a nice job of stating the key points of Infrastructure as Code. For me the main point is that automation configuration of environments is evolving from basic scripts to new development languages (e.g., Chef and Puppet) for developing infrastructure code that should be developed and managed using the same rigor and tools as application code. We've stated in previous blogs that a team needs to plan and track everything as well as version everything. Infrastructure as Code and agile development tools provides teams with the ability to do just that. New technologies such as Chef and Puppet provide us with programming languages to develop and apply infrastructure configurations using the same development best practices (modular, self-documenting, test-driven) as application code. Tools such as IBM SmartCloud Continuous Delivery embrace and promote Infrastructure as Code development best practices.
Just as an Application Developer develops application code, an Infrastructure Developer develops Infrastructure Code. It's that simple. What we hear from many customers is "Where do I find these Infrastructure Developers?" The good news is that most companies already have folks that can fill this new role. What I have found is that the role will be filled most likely by existing Infrastructure Specialists or Application Developers. Look for Infrastructure Specialists that are willing to learn and especially any that have a development background. An Infrastructure Specialist generally will not be successful if thrown into the new role without some training. You should expect to train an Infrastructure Specialist to be an Infrastructure Developer by
- Teaching basic agile development practices
- Teaching of new automation technologies such as Chef or Puppet
- Teaching the use of agile development tools (e.g., IDE and SCM)
Pairing an Infrastructure Specialist with an Application Developer is a great way to produce an Infrastructure Developer. As I pointed out, it is also possible that the Application Developer becomes an Infrastructure Developer if they have the ability and desire to gain enough operational skills to develop the necessary automation configuration code. However, pairing the two roles together is a good approach to produce a person (or two) that has the skills to develop high quality infrastructure code. There is a whole discussion about changing team dynamics that we will save for another blog post.
In closing, DevOps is a major driver of change and process improvement within an organization. While change is scary, you have to ask yourself "What Would You Do If You Weren't Afraid?" as Haw does within the book. Sometimes change is good and absolutely necessary.