<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>ACM Queue - Distributed Development</title>
    <link>http://queue.acm.org/listing.cfm?item_topic=Distributed Development&amp;qc_type=topics_list&amp;filter=Distributed Development&amp;page_title=Distributed Development&amp;order=desc</link>
    <description />
    <item>
      <title>Online Event Processing</title>
      <link>http://queue.acm.org/detail.cfm?id=3321612</link>
      <description>Support for distributed transactions across heterogeneous storage technologies is either nonexistent or suffers from poor operational and performance characteristics. In contrast, OLEP is increasingly used to provide good performance and strong consistency guarantees in such settings. In data systems it is very common for logs to be used as internal implementation details. The OLEP approach is different: it uses event logs, rather than transactions, as the primary application programming model for data management. Traditional databases are still used, but their writes come from a log rather than directly from the application. The use of OLEP is not simply pragmatism on the part of developers, but rather it offers a number of advantages. Consequently, OLEP is expected to be increasingly used to provide strong consistency in large-scale systems that use heterogeneous storage technologies.</description>
      <category>Distributed Development</category>
      <pubDate>Sun, 24 Mar 2019 16:42:54 GMT</pubDate>
      <author>Martin Kleppmann, Alastair R. Beresford, Boerge Svingen</author>
      <guid isPermaLink="false">3321612</guid>
    </item>
    <item>
      <title>Titus: Introducing Containers to the Netflix Cloud</title>
      <link>http://queue.acm.org/detail.cfm?id=3158370</link>
      <description>We believe our approach has enabled Netflix to quickly adopt and benefit from containers. Though the details may be Netflix-specific, the approach of providing low-friction container adoption by integrating with existing infrastructure and working with the right early adopters can be a successful strategy for any organization looking to adopt containers.</description>
      <category>Distributed Development</category>
      <pubDate>Tue, 07 Nov 2017 13:57:15 GMT</pubDate>
      <author>Andrew Leung, Andrew Spyker, Tim Bozarth</author>
      <guid isPermaLink="false">3158370</guid>
    </item>
    <item>
      <title>Functional at Scale</title>
      <link>http://queue.acm.org/detail.cfm?id=3001119</link>
      <description>Modern server software is demanding to develop and operate: it must be available at all times and in all locations; it must reply within milliseconds to user requests; it must respond quickly to capacity demands; it must process a lot of data and even more traffic; it must adapt quickly to changing product needs; and in many cases it must accommodate a large engineering organization, its many engineers the proverbial cooks in a big, messy kitchen.</description>
      <category>Distributed Development</category>
      <pubDate>Tue, 20 Sep 2016 14:30:47 GMT</pubDate>
      <author>Marius Eriksen</author>
      <guid isPermaLink="false">3001119</guid>
    </item>
    <item>
      <title>The Verification of a Distributed System</title>
      <link>http://queue.acm.org/detail.cfm?id=2889274</link>
      <description>Leslie Lamport, known for his seminal work in distributed systems, famously said, "A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable." Given this bleak outlook and the large set of possible failures, how do you even begin to verify and validate that the distributed systems you build are doing the right thing?</description>
      <category>Distributed Development</category>
      <pubDate>Mon, 01 Feb 2016 21:33:33 GMT</pubDate>
      <author>Caitie McCaffrey</author>
      <guid isPermaLink="false">2889274</guid>
    </item>
    <item>
      <title>Testing a Distributed System</title>
      <link>http://queue.acm.org/detail.cfm?id=2800697</link>
      <description>Distributed systems can be especially difficult to program, for a variety of reasons. They can be difficult to design, difficult to manage, and, above all, difficult to test. Testing a normal system can be trying even under the best of circumstances, and no matter how diligent the tester is, bugs can still get through. Now take all of the standard issues and multiply them by multiple processes written in multiple languages running on multiple boxes that could potentially all be on different operating systems, and there is potential for a real disaster.</description>
      <category>Distributed Development</category>
      <pubDate>Wed, 01 Jul 2015 18:21:35 GMT</pubDate>
      <author>Philip Maddox</author>
      <guid isPermaLink="false">2800697</guid>
    </item>
    <item>
      <title>Corba: Gone but (Hopefully) Not Forgotten</title>
      <link>http://queue.acm.org/detail.cfm?id=1388786</link>
      <description>&lt;h3&gt;Corba: Gone But (Hopefully) Not Forgotten&lt;/h3&gt;
&lt;h4&gt;There is no magic and the lessons of the past apply just as well today.&lt;/h4&gt;
&lt;h4&gt;Terry Coatta&lt;/h4&gt;

&lt;p&gt;
Back in the June 2006 issue of Queue, Michi Henning wrote a very good condensed history of CORBA and discussed how some of its technical limitations contributed to its downfall. While those limitations certainly aided CORBA's demise, there is a very widespread notion that the ultimate cause was the ascendance of Web Services, a notion that is compounded with the further belief that Web Services' dominance of the distributed computing landscape is indicative of its technical superiority to the systems that preceded it, such as CORBA and DCOM.
&lt;/p&gt;&lt;p&gt;
Having worked in distributed systems for a number of years&amp;#151;indeed far enough back in time that building a distributed system meant actually packing bits into UDP packets with lovingly hand-crafted C code&amp;#151;I think this assumption is unwarranted. Worse, it indicates a failure to appreciate the aspects of these previous systems that were well-engineered. This is a symptom of a "silver bullet" mentality that sees Web Services as a radical departure from the past that will finally remove the complexity from designing and building distributed systems.
&lt;/p&gt;</description>
      <category>Distributed Development</category>
      <pubDate>Mon, 14 Jul 2008 15:03:31 GMT</pubDate>
      <author>Terry Coatta</author>
      <guid isPermaLink="false">1388786</guid>
    </item>
    <item>
      <title>A Passage to India</title>
      <link>http://queue.acm.org/detail.cfm?id=1046948</link>
      <description>&lt;h3&gt;A passage to India&lt;/h3&gt;&#xD;&lt;h4&gt;Pitfalls that the outsourcing vendor forgot to mention&lt;/h4&gt;&#xD;&lt;h4&gt;&lt;em&gt;MARK KOBAYASHI-HILLARY, OFFSHORE ADVISORY SERVICES &lt;/em&gt;&lt;/h4&gt;&#xD;&lt;p&gt;Most American IT employees take a dim view of offshore outsourcing. It&amp;#8217;s&#xD;  considered unpatriotic and it drains valuable intellectual capital and jobs&#xD;  from the United States to destinations such as India or China. Online discussion&#xD;  forums on sites such as &lt;a href="http://www.isyourjobgoingoffshore.com"&gt;isyourjobgoingoffshore.com&lt;/a&gt; are headlined with titles&#xD;  such as &amp;#8220;How will you cope?&amp;#8221; and &amp;#8220;Is your career in danger?&amp;#8221; A&#xD;  cover story in BusinessWeek magazine a couple of years ago summed up the angst&#xD;  most people suffer when faced with offshoring: &amp;#8220;Is your job next?&amp;#8221; &lt;/p&gt;&#xD;&lt;p&gt;&#xD;  This article, however, is not designed to make the economic case for or against&#xD;  offshore outsourcing. Economists across the world are debating this issue and&#xD;  producing evidence on both sides of the macro-economic fence. What cannot be&#xD;    disputed is that the American IT industry is changing. According to the U.S.&#xD;    Bureau of Labor Statistics, in 1983, computer&#xD;  programmers accounted for 62 percent of all IT jobs in the U.S. with the remainder&#xD;  being computer engineers, analysts, and scientists. By 2002 this ratio had&#xD;  almost reversed, with programmers accounting for just 26 percent of IT jobs.&lt;/p&gt;</description>
      <category>Distributed Development</category>
      <pubDate>Wed, 16 Feb 2005 10:36:56 GMT</pubDate>
      <author>Mark Kobayashi-Hillary</author>
      <guid isPermaLink="false">1046948</guid>
    </item>
    <item>
      <title>Outsourcing: Devising a Game Plan</title>
      <link>http://queue.acm.org/detail.cfm?id=1036501</link>
      <description>&lt;h3&gt;Outsourcing: Devising a Game Plan&lt;/h3&gt;&#xD;&lt;h4&gt;What types of projects make good candidates for outsourcing?&lt;/h4&gt;&#xD;&lt;h4&gt;Adam Kolawa, Parasoft&lt;/h4&gt;&#xD;&lt;p&gt;Your CIO just summoned you to duty by handing off the decision-making power &#xD;  about whether to outsource next year&amp;#8217;s big development project to rewrite &#xD;  the internal billing system. That&amp;#8217;s quite a daunting task! How can you &#xD;  possibly begin to decide if outsourcing is the right option for your company? &#xD;  &lt;/P&gt;&lt;P&gt;&#xD;  There are a few strategies that you can follow to help you avoid the pitfalls &#xD;  of outsourcing and make informed decisions. Outsourcing is not exclusively a &#xD;  technical issue, but it is a decision that architects or development managers &#xD;  are often best qualified to make because they are in the best position to know &#xD;  what technologies make sense to keep in-house. Deciding what should and should &#xD;  not be outsourced is key to a successful game plan.&lt;/P&gt;</description>
      <category>Distributed Development</category>
      <pubDate>Mon, 06 Dec 2004 10:49:54 GMT</pubDate>
      <author>Adam Kolawa</author>
      <guid isPermaLink="false">1036501</guid>
    </item>
    <item>
      <title>Sink or Swim: Know When It's Time to Bail</title>
      <link>http://queue.acm.org/detail.cfm?id=966806</link>
      <description>There are endless survival challenges for newly created businesses. The degree to which a business successfully meets these challenges depends largely on the nature of the organization and the culture that evolves within it. That's to say that while market size, technical quality, and product design are obviously crucial factors, company failures are typically rooted in some form of organizational dysfunction. To help investors recognize signs of trouble before catastrophe strikes, I started working more than a decade ago on the Bell-Mason Diagnostic, a quantitative evaluation method that includes a set of rules for examining a company and comparing it with an "ideal" organization.</description>
      <category>Distributed Development</category>
      <pubDate>Thu, 29 Jan 2004 10:33:28 GMT</pubDate>
      <author>Gordon Bell</author>
      <guid isPermaLink="false">966806</guid>
    </item>
    <item>
      <title>Culture Surprises in Remote Software Development Teams</title>
      <link>http://queue.acm.org/detail.cfm?id=966804</link>
      <description>Technology has made it possible for organizations to construct teams of people who are not in the same location, adopting what one company calls "virtual collocation." Worldwide groups of software developers, financial analysts, automobile designers, consultants, pricing analysts, and researchers are examples of teams that work together from disparate locations, using a variety of collaboration technologies that allow communication across space and time.</description>
      <category>Distributed Development</category>
      <pubDate>Thu, 29 Jan 2004 10:29:21 GMT</pubDate>
      <author>Judith S. Olson, Gary M. Olson</author>
      <guid isPermaLink="false">966804</guid>
    </item>
  </channel>
</rss>

