DevOps has become one of those tech industry buzz-words like “agile” or “the cloud” that everyone thinks they understand when they hear it. But, in reality, unless you ask a few questions or read a little deeper, you can’t be really sure you are on the same page because everyone has a different point of view. Some people stop with a quick reference to the fact that it is a concatenation of the two words “development” and “operations.” While that is true, it really doesn’t say much. Others say it is all about IT automation and tools, and while if you are a tool vendor that might be a good place to start, it also doesn’t get at the heart of what DevOps outsourcing means or the industry movement that is a part of it.
To get this discussion on the same page, I would point to the article under the term in Wikipedia as a starting point. It is a well-balanced entry on the subject, but I highly recommend spending some time on the Agile Admin page on the subject. It is an excellent piece that covers in a page both the origins and the various sides of the subject.
Many articles in tech industry publications have proclaimed DevOps outsourcing to be the “total automation of the IT industry” and “the death knell of outsourcing” but the industry and outsourcing are still evolving in response to DevOps methodologies and it can be assumed those headlines are little more than “click-bait” to get readers on their platforms. Like agile, DevOps outsourcing is transforming the development and deployment of software to the last mile – the user device or desktop, but it depends on many changes and steps to reach full value. It will be sometime before everyone can arrive at a level of common experience and acceptance.
In a traditional “agile dev+IT ops” situation, a development team could use agile methodologies to incrementally release working software which was accepted by a product owner and then, at some point, it was “thrown over the wall” to IT operations so they could go through their processes and release the final product. This meant that the end user didn’t get the benefit of the incremental release cycle and the development team didn’t get the benefit of direct user feedback until the production version was released. In this type of a system, much of the promise of agile was stopped at the gates of operations to ensure that quality and reliability of organizational systems would not be impaired by the release.
In a DevOps situation, software development teams and IT operations are tightly tied together in a collaborative mix of automation, configuration, integration, testing and quality assurance to deliver software – incrementally – right to the desktop and the users are enabled to feedback on the application through operations to the dev team. This requires a cultural change within the organization but when it is fully implemented – it develops a continuous improvement loop inside the organization.
So – What Does This Mean for Outsourcing?
Before we look at how outsourced teams work in a DevOps organization, let’s step back to one more set of terms. As we discussed in our recent article about dedicated teams, application development can be basically divided into two types of projects, discrete and continuous support mode. Discrete projects might be developed by teams using agile methodologies, but in the end, they are passed off to IT operations and the development team will no longer be directly involved except to correct problems. In continuous mode, dedicated development teams and IT operations work together to provide the continuous improvement loop that is found in most services and applications on the Internet that are in wide use.
Both discrete and continuous support mode projects can be outsourced, but most companies have only tried outsourcing discrete projects. This practice goes back to the time when most projects used waterfall plans and were meticulously planned. Because much of the work outsourced was done offshore, in situations where direct communication with the dev team was difficult because of language and working hour offsets, detailed planning and layers of oversight were thought to be the best way to ensure that the final software would meet requirements. As agile has become the mainstay of the industry, outsourced teams have matured and adopted the methodology, but for a long time, application deployment has remained in a discrete project mode. Now, with DevOps becoming accepted as the gold standard for critical applications deployed on networks, outsourced teams are evolving to adopt the skills and practices needed to successfully integrate into DevOps situations as dedicated teams.
DevOps Outsourcing teams need to take responsibility for a wider range of issues than they would have in most discrete projects. In discrete projects, they have benefited from some of the tools of DevOps like test automation and continuous integration, but in most cases, the scope of their involvement in wider operations has been limited. In agile, continuous release situations, their involvement in operations includes participation in a wider scope for test automation and integration, as well as automated release processes, configuration management and other tools from data center automation. For outsourced dedicated teams, this means that their skills and experience need to encompass a range of DevOps practices and tools so that as a part of the larger team, they can quickly integrate and provide a positive contribution to production.
This is not to say that service providers for dedicated teams will be able to provide individuals with experience in every tool used in a specific DevOps practice, but just as not every agile implementation is exactly the same, individuals with experience in similar situations and a stack meant to achieve reliable results with a high level of quality should be able to adapt without serious problems. It should also be said that client organizations have many different levels of acceptance and maturity in their adoption of DevOps and in many cases, an outsourced team can bring a wider range of experience and knowledge along with their specific development skills.
DevOps requires a high level of communication and collaboration within teams. Tools are only part of the solution. If team members cannot communicate directly and work as peers within the organization, the effectiveness of the DevOps team as a whole will suffer greatly. Intermediaries and hierarchical chains of responsibility only push development and operations back into the silos that DevOps is meant to break up. Because of this, outsourced teams should have overlapping work hours, and no communication barriers from technology, language or culture so they can participate fully. Teams in the same geography or nearshore are usually the best situated to meet this requirement.
So bottom line – you shouldn’t expect your outsourced, dedicated development team in a DevOps environment to be any different that your in-house team. If they can’t blend in with the rest of your resources, it will cost you. Why would you consider an outsourced development team in this situation? Skilled, competent teams take time and money to develop. If a provider can take some of the load off of you to bring together a qualified team at a reasonable cost, with the right skills and personalities, it is a big plus if you are starting an new initiative and don’t want to go through a reorganization and hire cycle with your existing staff.
What to Look for DevOps Outsourcing
So boiling this down, here are key points to consider when picking a provider for outsourced teams in this situation:
- Start with the same requirements described in the dedicated teams article we discussed recently. Stepping away from the skills and experience for a second, be sure you are looking at the personality, cultural, and communication profiles of the team members offered. These characteristics are even more important in blended DevOps teams than they are in ordinary teams.
- Team members must be fully practiced in agile methodologies, remembering that their experience does not have to be exactly the same implementation as you are using inside your organization. DevOps is in many ways an outgrowth of agile. As a developer, you don’t get agile, it is a lot harder to adapt to different implementations of DevOps, even if you have some experience with the concept.
- Team members should have experience with DevOps tools and techniques – but again, don’t concentrate on the the exact same stack you are using. There are just too many different implementations out there. If their focus is at the same level of reliability and quality as you use, switching out a tool or dealing with a different procedure is a small problem.
- The service provider should be able to operate as a partner and a vendor. They should be able to focus on the long term goals and not get bogged down in small details cloud the relationship. They should be able to provide immediate value – the resources, infrastructure and practices needed to fit in quickly without a lot of heavy lifting.
You and the service provider should be able to come to an agreement that will give you a startup period with the new team on your premises or theirs to plan, test and run a “shake-down” of the initial environment and procedures needed for them to provide a solid contribution to the effort. The plans you lay down at this stage will and should evolve, but you must have a solid beginning if you expect to reach full production in a reasonable period of time.
- Select a provider that can provide a team that is available during the majority of your normal operating hours and has no barriers to direct communication between team members. And because you expect them to participate in the initial phases of the start-up phase face-to-face with your key team members, there should be no barriers to travel and interaction that are difficult to deal with. In most cases, this implies a team within a day’s travel time and without visa or travel restrictions.
- The infrastructure, security and IP protections in the outsourced team location must be able to meet your requirements for connectivity, reliability and security. In most cases, with mature vendors, this is not a serious problem – but it is important to discuss and check regardless.
- Don’t expect less of your outsourced team. If your in-house team senses that the new team has less responsibilities or is less capable, inter-team relationships and trust will suffer.
Again, in the final analysis, there are good, experienced vendors who can offer outsourced teams that can operate as dedicated members of DevOps teams for your projects. Of course, it will take some additional time to find the right match because the teams must be able to integrate into the operation without causing undue disruption. But in the end, the value-added can be quite worthwhile.
Scio Consulting International is an experienced, proven, nearshore provider of dedicated teams to projects in DevOps implementations for our clients in North America. We would be glad to discuss your project and environment and show you how our teams could work for you.