Refresher: deploying software and packages#
Why does JFrog exist, and what problems do they solve? The key is to understand the “DevOps” buzzword, which is what I’m here for. Quoting from the What’s DevOps post:
To understand why DevOps as a concept has gotten really popular recently, you need to understand software delivery and how that’s changed over time. → What it means to deliver softwareWhen a team of engineers builds an application, it’s just a bunch of code. And that code needs to run somewhere for users to access it and get value out of it. During development, developers tend to run that code on their personal computers, but that’s obviously not scalable - so when they’re ready to share the software with the world, they’ll put that code on big powerful servers, and let people access it via a domain name like https://technically.dev. So in general, delivering software means taking the application you’ve built and figuring out how to distribute it widely to whoever wants to use it.→ How things have changed, a lotJust 10-15 short years ago, a lot of delivering software meant literally delivering software - Microsoft Office used to ship to you on a CD that you’d install directly to your computer. And it wasn’t web-based, so you didn’t need internet access to use Excel or Powerpoint. The public cloud (AWS and co.) didn’t exist, so if you needed to run software on a server or two, you’d need to literally build that infrastructure yourself, which used to cost millions of dollars up front. So naturally, software delivery was bespoke and on the slower side.But then people started consuming software via the internet, and public clouds like AWS made it cheap and easy to use a server without having to build a data center. That fundamentally changed 3 things:The scale of software increased - software is generally used by a lot more people than in the past. You could realistically need to support millions of users for your applicationInfrastructure got more complicated - we’re moving towards increasingly specialized managed infrastructure for different parts of the stack. Generally, you don’t just throw your code onto a box and forget about it anymoreTeams started releasing a lot more often - changes in philosophy mean teams are now shipping code changes to users as often as multiple times a day, which means many many more opportunities to break thingsWith these fundamental shifts happening, teams needed to start building processes for managing this stuff, and making sure their apps didn’t constantly break and disappoint their users. And that’s basically what DevOps is - making sure your app works at scale.
There’s one more thing you’ll need to know to understand JFrog - packages. Today, pretty much all software you use is built on top of existing “packages” of code written by other people, most of which are open source. A few popular examples:
If (more like when) you’re using packages like these in your applications, they save you a lot of time and headache - but they also add complexity:
- Versioning - the folks working on React are constantly updating and improving it. Which version did you build your software with? Will newer versions of React break your software? How do you deal with upgrades?
- Packaging - how do you include the underlying code for React in your application itself? Do you pull it from the web, or store it on your own servers?
- Security - are the packages you’re using secure? If vulnerabilities are discovered, how do you patch them?
You’ll also see these packages referred to as dependencies, because your software is dependent on them to run.
If you’ve heard of NPM or Yarn, these are package managers, and they exist to solve some of the problems we’ve outlined above. They’ll register which packages your project uses, tie things to specific versions, and let you upgrade easily.
The JFrog product suite#
JFrog provides a group of integrated products that attempts to solve all of these DevOps issues together - moving your software from local to remote, managing packages, and building CI/CD pipelines.
Let’s walk through a couple of them:
1) Artifactory#
This was JFrog’s first product (back in 2009!). In software, the word artifact refers to pretty much any static group of code (your application, a package). Artifactory lets you upload your code and dependencies (the packages you’re using) through a simple REST API, and distribute them to your servers or customers across a globally distributed network (so it’s fast).
So if you’re using NPM for your Node app and Helm for your Kubernetes setup, Artifactory sits on top of those and integrates with both. The value prop is having a single place for all of your artifacts instead of using multiple package managers and worrying about how they work together. Gitlab offers a similar product.
2) XRay#
XRay scans your artifacts (so again, your code and dependencies) for security vulnerabilities and compliance issues.
Github sort of does this too.
3) Pipelines#
If you’re using something like CircleCI or Azure Pipelines to build CI/CD pipelines, you can use JFrog’s solution instead and integrate directly with the rest of their ecosystem.
For more on CI/CD, check out the original Technically post here.
4) MLOps with Qwak AI#
Like so many of its brothers and sisters, JFrog is also expanding beyond traditional DevOps into AI territory. They now have an AI product called JFrogML, that (fairly generically) supports all phases of the ML lifecycle, from training models to finetuning them and deploying them into production.
Part of this feature set is supported by their recent acquisition of Qwak AI (bad names stick together) to build out their Machine Learning operations (MLOps) capabilities. In English, this means that they'll be able to help companies deploy ML models into production more easily. Remember that there are about 1,000 options for productionizing ML out there, many likely better than JFrog's option; but none of them are integrated into the JFrog product, and that's what existing JFrog customers will care about most.
--
There’s a lot more to the JFrog product suite, like Distribution, Mission Control, and a Container Registry. Few of these individual products make sense by themselves, and there are strong alternatives in the market for each. But JFrog’s marketing and product strategy is all about integration - using all of these products together gives you a much more powerful experience than using them on their own. Pay attention to their website copy:
Universal package repository, SecOps, CI/CD and software distribution all in one platform.
Discover the power of an end-to-end DevOps platform.
It’s all about the “platform” and how it’s “end-to-end.”
Further reading#
- The JFrog S-1 has good contextual information on how they view the business, and more financial info
- Gitlab has a feature comparison between them and JFrog on their site (notice how similar the marketing is)