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.

 SSL Certificate for domain name validation. 

Problem statement: Recently, the certificate for a website I host by name https://booksonsoftware.com/algorithms had expired. When the certificate was renewed, it could not be used as the earlier ones as the error encountered from the nodeJs application stated: 

Error: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch 

    at Error (native) 

    at Object.createSecureContext (_tls_common.js:85:17) 

    at Server (_tls_wrap.js:775:25) 

    at new Server (https.js:26:14) 

    at Object.exports.createServer (https.js:47:10) 

    at Object.<anonymous> (/home/ravi/myapp/algorithms/booksonsoftware/app.js:140:25) 

    at Module._compile (module.js:577:32) 

    at Object.Module._extensions..js (module.js:586:10) 

    at Module.load (module.js:494:32) 

    at tryModuleLoad (module.js:453:12) 

This article explains the resolution for this error. 

Solution: The certificate was already renewed from the cloud service portal by using the same private key as earlier. 

This was then exported from the Portal and uploaded to the host machine where the site was hosted. 

The certificate was in the pfx format so this required the following commands to export the certificate and private key 

1. openssl pkcs12 -in ravirajamanikeyvault-booksonsoftwared9e73889-3e5d-485b-81c7-28227725e796-20221108.pfx -nocerts -out booksonsoftware-private-key.pem -nodes 

to extract the private key. 

2. openssl pkcs12 -in ravirajamanikeyvault-booksonsoftwared9e73889-3e5d-485b-81c7-28227725e796-20221108.pfx -nokeys -out booksonsoftware-cacert.pem  
   to extract the certificate 

with this the app.js file can specify the certificate as: 

var https_options = { 

    key: fs.readFileSync('booksonsoftware-private-key.pem','utf8'), 

    cert: fs.readFileSync('booksonsoftware-cacert.pem', 'utf8') 

}; 

And 

The server can be started with: 

var httpsServer = https.createServer(https_options, app).listen(8083, function(){ 

  console.log('Express server listening on port 8083 '); 

}); 

Express server listening on port 8083 

Typical port values for https are 8443 but in this case, I wanted to use this port. 

When the key-values for the cert and the private key don’t match, the certificate may need to be rekeyed. 

Rekeying a certificate generates a new key and certificate with the same name and expiration date as a previously purchased certificate. This is performed at no charge by the cloud service provider that issued the certificate request. It is usually done when the keys are lost or compromised. 

It is easy to check if the private key and the certificate match with the following commands to display the hash: 

• openssl pkey -pubout -in <private-key-name> | openssl sha256 

• openssl x509 -pubkey -in <certificate-name> -noout | openssl sha256 

If the hash values don’t agree, then there is a mismatch. 

One of the reasons for the mismatch has been found to be the presence of chained certificates in the certificate file extracted from the pfx. If we edit this to just retain the contents between ----BEGIN CERTIFICATE---- and ----END CERTIFICATE----, the error disappears.