Centroida & ITCE have joined forces in finding the most efficient way to transition organizations to DevOps. Our teams have both researched and experienced the numerous challenges organizations face when introducing DevOps in their workflow. This article will give you some ideas what approaches to take to avoid common mistakes in your journey towards adopting DevOps.
Coming up with concrete steps for implementing DevOps is rather difficult. Every company experiences different challenges and DevOps doesn’t allow for a “one-size-fits-all” approach to be applied across the board. Moreover, the very introduction of DevOps to your enterprise could turn into a debacle if such a step is not carefully planned and executed. Corporate culture, variety of deliverables and the processes currently in place need to be thoroughly analyzed and serve as the basis for a transition roadmap.
Fortunately, there are established approaches which enable a smoother transition to DevOps which might benefit your enterprise tremendously. But before taking that route, each enterprise should identify its desired DevOps structure. Below are several options which you might consider:
Option 1: Strong technical leadership (close collaboration between Dev and Ops)
There’s a widely held consensus that across the literature on DevOps that an enterprise should target a seamless collaboration between the development and the ops teams. However, for this to be achieved, a company needs to have middle and senior management with a strong technical background in order to align both departments. For this to happen, management must encourage both development and operations to take an extra step towards learning from and about each other. The development team needs to start seeking out guidance on setting up environments and making their configurations transparent. The operations team, on the other hand, has to familiarize itself with the tooling and processes developers use to create features.
Option 2: Product-focused company (No-Ops)
If your company has a single or a small set of products that it develops and supports, you can eliminate development and operations altogether and blend them into small (up to 5 people), cross-functional “No-Ops” team. Such an approach is best for companies which are focused on a single product such as Spotify. In Spotify, for example, there is no development and operations. Instead, each team consists of members with overlapping knowledge and with a so-called “E”-shaped skillsets which encompass development, testing, and operations. This kind of setup allows small teams to work in isolation despite the product being a complex, multi-layered system with millions of concurrent users.
Option 3: Infrastructure-as-a-service Operations
The infrastructure-as-a-service (IaaS) approach works best for companies which have based their products in the public cloud (e.g., on Amazon AWS) or which have a traditional operations department. IaaS allows the operations team to provide elastic infrastructure on demand which applications can be deployed on across different environments. What is critical for the operations team is the small part of the development team which works together with the IaaS team to set up a CI/CD pipeline and act as a go-to source of expertise when it comes to operational features, monitoring, and infrastructure. IaaS also allows interoperability between different project setups, making such setup essential for companies who have multiple services and products hosted in the cloud.
Option 4: Container-Driven collaboration between Dev and Ops
Using Docker for creating containers with isolated, all-you-need-and-nothing-extra environments for your applications and Kubernetes for container orchestration is the typical way of implementing DevOps in more forward-thinking companies. The operations team creates Docker containers in which applications run and which enable developers to create features in a controlled environment. With a good engineering culture in place, such an approach can work well but there’s a high risk of the development team starting to ignore operational considerations and reverting back to an adversarial relationship with the operations team.
Making the leap to DevOps
Once you’ve decided which of the DevOps structures mentioned above is most suitable for your company’s processes and culture, you need to think about how to carry out the restructuring itself. This is the most difficult part which, if not executed correctly, may cause turmoil inside your organization and possibly take the development and operations team further apart.
Given the significant risks associated with modifying the DevOps structure, the most important thing you need to remember is to start small. Don’t start with your biggest project, thinking that the benefits of DevOps will have the biggest impact there. They won’t. Such a premature transition will most likely result in endless meetings between Dev and Ops trying to figure out where to start from. Going to the senior technical staff and asking them to “change their ways” could be a hard sell as convincing them regarding the advantages of DevOps would probably take more time than actually implementing it.
Finding the DevOps evangelists in your organization
What you need is a small group of people who are either involved in development or operations and who are genuinely interested in DevOps. Put them together and ask them to start researching and experimenting what’s the right way to set up DevOps in your organization. Assign a small project to them which incorporates all of the DevOps practices from start to end – from setting up source control to creating a pipeline, environments and integrating logging and monitoring services.
As your newfangled DevOps-centric team advances, you won’t have to convince anybody that DevOps is the way to go – your team’s successes will speak for itself. More and more people in the organization will start to become curious about how fast and iterative the flow of the DevOps team is. It won’t take long until other members from both development and operations start asking questions on how they could achieve the same level of efficiency.
Once you get to that point, you have to embrace bi-modal IT – allowing your DevOps team to grow and evolve while keeping the rest of your organization to the old practices and processes. This will give the development and operations teams enough time to get acquainted with the new structure. Once the DevOps culture inside your organization has reached a relative level of maturity, you’d be in a good position to start implementing the practices across larger, higher risk projects. If you’ve read “The Phoenix Project” (spoiler alert), you’d regard your initial DevOps team as the team working on the “Unicorn” project while the rest of the organization would be working on the “Phoenix” project.
Creating an interim DevOps team
Another way of bringing development and operations together is by creating a team of DevOps specialists. The team can jump between projects and products to set up a standardized pipeline for all projects. This can be particularly useful if, for example, your company has several projects using similar technologies and setup. Instead of asking the teams assigned to each project to self-organize and agree on a setup, the DevOps specialists do it for them. They also coach and educate members from both development and operations on how to fully utilize the new tools and environments they’re given access to.Once the DevOps specialists have completed the job, they can be disbanded and brought back to their previous roles. For example, Google had a “Test Mercenaries” team between 2006 and 2009 in an effort to standardize testing practices across the organization. The team ended up not only helping out with tests but also helped to streamline the general flow of work across the company.
Choosing the tooling and sticking to it
When choosing your DevOps toolset, treat it as a marriage – you’re going to spend a lot of time with it and switching costs can be rather high. Most of the tech giants provide their own set of products and services related to DevOps:
Microsoft Visual Studio Team Services (VSTS) + Microsoft Azure
The Visual Studio IDE provides a seamless integration with Team Services, Microsoft’s version control, and continuous integration tool. Combined with Azure’s public cloud services, they make a great DevOps choice for companies working primarily with Microsoft products.
Atlassian
Atlassian is best known for its JIRA issue tracking product. Combining it with Bitbucket for source control Bamboo for CI can bring operations and development closer together.
Amazon AWS
Sporting a plethora of services and currently being one of the top choices for IaaS and serverless applications, Amazon AWS also offers its own product for source control – CodeCommit and CodePipeline for CI.
Google Cloud platform
Like its competitors, Google has the Google Cloud Platform which offers a cloud shell (similar to Azure), container orchestration (similar to Azure Container Service, AWS EKS) and which integrates with third-party CI.
IBM Bluemix
IBM has its own set of public cloud services and products, offering similar services to Microsoft Azure and Amazon AWS.
Gitlab, Github and other standalone products and services
There are numerous standalone products and services which can be integrated together. Source control can be done through Gitlab or Github, CI can be done with Travis CI or Jenkins and deployment can be done on platforms such as Heroku.
It is recommended that, when choosing a toolset, you start with what development and operations are currently using and are fond of. A general rule of thumb is that DevOps products and services from a single company (Microsoft, for example) integrate better between each other, especially for particular technologies that the company supports, thus providing faster and easier workflow than standalone solutions.
One thing is for sure - DevOps is not another buzzword – it’s a proven process that can bring numerous benefits to an organization which adopts it. In order to do it the right way, you need to think about the big picture but to start with small steps. The big picture is the structure of your DevOps culture a few years down the road and the first step is forming a small team to choose the best tools and practices.