09.02.2015 Views

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 ...

SHOW MORE
SHOW LESS

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.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!