| Info | ||
|---|---|---|
| ||
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. What is the current infra setup and which components it incorporates?
2. What services do they offer to which clients and what expectations do they have towards Warren?
3. What is level of commitment in cooperation with warren?
If these topics are cleared from their side, we can provide better answers from our side as well
First question of above three, is vital to gather information that affects following topics in Warren development:
* Architectural decisions:
- which external libraries, components and standards to use to cope the requirements of majority of DCs in target group?
- 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?
* Marketing content and business value:
- Can we actually offer the functioanlity we are claiming to be, in sufficient level?
- Are we doing it in a sensible way, e.g. the development effort is comparable to the actual value the development result is providing?
- Are all the features and functionality we are/will be providing also in correlation with the actual requirements?
To enhance the analysis result and make it directly usable as an input to development process, let's partition the hypotethical 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 influencial than others, both fututre 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 tradeoffs:
1. Availability vs Locality - the biggest tradeoff there is in multisite computing. ,( thus distributed cash and storage are simoultaneously good and evil at the same time)
2. Software- vs Hardware defined control of domains
1. Network.
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:
* Network topology (tree, clos, fat-tree, thourus, etc)
- This aspect restricts network traffic between components, servers, racks and between DC and internet. Also it sets DC's physical extendibility properties, thus we need to think through how will be handled automated discovery and deployemnt of new nodes, which components are involved in such process and how the non-positive results of such cases are handled.
Obviously, we cannot finetune 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 businessvalue 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
-