Cloud Computing for the Battlefield

The U.S. Department of Defense (DoD) is increasingly interested in having soldiers carry handheld mobile computing devices to support their mission needs. Soldiers can use handheld devices to help with various tasks, such as speech and image recognition, natural-language processing, decision making, and mission planning. Three challenges, however, present obstacles to achieving these capabilities.

1. Mobile devices offer less computational power than a conventional desktop or server computer.
2. Computation-intensive tasks, such as image recognition or use of a global positioning system (GPS), take a heavy toll on battery power.
3. Networks and bandwidth are unreliable.

This post at the SEI Blog by Grace Lewis explores SEI research in overcoming these challenges by using cloudlets. Cloudlets are localized, lightweight servers running one or more virtual machines (VMs) on which soldiers can offload expensive computations from their handheld mobile devices, thereby providing greater processing capacity and helping conserve battery power.

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

Free SEI Webinar 6/23: Service-Oriented Architecture: A Quality Attribute Perspective

On Thursday, June 23 from 1:30 to 2:30 Eastern time, Grace Lewis of the SEI will present a free SEI webinar, titled “Service-Oriented Architecture: A Quality Attribute Perspective.”

Register.

About the Webinar

Service orientation is an approach to software systems development that has become a popular way to implement distributed, loosely coupled systems, because it offers such features as standardization, platform independence, well-defined interfaces, and tool support that enables legacy-system integration. From a quality attribute point of view, the primary drivers for service-orientation adoption are interoperability and modifiability. However, a common misconception is that an architecture that uses a service-oriented approach can achieve these qualities by simply putting together a set of vendor products that provide an infrastructure and then using this infrastructure to expose a set of reusable services to build systems. In reality, there are many architectural decisions that need to be made. An architectural decision that promotes interoperability or modifiability can negatively impact other qualities, such as availability, reliability, security, and performance. This presentation will talk about  the effect that service orientation has on system quality attributes.

Lean Principles and Software Architecture: The Waste of Waiting

This is the second in a series of posts about Lean principles and software architecture by Nanette Brown. Read first post, Lean Principles and Software Architecture: Categories of Waste.

In Lean production, “..waiting refers to the periods of inactivity in a downstream process that occur because an upstream activity does not deliver on time. Idle downstream resources are then often used in activities that either don’t add value or result in overproduction.” ¹

The “waste of waiting” is certainly applicable to software development. Developers waiting for architecture specifications to be produced may be underutilized or may begin development anyway, potentially producing throwaway code or, more likely, making the “official architecture” moot. Developers waiting for requirements will often be pressured to start coding and therefore may feel obliged to make their own best guesses about what the customer wants. Testers may be idle waiting for a code drop, followed by an intense, exhausting blitz once the code finally does arrive.