Search results matching tags 'Developer', 'Application Fabric', 'Windows Azure', and 'Data'http://sqlblog.com/search/SearchResults.aspx?o=DateDescending&tag=Developer,Application+Fabric,Windows+Azure,Data&orTags=0Search results matching tags 'Developer', 'Application Fabric', 'Windows Azure', and 'Data'en-USCommunityServer 2.1 SP2 (Build: 61129.1)Rip and Replace or Extend and Embrace?http://sqlblog.com/blogs/buck_woody/archive/2011/09/13/rip-and-replace-or-extend-and-embrace.aspxTue, 13 Sep 2011 11:20:05 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:38437BuckWoody<p>As most of you know, I don&rsquo;t like the term &ldquo;cloud&rdquo; very<br />much. It isn&rsquo;t defined, which means it can be anything. I prefer &ldquo;distributed<br />computing&rdquo;, which is more technically accurate and describes what you&rsquo;re doing<br />in more concrete terms.</p>
<p>So when you think about Windows and SQL Azure, you don&rsquo;t<br />have to think about an entire product &ndash; you can use parts of the system<br />together or independently to accomplish what you need to do. You can use the<br />computing functions, storage, and more and more I see folks leverage the<br />Service Bus to enable current applications to expose things to the web.</p>
<p>And that brings up the point of this post. Once you decide<br />that a distributed architecture works to solve a problem, you&rsquo;re faced with a<br />decision: should you completely re-write your architecture to take advantage of<br />the current systems or should you just fold in new code that makes the data or<br />function available to the web?</p>
<p>Of course, the answer is always &ldquo;it depends&rdquo; on the situation<br />&ndash; and it does. But unless you&rsquo;re fixing a problem with current code, I usually<br />advocate a migration approach. That means at the very least retaining the<br />business logic (again, unless it&rsquo;s not currently working) and as much of the<br />code as you can. In fact, if you follow this paradigm, you&rsquo;re on your way to<br />making a Service Bus out of the functions you currently have. You can expose<br />the results of a system rather than opening the system up. Let&rsquo;s take an<br />example.</p>
<p>Assume for a moment that you have an order-taking system<br />on-premise. That system performs many functions, one of which might creating a<br />Purchase Order. Your system might be enclosed, meaning that it has an<br />application that talks to a middle-tier, and then from there to a database<br />system. A query is generated from a screen, and passed along to eventually<br />compute, store and return a Purchase Order Number, along with other<br />information. Imagine now that you wire up the code not only to return the PO<br />number to the client, but to make that number available on an endpoint &ndash;<br />actually really not that hard to do.</p>
<p>Now you can make that PO number available to the web using<br />Azure. You could restrict who can make that call to the system, or open it up<br />to a broader audience. Or instead of the PO Number, you could make a product<br />list available. And you can go further than that &ndash; EBay, for instance, uses the<br />OData protocol (which is very cool in and of itself) which you can query from<br />the web. You could compare your company&rsquo;s product catalog to what is on EBay,<br />and list the items you have there if there are no competitors in that space.<br />And on and on it goes.</p>
<p>So the point is this &ndash; where you can, retain what works.<br />Fold in systems like Azure where they make sense. Extend and Embrace.</p>