Deciding on two separate teams, or an integrated end-to-end team
While a lot has been said about “the right way” to do DevOps, what we’re seeing in practice are two different approaches being tried to enable development and operations to work together as a team. On the one hand, there’s the approach to create an end-to-end, integrated development team, which you might call ‘Devops’. On the other, there’s ‘DevOps’, featuring two development teams – one working on application code, with another developing a platform using Infrastructure as Code techniques in a virtualized environment.
DevOps: providing a platform
Perhaps the most obvious way to go is to have a platform team to provide a runtime environment that “just works”, and a separate application team that develops the business logic to run on the platform.
For some organizations, particularly where one of the teams is outsourced, this separation is going to make more sense. You might buy an off-the-shelf product, build your own platform in-house (which seems to be what many organizations are looking to do with Docker right now – warning: it’s harder than it looks!) … or sign up with a PaaS vendor.
Whatever the situation, the platform should be versioned, just like any other piece of software.
This approach can be ideal for developers because they are free to work on code and focus on the business logic, and they really don’t need to worry about how it runs in production. It’s up to the operations team to make sure that the platform is stable and that it delivers what the developers need.
Communication is still key
Even with a physical or organizational separation, the importance of effective dialogue between the two teams cannot be overstated. This won’t work if the relationship is adversarial. There has to be a genuine awareness of common goals. If the operations team doesn’t understand where the development team is going, and what they need from the platform, then there’s going to be trouble. The idea that one platform is going to cater for every development need is often unrealistic, so versioning and the ability to run multiple platform versions side-by-side, or cater for exceptional situations where a particular application might need its own stack, is very important.
There has to be a clearly defined boundary, which should be close to the application code and configuration layer. The application handles the business logic, the platform handles the deployment, logging, monitoring, failover and auto-scaling.
The development team can focus on getting those new features and improvements into the live product, while operations handles the actual roll-out and manages traffic. For this to work, the platform must enable you to quickly determine who is responsible for any problem that crops up. It’s worth investing time in the setup to ensure that errors are explicit, so you don’t waste time tracking them down.
Arguments between the two teams are bad for progress and morale.
Devops: A full stack development team
For some businesses, it’s going to make more sense to put together integrated development teams that work directly on delivering the full stack from a shared code base, from virtual machine to application code. This allows you to design and optimize each system in a way that takes the application’s specific perspective and requirement into account, and can be an especially good fit if your applications differ from each other greatly in terms of the operating systems, middleware, etc., that they run on.
This approach can only work if the overall group is small (Amazon’s “two pizza” teams are a good example) and has sufficient knowledge and experience to see the big picture of the entire system.
It’s not possible for everyone to understand every part of the full stack in detail, but there are areas of overlap where greater collaboration will increase the level of shared knowledge and allow the team to build a better overall system.
Pulling together
The shared foundation of the Devops approach builds mutual respect and enables more free-flowing communication, but it must be based on shared goals and a vision of what the overall purpose of the system is. This integrated approach can give you much more flexibility, but it also means holding the whole team responsible for keeping everything running. Shared code equals shared responsibility.
The right approach
You need to take a baseline, and then put metrics in place to track your progress. You have clear goals in mind and a system to measure them. So how do you find the right approach to achieve those goals?
It would be wrong to say that one approach is better than the other. What you need to do is assess what will work in your organization. Both are means to achieving similar goals, but finding the right approach is about understanding what your company is looking to achieve. You might choose common goals, like reduced expenditure, or reduced error, or you might choose something more specific to your industry. Establish your goals at the outset, and make sure that they’re measurable.
The right approach is going to be the one that gets results for you — that’s why setting up a baseline and metrics is so important. You may find that a hybrid of the two approaches is going to be the right fit, but you aren’t going to know for sure until you have some hard data to back up your expectations.
Be sure to join DevOps.com editor-in-chief Alan Shimel on Thursday, May 21st as he hosts the webinar, “Ship Faster without Breaking Everything” to further your smarts on Continuous Delivery.
About the Author/Andrew Phillips
Andrew Phillips heads up product management at XebiaLabs, a provider of continuous delivery automation. Andrew is an evangelist and thought leader in the DevOps, Cloud and Continuous Delivery space. He sits on the management team and drives product direction, positioning and planning.