The Five Big DevOps Changes to Expect in the Next Year
Software development and delivery goals should align with the new requirements for speed, security, and user experience as the DevOps vendor and solution landscape continues to evolve.
By Shlomi Ben Haim
The Five Big DevOps Changes to Expect in the Next Year
Software development and delivery goals should align with the new requirements for speed, security, and user experience as the DevOps vendor and solution landscape continues to evolve.
by Shlomi Ben Haim
Thoughts from the CEO's Desk

2017 started off with a DevOps bang: an enormous amount of capital was poured into DevOps technology companies by venture capitalists, and larger-scale adoption of tools and methodologies was approved in this year's IT budgets with the recognition that DevOps is a "must-have." These changes follow a Gartner report from 2016 that revealed most organizations will use and implement DevOps by the end of this year. A survey of 252 Gartner Research Circle members showed that 38 percent were already using DevOps in 2016, and an additional 35 percent have plans in place to implement DevOps in 2017. That's over 70 percent of the IT market!

While budget is there, DevOps is relatively new, so it's only natural that many organizations lack experience with the technologies and tools. In this evolving and maturing world, key players seek fundamental standards and a definition of ROI. Unfortunately, some vendors in the DevOps domain still treat the move to DevOps as a trend, while failing to address the real pain points and acknowledge that DevOps is a revolution, not a trend.

As we kicked off 2017, my JFrog colleagues and I calibrated our goals based on what we expect to see happening. Here are some of the changes we predict will happen in the next year in the DevOps revolution.

Change #1: Continuous Updates
Vendors will embrace and address the real pain!

Continuous integration, continuous testing, continuous delivery, and continuous deployment—these are all part of the evolution of software automation that has affected DevOps implementation. However, none of them provides an end-to-end solution that addresses the real pain that challenges companies adopting DevOps. In today's hyperconnected world, where every company has become a software company and software updates must happen at a much faster pace, an innovative IT pipeline must obey the rule of "Release Fast or Die!" Nobody at your company's management layer and none of your customers care if your tools are integrated or if you perform an integrated deployment. You need to release more, release faster, and continuously update the compute edge. It isn't surprising that when asked, "Which of the following outcomes has DevOps created for your organization?" the vast majority replied, "faster cycle times" (see the Gartner survey results in Figure 1).

Figure 1. Results of Gartner survey indicating DevOps results in faster cycle times

Continuous updates have been JFrog's main focus in 2017. As the "binaries people," we see it as our mission to solve our customers' real pain and support their increasing need to release software updates faster with the highest quality guaranteed.

Change #2: A Universal Tool to Serve All Technologies
IT leaders look for reliable and universal solutions.

Every organization, regardless of its size or industry, works with more than one technology. You might use Java, C++, .NET, Node Package Manager (NPM), or Python as your programming language while using RPM, Debian, or Docker for packaging and shipping. The world of DevOps will have to provide a universal solution. It doesn't make sense to use a different solution for each technology anymore.

There's no time for evaluation; it's production time, and developers and operations people want consolidation and a universal approach. Speaking of production, it's not good enough to have a "reliable" tool. For example, all of JFrog's enterprise customers—including Cisco, Oracle, Twitter, Netflix, Credit Suisse, and over 3,000 more—have realized that their data centers must be clustered and highly available. This means that DevOps tools will have to provide high availability (HA) solutions with five 9s availability to earn the ticket into the software release pipeline and production environment.

It has been three years since JFrog released the first HA version of Artifactory, and it is still the only real HA solution in the market. With the latest 5.X release, JFrog provides a cloud-native solution with no requirement for an NFS to empower your HA setup.

JFrog offers Artifactory as a universal, HA solution. It has been written that JFrog's solution is "too integrated to fail." We see it as the right way to code. Everyone implementing DevOps should have the freedom to choose their technologies without needing multiple solutions from different vendors. Everyone needs a Docker registry, an NPM registry, or a Maven repository; they shouldn't have to install and maintain multiple solutions or pay more.

Change #3: Freedom of Choice

On-prem, cloud, or hybrid: the freedom of choice between these models will empower DevOps.

Freedom of choice is not just about your in-house technology, it's also about the infrastructure you are riding on. Cloud providers have realized two main things:

  • They need to offer competitive prices when they charge per volume. In the next year, we should expect to see storage and bandwidth prices diminishing even more.
  • They need to attract developers with a full suite of services. The cloud services market is not the "real estate" market it used to be. Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure are fighting over developers and coming up with DevOps solutions to formulate better service packages.

Technology providers will need to give "freedom of choice" to the DevOps community. JFrog offers different variants of its solutions: open source and commercial solutions are offered both on premises or in the cloud. Beyond that, JFrog lets users choose what works best for them: JFrog solutions are offered on Amazon, Google, Akamai, and Microsoft Azure.

Change #4: Software Security Matters!

The ball is on the edge; it is not in the hole yet. Improved information security is starting to become a heavier burden on the automated software lifecycle. The fact that you can release faster doesn't mean that you are safe and can now have a fully "hands-off" process! Software packages must be monitored, and the pipeline should include an automated way to detect components with security vulnerabilities, outdated software packages, or open source software licenses that are forbidden by corporate policies, and issue informative and targeted alerts that you can act on. In the coming year, it will not be enough to offer a simple "alarm solution." The DevOps revolution requires a smart solution that provides the following:

  • Universal scanning. The world needs something that goes deeper than a "container scanner"—something that is not just a container-centric solution.
  • A way to see how one component affects others, such as a dependency graph, and a way to analyze those dependencies.
  • A combination of metadata and security information aggregated from a variety of sources to form a comprehensive security database.
  • Automation. DevOps teams should be able to break a build to protect their production environment when vulnerabilities and other issues are detected. I'm talking about DevOps business intelligence (BI). Tools and solutions should offer more than notifications, so organizations can gain insight from each failure and from technical answers to enable ROI calculations.

JFrog Xray and JFrog Mission Control are two tools released in 2016 to address these needs. These tools already support most of the above, and in 2018 and beyond, they will ride on the pipe between Artifactory repositories and the Bintray distribution platform to secure software and provide data to DevOps teams.

Change #5: Business Models Will Support the Ability to Scale

Increased release velocity will be facilitated by business models that let you scale easily.

This will not be a "proof of concept" year! Organizations and the majority of late adopters would like to hold on to their tools for several years. A fair business model should allow you to scale; if you need to keep counting seats, users, CPUs, or whatever, you can't scale or build a budget.

A fair business model supports scaling up and will not block you from taking the next leap forward. You should not be concerned about whether you have reached maximum usage. Tools should satisfy the DevOps hunger and support it.

Old-school models that take advantage when you scale up have no place in the DevOps world when budget is being managed from the bottom up. It's all about scaling and automation. The number of developers on your team will continue to expand, and your DevOps solution must be able to expand with that growth.

swampUP 2017—Living on the Edge of DevOps
Once again this year, JFrog held its user conference to share more of what it does at the swamp. DevOps leaders gathered at swampUP in Napa Valley, California, from May 24–26. The speaker lineup included tech talks and best practices from Google, Atlassian, Yahoo, CloudBees, Oracle, GitHub, and more. This year was better than ever with 350+ of the brightest technical minds discussing software development and delivery advances against a beautiful Napa backdrop. We were truly living on the edge of DevOps. Experience the content for yourself here, where we have all the keynotes and breakout sessions recorded for those who couldn't make it—but be sure to join us in 2018!

About the Author
Shlomi Ben Haim is the cofounder and CEO of JFrog.
Join the Database Community Conversation
Experience Oracle Cloud—Get US$300 in free cloud credits.