(c)iStock.com/franckreporter

The DevOps Enterprise Summit last month had a record number of attendees and speakers, all of whom were there to discuss the tremendous positive impact DevOps is having within the enterprise.

When representatives of financial services companies (not the usual industry of early adoption) such as ING, CapitalOne and Bank of America are listed among the speakers, it’s time to pay attention. This and the preponderance of articles presenting evidence, that enterprises of all kinds and sizes, are showing tremendous gains through the implementation of DevOps practices has to get the rest of the technical community thinking.

Let’s face it: which CEO wouldn’t want to see their development and operations teams and their business working seamlessly to define, deploy and maintain services for customers? Which CFO doesn’t want to hear that maintenance of services costs are down significantly?

As I recently wrote in Stop talking about cloud – and start talking about what cloud can enable: “DevOps is more than just a shift in how operations, development and the business stakeholders technically work together to develop new services. It is a cultural shift within an enterprise, which changes how business and technology relates to each other.

“This cultural shift causes technology organizations to move at a different pace than previously – a pace which can keep up with the business demands of time to market, as well as product and services lifecycles.”

So for those of us who could use a refresher into DevOps, I offer the following quick overview on DevOps components and benefits. There are many ways to implement DevOps and many components to choose from, not all listed below.

As with any methodology, an enterprise should choose those components that are appropriate to their situation. As this is only an overview, I remind the reader that a good deal more research needs to be done before trying to implement any of these components.

Community and culture

All the technology and tool changes in the world cannot replace the need to fundamentally change how the parts of a business (technology, architecture, engineering, application development, sales, marketing, product development) work together.

That may be a bold statement, but ask anyone who has successfully implemented a DevOps program. Without the following cultural mindset your impact will be limited:

• The various organisations need to see themselves as one team heading in the same direction.
• Process is critical and it needs to be a custom fit for the enterprise.
• Leadership is responsible to remove process roadblocks, not just reduce them. Anything that slows the teams down without a serious business reason needs to be looked at.
• All team members need to see themselves as a key part of the team. Get rid of the “it’s not my job” mentality.
• Start small and expand the community over time.

Application and infrastructure development

There are specific parts of DevOps that are development specific, but the all other teams need to understand what the development teams are doing and how they need to be supported. When I speak about development I am including a team that is creating components of the solution, application, API, tools, or infrastructure.

• Employing an agile methodology that fits your enterprise (and is common across the enterprise) is the first big step.
• Deployments need to be small and focused. This will allow for quick identification and repair of bugs as well as enable rapid/continuous deployment of new features and functions. This is one point where the rubber-meets-the-road in terms of rapid reaction to changing markets and business requests.
• As part of the deployment process, testing needs to be well defined, highly focused and rapidly executed. This may be one of the most difficult parts of the DevOps process to implement but also has the biggest impact.
• All application development should be based on APIs and software as a service (SaaS) concepts. Code and configuration repositories, Source code and configuration versioning and controls,  API and service based access to functionality. These provide flexibility and compartmentalisation necessary for continuous and rapid deployment.
• Infrastructure as code (IAC) is becoming a very big component of DevOps. In short IAC is the use of code development practices in the development and deployment of infrastructure configurations.

Operations and orchestration

To clarify: operations are not that group down the hall that we toss applications to! DevOps, as the name implies, requires that development and operations are partners in the creation, deployment and management of services.

Operations, as well as business stakeholders, need to be involved in the development process from the beginning. This will allow for the definition of supportability, testing, management, and security aspects of the services.

• Much the same as developing code around APIs, operations components should be developed as building blocks. This will, once again, increase flexibility, supportability and rapid issue resolution.
• A great concept that I recently heard about is the use of Flash Build Sessions to include partners and energise teams as part of the infrastructure and operations development process.
• While the choice of platform is a enterprise wide responsibility and needs to be considered seriously by all involved, a hybrid cloud platform is the platform of choice for agile enterprises. Hybrid cloud allows for rapid deployment of new services, issue resolution changes and upgrades.
• A standard set of orchestration tools coupled with hybrid cloud allow all involved to work more efficiently and more collaboratively.

Supporting concepts

There are a number of general supporting concepts that help enable a DevOps collaborative environment within the enterprise. Some of the top areas to keep in mind are:

• Consistent and continuous communication between teams and within teams is critical. Chat, Instant Messaging, Social networking, and/or email, whatever works for the enterprise.
• Leadership. DevOps cannot exist without strong leaders. Leaders are those who are willing to lead efforts by example and not by managing.
• Strong External Technology partnerships. Keeping your partners close will keep projects moving. They have knowledge about their components that you need and they are willing to share.

In conclusion, enterprises of all sizes and shapes are moving towards DevOps models. Many of the models differ greatly from each other, even within the same industries. The best way to get started is to choose a small team, a few things to change and one project to try this out on. There will be bumps in the road but keep trying and the benefits will show up eventually.