The DevOps movement began in earnest about 15 years ago, and while it has fundamentally changed how developers work and software is deployed, there are still numerous challenges in the space. Most of these challenges stem from the bespoke nature of many enterprise DevOps toolchains. In the early days of the movement, there were a lot of open source and commercial point solutions available and a vibrant community of collaboration. For example, an enterprise might use GitHub for source management, Cloudbees for continuous integration and JFrog’s Artifactory for binary artifact management.

This approach enabled very good cross-product integration, which allowed customers to assemble their own toolchains based upon their specific requirements and preferences.

What’s Wrong With Today’s DevOps Solutions?

The good news is that the spirit of collaboration continues. The bad news is there has not been much of a forcing function for enterprises to move away from bespoke approaches toward something more scalable and easier to manage. However, at its recent SwampUp 2024 event, JFrog made a strong case for modernizing software development processes by taking a platform approach to DevOps, DevSecOps and MLOps. After many conference sessions and private meetings with JFrog and its customers, I found the following complaints were common.

• Bespoke DevOps is harder to manage — The process of managing multiple DevOps tools has become unwieldy over time because each product has its own set of management features and analytics. Also, some of these tools have not received continued feature investment over time, so they’re out of date. Despite good cross-product integrations and APIs, ITOps struggles to keep everything up to date and running smoothly.
• Many DevOps solutions are not well prepared for the future — We have seen a pattern in the past where new technologies (such as mobile development or IoT) start out with their own toolchains, then are eventually consolidated into the enterprise toolchain. Due to the nature of how AI and ML models are built and trained, there have been good technical reasons for a separate toolchain, but that needs to end as AI and ML become more mainstream. A consolidated, platform approach is now necessary, as we see more progress with AI-assisted agents doing development tasks. The takeaway here is that there is enough change coming—driven by AI—that existing point solutions will likely need to be updated; that process will be harder with a multipart bespoke setup versus an integrated platform.
• Security and reliability are an afterthought — The global nature of application development and continuous integration both imply that your toolchain cannot afford any interruption caused by a security or reliability event. In either case, moving to an easier-to-manage on-premises platform, or even a SaaS platform, may be worth the increased investment.

“Everyops” And JFrog’s Vision For Developers

The idea of converging different development models and operational requirements is something that JFrog calls Everyops, and it’s a powerful vision of how developers will work in the future. JFrog’s idea is that developers must become more automated in their work to ensure that the apps they create (likely with the help of AI assistants) will not only work and be easily deployable, but also secure from end to end.

While some people are worried about the developer role becoming obsolete (something I debunk in this recent Forbes article) JFrog sees the role morphing into something bigger and broader including security, performance and managing AI agents. This expanded role also demands better tools for developers. Not coincidentally, JFrog has been steadily building out and acquiring components to align its offerings with this future vision.

Starting From A Place Of Trust: Artifactory

It helps that JFrog Artifactory is a leading component in today’s DevOps toolchains. Artifactory is an enterprise artifact repository to help developers manage binaries, packages, files, containers and other components. But it now goes beyond being a simple repository: there is also an element of curation to ensure that every artifact is from a good source and can be trusted when devs do a pull and wherever the artifact is deployed. JFrog also recently added release lifecycle management to Artifactory, extending that trust across the software development life cycle to software being released for consumption.

A lot of DevOps solutions focus on the toolchain (i.e., the process) but JFrog starts at the individual artifacts (i.e., the content). This creates a more granular and inside-out approach to the DevOps process. It is this approach that has opened some doors with respect to its new innovations.

A Diligent Approach To Innovation

Like a lot of software companies, JFrog shows a desire to expand from a point solution to a full platform. Not every company is successful in this, but JFrog is diligently making progress. After spending time with the company’s leadership team, I’ve found that “diligent” is also an apt way to describe its approach to innovation. For example, JFrog acquired the Qwak MLOps solution this summer and now offers a nice alternative to the hyperscalers when it comes to securing, managing, training, integrating and deploying AI and ML models.

It also launched a major partnership with GitHub that integrates Artifactory with GitHub Copilot. This, in my opinion, fills a major gap with AI code assistance. A challenge with AI code assistants is they are trained on public information. In order to get an assistant to comply with enterprise standards, the standards need to be documented so retrieval-augmented generation can be used to confine the model. Customers have to do this integration themselves and keep the standards up to date—and both of these tasks may be hard to do. However, Artifactory is a great reflection of the accepted versions and components that developers are allowed to use; by being pre-integrated with GitHub Copilot, the two challenges just mentioned are eliminated.

Announcements like these from other companies would inspire a very AI-heavy agenda and message. However, JFrog seemed much more interested in connecting the announcements to its Everyops messaging.

It strikes me that this approach is core to the culture of the company. JFrog was nice enough to let me speak to at least a half dozen customers one-on-one, and I was also able to connect with many more informally throughout the show. There was not a single customer who was not looking at expanding their relationship with JFrog, particularly with its recent security capabilities.

During keynotes, it was also made very clear that JFrog’s roadmap was crafted based on customer and partner demand, rather than what was “hot” in the market. When I asked different members of the team about this, it was clear to me that they were all dialed into this approach. My experience is that this kind of mindset is really hard to fake, because sustaining this approach requires steady incremental progress, versus big, flashy market moves.

Thoughts On The Future And Recommendations

I walked away from SwampUp 2024 impressed with what a company the size of JFrog is delivering. I also agree that the time is right for enterprises to consider how their existing DevOps will perform in the face of security and AI requirements that will only increase over time. That said, I was asked a couple of times what else JFrog could do better. Two items stood out to me.

1. Sharpen up the Everyops vision — While the industry broadly agrees that the developer role will evolve, there is not a lot of discussion about which needs that evolution implies. We saw something very similar when cloud development got moving. Cloud offered developers new opportunities in areas such as on-demand self-service infrastructure, mircoservices and continuous integration. Those technical opportunities were the catalyst for the DevOps movement as we know it today. I think that JFrog has already understood where development will be going in the next five years; that’s what it calls Everyops. However, now would be a good time to go beyond the product roadmap to provide some thought leadership on the Everyops roles, job definitions and processes that inform this strategy.
2. More security context, please — As I thought about JFrog’s approach to security, it stuck out how the team has a very inside-out approach. They start with the artifact and extend it out to the runtime. This is the opposite of many security tools that start at the edge and try to keep bad actors from entering. However, I saw a JFrog MLOps presentation where the speaker did a great job comparing JFrog to Amazon SageMaker. I think that when it comes to security—especially considering the number of competitors out there—JFrog should consider going a bit deeper in explaining its uniqueness vis-a-vis the more commonly held points of view in the industry.

To summarize, I was impressed with what JFrog, its customers and its partners all had to say about the direction of DevOps and JFrog’s role in the future. In the bigger picture, if your team is still struggling with a bespoke DevOps solution, you should take a look at a more platform-centric approach.