A case study for a multitenant solution for delivery of user-generated content to designated consumers

Content delivery networks do not solve the massive technical challenges of delivering media uploaded by users to specific groups of consumers. Media can include photos, videos, and podcasts, and are created by individuals, organizations, and small-to-medium businesses. The majority of these are of low interest to the general public, which runs counter to the principle of content delivery networks where content is for public consumption. The leading content delivery networks tailor their network architecture and operational structure toward popular content.

A multitenant solution that provides content delivery services can fulfill the requirements by virtue of isolation and scalability. When the implementation is designed for the cloud, it can become both elastic and, on a pay,-as-you-go model.   Such a service would redistribute content among edge servers and render them in a context-aware fashion.

YouTube and Facebook represent the content web platforms available for common use today. They have native support for social networking functionality but they do not provide private delivery services because all the content is aggregated together for delivery. Some web services support content delivery such as CloudFront and object storage as a cloud service but they do not support access management and segmentation requirements. Therefore, it is hard to find a solution that can address all of these requirements.

The essentials for a multitenant service that fulfills these requirements include the following:

1.       Media cloud – The media cloud is hybrid in nature. It can include on-premise appliances or public cloud services that support unconfigured content distribution with an underlying network infrastructure.  It exhibits resource virtualization in terms of computing, storage, and networking resources. For example, networks can be virtualized with point-to-site VPN connectivity or open-flow technologies.

2.       Content provider – When the content is published, a content-delivery request is submitted to a choice media service provider. Each request has the following parts:

a.       A list of locations for the content which could be private servers or storage space such as Amazon S3.

b.       A group of targeted consumers which could be a group of friends on a specific social networking platform or all the users in some geological location or within some subnet.

c.       A list of desired Quality-of-service metrics e.g. Bandwidth, delay, time jitter, security, and others.

d.        A time window during which their contents can be consumed.

3.       Workflow – Carving out a content delivery service from the underlying media cloud supports a virtual overlay that provides the required QoS with minimum cost. Storage, bandwidth, and compute required for delivery are reserved. Managerial routines can be delegated to compute that can be scaled up or down.

4.       Identity and access management to secure a targeted audience. This could be as simple as public-private key pairs to gain access.

When the virtual content delivery service is configured, contents are acquired from the storage locations and pushed into the set of edge servers from which a targeted audience can consume.

Reference: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=fBoKcN

 

 

 

Are multi-tenant SaaS Applications easy to maintain?

 The perception is that SaaS applications are maintenance free.  They certainly alleviate that concern from many customers, allows full scale across tenants who share application and database instances and remove deployment chores. Tenants can continue to download applications via the application store, but this does not impact one another. There is even cost reduction in overall application costs which makes the technology attractive to service providers.  The proper architectural choices can address numerous challenges such as resource sharing, configurability, shared instances, and scalability. The improper choices can significantly increase the costs for maintenance and operations.

Companies take the shortest path for multitenant systems as one where a single-tenant system is modified to be a multi-tenant system. They encounter two barriers that are:

·        The initial startup costs of re-engineering their existing single-tenant software systems into multi-tenant software systems.

·        The high configurability of the new systems which might even eliminate the maintenance advantage.

On the other hand, there are significant cost, the architectural choices could have been very different when the multitenant system is built from scratch. It follows that the new system design and the reengineering provide two different perspectives of the problem space and the tradeoffs between the choices.

The choices for application and database sharing include the following:

AD-  A dedicated application server is running for each tenant, and therefore, each tenant receives a dedicated application instance. 

AS – a single application server is running for multiple tenants and each tenant receives a dedicated application instance. 

AI – a single application server is running for multiple tenants and a single application instance is running for multiple tenants. 

DD – a dedicated database server is running for each tenant and therefore the database is also isolated. 

DS – a single database server is running for multiple tenants and each tenant gets an isolated database. 

DB – a single database server and a single database is being used for multiple tenants  

DC – a single database server is running for multiple tenants and data from multiple tenants is stored in a single database and in a single set of tables with same database schema but separation based on records. 

·        The challenges to overcome can be explained as:
Sharing of resources and higher than average hardware utilization, performance may be compromised. It must be ensured that all tenants get to consume resources. If one tenant clogs up resources, the performance of all other tenants may be compromised. This is specific to multitenancy and not single tenancy.  In a virtualized instances situation, this problem is solved by assigning an equal amount of resources to each instance. The solution may lead to very inefficient utilization of resources and may not suit all multitenant systems.

·        Scalability: When tenants share the same application and database, scalability suffers. An assumption with single tenancy is that tenants do not need more than one application or database but there are no such limitations that exist when placing multiple tenants on one server. Tenants from various geographies can use the same application which affects its scalability. In addition, geographies pose constraints, legislations, and regulations. For example, EU mandates that invoices sent from within the EU must be stored within the EU. Additional constraints can be brought by tenant to place all the data on the same server to speed up queries.

·        Security: When security is compromised, the risk for data stealing is high. In a multitenant environment, a security breach can result in the exposure of data to other, possibly competitive tenants. Data protection becomes an important challenge to tackle.

·        Zero-downtime: Introducing new tenants or adapting to changing business requirements of existing tenants brings along the need for constant growth and evolution of a multi-tenant system

Content reselling platform continued

 

Components:

Storage:

Media content is binary and immutable in nature. An S3 storage enables it to have web accessible address. Generating a presigned URL to upload an object enables the user interface to bypass the middle tier for uploads. This will significantly improve the time it takes to upload content. S3 acceleration can help with downloading by pointing to the closest mirror. The metadata and user information can be collected in a relational store for use by the webAPI.

When the application requires to serve the users to the scale of social engineering applications, Presto can be used to store the high-volume data in NoSQL stores and with the ability to bridge a SQL query over the data. Presto from Facebook is a distributed SQL query engine can operate on streams from various data source supporting ad-hoc queries in near real-time. It does not partition based on MapReduce and executes the query with a custom SQL execution engine written in Java. It has a pipelined data model that can run multiple stages at once while pipelining the data between stages as it becomes available. This reduces end to end time while maximizing parallelization via stages on large data sets.   
A data warehouse can be supported in the cloud in virtual data centers. It can support data ingestion in the form of JSON from data pipelines. The ability to perform queries over this warehouse follows the conventional Online Analytical Processing model and serves the reward points very well. While Presto does not dictate the data source, a data warehouse forms a veritable data store. Both can scale but there are cost-benefit ratios to consider when deploying custom stores via something offered from public clouds. 

WebAPI:

The APIs for Media and content publishing can simply be REST/GraphQL APIs for a resource named say Movie, which looks like the following: 

·        Storing movies in a database with user details such as  

o   Movie-form,  

o   user relationship,  

o   target URL to fulfil the reward from backend store, and  

o   active versus inactive state for movie

·        API to create/update/delete movies that includes: 

o   GET /api/v1/movie/ to list 

o   POST /api/v1/movie/ to upload

o   GET /api/v1/movie/:id/ to lookup  

o   PUT /api/v1/movie/:id/ to edit 

o   DELETE /api/v1/movie/:id to delete

·        List and implement movie types 

o   a name in the name.verb syntax. 

o   a payload to simply mirror the representation from the standard API. 

·        send hooks with POST to each of the target URLs for each matching movie 

o   compiling and POSTing the combined payload for the triggering resource and hook resource 

o   sending to known online retail stores with the Movie where X-Hook-Secret header has a unique string and one that matches what was issued by the backend retail store. 

o   confirming the hook legitimacy with a X-Hook-Signature header 

o   Handling responses like the 410 Gone and optionally retrying connection or other 4xx/5xx errors. 

 

Rules Engine:

A Rules Engine can be provided that introduces a callback as a URL for the Movie API servers to call which permits a dynamic policy for the translation of movies and the ability for the organization to set policies. 

·        Rule Execution Sets should be provided by the organization administrators 

o   Any complex rule involving nested if and else should be flattened to ordered list of if statements and appropriate conditions. 

o   Ordering of the conditions should be specified by the administrators. 

·        Exports or Objects returned by the Rule Engine should be published 

o   Multiple objects should be returned as a list 

o   These should be filtered by the object filter specified by the client 

o   Not include any sensitive information. 

 Content Reselling Platform: 

Introduction:  

This is a proposal for a content provider to help with a multi-outlet reselling. Content providers include those experts who write books, publish videos, and provide other forms of digital content. Earlier the media platform of choice have been Youtube for videos and Instagram for images but the limitations for these providers have included losses in copyright royalties, declining brand value, reliance on searches from users and unpredictable search rankings, and above all a commoditization of content. While those content platforms have ubiquitous reachability, they do not provide content resellers the ability to customize, repackage and resell the content via dedicated or boutique channels. End users who must rely on http access to the content also suffer from privacy and website monitoring from networking providers. On the other hand, consider mobile applications that are targeted for specific publishers, resellers and their clientele who wish not only to own redistribution of the content but also the channel and the source integration of these content via customizable but templatized applications, web services and end-user interfaces. These applications serve to provide content at the convenience of wearable computing and with the increased efficiency of time to market, low code or no code solutions over a consistent, governed, and managed multi-tenant platform and a revenue collection framework that is the envy of seller platforms and shopping framework 

Description: This proposal describes the technical feasibility of implementing such a content reselling platform that can be leased by tenants to reach end users with specific content on subscription-basis. Unlike an E-commerce application, this proposal owns the end-to-end integration of mobile applications that can be skinned with different brands and campaigns to make a distinguished offering to buyers and subscribers. The proposal also includes billing and subscription model that can be extended to suit different buying and reselling policies. The rest of this document is structured in the form of architecture and usage policies with which to implement this framework. 

Architecture: 

A multitenant architecture serves to isolate the resellers and their customers while providing a common infrastructure to meet their business needs with little or no ownership of the infrastructure. It is shy of implementing an MDM-as-a-cloud-service for these SaaS customers but provides a more integrated approach for content reselling purposes. 

Billing usage: 

The control over the resources, web application APIs and the end-user interfaces enable this framework to decouple the technology stack and architecture from the tenant’s requirements for end-user billing policies. Control over the client facing technology enables the framework to pass it on to the tenants who then determine their billing with the help of policies that the infrastructure can evaluate. The infrastructure is billed to the tenant on a pay-as-you-go model and subscription basis. Content sourcing is independent of the billing for the tenants and their end-users, and the framework assumes that it is sourced directly from the content providers or via collection frameworks. 

Conclusion: 

There are many frameworks for content publishing and sharing but media platforms that allow reselling for different agencies must leverage an ecommerce stack tailored for them. This includes s3 acceleration storage, tenant specific membership providers and billing and reselling customizations via extensibility. 

Container Based Multitenant Applications

Multitenant applications comprise of many services and containers are best suited to host them. A container has a lower resource consumption and is easier for migration and expansion. When compared to Software-as-a-service application deployed to physical or virtual machines, container technologies provide good performance isolation and cost-effectiveness.

SaaS application deployment strategies include shared container, no shared container, and shared container per SLA class. Shared container strategy is easy to deploy and expand but not so great for performance isolation. No shared container strategy is just the opposite of shared container strategy.

A large scaled application can be separated into a group of loosely coupled, applications according to core functions. The application can be developed and deployed independently in the form of components, and this meets the differentiated function customization and performance requirements of tenants. The container based microservice instances are allocated to tenants

The multitenant SaaS applications under microservice architecture can achieve performance isolation based on container technology. An SLA oriented multitenant and multi-instance hybrid deployment scheme is designed to meet the performance requirements of different level of tenants. Tenant performance isolation algorithms for microservice clusters can be implemented that provide effective performance isolation for tenants and guarantees the quality of service.

Performance isolation mechanism for multitenant SaaS applications can be discussed in terms of system architecture, SLA-oriented multi-tenant and multi-instance hybrid deployment scheme and performance isolation algorithms for microservice clusters.

The architecture for performance isolation mechanisms can be based on Access Layer, Control Layer and Service Layer. SaaS service gateway is used to select container clusters according to tenant SLA level. Control layer can implement access control mechanism. A concurrent scheduler could regularly collect the estimated resource consumption of requests from service layer. A reverse proxy-based load balancer is used to schedule tenant requests to corresponding microservice instances in the service layer. Each microservice instance is deployed in a docker container.

With the SLA-oriented multitenant scheme, the resource allocation of tenants with different SLA levels is achieved by allocating different resource quotas to the containers. Service providers can classify the tenants’ SLA into several levels in terms of data size, request concurrency, response delay, number of users and so on. This strategy provides improved security isolation.

The performance isolation algorithm for microservice clusters is about resource consumption and limits. There exists contention between tenants at the same isolation level. When there are lots of requests, there can be higher resource utilization leading to higher latency and error rates. Some form of admission control mechanism will be required along with the stopping of the tenants who have exceeded their quotas.