EDN, May 26, 2011

Issue link: http://dc.ee.ubm-us.com/i/43174

Contents of this Issue


Page 8 of 63

EDN.COMMENT BY RON WILSON, EDITORIAL DIRECTOR many of which go into terminal sticker shock when they see the pricing on sys- tem-modeling software. What do they think when they see The Cloud simply go away for a day or two? Nebulosity and The Cloud occasionally have problems. This incident, however, was news because this server glitch disrupted "The Cloud." A As you may know, Amazon has many aspects. In addition to retailing, the Web giant hosts a number of shared virtual resources that we call clouds, portions of The Cloud. Such a plan can be handy for a heavy user of servers. Amazon, for example, can build its serv- er colonies to support not the average but the peak loads from its highly sea- sonal retail busi- ness. Instead of just eating the cost of those additional servers for the non- holiday-season portion of the year, Amazon can sell the unused capac- ity to others under defined-service contracts. Smaller companies need not make capital investments in large numbers of underused servers, Amazon receives payment for keeping a reserve against peak demand, and every- one comes out happy—until something goes wrong. In this case, Amazon's glitch caused a portion of The Cloud to evaporate, leaving a number of high-profile Web sites without computing capacity. The problem probably also shut down a lot of less-public undertakings, but you are unlikely ever to hear about those endeavors. The disruption leaked fuel onto one of the major debates about cloud computing—guaranteed quality of service. And that debate makes this little news story relevant to many of you because The Cloud intersects your practice of electronics design, and it introduces new risks at each point of intersec- tion. For example, design teams may use The Cloud to store design data. A disruption that renders data unavailable for a day or two could affect a schedule. A glitch or a mali- cious attack could cause outright loss of data. Similarly, many design teams are thinking about hosting tools in The Cloud, saving license fees and server investments. The idea is appealing to teams outside the IC-design world, n interesting story recently flickered across the business pages of news sites before fading into the vast forgetfulness that is the Web. Amazon.com, the "dreadnaught" of online retailers, had experienced a problem in one of its massive server colonies. Ordinarily, this situation would not have even sparked any interest across the news screens. Servers There is a deeper problem, too. Some embedded designs today use The Cloud in the design itself, as a place for their systems to log data or as a site for postprocessing to extract cost, billing, or failure-prediction information. Some designers also even discuss implement- ing functional algorithms with hard real-time deadlines in The Cloud, sav- ing the cost and power consumption of heavy-duty computing hardware in an embedded design. Things get interest- ing during that step. Does your system halt gracefully? Does it throw a tan- trum and damage those around it? Your answers had better be concrete. Access to The Cloud necessarily invokes the uncertainties of the Internet. Both latency and delivery are unpre- dictable. Once your message reaches The Cloud, the physical memory and computing resources you get depend on many factors beyond your control. And, as Amazon has demonstrated, The Cloud may simply be momentarily absent. Such uncertainties call for a new style of design. You must assume vari- able latencies—as long as, apparently, several days—and understand how your system will behave when such delays occur. Does your system halt gracefully? Does it throw a tantrum and damage those around it, or—and here is the real challenge—can you design the system to degrade gracefully and to resume smoothly once access to The Cloud returns? The Cloud may be nebu- lous, but your answers had better be concrete.EDN Contact me at ron.wilson@ubm.com. MAY 26, 2011 | EDN 9

Articles in this issue

Links on this page

Archives of this issue

view archives of EDN - EDN, May 26, 2011