Computing's annual research finds DevOps entering the mainstream and early adopters looking at how to scale their efforts
As DevOps scales up and out, the need for coordination increases, be that in allowing groups across different timelines to work together or allowing builds to take place concurrently. In practical terms this generally means moving off on-premises testbed servers and onto PaaS or IaaS services or a private cloud. We expect to see a continued move cloudwards over the coming months.
Among developers of event-driven programmes and small applications there's been a lot of noise around 'serverless' - function as a service - services. Serverless is still pretty new. Market leader Amazon AWS Lambda is just three years old and Oracle only announced its own offering, Oracle Fn, at the end of last year. More importantly the usefulness of serverless is, so far, restricted to applications where state does not need to be locally stored.
Nevertheless, serverless has been the subject of intense interest over the last 12 months and still carries the promise of 'next big thing' about it, with some heavy-duty marketing on behalf of the cloud giants as well as evangelising by developers.
Meanwhile, last year's 'next big thing' - containers - show no sign of throwing in the towel. The last year has seen a rapidly growing interest in orchestration solutions, particularly Kubernetes, as a way of deploying container-based applications across platforms and at scale, and containers retain their popularity among those using microservices architecture.
Among the developers polled, serverless is attracting more interest than containers, perhaps reflecting the current buzz around the topic. However, for 'advancing' and 'mature' DevOps respondents containers are still very much the core area of focus. Containers are the more established technology with broader range of use cases so far and one that goes hand-in-hand with microservices. No doubt serverless will be an increasingly important part of the picture, however. Serverless can be incredibly cost-effective for inconsistent or event-driven workloads and also high volume back-end processes.
Some tools such as Puppet and Jenkins (or Hudson as it was then) predate the coining of the term DevOps and remain well used to this day, but they have been joined by a whole raft of solutions since. There are tools for source code management, for build, for testing and for config management. There are containers and cloud services - PaaS, IaaS and serverless. There's release management, collaboration, continuous integration, delivery and deployment.
The choice of tools has never been greater, but this is both a blessing and a curse. Tools tend to be selected because developers are familiar with them, or because they are free versions are available which is great when you're just getting started but which can lead to a tool silo, a situation that is antithetical to the change-fast culture of DevOps.
"We have a glut of tools," one respondent told us. "There's always a worry that you choose the wrong one and find yourself a year in the future having to rearchitect it because you've gone for Puppet over Ansible or something."
In most markets there would have been a degree of consolidation by now, but aside from a few acquisitions at the edges this hasn't happened with the DevOps toolchain. This picture may change as operations head cloudwards and the platform providers see an opportunity to link services together.
Turn to next page