The Amazon EC2 outage

I have recently been educating myself about the cloud and infrastructure as a service (IAAS). One of the issues that came up in my reading is the outage that Amazon EC2  suffered on April 21. There seem to be two schools of thought about this outage:

1. This goes to show that you can’t trust the cloud to be 100% reliable.
2. Of course the cloud is not 100% reliable and the prudent thing for an engineer to do is to assume that it will fail and to architect your system so that it is resilient to failure.

I have been convinced by the second argument mainly because I have been reading the Netflix tech blog. In one post, they describe why Netflix  customers were unaffected by the Amazon outage even though Netflix has moved almost all of its operations onto EC2. It comes down to, in the words of one commentator, whether 99.95% availability should be read as saying that an outage is an extremely rare occurrence or whether it should be read as a guarantee that EC2 will be unavailable .05% of the time. Netflix took the second interpretation and architected their cloud usage to survive the outage.

- Len Bass, SEI

Presentation to International Conference on Global Software Engineering

I recently gave a presentation to the International Conference on Global Software Engineering on a notation for coordination models.

You can find it at http://www.sei.cmu.edu/library/abstracts/presentations/icgse-bass-2010.cfm

- Len Bass, SEI

Essays in Design (3) – Len Bass

In this last post, I discussed where the initial hypothesis comes from in the generate-and-test cycle. In this post, I will begin discussing the test phase.

The test phase of generate and test subjects the current design hypothesis to a variety of tests and uses the results of these tests to inform the generation of the next design hypothesis. Before we discuss the tests that are applied in this phase, we will discuss three other questions: when are we done, how are the tests applied, and what are the outputs of the tests?

Essays in Design (2) – Len Bass

Generation of the initial design hypothesis

In the last post, I laid out the generate-and-test philosophy as a basis for choosing which decisions are to be made. In this post, I discuss where the initial design hypothesis comes from.

The goal in choosing an initial design hypothesis is to try to find a design as close as possible to a satisfactory design. The closer the initial design hypothesis is to the final design, the fewer iterations will be needed through the generate-next-design-hypothesis phase.

Essays in Design (1) – Len Bass

This is one of a series of essays that reflect my current thinking about the design process. I begin by comparing two different design philosophies—design as a process of making decisions and design as generate and test—and describing how these two philosophies are complementary.

Design as a process of making decisions

When generating a design in any field—software architecture or art—one makes decisions. In software architecture, the decisions may be about which tactic to apply in a particular context, and in art the decisions may be about background and perspective; but in every case, one could view the finished product as a sequence of decisions. Decision 1 is followed by decision 2 and so forth. Recreating the design from its description as a sequence of decisions is a matter of repeating the consequences of each decision. The earliest description of this philosophy that I am aware of dates from the 1940s.

What is function?

After more than 15 years of writing and discussing the distinction between functional requirements and quality requirements, the definition of functional requirements still eludes me. Quality attribute requirements are well defined – performance has to do with the timing behavior of the system, modifiability has to do with the ability of the system to support changes in its behavior or other qualities after initial deployment, availability has to do with the ability of the system to survive failures, and so forth.

Software architecture for acquisition people

I recently gave a presentation titled “The Importance of Software Architecture in the Acquisition Process.”

My basic argument was that software is critical in the system development process and software architecture is critical in the software development process.

The most difficult portion of the argument for me was the first premise. Arguing that software is critical for system development is kind of like arguing that 1+1=2. I have been in the software business too long to be able to look at this problem with outsiders’ eyes. I fell back to a cost argument and used cost figures from defense systems. I found this very unsatisfactory but it was the best I could do.

The criticality of software architecture to the software development process is something I have been arguing for years and I found this argument much easier to make.

The extension to acquisition depends on the level of involvement and oversight that acquisition personnel are willing and able to make.

In any case, you can see the presentation here.

Len Bass

What are those business goals?

A truism in the software development business is that systems exist to support business goals. Any system design decisions  that does not support business goals should not be made, and system design decisions that do support the business goals should be prioritized based on the particular goals.

The assumptions made in the above statement are that the business goals for a system are explicit and agreed upon by all stakeholders. Unfortunately, these assumptions are rarely true. More frequently, different stakeholders have different business goals for a particular system (often conflicting), some business goals are implicit and unstated, and still other business goals are not realizable.

Another usability/software architecture link

For those interested in the relation between usability and software architecture, my colleague in this work–Bonnie John of the Human Computer Interaction Institute at Carnegie Mellon University–gave a talk a while ago at Stanford on the work. You can see her talk on YouTube:

Usability and Software Architecture: The Forgotten Problems

- Len Bass, SEI

Developmental qualities

The community has done a good job in describing and understanding techniques for achieving operational qualities. Performance, availability, security, and usability have been well studied from the point of view of definitions and techniques to achieve them.