Cloud Computing and SOA Convergence in Your Enterprise: A Step ...

Where Are the Applications 181
However, you could find that your architecture has performance and reliability
issues because you leveraged too many platforms to host those services.
The problem arises when you consider that the application is dependent on
every service functioning in order to continue processing, and thus a single
platform failure could stop the entire application from working, depending on
how it is designed. In essence, your reliability is really a function of the reliability
of all systems, on-premise or cloud-based, that support that application.
Consider the number of links in the chain. The more you distribute the application,
the more likely you are to have reliability issues. That is the reality of
distributed computing.
Furthermore, you should consider performance. It is well known that
SOA services that are too finely grained have a tendency to cause performance
problems, since each service needs to talk to other services through a single
interface. The more services, the more communications occur, and the more
the network and the processors get saturated. There are no hard and fast rules
around granularity for SOA, or SOA leveraging cloud computing; it is simply a
matter of understanding how your architecture will be affected by additional
services and understanding the functional need to break down the services
into smaller, more fine-grained services.
There are trade-offs, and perhaps you should not go too nuts when
decomposing services, from coarse- to fine-grained services, and distributing
them across too many systems and platforms, on-premise or in the clouds.
In essence, we identify locations where the services, processes, and data—
the architectural components—will reside, and we determine how those components
will make up applications. In other words, we break our architecture
down to the primitives of services, processes, and data. Then we figure out
where to best place them, taking into consideration the business and technical
issues we looked at in the last several chapters, and we determine the proper
platforms to host those components.
Consider the next several figures, as a way to better understand this process.
Figure 10.1 is a starting point. Using the steps and processes covered in
the last several chapters, we have a service, process, and data understanding
of our problem domain, and we understand what each architectural component
does and the interdependencies of each.