<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Scale out versus scale up &#8211; How to scale your application.</title>
	<atom:link href="http://spacebug.com/scale-out-versus-scale-up-html/feed/" rel="self" type="application/rss+xml" />
	<link>http://spacebug.com/scale-out-versus-scale-up-html/</link>
	<description>Keeping Software Simple, Open and Pragmatic.</description>
	<lastBuildDate>Wed, 11 Jan 2012 01:15:39 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Amir Shevat</title>
		<link>http://spacebug.com/scale-out-versus-scale-up-html/comment-page-1/#comment-15</link>
		<dc:creator>Amir Shevat</dc:creator>
		<pubDate>Wed, 01 Apr 2009 12:07:08 +0000</pubDate>
		<guid isPermaLink="false">#comment-15</guid>
		<description>Thank you,

I totally agree that scale up starts as a low hanging fruit, especially when virtualization is driving the complexity of scale up even lower.

I do think that scale out, by keeping exact copies of the application on each server in the farm, might hide some development effort in the form of synchronization and consistency of data in the farm. I agree that this kind of &quot;horizontal&quot; scale out might be simpler to implement.  

Good luck on your presentation.

Amir Shevat</description>
		<content:encoded><![CDATA[<p>Thank you,</p>
<p>I totally agree that scale up starts as a low hanging fruit, especially when virtualization is driving the complexity of scale up even lower.</p>
<p>I do think that scale out, by keeping exact copies of the application on each server in the farm, might hide some development effort in the form of synchronization and consistency of data in the farm. I agree that this kind of &#8220;horizontal&#8221; scale out might be simpler to implement.  </p>
<p>Good luck on your presentation.</p>
<p>Amir Shevat</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: anonymous</title>
		<link>http://spacebug.com/scale-out-versus-scale-up-html/comment-page-1/#comment-14</link>
		<dc:creator>anonymous</dc:creator>
		<pubDate>Wed, 01 Apr 2009 11:42:50 +0000</pubDate>
		<guid isPermaLink="false">#comment-14</guid>
		<description>Very good post, Amir. Clear and concise

Want to add that the drawback of scale up as expensive is manifested -exponentially- the more you scale but in the lower end is actually cheaper than scaling out

To clarify where scale up is a low hanging fruit compared to scale out, that comfort area is determined if, after diagnosing where contention is being produced, we find -let&#039;s say- that contention is for CPU usage but not for memory, vice versa, or even both but we could solve the problem by just adding another CPU, a couple of gigas to the server as long as we have available slots in the current infrastructure
When that is the case, we could say that scale up is still more cost-effective. When we have no more room to grow in that infrastructure, migrating to a bigger one could start being more expensive -in the long term- than scaling out

Still there are two ways to scale out, one being keeping exact copies of the application on each server in the farm -so we could say that impact in the application should be minimal or probably null-. The other one being by partitioning the application in tiers. This last case will have two negative impacts, one at development time (as we&#039;ll need to consider inter-process communications, time-outs, distributed transactions and possible compensations, etc) and execution time: a single client request may traverse more than one tier to be resolved, adding a performance impact derived from network latency, parameter marshalling, and so forth



Scaling apps is one of the topics I&#039;m presenting next May in SATURN 2009 (a SEI conference, http://www.sei.cmu.edu/architecture/saturn/2009/program.html#may7 )
Mentioning this ad you can get important discounts! (just kidding, I&#039;m sorry)</description>
		<content:encoded><![CDATA[<p>Very good post, Amir. Clear and concise</p>
<p>Want to add that the drawback of scale up as expensive is manifested -exponentially- the more you scale but in the lower end is actually cheaper than scaling out</p>
<p>To clarify where scale up is a low hanging fruit compared to scale out, that comfort area is determined if, after diagnosing where contention is being produced, we find -let&#8217;s say- that contention is for CPU usage but not for memory, vice versa, or even both but we could solve the problem by just adding another CPU, a couple of gigas to the server as long as we have available slots in the current infrastructure<br />
When that is the case, we could say that scale up is still more cost-effective. When we have no more room to grow in that infrastructure, migrating to a bigger one could start being more expensive -in the long term- than scaling out</p>
<p>Still there are two ways to scale out, one being keeping exact copies of the application on each server in the farm -so we could say that impact in the application should be minimal or probably null-. The other one being by partitioning the application in tiers. This last case will have two negative impacts, one at development time (as we&#8217;ll need to consider inter-process communications, time-outs, distributed transactions and possible compensations, etc) and execution time: a single client request may traverse more than one tier to be resolved, adding a performance impact derived from network latency, parameter marshalling, and so forth</p>
<p>Scaling apps is one of the topics I&#8217;m presenting next May in SATURN 2009 (a SEI conference, <a href="http://www.sei.cmu.edu/architecture/saturn/2009/program.html#may7" rel="nofollow">http://www.sei.cmu.edu/architecture/saturn/2009/program.html#may7</a> )<br />
Mentioning this ad you can get important discounts! (just kidding, I&#8217;m sorry)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: anonymous</title>
		<link>http://spacebug.com/scale-out-versus-scale-up-html/comment-page-1/#comment-10</link>
		<dc:creator>anonymous</dc:creator>
		<pubDate>Sat, 06 Dec 2008 07:43:43 +0000</pubDate>
		<guid isPermaLink="false">#comment-10</guid>
		<description>Thanks for your post, it help me understand exactly these terms with very simple examples.</description>
		<content:encoded><![CDATA[<p>Thanks for your post, it help me understand exactly these terms with very simple examples.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

