Next evolutionary step in enterprise-scale system design and deployment. Distributed microservices beyond the cloud.

Fundamental building block   Is a "system" which has:

• GUI widgets,
• distributed processing middleware (essentially a MapReduce variant),
• a web server,
• a shard & partition manager,
• a paged memory manager & stream processor, and
• a multi-model database engine.

Each "system" instance   Is a small vertical software stack running in a loosely coupled process that is an independent processing entity (a "system") in a distributed processing environment. The software framework gives programmers explicit and granular control over sharding and partitioning of the distributed data. The software framework also constructs software data processing/caching pipelines to efficiently move data to the CPU core during run-time processing.

The performance   of System Oriented Programming applications is due to Locality Optimization™ technology:

• At data prep time (essentially "system compile time"), for Locality of Reference at run-time when the distributed processing system is doing real work, and,


• At software developmen time, for Locality of Logic to reduce and simplify application-layer code.

Best use cases   are enterprise-class applications that support mission critical repetitive business processes. Examples of this are: billing, forecasting, reconcilliation, and other customer care oriented applications.

Emperical results   Locality of Reference optimization can reduce I/O wait-states in application layer code by multiple decimal orders of magnitude (compared to a similar legacy application implemented in a relational database). We have customers with production applications that are now running 1,000x to 1,000,000x faster than their legacy application.

Simultaneous innovation   System Oriented Programming consists of simultaneous innovations in:

• Distributed processing,
• Database architecture,
• Stream processing,
• Object oriented programming,
• Micro-services architecture,
• Full stack development frameworks (at macro and micro scale), and
• Compiler design.

Next evolutionary step in enterprise-scale system design and deployment. Distributed microservices beyond the cloud.

Fundamental building block   is a "system". Each "system" instance is a small vertical software stack running in a loosely coupled process that is an independent processing entity (a "system") in a distributed processing environment.

Each system contains the entire application   A user, or another application, interacts with an individual system instance via web services. The system contains all of the data and code (including all user interface widgets) for the application that the user wishes to run. Each system instance is a smaller scale version of the overall application.

Billing example   if the user is running a billing application, an individual system instance might be responsible for on the order of about 25,000 customers and all of their associated information. If the user asks the system to "show a list of all customers" the system instance will respond with a list of 25,000 customers. If the system instance is running in a System Oriented Programming™ environment where it can communicate with all of the other system instances in the environment -- then before the system instance sends a response back to the user, it broadcasts a message to the other system instances asking them if they also manage any customers. The system instance takes all of their responses and folds them into its internal response before sending the final response back to the user. The mechanisms for dissiminating requests out to other systems and integrating their results into a final result is part of the infrastructural framework of the System Oriented Programming environment.

Spreadsheet example   If the user wants to build an application with a "spreadsheet" implementation style, each system instance is responsible for a section of the spreadsheet. Often these type of spreadsheets are organized as multiple "sheets" within the overall system-wide spreadsheet. Each system instance is response for it's assinged sheet in the spreadsheet. This System Oriented Programming approach to spreadsheet implementation makes is possible to have infinite spreadsheets that enables a simple application implementation style (spreadhseet programming) to scale to arbitrarily large data sets and to utilize massive amounts of parallel processing. Each system instance manages its iSheet™ sheet in the aggregate system-wide spreadsheet in parallel and the System Oriented Programming framework provides the programmer with Locality Optimization™ tools to insure parallelism for optimal run-time performance.

Fractal System™   architectures have this unique characteristic that is extensively exploited in System Oriented Programming. Each system instance contains a fully functional application with all of the data and application logic for performing some task. The user experience of interacting with an individual system instance or the entire network of system instances is exactly the same -- the result sets are either a fraction of the total data set (when interacting with only a single system instance) or the entire data set (when interacting with a system instance that, in turn, is communicating with the other system instances).

All system instances are the same   A Fractal System architecture is a true peer-to-peer architecture. A user can attache to any system instance in the network to initiate a request. Each system instance is capable of communicating with all of the other system instances and assembing a complete result for the user. A Fractal System architecture enables massive parallel processing, fault-tolerance, and high availability of the overall application since failover and backup logic is also embedded in each system instdance as part of the System Oriented Programming infrastructural framework.

Minimalist but complete.

Just a sliver   A Cloud-Sliver contains just the necessary essence, a sliver, of the massive software infrastructure resident in the cloud and enterprise scale applications.

Reduce need for data centers   A Cloud-Sliver instance manages storage and compute resources at a granular scale. A Cloud-Sliver runs on hardware at the network edge or the minimal instance of the cloud. A Cloud-Sliver runs on mobile devices, network hardware, desktop PCs, departmental workstations, and conventional servers in your data center and in the cloud. If the hardware has a processor, some storage, and a network connection -- it can be a Cloud-Sliver resource. Cloud-Sliver enables you to migrate OUT OF DATA CENTERS, reducing your energy footprint.

Distributed processing & storage   Cloud-Sliver is a distributed development and delivery software platform. It enables an enterprise application and its databases to be split into dozens, hundreds, thousands, or millions of loosely coupled distributed processing and storage resources. Decentralized, distributed management of these resources so they behave as a coherent whole is an innate capability of each Cloud-Sliver instance.

Development community   Cloud-Slivers utilize distributed libraries of features and content for industry specific or use-case specific applications. Business unit and department level resources that understand Javascript programming can contribute to, and make use of, these community libraries to develop and deliver enterprise scale applications in a single business quarter.

Example   A medium size 10 million customer billing system is typically deployed on 10 Intel NUC's, each running 40 processes ("systems"), for a total of 400 processes ("systems").

Each Process ("system")   Is a small vertical software stack running as a loosely coupled process that is an independent processing entity (a "system") in a distributed processing network.

Data sharding & partitioning   Each loosely-coupled system typically hosts 3 types of databases.

Data flow   Input data is streamed by the service point DB which guides calculations to produce the output data. This processing is done via a software processing pipeline that optimizes data flow so that data is paged into layer-2 cache immediately prior to a CPU core requiring the next data block from a data stream.