...

...

Introduction

All the necessary information from DC side can and should be addressed as a set of simple, unambiguous questions. These questions in turn can be divided roughly in three subsets, based on the goal they are helping to achieve. Each subset can be expressed as a more general "umbrella question":

...

1. First question of above three, is vital to gather the information that affects following topics in Warren development:
   1.  Architectural decisions:
      1. which external libraries, components and standards to use to cope the requirements of majority of DCs in target group?
      2. How to design the functionality in component systems, so that the we provide the value we claim to be offering, without causing the decrease in quality of services and processes existing there before Warren adoption?
   2.  Marketing content and business value:
      1. Can we actually offer the functionality we are claiming to be, in sufficient level?
      2. Are we doing it in a sensible way, e.g. the development effort is comparable to the actual value the development result is providing?
      3. Are all the features and functionality we are/will be providing also in correlation with the actual requirements?

...

Conflicting nature in DC service requirements

To enhance the analysis result and make it directly usable as an input to development process, let's partition the hypothetical DC stack (hardware, firmware, software) into functional domains that have common properties to according Warren components. Two of DC functional stack domains they have before Warren adoption are more influential than others, both future development- and adoption process-wise to us. These are Network and Storage. They are also tightly coupled, as decisions in one domain heavily depend on properties of the other. If analyzed, the connection between these two domains is expressed best in decision making process, as two fundamental trade-offs:

1. Availability vs Locality - the biggest trade-off there is in multi-site computing, (thus distributed cash and storage are simultaneously good and evil at the same time ). 
   
   1. Availability in this context denotes:
      1. Spacial - data or service is concurrently available to recipients/consumers in different locations rather than just one (many VMs using same database that resides in distributed storage)
      2. Temporal continuity - data or service is kept available even in case of soft- or hardware failures ("High Availability")
      
      Both of these aspects may seem very desirable, especially in cloud computing, but the downside is delivery speed in various forms. For example distributed storage without high-end hardware may not have sufficient latency for storage-sensitive applications. Also, to keep the applications availability rate high, there are software and several levels of hardware redundancy involved that means buying additional devices and keep them constantly running.
      
      
   2. Locality denotes the physical distance of some functional domain from compute resource (local storage vs distributed storage)
      
      While High Availability metrics are received by involving distributed and redundant resources, locality is also not free from redundancy cost, however it is usually the one of sub-server level, so definitely less expensive. Local storage has also much lower latency, but total capacity is very limited and, as data on this storage is not available to outer devices without additional control and services, it introduces additional data duplication need in addition to one that is meant for "High Availability".
      
      
2. Software- vs Hardware defined control of domains, can mostly described as: 
   1. SD* - slow, but flexible, automatically reconfigurable and easily portable
   2. HD* - high speed, low portability, automatic configuration is limited or impossible

...

Requirements in network domain

There are several factors in DC's network setup that dictates what we need to think through in Warren application development process. Such factors include:

1.  Network topology (tree, clos, fat-tree, thorus, etc)
   This aspect restricts network traffic between components, servers, racks and between DC and internet. Also it sets DC's physical extendability properties, thus we need to think through how will be handled automated discovery and deployment of new nodes, which components are involved in such process and how the non-positive results of such cases are handled.
   Obviously, we cannot fine-tune our setup for every topology type because it's not a standalone factor, so the set of variables in such analysis is large and too costly compared to the business-value of the outcome. But we can target the solution that covers topologies mostly used in target DC's with sufficient degree of quality (metrics of service reliability and availability standards are something that cannot be purely theoretically calculated in platform that is under heavy development and will rather be deduced during DC adoption process). Current assumption is that most widely used topologies in probable target DC group are fat-tree and various forms of clos. Based on that
2. Application/Service types
   Although, both, this and next point seem to be trivial compared to a real problem magnets like network topology, adopting SDN solution or better yet, consolidating different SDN solutions; this has become a major issue in public clouds (and presumably also in private ones, where such issues are usually not materialized as a series of scientific papers). As almost all (except for SDN maybe) network-related considerations, also this one has the quantity-dependent nature. The bigger the amounts of data-flow between hardware devices, the bigger of a problem it tend to be. 
3. In-DC traffic amount between racks
   This traffic (and also In-DC traffic between silos, if larger DC is under consideration), is the one that measures the service system (Warren) efficiency. It's a two-fold problem, first the traffic 
4. Existing SDN solution

...

Requirements in storage domain

Storage is 

• TODO: CONSTRAINTS WITH EXPLANATION AND EXAMPLES.
• TODO: TO EACH CONSTRAINT, EVALUATION AND POSSIBLE SOLUTION

...

Warren components placement in DC

Based on network and Storage requirements, there can be predicted several issues due to poorly planned location of Warren control plain components such as:

...