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.

Governance for the <strong>Cloud</strong>s 149<br />

form know that a service was chang<strong>in</strong>g. You can consider this a dance that<br />

<strong>in</strong>cludes those charged with design<strong>in</strong>g <strong>and</strong> build<strong>in</strong>g the architecture, those<br />

who operate the systems with<strong>in</strong> the enterprise, <strong>and</strong> those who operate the<br />

systems with<strong>in</strong> the clouds. If they do not all come together on service governance,<br />

it simply will not work no matter what technology you leverage or<br />

how good it is.<br />

Governance for the <strong>Cloud</strong>s<br />

We do governance for the simple reason that once we get to a certa<strong>in</strong> number<br />

of services, we will not be able to keep track of them all <strong>and</strong> provide the control<br />

they require. Those who build <strong>SOA</strong> call this the “tipp<strong>in</strong>g po<strong>in</strong>t,” or the<br />

po<strong>in</strong>t at which the number of services under management becomes so high<br />

that it is impossible to manage them properly without a governance model,<br />

approach, <strong>and</strong> service governance technology.<br />

The number of services, as well as the complexities around us<strong>in</strong>g those<br />

services with<strong>in</strong> the context of cloud comput<strong>in</strong>g, makes service governance<br />

even more compell<strong>in</strong>g; they <strong>in</strong>clude<br />

Location of the services<br />

Service dependencies<br />

Service monitor<strong>in</strong>g<br />

Service security<br />

Many of the services are not hosted <strong>and</strong> owned by the bus<strong>in</strong>ess; they are<br />

cloud-based, so controls must be placed around them to mediate the risks.<br />

What is important when leverag<strong>in</strong>g on-premise <strong>SOA</strong>s is even more important<br />

<strong>in</strong> the world of cloud comput<strong>in</strong>g. In essence, we use the “trust but verify”<br />

model, plac<strong>in</strong>g a layer of processes <strong>and</strong> technology around the services<br />

so that every event, such as a change to services or a service failure, is quickly<br />

known, allow<strong>in</strong>g us to take corrective action or perhaps allow<strong>in</strong>g the technology<br />

to self-correct (see Figure 8.3).<br />

When consider<strong>in</strong>g the end-state architecture as a comb<strong>in</strong>ation of <strong>SOA</strong><br />

<strong>and</strong> cloud comput<strong>in</strong>g, we are look<strong>in</strong>g to build a series of services that are<br />

formed <strong>and</strong> reformed to build bus<strong>in</strong>ess solutions. The services may exist onpremise<br />

or may be cloud delivered, but the use of those services by applications<br />

<strong>and</strong> processes, as well as their location, should be completely transparent<br />

to the service consumer.

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

Saved successfully!

Ooh no, something went wrong!