No one can look into the future. However, trends come and go in the IT software industry. As of now, the DevOps hype is present in almost every organization that produces or consumes software applications. Not only for their core business but much more than that. Despite this great movement, some people have already sketched a potential new movement that follows this development. In this article, we’ll review a couple of these ideas. DevOps and the future – what comes next?
Cloud Engineering Culture
Developers are already familiar to write declarative source code to provision infrastructure building blocks in the cloud that they need for their application. It would be very logical for Ops engineers to do the same so they also gain practical experience in applying DevOps principles to their day-to-day work. It would be very logical for them to use the same tools and techniques similar to the developers.
Every change, whether it be an application or an infrastructure resource is tracked in version control. Since infrastructure requires specific knowledge about scaling, fail-over, integration, and interaction (with cloud services). It is still a separate disciple.
Since the only focus is on the cloud, this requires a so-called “Cloud Engineering Culture“. Software engineering and tools which are needed for infrastructure, application development, and (software) compliance are standardized. By focusing on this concept, working with complex cloud environments is simplified a bit. Organizations treat Developers, System Operators, and other persons such as Security Experts all in the same manner.
Spreading around
Even though it’s hard to overcome (the initial) resistance of the people moving toward a DevOps-enabled way of thinking and way-of-working, DevOps might spread to other organizational departments. Linking Dev and Ops might just be the beginning of a greater movement. Adding security into DevOps is already pretty common. What about adding QA (Quality Assurance) so you would get DevQAOps. Another popular phrase is BizOps linking business-related activities closer to Operations (or the other way around off-course).
As of today, not many organizations are already applying DevOps principles against all of their business units, but it could be the case in the (near) future.
Increased ROI
It can either lead to an increased ROI since every department streamlines its operational activities and all work in the same way. There would be less friction between departments to build IT products in a similar fashion. This can really speed up the delivery of new features thus pushing ROI to new levels.
The more the (senior) management and budget holders acknowledge this, the more likely they are to invest more money into every DevOps-related project or activity.
Or not?
By looking at the previous scenario and when taking into account that almost everyone will be doing DevOps, there will be organizations for which DevOps is not a good fit. Sooner or later they will experience the downsides of DevOps which do not work for them.
Besides this, several articles and blogs are published recently that some organizations do not need DevOps at all. It’s this criticism that helps to judge whether or not “DevOps-ifying” your entire organization is a wise thing to do or not. Those organizations might seek alternatives that do the complete opposite and this will most probaly cause a backlash against DevOps.
It’s impossible to sketch a scenario that gives a solid answer to this. From my personal point of view, I’m really curious to see how things evolve.
Removal of safety nets
Many companies adopt certain safety nets in the early stages of a DevOps transformation program. This ensures DevOps teams are a bit more protected from making (security) mistakes since there are guardrails in place. Once these teams become more mature, they feel more confident that they don’t need these safeguards anymore.
For sure, the automated checks need to be implemented, but as the teams gain more experience, less restrictive validations need to be in place. While teams might use a fully-fledged Acceptance environment to test their applications in a “pre-production environment” they might want to remove that step entirely once they rely more on their logging, monitoring, and observability-related systems. Since they can (re)deploy their application faster to production, without any downtime and less risk, they can react to problems in a timely manner.
Save time and decrease the risk of configuration drift for the Acceptance environments. Every time you create them, but also for every build iteration. Skip testing in Staging environments also shifts the attention of end-users toward production. That leads to even faster feedback in the CI/CD cycle.
Time will tell if there will be really fewer safety nets for experienced DevOps in the future.
NoOps
Consider the situation as mentioned before in which there are fewer safety nets and fewer (Acceptance) environments. This leads to fewer infrastructure components and thus resources needed to set these up and maintain the source code to keep them healthy and secure. This also means fewer Operations personnel.
In turn, this accelerates the usage of serverless infrastructure that abstracts away the infrastructure layer from the application. The border between them already becomes a bit blurred if both are defined by source code and heavily inter-twinned. Now the infrastructure layer is completely invisible. NoOps becomes a reality. Business representatives might be happy with this evolution so they gain bigger budgets for their features. A nightmare for infrastructure departments that employ system operators. They need to change, quick!
Runnable specifications
The above-mentioned scenario is still geared towards two main stages: writing specifications and implementing those across your (cloud-native) systems. There is always a gap between what you specify and what you run. On an organizational level, it’s also a gap between the strategic departments, the business units which operate on the tactical level, and the guys that operate the business.
With “runnable specifications” it’s possible to validate what you are running (in production) by validating your specifications. Therefore you need to change the way you think about specifications: they’re not theoretical, written in isolation. Instead, they can actually be executed (called runnable), just like actual application source code.
Build your specifications with tools and make them easy to read and execute so you can verify your implementations with confidence. To make it a bit more practical, check out the article about Runnable Specifications in Javascript.
Smart Contracts
Runnable specifications eliminate the need for functional and technical designers that specify the features and nonfunctional requirements for applications. So, how can you further enhance the workflow from business idea to realization? Extend the concept of runnable specifications towards payment of the features being built. Enter the world of “Smart Contracts”.
In the article by Jani Happala, he refers to Smart Contract as a “self-executing contract that releases the payment automatically when the terms of the contract are met”. This eliminates manual testing and negotiation about the test outcomes of software features. This is the implementation of the specifications which are defined beforehand.
There are five steps to make this practical:
- Every piece of the application and infrastructure architecture should consist of small autonomous functions.
- Make sure your application can run directly in the cloud (no infrastructure provisioning allowed).
- Automate the test cases which are defined by the business representatives. The big difference here is that they define those test cases in the proper format. You need to help them here, for example by specifying the right format and the way they need to write them.
- Learn how to create and implement smart contracts by digging into the technologies behind blockchain.
- Automate the test cases in a certain time frame and be sure to flag (automatically) functionality that is met.
All of this acts as the baseline for a contracting (outsourcing) party or individual developer to be paid. Smart Contracts help to eliminate the need for project leaders and organizational departments that handle contracts and subsequent conditions based on a “result-driven approach”. For sure you can expect resistance when you want to launch this kind of “future topic”.
Success metrics on the winning hand
In relation to all the above-mentioned scenarios, the metrics that your organization collects become even more important. Since metrics are (becoming) tight to business outcomes rather than technology-focused KPIs, they reveal how well or how bad your software development activities evolve over time.
Everyone within the organization would need access to those metrics to utilize the potential that comes out of them. In turn, it will trigger further enhancements of automation tasks. It might also accelerate the “friendly competition” of different DevOps teams working in different departments.
Concluding words
DevOps is hot and everyone is jumping on this (new) hype. Some folks already think about the next step after DevOps. In this article, I’ve summarized a number of potential future scenarios which can happen in the coming years. It might be an eye-opener for those still working in Agile/Scrum (or even Waterfall) teams within isolated departments and thus processes. For existing DevOps teams, it’s valuable to know what their next challenges might be. In both cases, organizations face new opportunities to increase their efficiency even more.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
