Strider: a black-box, state-based approach to change and configuration management and support

AbstractWe describe a new approach, called Strider, to Change and Configuration Management and Support (CCMS). Strider is a black-box approach: without relying on specifications, it uses state differencing to identify potential causes of differing program behaviors, uses state tracing to identify actual, run-time state dependencies, and uses statistical behavior modeling for noise filtering. Strider is a state-based approach: instead of linking vague, high level descriptions and symptoms to relevant actions, it models management and support problems in terms of individual, named pieces of low level configuration state and provides precise mappings to user-friendly information through a computer genomics database. We use troubleshooting of configuration failures to demonstrate that the Strider approach reduces problem complexity by several orders of magnitude, making root-cause analysis possible

Designing supportability into software

Thesis (S.M.)--Massachusetts Institute of Technology, System Design & Management Program, February 2004.Includes bibliographical references (p. 114-116).Background: Despite the identification of a "software crisis" in the 1960s, large software projects are full of defects even today [19]. These defects cause the software to behave unexpectedly. The cause generally is attributed to the inherent property of software to possess arbitrary complexity [20]. Additionally, computer software is becoming all pervading. There is literally an explosion of software automating things that were considered impossible to automate only a few years ago. Essentially, software is growing to encompass anything and everything with such speed that we don't have the time to reflect on 'what happens when the software does something that it was not intended to do?' In other words, the software encounters an anomaly or a defect something customers encounter everyday. In any case, whenever customers encounter problems caused by defects they need help to solve these problems. They generally seek such help at a software vendor's product support services. With software getting more and more complex it is getting extremely difficult to support customers in a timely and cost effective manner. There is a constant struggle to ensure high Quality of Service (QoS) with low Total Cost of Ownership (TCO), which in turn affects Return on Investment; in such a scenario considering nearly 80% of the costs associated with software occur after it is shipped to the customer. Currently, there are two solutions to such problems caused by defects: First, if the source of the problem itself is found to be a defect in the software then the software vendor generally fixes the problem by modifying their code. Such a problem is generally classified as a bug. By now it is known that software applications have such bugs or defects or anomalies. These bugs cause the software to behave unexpectedly. Depending on its severity this behavior can on one extreme go unnoticed or one the other end produce catastrophic results. It pervades all software whether it is the AT&T long distance switching node crash in 01/15/90, the well known Y2K bug in database related software, Microsoft Passport Security defect, Mars Polar Lander defect, or the Ariane 5 rocket defect. These are just a few examples of well known software bugs. For each well known bug there are untold numbers of bugs that may not see the limelight. These defects can arise due to many reasons during the design and development of the software however they primarily arise due the essence of software to possess inherent properties of complexity, conformity, changeability, and invisibility [20]. Hence, a question arises, "Do we still try to single-mindedly go for the elusory 0 bug product? OR Do we accept that there are going to be bugs and try incorporate / accommodate for this directly into the product or otherwise?" Second, if the source of the problem is such that the vendor cannot simply fix the product, then it is classified as a limitation of the software product itself. In such a case the support organization works with the customer to find a workaround. Additionally, if many customers encounter the same problem then the product needs to be modified based on the workarounds their support services have provided to customers. In other words the product evolves based on how its customers use it. Product support services also receive numerous problems that are non-defect related where the source could be customer error or ignorance, improper documentation etc and their solutions generally require end-user education and training, better documentation etc. However such nondefect related support incidences fall outside the scope of this thesis. In the defect related scenarios illustrated above most of the contemporary efforts to determine the root cause of a customer's problem, requires in-depth knowledge of the product, extensive debugging that is extremely tedious, painstaking, and manual. Resolution of a problem depends solely on the troubleshooting skills, experience and subjectivity of the Support Personal that the customer is able to get a hold of. Products have all along incorporated functionality such as better features, performance, scalability etc. into their designs however none explicitly addresses how to tackle a software application's problems. This is unfortunate since such problems deeply affect customers and software development organization alike. The former looses productivity, effectiveness, time and money while the latter expends dedicated monetary and human resources for troubleshooting software products for a number of years until the product is declared obsolete or the customer's license expires. Problems affect overall customer satisfaction with the software making them more skeptical of future releases. The bottom-line is that there is a strong need to innovate software design and development itself to address how to deal with software problems so that customers should not have to loose their time, money or their life because the software application they are using has problems.by Prashant A. Shirolkar.S.M

A Novel Approach for Triggering the Serverless Function in Serverless Environment

Serverless computing has gained significant popularity in recent years due to its scalability, cost efficiency, and simplified development process. In a serverless environment, functions are the basic units of computation that are executed on-demand, without the need for provisioning and managing servers. However, efficiently triggering serverless functions remains a challenge, as traditional methodologies often suffer from latency, Time limit and scalability issues and the efficient execution and management of serverless functions heavily rely on effective triggering mechanisms. This research paper explores various design considerations and proposes a novel approach for designing efficient triggering mechanisms in serverless environments. By leveraging our proposed methodology, developers can efficiently trigger serverless functions in a variety of scenarios, including event-driven architectures, data processing pipelines, and web application backend

Managing Smartphone Testbeds with SmartLab

The explosive number of smartphones with ever growing sensing and computing capabilities have brought a paradigm shift to many traditional domains of the computing field. Re-programming smartphones and instrumenting them for application testing and data gathering at scale is currently a tedious and time-consuming process that poses significant logistical challenges. In this paper, we make three major contributions: First, we propose a comprehensive architecture, coined SmartLab1, for managing a cluster of both real and virtual smartphones that are either wired to a private cloud or connected over a wireless link. Second, we propose and describe a number of Android management optimizations (e.g., command pipelining, screen-capturing, file management), which can be useful to the community for building similar functionality into their systems. Third, we conduct extensive experiments and microbenchmarks to support our design choices providing qualitative evidence on the expected performance of each module comprising our architecture. This paper also overviews experiences of using SmartLab in a research-oriented setting and also ongoing and future development efforts

Autonomous Recovery in Componentized Internet Applications

In this paper we show how to reduce downtime of J2EE applications by rapidly and automatically recovering from transient and intermittent software failures, without requiring application modifications. Our prototype combines three application-agnostic techniques: macroanalysis for fault detection and localization, microrebooting for rapid recovery, and external management of recovery actions. The individual techniques are autonomous and work across a wide range of componentized Internet applications, making them well-suited to the rapidly changing software of Internet services. The proposed framework has been integrated with JBoss, an open-source J2EE application server. Our prototype provides an execution platform that can automatically recover J2EE applications within seconds of the manifestation of a fault. Our system can provide a subset of a system's active end users with the illusion of continuous uptime, in spite of failures occurring behind the scenes, even when there is no functional redundancy in the system

Ohjelmistokonttien hyödyntäminen pilvipohjaisen mobiiliverkon sovelluksissa

Mobile service providers and manufacturers have moved towards virtualized network functions, because the amount of mobile data traffic has increased a lot during the past few years. Virtual machines offer high flexibility and easier management. They also enable flexible scaling, which makes it easier to respond to the varying traffic patterns during the day. However, the traditional virtual machines contain overhead and have reduced performance in most of the operations. One high performing alternative to a virtual machine is a Linux container. Linux containers do not contain additional operating system or any unnecessary services. Containers are isolated user spaces which share host computer's kernel. This makes processes inside them perform almost as well as if they would be running directly on host. Also, the startup time of containers is extremely fast compared to virtual machines. This thesis studies, if Linux containers are suitable for telco applications. The research is conducted via proof-of-concept where parts of an existing telco application are moved to containers. First, the container technology and related tools are discussed. Benefits and requirements of the Linux containers are then studied based on the proof-of-concept. In this thesis, it was found out that containers are suitable for running small parts of the application. For example, the software update and scaling are a much more efficient processes with containers than with virtual machines. However, the isolation is weaker in containers than in virtual machines, and at the moment they are not suitable for applications or environments where strict isolation is a necessity.Mobiilidatan määrä on kasvanut voimakkaasti muutaman viime vuoden aikana. Tämän johdosta mobiiliverkon palveluntarjoajat ja laitevalmistajat ovat alkaneet virtualisoimaan mobiiliverkon laitteita. Virtualisointi tarjoaa joustavuutta ja helpottaa laitteiden hallintaa. Virtualisoinnin avulla mobiiliverkon laitteita voidaan skaalata verkon liikennemäärien mukaan. Virtuaalikoneet sisältävät ohjelmien suorituksen kannalta epäolennaisia palveluita ja niiden suorituskyky on usein heikompi verrattuna tavallisiin tietokoneisiin. Linux-kontit tarjoavat kevyemmän ja suorituskyvyltään tehokkaamman vaihtoehdon virtuaalikoneille. Ne eivät sisällä ylimääräistä käyttöjärjestelmää tai ylimääräisiä palveluita. Kontit ovat eristettyjä alueita käyttöjärjestelmän sisällä ja ne myös jakavat käyttöjärjestelmän ytimen. Tämän ansiosta prosessien suorituskyky kontin sisällä on lähes identtinen kuin ilman kontteja. Konttien käynnistymisaika on myös huomattavasti lyhyempi kuin virtuaalikoneiden. Tässä diplomityössä tutkitaan, soveltuvatko Linux-kontit mobiiliverkon sovellusten suorittamiseen. Tutkimus suoritetaan käytännön esimerkin avulla, jossa erään mobiiliverkon sovelluksen osia suoritetaan konteissa. Aluksi tutkitaan Linux-kontteja, niiden teknologista taustaa sekä niihin liittyviä työkaluja. Tämän jälkeen konttien hyötyjä ja niiden vaatimuksia tutkitaan edellä mainitun käytännön esimerkin avulla. Tässä työssä saatiin selville, että kontit soveltuvat pienien sovelluksen osien suorittamiseen. Esimerkiksi sovelluksen päivitys ja skaalaus on tehokkaampaa kontteja käytettäessä. Konttien eristys on kuitenkin heikompaa kuin virtuaalikoneiden ja tällä hetkellä ne eivät sovellu sovelluksille tai ympäristöihin, joissa vaaditaan vahvaa eristystä

Sandboxed, Online Debugging of Production Bugs for SOA Systems

Short time-to-bug localization is extremely important for any 24x7 service-oriented application. To this end, we introduce a new debugging paradigm called live debugging. There are two goals that any live debugging infrastructure must meet: Firstly, it must offer real-time insight for bug diagnosis and localization, which is paramount when errors happen in user-facing applications. Secondly, live debugging should not impact user-facing performance for normal events. In large distributed applications, bugs which impact only a small percentage of users are common. In such scenarios, debugging a small part of the application should not impact the entire system. With the above-stated goals in mind, this thesis presents a framework called Parikshan, which leverages user-space containers (OpenVZ) to launch application instances for the express purpose of live debugging. Parikshan is driven by a live-cloning process, which generates a replica (called debug container) of production services, cloned from a production container which continues to provide the real output to the user. The debug container provides a sandbox environment, for safe execution of monitoring/debugging done by the users without any perturbation to the execution environment. As a part of this framework, we have designed customized-network proxies, which replicate inputs from clients to both the production and test-container, as well safely discard all outputs. Together the network duplicator, and the debug container ensure both compute and network isolation of the debugging environment. We believe that this piece of work provides the first of its kind practical real-time debugging of large multi-tier and cloud applications, without requiring any application downtime, and minimal performance impact