Cloud Computing and SOA Convergence in Your Enterprise: A Step ...
Cloud Computing and SOA Convergence in Your Enterprise: A Step ...
Cloud Computing and SOA Convergence in Your Enterprise: A Step ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
70 Chapter 4 Mak<strong>in</strong>g the Bus<strong>in</strong>ess Case for <strong>Cloud</strong>s<br />
Perhaps it is better to use an example. Let’s say you are support<strong>in</strong>g an <strong>in</strong>ventory<br />
management system <strong>and</strong> you leverage cloud comput<strong>in</strong>g resources<br />
for database-as-a-service <strong>and</strong> platform-as-a-service. In this example, you<br />
avoid the cost of data center–bound resources, <strong>and</strong> more importantly, the<br />
cost of the risk. By leverag<strong>in</strong>g cloud comput<strong>in</strong>g resources, you avoid the <strong>in</strong>vestment<br />
<strong>in</strong> a set of on-premise comput<strong>in</strong>g resources that have two major attributes:<br />
First, they require a specific amount of capital <strong>in</strong>vestment for<br />
hardware <strong>and</strong> software; second, they have an upper limit <strong>in</strong> scalability from<br />
the po<strong>in</strong>t where you need to purchase additional resources to scale up process<strong>in</strong>g<br />
to meet the needs of the bus<strong>in</strong>ess.<br />
In Figure 4.3, you can see that the <strong>in</strong>vestment of $500,000 <strong>in</strong> hardware<br />
gets you to a specific number of transactions per day, <strong>and</strong> then you have to<br />
<strong>in</strong>vest aga<strong>in</strong> to support the <strong>in</strong>creas<strong>in</strong>g load as transaction volumes <strong>in</strong>crease.<br />
You have excess capacity you are pay<strong>in</strong>g for, <strong>and</strong> you are tak<strong>in</strong>g on the risk.<br />
Indeed, you always have to keep additional capacity on h<strong>and</strong> <strong>in</strong> order to h<strong>and</strong>le<br />
the peak transaction process<strong>in</strong>g loads. This does not consider the disruptive<br />
nature of purchas<strong>in</strong>g, configur<strong>in</strong>g, <strong>in</strong>stall<strong>in</strong>g, <strong>and</strong> test<strong>in</strong>g new hardware<br />
<strong>and</strong> software.<br />
In this scenario, there is the risk that, for the amount of capital committed,<br />
it will provide either more capacity than is required for a specific period<br />
of time or not enough capacity for a particular period of time. Either way,<br />
you are runn<strong>in</strong>g a risk.<br />
$1,000,000<br />
$500,000<br />
Hardware/Software<br />
Transaction/Day<br />
Year<br />
1<br />
Year<br />
2<br />
Year<br />
3<br />
Year<br />
4<br />
Year<br />
5<br />
Figure 4.3 When us<strong>in</strong>g an on-premise approach, you have to purchase hardware<br />
<strong>and</strong> software to support the current process<strong>in</strong>g load, <strong>and</strong> then re<strong>in</strong>vest <strong>in</strong> the<br />
future <strong>in</strong> order to scale. The risk is on you.