Inedo
What is “ProGet Edge Computing Edition” All About?
Last year, we worked closely with one of our long-time users to create a specialized offering called ProGet Edge Computing Edition.
Although this is a niche offering that’s not intended for most users, the story behind the collaboration will give you a glimpse into how we develop new features. Hopefully, it will inspire you to share some of your painpoints or ideas for improving our products.
In this article, I’ll talk about the following:
- Creating ProGet Edge Computing Edition in collaboration with Derivco
- Challenges in Edge Computing that ProGet helps solves
- Difference between Edge Computing Edition and Enterprise Edition
- How you can work with us to improve our products
Creating ProGet Edge Computing Edition
Unlike most software vendors, we don’t have a dedicated “customer support” team. Instead, our product engineers — i.e., the folks who design and develop our products — support our users directly. This includes me (the CEO), as I’m quite hands-on with our code.
I believe this not only provides the highest quality of support to our users, but it gives us a deeper understanding of the problems users are trying to solve. This helps us make improvements and add new features that better align to users’ actual needs.
Many years back — while providing support to Derivco — we learned that they were using ProGet in an unexpected way. Instead of managing developer libraries like NuGet and npm, they built a private content distribution network using the feed replication feature.
At the time, they were using NuGet to distribute tens of thousands of large packages (some exceeding 5GB) to nine hosting sites — a.k.a. edge nodes — around the globe. Due to regulatory requirements, all of their infrastructure had to be self-managed.
“The main Production feed sits at just over 800GB with 79,000 packages, with some exceeding 5GB. So really, you can see how this is a problem. How do we get these packages around the world?”
Before ProGet, Dervico was using an amalgamation of unreliable, difficult-to-maintain homegrown applications to distribute this content across their edge network. While ProGet eliminated those problems, they sought our help to solve a new, unforeseen problem.
New Problem: Limited Replication Configuration
ProGet’s replication feature was originally designed to mirror packages across two feeds, meaning changes in one feed would be immediately propagated to the other feed and vice versa. Derivco had configured multiple ProGet servers to replicate in this manner, building a content delivery network for edge computing.
However, they only wanted to distribute packages from a central location to different edge nodes. The fact that changes in an edge node could propagate across the network was a major risk. For example, if a package was accidentally deleted from an edge node, it would soon be deleted from all edge nodes.
Ultimately, we solved this problem by rethinking our replication feature. Users can now configure a replication mode — Push, Pull, or Mirror — at the feed-level. This allowed Derivco to add a lot more edge nodes to their network.
But with that success, a new problem emerged a couple years later.
New Problem: Poor Replication Visibility
As the number of ProGet edge nodes in Derivco’s global network grew, it became more and more tedious to find replication problems across their network.
Each edge node had a detailed replication dashboard that would display feed replication status and detailed logs about content that was pulled from the hub server. However, that information wasn’t centralized. This meant that each edge node had to be checked individually to determine if packages weren’t pulled due to network errors or other problems.
After brainstorming with Derivco on how to centralize this information, we designed an improved dashboard on the hub server that can display new status information that sent by the edge nodes. It looks something like this:
With this dashboard, Derivco was able to quickly identify which edge locations have successfully replicated from each hub and diagnose stale or problematic connections.
However, early last year, we discovered another problem.
New Problem: Managing Licenses & Costs
There are often many internal procurement procedures that need to be followed to purchase an additional ProGet license. You need to request a quote, allocate a budget, get internal approval, request a purchase order, and so on.
For Derivco, not only were these processes time consuming, but it was difficult to predict exactly when they’d need a new ProGet license. On top of that, managing dozes of ProGet license keys was tedious and error-prone. Especially when the time came to renew and they had to replace all the keys on every server.
We brainstormed for a bit, and came up with a novel idea: ProGet Edge Computing Edition.
By this time, a number of other customers were already using ProGet to power their edge computing network. This specialized edition would formalize our offering.
What is ProGet Edge Computing Edition?
ProGet already has the replication features required to build an edge computing network, but the ProGet Enterprise licensing model just doesn’t make sense.
Our largest installations have hundreds of edge nodes, but we’re not exactly solving a multi-million-dollar problem. Or, maybe we’re just not good at selling seven-figure software. Either way, the biggest feature is the licensing model.
Licensed/Priced to Scale
ProGet Edge Computing Edition starts at $49,995. The cost is based on the total number of edge nodes and hub servers. Edge nodes use a “banded license” model, which means they can be purchased as “up to 5 nodes”, “up to 10 nodes”, “up to 25 nodes”, etc.
Simple Edge Node Configuration
Instead of entering a license key, a ProGet instance can be configured as an “edge node”.
When configured in this manner, ProGet will essentially only be able to pull content from a ProGet Enterprise Edge Hub with replication.
The feature restriction has an additional benefit: edge nodes shouldn’t be able to do anything else. Fewer features to configure means a much lower risk of misconfigured edge nodes.
Tight Collaboration & Product “Customization”
Over the past few years, ProGet’s edge computing usage has grown significantly. Although these users represent less than 1% of our paid userbase, they account for nearly 10% of ProGet’s revenue.
As a result, we can dedicate a lot of engineering effort to a relatively small userbase, and improve replication features or add edge-only features.
For example, if one of our edge computing users has an idea for a new edge dashboard or an edge API, it’s easy to ask all the other edge computing users if that change would makes sense for them, too.
It’s not quite “custom” software, but it’s about as close as you can get with a product like ours.
What Should We Do Next?
Inedo is one of the few vendors in our space that’s neither a publicly-traded behemoth, nor trying to “scale-up” and flip the company to investors. We are in this for the long-term, and truly enjoy solving problems together with like-minded users.
I call this User-driven Development. We see our customers as investors, and work closely with the community to develop features, enhancements, and bug fixes as quickly as possible.
“From what we’ve learned through this whole journey is to speak to Inedo. Tell Inedo your problems; take it over to the guys who understand what actually has to happen in the background.”
If you’ve got an idea for how to improve our products, just let us know! It could end up as a feature, or even a whole new edition.
