Practical DevOps for Big Data/Preface
Around 2010, the head of the Research & Development unit of Alcatel-Lucent mentioned the expression “Big Data” for a meeting of the ICT scientific council of the French Research Agency (a.k.a. ANR). He told us that networks increasingly convey data on an exponential scale and, as a consequence, ICT scientific issues must be totally rethought and re-addressed in light of the durable “Big Data” phenomenon. Indeed, network players were disturbed in their daily business by IT customers that ask for new means for creating value from data (early, from networks, if possible!). As gold nuggets, data includes “senses”, but immense volumes do not, by definition, facilitate any inherent comprehension, or allow for smart manipulation within reasonable time scales. Worse still, well-known storing, formatting, searching, mining or whatever data technology is no longer suitable for the requirements of “Big Data”!
In charge of defining relevant research directions of funded research programmes for the French public and privates sectors, I was first skeptical about the “big” adjective, which confuses me with “raw”, “coarse-grain”, “unstructured”, etc. For example, while everybody uses “Big Data” as a buzzword, few state a more appropriate usage of “Big Data”: are “Big Data” sets, tera, peta, exa, zetta… data sets? In other words, which average data quantity qualifies “Big Data”? Are, for instance, exa (1015) or zetta (1018) “Big Data++” sets or common “Big Data”?
Moving forward, and thus interrogating the High-Performance Computing community that used massively parallel computing infrastructures, my feeling was that this community’s assumption is the fact that all data is available, close, fairly structured… To exaggerate, all data is in high-performance memory at any time! This cloud computing anti-vision disappointed me…
In contrast, interrogating the Massive Data Sets community, they proposed “data methods” in this case, of course, data volumes are “massive” (“huge”? “big”? what else?). Ambiguity arose from the difference/equivalence between “massive” (their chosen name) and “big” in “Big Data”. I quickly understood that their methods cannot be appropriate since they do not approach problems with High-Performance Computing: a proof that their data quantities remain “not so big”. In relation with this loophole, assumptions about “data methods” systematically push SQL, XML, etc. as formatting frameworks, something often far from the “Big Data” reality!
Other disciplines (e-commerce, energy, health, sustainability …) helped us out of the confusion. They challenge ICT people about the unstoppable digitalization of their own sector, which requires, again, rethinking and re-addressing how systems have to be designed in each sector.
Typically, in energy, a smart grid is not an energy distribution system equipped with hardware and software for intelligent monitoring and control. Instead, a smart grid is a “Big Data” processing infrastructure whose intimate relationship with the real world relies on sensors and actuators. The real world deals with energy through a surrounding physical infrastructure. How then, as an innovating system in the energy sector, has a smart grid to be designed? The digital component of the overall system is the core, and, as such, produces constraints on the way the remaining part (surrounding physical infrastructure) has to be composed with! This vision displeases energy engineers, but perfectly illustrates the way “Big Data” problems may be solved: the price of progress!
In fact, “Big Data” as a new scientific discipline is the digitalization of business systems at a never encountered scale. Scientific problems are not computer science problems on one side and/or extant scientific problems in other disciplines on the other side. Solutions depend upon the way scalability issues are properly addressed: scalability is the core of “Big Data” problematics. In other words, data methods or technologies for “lower” scales (i.e., “controllable” data volumes) become obsolete when scales increase. New solutions have to be invented, including software development methods that effectively single out collaborative multidisciplinary behaviors from both the software (dev. engineers, op. engineers) and sectoral (IT customers, end-users…) sides.
“Practical DevOps for Big Data”, this book, intends to tackle this objective. From proven and relevant software engineering paradigms, namely model driven engineering and DevOps, authors expose results from the European ICT DICE project (http://www.dice-h2020.eu/). DICE focuses on quality assurance for data-intensive applications. Due to the fact that “Big Data” applications stress a more interdisciplinary approach in tight collaboration with IT customers/end-users, DICE puts forward key criteria like performance and trust. These criteria drives the way software is first designed and next released in production. Criteria act as early input constraints or quality contracts. As inescapable constraints, DICE wonders how running applications process data and deliver “senses” while satisfying constraints from end to end. The DICE methodology is loopback-based, including monitoring and control for applications in production so that performance anomalies for instance, may be injected in maintenance cycles for quality preservation. Of course, the book also explains how dedicated integrated tools support the methodology for the successful “Big Data” world!