What is the Future of DevOps and How to Prepare

In the 12 or so years since the DevOps movement started to formalize into how we know it today, no one can deny that it has had a monumental impact on the world of IT and software development. While it is no easy feat to learn DevOps, we have plenty of courses to get you there.

DevOps came from humble beginnings and growing concern over the dysfunctional separation of software developer teams and IT operations teams. Dev would throw code "over the wall," leaving it up to Ops to just make it work. Ops would reject new code with common anthems of "it doesn't run on my computer". One department measured success by pushing out new features and fixes, the other considered risk-averse system stability their highest goal. Two teams with completely antithetical reasons to exist, yet both necessary to create and execute software products.

It was this division that birthed the methodologies, practices, and philosophies that became formalized as what we know today as DevOps. It's literally in the name, Developers and Operations, working under one set of complementary operating procedures to push both goals of continuous improvement and stability of systems. These teams, former rivals, now come together as allies in the same goals; they win, the company wins, and customers win.

It's not a magic bullet though. DevOps isn't a thing you can buy and install once to fix all your problems, servers will still catch fire and code will still ship with regressions. Most of all transformation won't happen overnight. But incremental changes have forever changed how countless organizations release and run their software products.

With the past decade-plus of change, what will the next decade bring? How can the methodologies and tools continue to grow and mature to serve devs and IT alike in the coming years? What will be the next sure bet, the game-changing technology, the next Kubernetes or AWS? We don't have a magic crystal ball to see the future of DevOps, but some predictions won't be too hard to make given the directions things are already flowing.

The Future Holds Many Cool DevOps Tools

Let's deal with the elephant in the room first and talk about tools. Of course, we all love cool new tools to solve problems or just make life easier, and the future will hold no shortage of them.

Just take a look at the current world of DevOps tools with the Cloud Native Computing Foundation's interactive landscape. It's a mind-boggling amount of projects in every area you could think of: CI, security, automation, API gateways, Kubernetes service providers, on and on.

It's also a mix of open source and commercial projects. Some of these projects might make it, some might be abandoned or go out of business, but the landscape will only get broader as cloud-native becomes more the norm.

Expect more tools, but also more mature and well-funded tools. Cloud Native definitely works in this direction, as an incubator for many of these projects. Investors are catching on too, seeing the value and potential in funding developer-centric projects.

Another trend: new and developing categories will gain leaders as companies aspire to corner as much of their niche as possible. Kubernetes definitely owns Scheduling & Orchestration, Argo fronts the CI space, but who will emerge in other less well-established markets like Security & Compliance or the crowded Service Provider space? Time will tell.

The Future Means More Microservices

Microservices have already become ubiquitous as a result of DevOps practices. The rise of automation and rapidity of release delivery would only be possible with the architectural shift from large monoliths to many small microservices.

Such a shift isn't always easy, especially for busy teams already stressed just by trying to keep up. But it's a big project well worth undertaking to gain all the advantages microservices offer: clear lines of responsibility for each service, less risk around outages of one service versus the entire monolith, greater flexibility in scaling, and SPEED, SPEED, SPEED in feature releases and bug fixes.

That last point is huge: devs get to push features, but ops already has the streamlined release and testing pipelines to keep things stable. It's a win for everyone.

As more and more large companies see these advantages and take the plunge with converting their monoliths to microservices, this architecture will continue to become the default way to build and deploy software.

This isn't a prediction of anything new or revolutionary, but an important continuation and acceptance of a growing trend. Microservices will remain the clear indicator of an organization focusing on DevOps principles for delivery.

DevOps will Continue to Provide Value

Stable and constantly improving software equals happy customers, and happy customers will buy more of your products. The bottom line is how DevOps will improve, well, your organization's bottom line.

How do we see this as a continuous change the most? Business leaders, not just the CIOs and CTOs and Engineering VP, but CEOs and COOs, publicly share success stories behind how their products and development have improved. We may all be growing tired of seeing buzz words like "digital transformation" thrown about, but this points to the greater truth of how DevOps practices have affected companies from top to bottom, and how top leadership is recognizing and championing the change.

Expect greater recognition of and investment in the value that DevOps can create as executives (technical and not) continue to evangelize on the principles that have brought their companies success.

Application Security: Front and Center

Rapid development historically pushes security to the back seat. This trend however absolutely cannot continue. As the tools and architecture develops and matures, attitudes and tools around security have also matured, and application security must absolutely remain on the front of every DevOps practitioner's mind, not an afterthought.

One sure sign of this trend gaining steam now and into the future: the rise of SecDevOps. This twist on the DevOps processes makes addressing security issues as immediate to developers as address functionality issues. App teams must take responsibility for their code's security, with support from the infosec team. It's not a stretch to see SecDevOps in the same light as to how DevOps fuses the goals and responsibility of developers and operations. There is just a third team also made integral to the mix now. Security isn't a hindrance to pushing stable code fast, it's an essential element to pushing stable and secure code fast. Think more collaboration and less team siloing.

This is one area we've definitely seen a rise of mature tooling focusing on security, projects like Snyk and Falco that are developer-focused for securing cloud-native environments like Kubernetes clusters. The fact that a security product focused on marketing to developers speaks volumes of how responsibility for app security must start with the developers writing the apps. It's not just something for infosec to worry about after release anymore.

Another point: such tooling fits right into a DevOps-centric release pipeline. It's not a separate process to run as an afterthought to check a box saying "yeah we did our quarterly security review, the scanner didn't find anything that bad." Nope, build those scans into your deployment automation. The Jenkins or CircleCI or whatever CI tooling you use should, as a part of the regular releases you're already doing, include security scanning so that vulnerable code is never deployed.

As security breaches continue to be front-page news with greater regularity, the only resolution is a greater effort around security posturing and practices and a shared responsibility between all the involved parties.

The Future of DevOps Languages

This one isn't as revolutionary as some of the other topics we've covered today, but it is definitely something important to pay attention to as you develop your career: what languages are gaining the widest adoption across DevOps. To get hired you must have the right hard skills.   While every org might care about different skills and different languages, the more you can embrace the popular ones the more likely you might be to get your foot in the door.

Python has been the long-time favorite of DevOps-focused teams and tooling. It's mature, it's flexible, and it has a huge ecosystem of third-party libraries and modules. The DevOps roots in Python clearly came out of the sysadmin world where it was a favorite for years before anyone cared about clouds or containers. Whether it was for custom tooling and scripts or integrating with common sysadmin architecture tools like Chef or Puppet, Python is king and will continue to stick around.

Very close on Python's heels though is Go. Go has become very popular in the DevOps world and will continue to gain steam in the years to come. It's simple, it's readable, but most importantly it's FAST. Another huge advantage: it's statically linked, so compiled code has all the dependencies included in the binary. That makes those binaries portable and easily distributed across platforms.

To see the growing trend of Go and DevOps, just take a look at the list of tools that have been written in Go: Kubernetes, Docker, Helm, Prometheus, Etcd, Grafana, Istio, the list goes on. Go is here to stay and will only become more popular.

The Future is Now

No one can argue against the fact that the DevOps methodology is here to stay. The data center may not be dead yet, or even for a very long time, but software released on the cloud, rapidly, securely, and aligned with company leadership is a trend quickly becoming the norm. It only gets better from here.