It’s Jan. 1, and that means it’s time to pull out the crystal ball (or oscillator?) and predict the future. Keep reading for insight on how the team at Fixate (the folks who bring you Sweetcode) and friends in the ecosystem foresee DevOps evolving in the new year.
Quality Takes Precedence over Quantity in Software Delivery
Traditionally, the main selling-point of DevOps has been that it makes software development and deployment faster by enabling continuous delivery. But one can argue that continuous delivery has a downside, which is that software quality is not as closely controlled as it should be because changes roll down the pipeline too fast.
However, there is no reason that continuously delivered software can’t also be high-quality software. You just have to make sure you build strong quality assurance into your delivery pipeline. We think that will become a more significant focus for DevOps teams in the new year — and we believe that DevOps-friendly QA automation platforms will be important tools for helping DevOps teams achieve that vision.
2017 becomes the CaaS “Tipping Point”
David Messina of Docker predicts that Containers-as-a-Service, or CaaS, will reach a “tipping point” in the new year. By that, he means that companies will migrate from traditional PaaS solutions to container-based alternatives, which means CaaSes:
Rising confidence in container security, to the point that developers consider containers more secure than alternative technologies, drives an increase in the use of Containers as a Service (CaaS), displacing legacy PaaS approaches to application development and deployment
We also think it’s a safe bet that CaaSes will become the go-to choice for companies seeking to implement containerized architecture. While anyone can build a Docker stack from scratch, the maturity of many of the CaaSes available today — from on-premise options like Rancher Labs and OpenShift to public cloud offerings like AWS ECS — means that organizations can save a lot of time, effort and (in many cases) money by adopting a CaaS instead of going the DIY route when they want to migrate to Docker.
Container Adoption Really Takes Off
Speaking of containers, 2017 will be the year when enterprises really, truly start using containers in a big way for production.
Well, OK. Lots of enterprises are already using containers in production, according to surveys conducted in 2016, like this one from ClusterHQ (a container vendor that sadly went defunct at the end of 2016). But those surveys tend to define “production” rather broadly. It’s not always clear that enterprises that are ostensibly using containers in production are actually migrating the bulk of their large-scale production workloads to containers; instead, they may simply be experimenting with containers for production on a small scale.
Plus, it has arguably only been in recent months that container platforms have become truly ready for the big leagues as orchestrators and security solutions have reached full maturity.
But don’t take our word for it. Here’s what Nati Shalom, CTO of GigaSpaces, told us about how container management solutions are evolving, and what that means for serious production deployments:
The battle in container orchestration has been growing — and will likely come to a head in 2017. While Kubernetes has been strong and continuously growing, Docker is finally snapping out of its stupor and delivering a much more viable product with Swarm by baking it directly into Docker Engine, and providing much needed usability improvements around manager/worker, auto-heal, manual scale, service support with load balancer fixed IP, overlay networks & DNS – as well as more robust security out of the box – among many other features that are now giving K8s a run for their money…In 2017, the container war really begins and we will see many more large-scale production deployments as containers become more resilient.
That’s a long way of saying the technology is finally here for enterprises to migrate a majority of their workloads to containers in 2017.
Security Gets Serious
Few DevOps-specific security tools have appeared to date. In their absence, DevOps teams have mostly had to make do by adapting old-generation security solutions to fit next-generation DevOps workflows and technologies.
But that has started to change. A whole slew of tools for securing containers are now available, like, Twistlock, Clair and Docker Security Scanning. Plus, the focus on better quality assurance within continuous delivery pipelines, which we discussed above, will also help to promote better security by encouraging DevOps teams to review changes for security reasons more thoroughly.
This is part of the reason why Messina also wrote that “by the end of 2017, no major hacks or breaches will have been found to be attributable to container vulnerabilities.” We don’t like absolute statements — so we won’t go on record saying that absolutely no major breaches will involve security problems with containers — but we agree that containers will be at the root of many fewer security vulnerabilities in 2017.
The Year of the Serverless Server
Last but not least, 2017 is poised to be the Year of the Serverless Server.
That’s a neat way of saying that serverless computing is going to be a really big deal in the new year. Sure, serverless functions from AWS Lambda have been around since 2014. They’re old news.
But in recent months, serverless computing has diversified and become easier to obtain as other vendors, like Azure (via Azure Functions) and IBM Bluemix (through OpenWhisk) have added production-ready serverless computing solutions of their own.
Those changes come at the right time. DevOps teams are looking for more and better ways to streamline their apps. Containers provide one way to do that, but they only solve certain problems and apply to certain use cases. Serverless computing functions can help to make app deployments much more efficient in another way — especially when you need to handle workloads that “spike” frequently, and you don’t want to have to maintain a massive infrastructure just to run some small but resource-hungry snippets of code.