Level-up your software distribution program
When delivering software to clients, many independent software vendors (ISVs) still rely on methods involving traditional software packaging methods such as downloadable binaries, ZIPs, or other type of compressed delivery. These distribution approaches are often OS specific. As a result, developers are forced to spend precious time on tailoring software delivery rather than innovation. Containerization is already simplifying software delivery for many of today’s mainstream products. Choosing the right container registry that meets ISVs requirements is crucial to satisfy vendors and meet client expectations.
ISVs should take advantage of advances in this area to focus on packaging their product as container images. It must provide automation, easy customer access, and self-service options. In this article, we will explore a solution allowing software vendors to distribute their product as container images and link the container registry with a payment system.
An ISV builds and distributes branded software meant to run on multiple client systems. It follows the tenet that software packaging and delivery is a core part of an ISV’s operations. As revolutionary as the vendor’s new software might be, the client will have a hard time adopting the software if it is a pain to install and operate.
A promising method for efficiently packaging software for distribution is containerization. It provides a way to package software, its dependencies, and configuration files into a single, distributable container image. A piece of software may be targeted for a specific operating system. However, containerized software packages do not require a copy of an OS to be included in the image. Instead, containers utilize the host machine to securely isolate one or more instances of the software. Furthermore, they allow for cross-platform compatibility so that the program may run on a variety of operating systems.
You can think of a container image as an ISV’s product wrapped in a ready-to-go package. One containing everything a client needs to run the software when combined with their preexisting infrastructure.
Because vendors distribute software intended for client-specific environments, containerization allows them to develop a universal package instead of catering to a specific OS. Experience dictates that most clients are happy to receive a package that is not machine-dependent. Although, there are instances when they may require the ability to use the software using both traditional and newer methods.
There are key benefits to distributing software as a container image or even as multiple container images. First of all, the method facilitates the software’s management and deployment with existing infrastructure like Docker or Kubernetes.
Second, distributed container images have an out-of-the-box update mechanism using docker pull. This command lets you easily download the image that you require. The pull command will also update the image if a new version is available.
Third, because container images follow standards in how they are constructed, many tedious tasks can be automated. Tools like Clair allow you to parse through the contents of a container image, exposing any known security vulnerabilities via dependency scanning.
Lastly, delivering software as a container provides an optimally consistent operating environment for the software. As long as the required configuration and environment variables are in place, you can be rest assured the image will perform for the client without regard for machine specifics.
Traditional digital software distribution is performed not only with different packaging formats, but different transmission channels as well. The most common of which are http, ftp, or an email attachment. In the containerization world, images are distributed primarily over container registries. These registries are directly accessed from the customer’s container hosting environment at runtime. The workflow is highly standardized, fully automated, and require the ISV to provide a container registry for clients to access.
One major challenge that emerges when distributing a container image stems from customer access to your private container registry. You want clients to download the software they pay for, but do not want to give them access to images that they are not entitled to. How do you provide the best developer/customer experience while only giving customers the level of access that they require? Additionally, how do you integrate a CRM, ERP, or payment system with a container registry in a way that automates the provisioning of customer access to the software at sale completion?
Based on client expectations and typical ISVs workflows, one can infer key requirements for container registries for ISVs. When choosing a container registry, it is important to clarify some aspects. For instance, what integrations do you require? What tasks will need automation? How would a container registry fit into your current distribution channel?
A container registry should:
In addition to the above, there are other aspects that may be considered useful such as a custom domain, easy Web UI, and auditing capabilities.
Docker Hub has made huge strides in container technology, but that does not mean it is automatically the defacto choice in the realm of software distribution. While Docker Hub offers special programs for ISVs, it lacks fine-grain access control that vendors often seek. Other drawbacks of Docker Hub include a functionally limited REST API and a short list of accepted payment methods. More importantly, Docker Hub charges a fee of two-digit percentage points on all software sold through their marketplace. A strong factor for any ISV when choosing a solution.
While there are some software vendors using Docker Hub, Container Registry’s ISV programs offer a combination of features that give enterprise users a leading edge in software distribution. For example, based on Harbor, Container Registery offers all the pros of Docker Hub with advanced security and identity-management features built-in. This allows clients to consume images without restriction for only the products they have purchased.
As a solution, it is recommended you manage client access to projects using a setup like Harbor’s Guest or Limited Guest accounts or Robot accounts. Using one of these methods, you can manage privileges and extend access to customers based on their subscription.
There are two ways to distribute images with Container Registry. The first involves distribution from an account that the client creates, or one you create for them using the API. However, if the registry is using an identity provider like LDAP or OpenID Connect, the client needs to have an account with such identity provider. In a corporate environment, this may not be possible since identities are usually handed out to employees only.
In the second scenario, a robot account associated with a particular client needs to be generated over the API. With this approach, the client will not have a UI login. Rather, they end up with only a permission to pull images. Aside from the type of account created, there is not much difference in the two workflows.
Using this methodology, let us look at an example of how to synchronize a subscription management service with a container registry. The Harbor container registry provides a complete OpenAPI Specification that makes managing users and projects seamless over a RESTful API.
A Python integration example is available to demonstrate Stripe Billing with Python SDK. This will provide specifics on how to get started with the Container Registry as an ISV. Full documentation and source code can be found on GitHub.
Let us say your client signs up for an account. Your ISV script generates a repository and creates credentials for them based on a subscription webhook. In this script, specific files are dedicated to responding to a client’s subscription. In the views.py file, we receive and process webhooks from Stripe. Information regarding the customer’s subscription status is returned and action is taken accordingly. This is done by creating functions that direct the program as to how to handle client actions:
def handle_new_subscription(subscription):
customer = Customer.objects.get_or_create(
stripe_id=subscription['customer'])
customer.ensure_email()
customer.create_harbor_user()
customer.save()
The webhook handler will call such functions by first taking the request body and determining what type of event the client has initiated:
def webhook_handler(request):
payload = request.body
event = None
try:
event = stripe.Event.construct_from(
json.loads(payload), stripe.api_key)
Upon determining the event type, the handler will then execute the appropriate action from a list of possible actions based on the webhook’s payload. For example, for a new subscription, it calls the above defined function constructed for that specific case:
if event.type == 'customer.subscription.created':
new_subscription = event.data.object
handle_new_subscription(new_subscription)
In the models.py file located in the same directory, we will update the internal database and manage access for the container registry. If the customer is in good standing, they receive credentials; if they have overdue payments, their container registry credentials are disabled:
def provision_product_access():
h.provision_harbor_permissions_for_customer(self)
def remove_product_access():
h.remove_product_access_for_customer(self)
As you can see, designing webhooks to respond to customer actions is a very straightforward process but one that requires thorough planning. Fortunately, many subscription management solutions used for integrations provide documentation (e.g., Stripe’s endpoint guide) to walk you through setting up your webhook notifications code.
In this article, we went over why ISVs should be distributing software as container images. We touched on the challenge of determining appropriate client access and offered a solution before presenting Container Registry as the service of choice. Lastly, we went over an example of using webhooks to sync subscription management software with your container registry. The full example of which can be found on GitHub.
This example is just one possible option on how ISVs can distribute software to clients. Let us know about your particular requirements and see if Harbor can be used for that.
If you are ready to level up your software distribution program, head over to Container Registry.
Level-up your software distribution program with our Harbor based Container Management Solution.
Published — February 7, 2021
