Data Modernization:

 

Data technologies in recent years has popularized both structured and unstructured storage. This is fueled by applications that are embracing cloud resources. The two trends are happening simultaneously and are reinforcing each other.

Data modernization means moving data from legacy databases to modern databases. It comes at a time when many databases are doubling their digital footprint. Unstructured data is the biggest contributor to this growth and includes images, audio, video, social media comments, clinical notes, and such others. Organizations have shifted from a data architecture based on relational enterprise-based data warehouses to data lakes based on big data. If the survey from IT spends is to be believed, a great majority of organizations are already on their way towards data modernization with those in the Finance service firms leading the way. These organizations reported data security planning as part of their data modernization activities. They consider the tools and technology that are available in the marketplace as the third most important reason in their decision making.

Drivers for one-time data modernization plan include security and governance, strategy and plan, tools and technology, and talent. Data modernization is a key component of, or reason for, migrating to the cloud. The rate of adoption of external services in the data planning and implementation is about 44% for these organizations.

The perceived obstacles to implementing data modernization include budget/cost constraints, lack of understanding of technology, lack of consensus among decision-makers, absence of clarity on success metrics, and such other causes. Cloud is already a dominant storage location for nine out of ten of these organizations and it is both a means and an important consequence. A majority of these organizations have all their important applications and data in the cloud. Application and data can be moved independently but many organizations are putting it on modernized platforms at the same time and moving them from on-premises to the cloud. Traditional IT architectures and on-premises data centers often come with their own cost concerns which makes cost a key driver of cloud migration. Those organizations that have combined cloud migration and data modernization could deliver on their strategic goals.

This leads to the assertion that almost all data management approaches will likely eventually be modernized and almost all data and applications will be in the cloud. Cloud migration and data modernization will continue to mutually reinforce each other. Since these two trends support and overlap each other, most companies will do well with both trends.

Collaborative caching for multitenant solutions:

 With the case study for developing a multitenant solution for the delivery of user generated content to designated audience, different algorithms are required to tune the system for higher performance. These include collaborative caching, context aware streaming, user redirection, distribution tree etc. This section discusses one of them.

Content caches are strategically located through the network which support services with optimally distributing the content from its source to its consumers. Collaborative caching allows software to use hints to influence cache management. When the hints are about the inclusion property, optimal caching can be achieved if the access sequence and cache size are known beforehand. An example of such a hint could be a binary choice between Least Recently Used Algorithm or Most Recently Used Algorithm. Another way a hint could be provided is with a number encoding a property. The result is a new algorithm that can be described as priority LRU and captures the full range between MRU and LRU.

Hints are added by annotating each memory access with a numerical priority. Data accessed with a higher priority takes precedence than data accessed with a lower priority. Collaborative caches enable the caller to specify the importance and the system to determine the priority to manage the data. LRU/MRU used to infer this importance but with a sliding scale priority specified by the caller, a new type of inclusion – non-uniform inclusion becomes possible.

The word inclusion derives from the hierarchy of caches at the machine level namely L1, L2 and so on. The property states that the larger cache will always contain the content of the smaller cache. Generally, a stack data structure is used to visualize hits and misses in play. The stack distance is a useful metric derived from the stack simulations such as for LRU and denotes the amount of data accessed between consecutive re-uses of the same entry and suggests system locality. Data elements at the top c stack positions are the ones in a cache of size c. The stack position defines the priority of the stored data. All accessed data are ordered by their priority in a priority list. The stack distance gives the minimal cache size to make an access, a cache hit and is calculated by simulating such a cache of an infinite size. In the simple LRU case, the data is prioritized by the most recent access time.  The data in a MRU cache is also prioritized by the most recent access time but unlike LRU, the lowest priority is the data element with the most recent access time.  The LRU-MRU can also be mixed where a hint indicates whether the access is LRU or MRU.  Its stack distance would be computed by the stack-based algorithm by assigning the current access time as priority for LRU and corresponding negation for the MRU. The priority hint changes the default scheme.

The effects of the priority hints on cache management include 4 cases for cache hits and 2 cases for cache miss. Consider the access to w with a priority i, (w,i) arriving in a cache of size m, and the current stack position j. The change in priority leads to the item moved up, not at all or moved down in the stack of m items and the move is just conceptual pertaining only to the organization in the stack.

These cases include:

1.       1 <= i < j <= m and w is found in the cache which leads to hit up move where item moves up to position i and the entries from i to j-1 move one position lower.

2.       1 <= j  = i <= m and w is found in the cache which leads to no movement

3.       1 <= j < i <= m and w is found in the cache which leads to hit down move where the item moves down to position I and the entries j+1 to I move one position higher.

4.       1 <= j <= m < I and w is moved out of the cache and the entries from j+1 to m are moved one position higher. This is a voluntary eviction.

5.       j = infinity and 1 <=i and <= m and the accessed data element w is missed from the cache and moved into the position at I and all entries move one position lower. The lowest priority entry is evicted.

6.       J = infinity and i > m which results in a miss bypass and the entries in the cache are unaffected.

This way the priorities stated in the hints and those implied in the access sequence is reconciled.

The case for disk quotas:

 Oracle Solaris ZFS demonstrated the use of resources and quotas. With the evolution towards cluster-based computing, Network Accessible Storage significantly widened the horizon for unlimited disk space because capacity could now be added in the form of additional nodes and their disks. This represented a virtualized storage but there were no reservations. While ZFS demonstrated effective resource management with isolations for workloads, the cluster would not keep up with the same practice without some form of roles in the form of control and data nodes. In addition, the reservations need not be governed exclusively by the user. They can be decided by system as quality-of-service levels. To achieve service levels, on the same shared disks, we can create disk groups.

There will be times when node disk groups become overloaded by I/O requests. At such time, it will be difficult to identify where the I/O requests are predominantly originating from so that those accounts could be throttled while well-behaved accounts are not affected. Each node disk group keeps track of accounts that issue the I/O requests. The system can then use a Sample-Hold algorithm to track the request rate history of the top N busiest accounts. This information can then be used to determine whether an account is well-behaved or not. If the traffic reduces when the account is throttled, it becomes well-behaved. If a node disk group is getting overloaded, it can use this information to selectively limit the incoming traffic, targeting accounts that are causing the issue. For an example of a metric to serve this purpose, a node disk group can compute a throttling probability of the incoming requests for each account by determining the request rate history for the account. If the request rate is high, it will have a higher probability of being throttled. The opposite also holds. When the metric builds up a history of measurements, it will be easier to tell if the account is well-behaved.  

Load balancing will continue to keep the servers loaded within an acceptable limit. If the access patterns cannot be load balanced, then there is probably high traffic. In such cases, the accounts will be limited, and they will be well-behaved again.  

A node may have more than one disk group so it can form logical partitions in its existing disk space while not requiring cluster level changes in providing service levels from its disks. This is the intelligent node model. If the cluster can perform more effectively by grouping data nodes or their disks and with the help of dedicated control nodes, then the data nodes are freed up to focus on the data path and merely read-write from disk groups. In either case the group id is merely a part of the metadata.
The word group is generally used with client-facing artifacts such as requests and the system resources such as disks are referred to as pools. By that definition, I’m sorry for using the word group and the above argument could be read as for disk pools.
 

 

This article picks up the previous discussion on the requirements from a multi-tenant solution for the delivery of user-generated content to designated consumers and delves into the architecture.

The architecture comprises a cloud infrastructure layer, a content service virtualization layer, and an Identity Access Management that provides authentication, authorization, and auditing. These can be integrated through an inter-cloud messaging bus that facilitates a distributed protocol for resource management, account management, content management and service orchestration.

The cloud infrastructure layer spans the public, private and personal cloud. The purpose of stretching a cloud infrastructure layer over hybrid IT resources is to form a dynamic content delivery service overlay. This overlay consists of a content distribution tree which provides 1) the required Quality-of-Service and 2) has a minimum cost. In addition to the standard storage and bandwidth required by the overlay, some computing resources are reserved for content processing, rendering and management functionalities. Each of these functionalities requires a dedicated application engine. The key module to pool all the required IT resources together is a distributed algorithm for cloud resource management. Any message-based consensus protocol could be used here such as Paxos or Raft*.

The content service virtualization layer is the one providing a suite of middleware components to support different application engines. These include:

Content distribution: which provides services for optimally distributing the content from its source to its consumers. These services are supported by content caches strategically located through the network. The distribution component. The distribution component also includes the actual mechanism and the protocols used for transmitting data over the underlying network and serving the content to the consumers.

Content processing: which provides services for sourcing and adapting content based on available bandwidth, user preferences and device capabilities. Modification and conversion also includes those for wireless devices.

Content storage: which includes modules that provision directories and artifacts for storing user generated content with security specified by the providers. The implementation of an S3 storage is a good analogy here. Functionalities include distributed secure storage, content naming, and resolution, and content replication.

Request routing: which provides services for navigating both clients’ requests to upload their contents and consumers requests to retrieve the content from the nearest and available location. The selection of this location depends on both the proximity and the availability of the system resources.

Service orchestration: which provides services for integrating different media services for internal and external service entry points. For example, a social TV application would draw a lot of individual media services such as a buddy service from social networking and a media streaming service.

The IAM and Service Bus are left out to be completed as appropriate for the above application engines.

 

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.