APS technology: cloud standard
Hi, Habr! My name is Timur Nizametdinov, I work as a Senior Software Architect for the Odin (Ingram Micro) cloud ecosystem. Today I want to tell you about APS (Application Packaging Standard) - a key technology used to integrate into the OaDin Automation platform for the sale and consumption of cloud services (SaaS marketplace).
')
We are building a platform that will connect all developers and consumers of cloud services through the infrastructure of major service providers (providers of telecommunications and hosting services), while also providing an entry point for end users: a control panel or portal, with which you can create a website, configure mail, Buy antivirus or virtual machine in the cloud.
OSS manages the creation of services and their consumption. In the case of cloud services, this becomes a non-trivial task, because each service has its own API. In order to solve this problem, we need APS, which provides the operations support system with a single API for managing and accounting for cloud services.
APS allows different companies to integrate their services into the platform using the so-called APS Connector. In addition to interacting with the platform as such, services can interact with each other through a standardized RESTful API within the APS bus.
APS bus is a protocol that provides all participants with access to each other’s resources, including platform resources.
The bus function is provided by the so-called APS Controller, which takes over the functions:
The technology supports the policy system - each category of users has its own set of privileges and restrictions. Among other things, we support deep integration into the control panel user interface, which allows:
The platform services themselves (User Management, DNS Management, Account Management) interact with each other through the APS bus. In this sense, we are engaged in dog-fooding - we use APS to isolate our own modules.
In marketing, there is a 4P rule: product, price, promotion, place . To make a product “shot” it is not enough to make a candy out of it: you need to correctly determine its price (price), unwind (promotion) and figure out where to sell it (place). All this is true for software products, many of which today are distributed through various platforms - app stores. At the same time, the best thing that the platform can do is to save you from the problems with the last three “P”: make the application visible to all potential consumers with minimal effort from the developer.
All of the above applies to cloud services - they also need to be sold, unwind and select sites for distribution. Service providers, such as telecommunications and hosting service providers, who have a huge user base, can act as such sites. For a developer, entering such a base is a key opportunity for the development of a service. Interested in big players such as Microsoft Office 365, Symantec, Trend Micro and Dropbox, who are looking for new and new markets, as well as small ones that are at the beginning of the way - have created a service, but do not yet know how to sell it and not have their own billing.
As a result, the service developer does not need to think about product promotion (market analysis, creating and setting up sales plans), payment, or even about the geography of sales — large providers may have so-called resellers. For example, O2 (yes, the same operator in roaming in Europe) is a subsidiary of the largest telecommunications provider Telefónica.
Recently, the model of consumption of various services is changing, especially in the segment of small and medium businesses. The classical consumption model of software and hardware (“boxed” software, purchase of servers, as well as their installation and support) is dying. Both the provision model (increasingly - service, from the cloud) and the method of purchase (by subscription) are changing.
For example, a user used to buy from a Microsoft Office reseller on a CD through a standard Microsoft distribution channel. In the new consumption model, the company physically transferring the media no longer exists. The consumer receives cloud licenses for Microsoft Office 365 either directly from the developer - vendor, or through a service provider connected to a platform such as Odin Automation.
About the purchase directly by an individual, everything is clear, and if the company uses many different services? Microsoft Office 365, Adobe Creative Cloud, Azure, Dropbox, My Warehouse, etc. You need to have a lot of disparate contracts, manage subscriptions and distribute them to employees, monitor use rights, separately and on time pay for each service in different currencies, start accounting documents with each developer. There is a need for an aggregator that can take on all these functions. This is the essence of the Odin Automation platform.
Among other things, the consumption model has changed: the user pays for cloud services at a certain frequency within a subscription, in contrast to traditional products, which are purchased once.
Odin has created a b2b2b platform (business to business to business, business-to-business) for the sale and consumption of cloud services, deployed in the infrastructure of service providers. At the same time, the buyer (business owner in the b2b2b chain) can manage their acquired services from a single control panel.
For example, using our platform, a small or medium business owner can provide mail and antivirus to several of his employees at once, view his balance on all services in his personal account, pay all subscriptions with a single bill in local currency, and also receive advanced technical support. Its success with customers depends on how many different services the provider provides: this trend has been widely developed in America and Europe for several years.
Create an APS Connector, APS package and place the APS package in a directory.
APS Connector is a key element in service integration.
It consists of 2 parts:
1) APS Connector Backend,
2) APS Connector Frontend.
The APS Connector Backend converts the APS API into a service-specific API. APS Connector Frontend provides an interface that integrates into the control panel of Odin Automation.
APS Connector Backend is an HTTP Endpoint whose API is subject to certain conventions. For example, to create a service, the platform will send HTTP POST with resource representation to the APS Connector Backend. Based on the data in the representation (for example, links to a user - a potential customer of the service), the APS Connector Backend can decide to create a resource — for example, a user — on the service side.
The resource itself is described in the json-scheme placed in the APS package. The scheme allows Odin Automation to understand how to manage and sell a resource.
That is, for example, when purchasing a Microsoft Office subscription through a service provider, the license on Microsoft Office servers is created using logic implemented in the APS Connector Backend.
A developer can develop an APS Connector Frontend — enable specific presentation logic (user interface) for:
After deploying the APS Connector package in the infrastructure of the service provider, it is ready for sale. At the same time, the APS Connector Backend can be placed in the cloud and be deployed, for example, in any PaaS service such as Google App Engine or Microsoft Azure WebApp.
Among other things, we certify APS Connector packages by analogy with Google PlayMarket and Apple AppStore. After certification, the application enters the APS directory, from where it can be installed into the service provider's infrastructure.
Thus, Odin Automation already packs more than 500 applications, including Microsoft Office 365, Dropbox, Symantec, Acronis, Autodesk, Autocad, Trend Micro and many others.
For now, we’ll consider only the creation of the APS Connector Backend, the creation of the APS Connector Frontend is the topic of a separate article, and we are also working on a technology that allows you to create APS Connector very quickly and generate a fairly advanced user interface automatically.
Suppose you have a service that provides cloud storage for users and organizations. Let's call it Fallball.
In the simplest form, Fallball has the following model:
Suppose files are stored on some disk on a computer in your room in the / <accountId> / <userId> folder, and users will be granted access via WebDav.
First, we express the service model in terms of APS.
Let your service be sold by subscription and when you buy, you can limit the total amount available to the business owner for all its employees. The provider, in turn, will configure the corresponding plans for sale using our platform, for example, Basic (10 GB) and Advanced (100 GB). The size of the space allocated to the user will be stored in the diskspace field.
Blue marked APS resource schemes, which will be described in the APS Connector package.
Next you need to make HTTP-endpoint APS Connector Backend. Choose any technology to your liking: from a small Python application with flask in your home, to a Java webapp deployed in Google App Engine.
For simplicity, let us assume that when creating an account or user, the corresponding account and user in the service will be deleted. In a very rough form, the sequence diagram will look like this:
Pay attention to the diskspace field - this is the standard type “APS Counter”, which is a structure. In the limit field, Odin Automation transmits the limits specified in the billing. The service may use this information in order to prevent the consumer from going beyond this value. In this case, limit the storage space to 10 GB.
It remains to describe the types in the form of a json-schema, declare url-routing (in this case, specify that when creating a subscription, you need to make POST to / account). And that's it - APS Connector Backend is ready!
This article is a very brief introduction to APS technology. We didn’t cover those technologies that are behind the standard, and, in fact, we made a platform for seamless integration of various cloud services created by third-party developers, with the goal of selling by the provider and user consumption in a single control panel.
If it is interesting, in the following posts we will describe in more detail how it all works.
And yes, here is the link to the official Odin Automation SDK documentation, the main part of which is the APS standard: doc.apsstandard.org/7.1 .
Thank!
About the platform
')
We are building a platform that will connect all developers and consumers of cloud services through the infrastructure of major service providers (providers of telecommunications and hosting services), while also providing an entry point for end users: a control panel or portal, with which you can create a website, configure mail, Buy antivirus or virtual machine in the cloud.
Odin Automation consists of the following components:
- An online store whose mission is to attract end users, as well as small and medium-sized businesses interested in purchasing products such as Microsoft Office 365 or Dropbox for Business. The system helps to choose the most appropriate solutions, to orient in their capabilities and versions.
- Control panel of purchased services (Control Panel / Self-management Control Panel), the task of which is to provide management capabilities, additional purchases (upsell) and cross-sell (cross-sell) of services to the buyer.
- The Business Support System (BSS, Business Support System) , which manages workflows, initiates payment, provisioning, billing, and so on.
- Operation Support System (OSS, Operation Support System) , which deals with accounting, planning and provision of services.
OSS manages the creation of services and their consumption. In the case of cloud services, this becomes a non-trivial task, because each service has its own API. In order to solve this problem, we need APS, which provides the operations support system with a single API for managing and accounting for cloud services.
APS allows different companies to integrate their services into the platform using the so-called APS Connector. In addition to interacting with the platform as such, services can interact with each other through a standardized RESTful API within the APS bus.
APS bus is a protocol that provides all participants with access to each other’s resources, including platform resources.
The bus function is provided by the so-called APS Controller, which takes over the functions:
- access control (the policy system - each category of users and applications has its own set of privileges and restrictions);
- resource lifecycle management services;
- search and store the necessary data (in some sense, the cache, which allows not to request data from the service every time, for example, to draw the UI; in fact, we made a post NoSQL database, but more on that in the following articles).
The technology supports the policy system - each category of users has its own set of privileges and restrictions. Among other things, we support deep integration into the control panel user interface, which allows:
- implement screens that will become part of the overall navigation tree;
- place the screens of one application in another (for example, in the wizard to create a user);
- provide parts of the user interface in the form of widgets (for example, in the form of a tile on the main page).
The platform services themselves (User Management, DNS Management, Account Management) interact with each other through the APS bus. In this sense, we are engaged in dog-fooding - we use APS to isolate our own modules.
Why a developer of cloud services Odin Automation and APS?
In marketing, there is a 4P rule: product, price, promotion, place . To make a product “shot” it is not enough to make a candy out of it: you need to correctly determine its price (price), unwind (promotion) and figure out where to sell it (place). All this is true for software products, many of which today are distributed through various platforms - app stores. At the same time, the best thing that the platform can do is to save you from the problems with the last three “P”: make the application visible to all potential consumers with minimal effort from the developer.
All of the above applies to cloud services - they also need to be sold, unwind and select sites for distribution. Service providers, such as telecommunications and hosting service providers, who have a huge user base, can act as such sites. For a developer, entering such a base is a key opportunity for the development of a service. Interested in big players such as Microsoft Office 365, Symantec, Trend Micro and Dropbox, who are looking for new and new markets, as well as small ones that are at the beginning of the way - have created a service, but do not yet know how to sell it and not have their own billing.
As a result, the service developer does not need to think about product promotion (market analysis, creating and setting up sales plans), payment, or even about the geography of sales — large providers may have so-called resellers. For example, O2 (yes, the same operator in roaming in Europe) is a subsidiary of the largest telecommunications provider Telefónica.
And why should a consumer buy cloud services from a service provider?
Recently, the model of consumption of various services is changing, especially in the segment of small and medium businesses. The classical consumption model of software and hardware (“boxed” software, purchase of servers, as well as their installation and support) is dying. Both the provision model (increasingly - service, from the cloud) and the method of purchase (by subscription) are changing.
For example, a user used to buy from a Microsoft Office reseller on a CD through a standard Microsoft distribution channel. In the new consumption model, the company physically transferring the media no longer exists. The consumer receives cloud licenses for Microsoft Office 365 either directly from the developer - vendor, or through a service provider connected to a platform such as Odin Automation.
About the purchase directly by an individual, everything is clear, and if the company uses many different services? Microsoft Office 365, Adobe Creative Cloud, Azure, Dropbox, My Warehouse, etc. You need to have a lot of disparate contracts, manage subscriptions and distribute them to employees, monitor use rights, separately and on time pay for each service in different currencies, start accounting documents with each developer. There is a need for an aggregator that can take on all these functions. This is the essence of the Odin Automation platform.
Among other things, the consumption model has changed: the user pays for cloud services at a certain frequency within a subscription, in contrast to traditional products, which are purchased once.
Odin has created a b2b2b platform (business to business to business, business-to-business) for the sale and consumption of cloud services, deployed in the infrastructure of service providers. At the same time, the buyer (business owner in the b2b2b chain) can manage their acquired services from a single control panel.
For example, using our platform, a small or medium business owner can provide mail and antivirus to several of his employees at once, view his balance on all services in his personal account, pay all subscriptions with a single bill in local currency, and also receive advanced technical support. Its success with customers depends on how many different services the provider provides: this trend has been widely developed in America and Europe for several years.
And what should be done for integration?
Create an APS Connector, APS package and place the APS package in a directory.
APS Connector is a key element in service integration.
It consists of 2 parts:
1) APS Connector Backend,
2) APS Connector Frontend.
The APS Connector Backend converts the APS API into a service-specific API. APS Connector Frontend provides an interface that integrates into the control panel of Odin Automation.
APS Connector Backend is an HTTP Endpoint whose API is subject to certain conventions. For example, to create a service, the platform will send HTTP POST with resource representation to the APS Connector Backend. Based on the data in the representation (for example, links to a user - a potential customer of the service), the APS Connector Backend can decide to create a resource — for example, a user — on the service side.
The resource itself is described in the json-scheme placed in the APS package. The scheme allows Odin Automation to understand how to manage and sell a resource.
That is, for example, when purchasing a Microsoft Office subscription through a service provider, the license on Microsoft Office servers is created using logic implemented in the APS Connector Backend.
A developer can develop an APS Connector Frontend — enable specific presentation logic (user interface) for:
- informing the user about the status of purchased services (for example, the remaining Microsoft Office licenses);
- the possibility of additional services purchase within the service (for example, additional disk space in the cloud storage);
- facilitate access to application resources (for example, download links for a client to access Dropbox and documentation).
After deploying the APS Connector package in the infrastructure of the service provider, it is ready for sale. At the same time, the APS Connector Backend can be placed in the cloud and be deployed, for example, in any PaaS service such as Google App Engine or Microsoft Azure WebApp.
Among other things, we certify APS Connector packages by analogy with Google PlayMarket and Apple AppStore. After certification, the application enters the APS directory, from where it can be installed into the service provider's infrastructure.
Thus, Odin Automation already packs more than 500 applications, including Microsoft Office 365, Dropbox, Symantec, Acronis, Autodesk, Autocad, Trend Micro and many others.
Creating an APS Connector Backend with an example
For now, we’ll consider only the creation of the APS Connector Backend, the creation of the APS Connector Frontend is the topic of a separate article, and we are also working on a technology that allows you to create APS Connector very quickly and generate a fairly advanced user interface automatically.
Suppose you have a service that provides cloud storage for users and organizations. Let's call it Fallball.
In the simplest form, Fallball has the following model:
Suppose files are stored on some disk on a computer in your room in the / <accountId> / <userId> folder, and users will be granted access via WebDav.
First, we express the service model in terms of APS.
Let your service be sold by subscription and when you buy, you can limit the total amount available to the business owner for all its employees. The provider, in turn, will configure the corresponding plans for sale using our platform, for example, Basic (10 GB) and Advanced (100 GB). The size of the space allocated to the user will be stored in the diskspace field.
Blue marked APS resource schemes, which will be described in the APS Connector package.
Next you need to make HTTP-endpoint APS Connector Backend. Choose any technology to your liking: from a small Python application with flask in your home, to a Java webapp deployed in Google App Engine.
For simplicity, let us assume that when creating an account or user, the corresponding account and user in the service will be deleted. In a very rough form, the sequence diagram will look like this:
Pay attention to the diskspace field - this is the standard type “APS Counter”, which is a structure. In the limit field, Odin Automation transmits the limits specified in the billing. The service may use this information in order to prevent the consumer from going beyond this value. In this case, limit the storage space to 10 GB.
It remains to describe the types in the form of a json-schema, declare url-routing (in this case, specify that when creating a subscription, you need to make POST to / account). And that's it - APS Connector Backend is ready!
At last
This article is a very brief introduction to APS technology. We didn’t cover those technologies that are behind the standard, and, in fact, we made a platform for seamless integration of various cloud services created by third-party developers, with the goal of selling by the provider and user consumption in a single control panel.
The most interesting technology used by us in brief:
- Own post NoSQL database (the term “ontology base” is often used) for storing data (resources) of heterogeneous services and maintaining links between them.
- Types with support for inheritance; json-scheme as a description format;
- Resources as type instances with the ability to store both structured and unstructured data and support links;
- Connections (both explicit and implicit);
- Resource methods with http routing support;
- Ways of access to entities, collections, connections using a special language for access to REST objects - RQL;
- Differentiation of access to resources, in which any resource can act as a security principal (not only the user, but, for example, an application);
- Versioning;
- Authentication mechanisms (SSL client certificate, OAuth);
- Creating and managing the life cycle of the resource;
- Own technology for combining screens and data services into a single user control panel;
- General declarative navigation based on a common data bus;
- Isolation of applications from each other;
- Unified UX Guideline;
- Common js framework;
- Only RESTful interfaces as a cross-component API;
- API standardization;
- Active use of PaaS (Google, App Engine standard, Compute Engine, Cloud SQL, Amazon DynamoDB, Azure, Azure App Service, SQL Azure Database);
- Public API with all the consequences:
- Versioning;
- 100% test coverage;
- Constant monitoring of logical integrity, expressiveness, compliance with the level of abstraction of the subject area;
- Self-documentation.
If it is interesting, in the following posts we will describe in more detail how it all works.
And yes, here is the link to the official Odin Automation SDK documentation, the main part of which is the APS standard: doc.apsstandard.org/7.1 .
Thank!
Source: https://habr.com/ru/post/324422/
All Articles