Autonomic Computing

Software, as an artefact, has been tremendously successful. It has pervaded every aspect of our professional and social life, due mainly to the outstanding advances in hardware, but also to undeniable progress in software engineering practices that allow the timely production of high-quality computing products. Software is however a victim of its own success. The software systems of today have to constantly face new and demanding requirements in terms of their availability, robustness, dynamism and pervasiveness. This is challenging, the way software systems are produced and managed. In particular, great pressure is put on the maintenance of software and systems; maintenance tasks are becoming increasingly difficult and correspondingly more time-consuming to carry out. Today, many believe that we have reached a barrier in terms of complexity and that innovative practices are needed to ensure the continuous delivery of software-based services. In this introductory chapter, we present how software systems are currently being developed and managed. We show how the use of software has evolved and how this has impacted on the software development and maintenance processes. In particular, we show that much of the complexity involved with the software life cycle has moved from the development stage to the maintenance stage, which raises formidable challenges for practitioners. Finally, we briefly introduce the field of autonomic computing, a relatively new spin on the ways we build and maintain software systems and whose purpose is to overcome some of these aforementioned problems we highlight. This chapter motivates the need for autonomic computing systems.

The purpose of this chapter is to define the notion of autonomic systems and to introduce related terminology. It discusses the main ideas that are essential to any autonomic computing system, including the concepts of ‘goal’, ‘context’ and ‘self-*’ capabilities.

The chapter also presents the initial motivations behind the autonomic computing initiative. It subsequently discusses the relevance of these motivations in light of both research and real-world implementations since this initiative was launched in the early days of the millennium.

We highlight the most important benefits that autonomic computing promises to bring to the IT domain as well as the equally important challenges that must be surpassed before computer systems can be endowed with autonomic management capabilities. An incremental approach to autonomic computing is presented in this context, proposing a five-step roadmap for progressively transforming current IT systems from their current (non-autonomic) status to full autonomic management support.

Finally, the chapter aims to position the relatively new autonomic computing initiative with respect to similar technological fields, supported by industry, governments or academia, as well as with respect to existing computing domains. Further relevant fields are discussed in the following chapter highlighting the inspiration that autonomic computing has and can draw from existing domains.

Autonomic computing can capitalise on advancements available from several scientific fields, both within and beyond the computer science domain. This chapter provides an overview of such fields and highlights their possible contributions to autonomic computing systems. The manner in which concepts, mechanisms and processes can be adopted and reused as software engineering approaches is highlighted across this chapter.

We discuss biology as the first source of inspiration for autonomic computing. While the bio-inspired autonomicity concept is highly relevant to autonomic computing, the potential of biology to inspire this field largely surpasses this metaphor. We therefore enlarge our discussion to biological systems in general, especially nervous systems, highlighting how their implementation in different species can inspire various solutions to autonomic computing systems.

We also show how autonomic computing shares many of its goals and necessary underlying constructions with some well-established engineering and computing fields such as automated control systems, robotics, artificial intelligence and multi-­agent systems. The chapter summarises some of the most relevant concepts and approaches available from existing fields and indicates the manner in which they can be adopted to serve the autonomic computing initiative.

A number of interrelated theoretical fields provide a potentially significant link between natural and artificial autonomic systems. Areas such as complex systems theory, cybernetics, networked systems theory and artificial life have set out to decipher the inner workings of complex adaptive systems and ultimately to control or to build artificial ones. We briefly point out the relevance of such fields and the core concepts that seem most readily applicable to autonomic computing.

Certainly, the chapter cannot provide a comprehensive view of all areas relevant to autonomic computing. Rather, its purpose is to provide an (probably biased) overview of the most relevant sources of inspiration and to offer pointers towards more extensive specialty literature.

Software architecture specifies the structure of the components of a system, their interrelationships, principles and the guidlines governing their design and evolution over time [1]. This is the very purpose of this chapter: defining the main constituents of an autonomic system and understanding their structural and temporal relations.

Such exploration of the internal structure of autonomic systems will allow us to better understand the challenges in building autonomic systems. It will permit us to identify the major design and implementation barriers and their needs in terms of techniques, technologies, formalisms and methods.

This chapter highlights that there are not common agreements as to what an autonomic system is and what its constituent parts are, yet alone what those parts actually do. In some way, this chapter sets up the rest of the book in that the chapters that follow aim to provide answers, partial in some cases where research is still required, to the issues raised by this architectural chapter.

Monitoring can be seen as putting the self into self-management. Just as in psychology, the self is the representation of one’s experience or one’s identity; in autonomic computing, the data obtained from monitoring contributes to the representation of the system’s experience or current state, self-knowledge if you like. Knowing the system state both from a functional and non-functional perspective is fundamental to being able to perform the operations necessary to achieve system goals at the desired level.

To maintain the analogy, just as a human can become self-conscious, that is, excessively conscious of one’s appearance or manner leading to suboptimal functioning, so too can an autonomic system. Here where there is too much monitored data or the understanding of that data is erroneous or unclear which means the system is trying to change but does not know how to. Therefore, there have been a number of approaches to the monitoring of autonomic computing systems, the aim being to minimise the intrusiveness of the monitoring function while ensuring sufficient system self-awareness to optimise decision-making.

This section will focus on the monitoring function. To this end, we focus on the establishment of absolute measureable technical metrics that represent the performance or state of the system. This data can then be processed and these conclusions used to derive whether or not a system is meeting its quality levels or fulfilling a contractual obligation at the much higher levels of abstraction.

Software adaptation is at the heart of autonomic computing. Indeed self-­management cannot be reached without the ability to modify the structure and behaviour of a system. Unfortunately, software adaptation remains a particularly complex task. It requires changing low-level code, an act that is often complicated and intricate. Side effects that succeed an update are difficult to anticipate and to fix. An additional challenge specific to autonomic computing is that the code to be modified has already been run or is currently executing, meaning that computational state has to be identified and preserved.

The purpose of this chapter is to define precisely the notion of software adaptation and discuss the related challenges. It is also to present a set of techniques that can be used to implement self-managed software systems. As we will see, adaptation can be realised at different levels of abstraction, and very diverse approaches can be implemented. This diversity of technique is welcome. As said in previous chapters, a self-managed system is made of a number of collaborating autonomic elements with different requirements in terms of reactivity, scope, precision, etc. Different, complementary approaches are needed to meet these demands.

In this chapter, we will focus on techniques allowing dynamic updates. Indeed, more and more, users require updates to be dynamic, at runtime, as downtime is not an option; service interruption can be very costly and has to be avoided as much as possible. This is especially true for critical systems that may have to be updated tens or hundreds of times every year and that cannot be stopped that often.

In the previous chapters, we saw how self-managed systems could accumulate information about their execution context and how they could adapt their own internal structures. We now focus on the decision function that links sensory inputs to actuating outputs. This function heavily relies on the notion of knowledge (knowledge about the system internals, knowledge about the computing environment, knowledge about ways to solve problems) and as well as the ability to reason about this knowledge. There are many different ways to represent knowledge in computing science, and a wide range of reasoning techniques have been proposed, in particular in the artificial intelligence community.

The purpose of this section is to present different knowledge representations and associated reasoning techniques well suited to autonomic systems. It is not meant to be exhaustive. In fact, there is no such thing as a general knowledge representation of reasoning approach for autonomic management. Depending on the requirements, different formalisms and techniques with different properties can be selected.

Computer scientists, and the computing industries, rely on the ability to build systems and iteratively evaluate the design and implementational decisions that they have made during that process. As we have seen in previous chapters, an autonomic computing system can take many forms and as a consequence their evaluation, and moreover comparison, can be difficult. The very nature of some systems that emerge solutions adds further complexity to their evaluation. This chapter presents the challenges to evaluating an autonomic system, what to look out for and what others have attempted to do to aid this activity.

The chapter’s aim is to enable the reader to be able to design tests and metrics that can be used to evaluate autonomic computing systems with a particular focus on the aspects that makes an autonomic system different from those without self-management features. As you will see, there is no single definitive metric that can be used in assessing the mechanisms of all autonomic computing systems.

Software integration is a well-known and very demanding activity. The purpose of this activity is to allow the interoperation of software applications that have been developed independently and often at different times. Such integrations are frequently required in software organisations in order to improve the existing computing infrastructures and provide new services.

Today, modular architectures are often used to design and implement integration solutions. Many are based on the notion of mediation, which focuses on the timely integration of disparate information sources and destinations. Most current solutions, however, are not autonomic. Updates are generally prepared offline by experienced developers and administrators and committed all at once in a static fashion. This requires some downtime and the availability of skilled administrators to deal with technical, low-level administration aspects.

Cilia is an autonomic mediation framework essentially developed by the Adele team1 and currently used in collaborative initiatives like the Medical project.2 This framework, designed with autonomicity in mind, allows the autonomic admini-stration of mediation solutions. The purpose of this chapter is to show how the Cilia framework has been made autonomic, using many of the techniques presented in this book. This chapter also presents ongoing work offering further management capabilities, aiming to progress towards Cilia technology endowed with fully autonomic life-cycle management capabilities.

The purpose of this last chapter is twofold. First, it draws together the lessons we have learned about autonomic computing and the techniques that are used, at the time of writing, to design and implement self-managed software systems. Our purpose is clearly to help readers to understand, develop and maintain autonomic systems.

The second objective of this concluding chapter is to look ahead and foresee the future of autonomic computing, while also attempting to point out some of the most important challenges to address in order to attain the full autonomic computing vision. To achieve this risky exercise, we view the topic from the perspective of how autonomic systems will be engineered and how assurances regarding their behaviours can be made. We acknowledge that targeting system-level autonomy will presumably necessitate integrated solutions, incorporating multiple autonomic elements, each one dealing with different management concerns and operating at various granularity levels. In this context, we provide some examples of the more specialised fields of autonomic networking and autonomic machines. We also have a discussion about next-generation software engineering techniques, approaches and tools that would be required to meet future computing system requirements.