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.
- Mobile devices offer less computational power than a conventional desktop or server computer.
- Computation-intensive tasks, such as image recognition or use of a global positioning system (GPS), take a heavy toll on battery power.
- 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.
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:
- This goes to show that you can’t trust the cloud to be 100% reliable.
- 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
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.”
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.
Posted in Architecture-Centric Engineering, Architecture-Centric Practices, Cloud Computing, Quality Attribute Analysis, Service-Oriented Architecture
Tagged cloud computing, non-functional requirements, SEI, SOA, software architecture, software design, software development, software engineering, Software Engineering Institute, system of systems
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.” 1
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.