Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Given DevOps’ emphasis on close collaboration, what are we to make of the idea of DevOps as a Service? Aaron Walker, cloud and integration principal at base2Services explains.
base2Services started as a consultancy service specializing in open source software (especially middleware), but also developed software for its clients. Over time, the pendulum swung towards development, but clients also wanted the company to provide hosting services and ongoing delivery management.
In the late 2000s, “We gravitated towards cloud because it was a natural fit… we could manage infrastructure as if it were software,” says Walker. “We were a big Agile shop, so it made sense to apply those practices to operations.”
By 2012 base2Services realized it had built significant capabilities in this area, and so abandoned software development to concentrate on infrastructure management with a focus on ‘infrastructure as code,’ and migrating clients’ systems to the cloud and then providing ongoing management.
“We don’t do anything that doesn’t have a cloud element,” says Walker, who explains that base2Services can help clients take advantage of the cloud even if they are still using a traditional piece of software.
Because of the company’s history, “the DevOps thing was something we just did,” says Walker.
base2Services’ goal is to enable its clients to move more quickly, and it does this by carrying out the tasks that a client is not yet ready for, by working to minimise any gap between its own and the client’s teams, and through skills transfer.
The company focuses on continuous improvement, and on the development of a continuous integration and delivery environment for the client.
base2Services’ clients come from a broad range of sectors, says Walker, but especially e-commerce as well as traditional enterprises and government departments that are moving into the cloud. The former “get the fact that they need to be in the cloud,” while “we’re bringing traditional IT departments along on the DevOps story.”
In some cases, base2Services is brought in to challenge an internal IT team. This makes it important to show “we’re here to help and we’re not there to replicate what they already do,” he says.
This approach has proved successful in helping other IT organizations become more agile so they can focus on serving their colleagues on the business side through much shorter cycles.
Physical proximity of development and operations staff tends to be a characteristic of DevOps, and that would seem to work against base2Services’ strategy of providing the Ops part as a service.
Not so — “We’re very hands on,” says Walker. When working remotely, base2Services staff take advantage of ChatOps and also attend customer standups via Skype or similar technologies.
“It all depends on the customer and its maturity,” he explains. More maturity means more daily interaction; less maturity means base2Services people are more likely to physically attend the customer’s premises on the days they are required during each sprint. “We’re pretty flexible… we’ll work with customers how they want to work.”
base2Services customers include fashion e-tailers Cotton On and The Iconic, utility service provider Service Stream, and state government agency Emergency Management Victoria (EMV).
EMV is “a really great story of DevOps working to deliver a platform very quickly,” says Walker, as the new system had to be deployed between bushfire seasons. Multiple partners were involved in the project, with base2Services providing full automation for the environment, plus ongoing management including the deployment of new features and capabilities. “It wouldn’t have been able to happen so quickly under a normal government structure — they would have still been at the requirements specification stage.”
The challenge with new customers is that they need to understand that DevOps is a process, Walker explains. “I cringe when I see job ads for a DevOps engineer,” he says. “DevOps is not a person or a set of tools, it’s a culture. You have to facilitate the culture and the processes when introducing it to an organisation, and use DevOps as a guiding principle to get people to work effectively together.”
Sometimes the customer does not have the right internal structures for the successful adoption of DevOps, in which case base2Services assists with the transformation.
“The biggest problem we find is that while teams naturally self-organize in smaller organizations, enterprises and government departments tend to be quite rigidly structured with defined roles and responsibilities — but by its nature, DevOps has to be cross-functional.” This leads to conflicts, because people become unsure of their place in the team and exactly what they are responsible for.
The answer is education, combined with gradually introducing the various stakeholders to DevOps at an early stage of the project, he says. “You want them to take shared ownership, and the way to do that is to carve out one piece at a time rather than trying to change the whole organisation at once. This approach builds energy and enthusiasm, which encourages other stakeholders to engage with the process.”
It is also important to avoid being over-prescriptive: “Pick one aspect — perhaps automation of a certain task — and adopt that as a starting point.” That way, even large and traditionally structured organizations can benefit from DevOps.
For some people, “it becomes religious… ‘You have to follow all these practices or it’s not DevOps’,” but that is not constructive according to Walker. His advice is to avoid getting stuck in the details, and instead make a start and commit to constant improvement. Seeing through small but meaningful changes will deliver value, he says, because the introduction of DevOps is one of many situations where it does not make sense to try to boil the ocean.
