This content is part of the Essential Guide: Guide to SOA and the cloud
Manage Learn to apply best practices and optimize your operations.

Cloud and SOA componentization: Complementary or conflicting?

Understanding the differences between cloud and SOA componentization, as well as potential issues that can arise, is key for success.

SOA and cloud computing presume that applications will be componentized for maximum efficiency, and from that it's logical to assume that the cloud and SOA would be harmonious. However, between 20% and 30% of the users who have migrated SOA to the cloud report at least one serious issue, according to a 2013 survey conducted by the CIMI Corporation.

To avoid problems, it's important to understand the differences between optimum cloud and SOA componentization. Special care should be taken with workflow efficiency, security and application lifecycle management (ALM). Appropriate steps should be taken to harmonize componentization goals as applications evolve.

SOA encourages architects and developers to think of software design in terms of reusable services, represented by an inventory of software components. These components are assembled into an application through the use of a service bus that steers work according to business-level rules, often expressed in business process execution language. An application is thus almost a set of policies for workflow through components aimed at improving development efficiency and software agility.

In the cloud, the primary goal is to reduce resource expenses, particularly capital equipment costs. Applications are likely to be componentized to facilitate effective deployment on a pool of resources, and to permit elastic horizontal scaling of application performance through the increase or decrease in the number of copies of a component.

No single approach will ever offer everything, but a smart architect can at least understand where tradeoffs must be made.

In practice, the difference in the goal of componentization has created two distinctly different models of application integration and workflow. In SOA, components are typically proximate to each other, hosted in the same data center or in multiple centers with high-speed inter-facility links available. In cloud applications, a Web front-end component typically drives transactions into applications that are probably not local to the front end and unlikely to be highly componentized themselves.

Cloud and SOA componentization issues

The largest problem users report in migrating SOA componentization to the cloud is major increases in response time due to larger workflow propagation delays. Users have little control over the performance of network paths into, out of, or within the cloud. As a result, they are likely to see an increase in delay and often considerable variability in delay depending on where images in the cloud happen to be hosted.

The greatest problems seem to occur into or out of the cloud. It's possible to mitigate performance issues by hosting SOA applications either totally within the cloud or in the data center and steering work from a Web front end in the way cloud applications would normally work.

The second-largest problem is compromised security and governance. The issue is created by the fact that the cloud is often used to broaden access to information and SOA is often expected to run within a highly secure network. Using the cloud only for a front end and passing work to data-center-hosted SOA components will normally address this concern, but cloud bursting and cloud failover require some migration into the cloud. Even there, if access security is provided by the Web front end, it's normally possible to sustain current levels of application and component security as long as workflows are encrypted.

The final issue, perhaps the most insidious, is with ALM. Most users who migrate SOA applications to the cloud make minimal changes in ALM, presuming the same testing and deployment models will work. What they find is that the combination of the cloud and SOA has to be rigorously tested as part of the ALM application pilot and certification process. This is because the number of variables that impact performance and security or governance are larger in a cloud and SOA deployment than with SOA alone.

While it's tempting to start with existing ALM procedures and cloudify them, experience of real users suggests it's better to start from scratch and develop an ALM procedure that fits the cloud and SOA testing and governance needs.

Thinking of cloud and SOA componentization through the ALM lens may be helpful in identifying areas where application changes or modernization should be used to alter the component model. In particular, it could help locate places where SOA componentization for agility reasons isn't granular enough to make optimum use of the cloud, or where it may be too granular to be efficient for cloud workflows.

Reviewing ALM procedures with an eye toward identifying reused components and their impact on application lifecycles may show that some components are not being reused, meaning that SOA-based componentization isn't bringing any benefits. If that's the case, separating components may risk performance problems at the application level. It may be wise to recompose these components into a single component to localize workflows. Be watchful for component reuse that shows groups of components are almost always composed together.

Working with new applications

For new applications where componentization options are open, the best approach is to start with cloud-based benefits in failover and cloud bursting and determine the componentization model that optimizes these benefits. After the review, see if any of the components can be subdivided further to provide real agility benefits.

Most SOA architects will acknowledge that teams are more likely to over-estimate agility benefits when considering SOA componentization, and thus are likely to over-componentize. Keep this in mind because in a cloud world, excessive componentization will nearly always increase performance and security risks and make ALM testing and certification more difficult. Be sure to have a solid reason to believe a given component model will be valuable before adopting it because there will almost certainly be costs to face.

Agility in addressing business changes and opportunities, software reuse potential and resource optimization are different goals requiring different strategies. No single approach will ever offer everything, but a smart architect can at least understand where tradeoffs must be made.

About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.

Follow us on Twitter at @SearchSOA and like us on Facebook.

Next Steps

The expenses involved with cloud computing and SOA

Social media and mobile demands push SOA systems to the cloud

Embracing the cloud and SOA

Dig Deeper on Container orchestration

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Do you think cloud and SOA componentization is complementary or conflicting?