I recently came across something I didn't know much about: the "Application Packaging Standard, or APS. It seems you can't find a lot of independent information about this topic yet. If you google the term, you won't get more than press releases, along with some other official documentation. No active user community seems to be surrounding this "open standard.” As it could be an opportunity for my own cloud emailing company, I've decided to dig a little bit into what APS has to offer to APIs in general.
What is the APS Standard?
APS is an initiative coming straight from Parallels, a virtualization technology company and global cloud service leader. The company describes APS as the following:
Application Packaging Standard (APS) is a set of specifications for provisioning, managing, and integrating cloud-based apps and services. (...) APS is an open standard, and all APS specifications are available (...) for free.
In other words: if you package your app with APS, it will make it interoperable with Parallels' ecosystem.
3 Types of APS Apps
The Webspace Applications: this type of application, which involves a partition inside a Web server, is designed to work in a shared hosting setting and requires a Web stack (http, https, php/python, etc.). For example, the web servers: Apache, IIS, CloudLinux LVE, Azure (Web)...[Trop confus ces exemples, a revoir]
The Dedicated Applications: This type of application, which involves a standalone operating system image, requires a non-shared environment. Example of environments: Physical, VZwin, VZlin, PSBM, etc.
The Connector Applications: This type of application, which interfaces to an external service, gives users a way to programmatically control a remote service. Example environments: Externally hosted services. Installer Type: Set of files or native package. Typically relies on APIs!
Note that only the third type relates to cloud apps that fully rely on an API. We'll focus on these.
The Business Model Behind
There are 3 business models proposed by Parallels to Internet Service Vendors (ISVs):
The Direct Model: "your revenue comes directly from the sales activities of the Parallels partners, in accordance with the terms of your agreement with them." In this scenario, you don't deal with Parallels at all, you simply pay a transaction fee to the partner (the partner delivers services from a Parallels platform, see next sections for examples).
The Referral Model: "you and Parallels have an agreement to collaborate more closely on the sale of your offering. In this case, Parallels receives a percentage of the wholesale price of every sale you make to the Parallels PA or Plesk Panel partner. This model increases the interest level of Parallels' sales team to drive joint sales activities." Here, the relationship gets closer!
The Reseller Model: "Parallels sells your offering directly to the purchaser via an e-commerce (credit card) experience." The reseller model fits better with businesses selling licenses (as opposed to SaaS vendors).
Bottom line: Your relationship with Parallels heavily depends on the model that you choose. Each of them has its constraints, but the more Parallels in implicated with your app, the better the distribution!
Is API Packaging All About the Distribution? Not Only...
For sure, standardizing your app gives you access to a powerful distribution network that includes Parallels Automation and Plesk Panel partners. The latter actually are the service providers who will resell your product. As examples, we can cite: LuxCloud, 1&1, T-Systems, ReadySpace, etc. These relays will help you increase your time to market. Actually, the targets that you reach through these channels don't need to spend time on integration. But there's more.
Reaching clients through APS may also reduce your churn rate. The end clients actually get all their services in a one-stop shop: this improves your customer retention as they may feel more comfortable sticking with your service, because it's so easy to use and integrate into their all in one interface.
Is APS an Opportunity for You?
Here's the personal advice I would give. To see if APS can be interesting for you, browse the catalog and find an app similar to yours. Then, compare from one week to the next how many times their package was downloaded. Do this for one month. This technique is not time consuming and quite informative. It will allow you to measure Parallels' traction. This is what I do to see if it would be beneficial for Mailjet ;-)
A Real World Example
It's interesting to see what all this actually looks like for the end user. Let's stick to my Mailjet app example. Half fictitious, but it helps to understand!
After a few weeks, we've realized that APS was in fact beneficial for us. So, we've decided to package our API with it. Now, as a marketer, I want to leverage this new channel. So I decide to get in touch with some Parallels partners who use the APS standard to deliver applications. My first name on the list would be Luxcloud: their model is typical and here's what it looks like:
Mailjet is an all-in-one solution to send, track and deliver both marketing and transactional emails. Thus, it seems like it could perfectly fit in their offering. Therefore, I will want to contact them and see what kind of partnership we could establish: would they use us a white label solution? In this scenario, the end-clients don't know they're using Mailjet and the emails sent can be invoiced at any price. Or should we propose a model where we pay a fee for each client activated through this channel? The possibilities are seemingly endless.
To finish, here's what the interface of the end-user looks like:
Luxcloud is one of the many Parallels partners. Counting the number of downloads of similar apps may not be enough :-) Therefore, to see if APS could be an asset for your business, you might want to get in touch with a certain number of partners and see if your product fits their offer. If that’s the case, you then can make a decision.
My objective is not to write a White Paper about APS, so I'll stop here! But I wanted to give a brief overview of what it is. At first sight, when you browse official documentation, you can get a bit lost in the theory. Although this project is already a few years old, it still seems like it's in a launching period. If there are a lot of "case studies" available, it is very hard to find real feedback about the efficiency of an integration. So... any feedback will be more than welcomed!