You might like to know more about the impact of other architecture styles and trends on SOA. This article explains why SOA is a good fit for cloud-based deployments and how the cloud affects SOA. Dividing business capabilities into autonomous components fits well both gradual transitioning to public clouds and hybrid cloud setups.
This article is based on SOA Patterns, to be published in Summer 2012. This eBook is available through the Manning Early Access Program (MEAP). Download the eBook instantly from manning.com. All print book purchases include free digital formats (PDF, ePub and Kindle). Visit the book’s page for more information based on SOA Patterns. This content is being reproduced here by permission from Manning Publications.
Authors: Arnon Rotem-Gal-Oz, Eric Bruno and Udi Dahan
Cloud computing is an important IT trend taking virtualization to the next level by using a large pool of virtualized hardware to provide utility computing capabilities—cloud computing provides an electricity-like mode where computational resources are available on demand (usually with a pay-as-you-go model) and with the ability for elastically grow and shrink resource use as needed. We’d like to see how this, relatively new, playground affects SOA, but let’s first try to make sense of the cloud-related terms.
The cloud terminology soup
Cloud computing sounds a lot like many other virtualization and hosting solutions we had around before. However, while cloud technologies share and use similar concepts there are several characteristics that differentiate clouds. The US national institutes of standards and technology published a formal definition of cloud computing (see further reading below) where they define five essential characteristics:
* On-demand self service—The ability to provision additional capabilities (for example, an additional VM, more storage) by cloud users.
* Rapid elasticity—As mentioned above, the ability to add/remove resources on demand.
* Measured service—Collecting, controlling, reporting and optimization of resources (bandwidth, CPU usage). The consumption of these resources is usually the basis for service charges
* Resource pooling—Resources are shared by multiple consumers in a transparent manner; users are not aware where exactly the resource are located or of other tenants using the resource.
* Ubiquitous network access—Capabilities are accessed over the network and accessible via heterogeneous networks.
Cloud computing can be delivered as a public cloud where anyone can register and use the resources such as Amazon AWS or Microsoft Azure. The pros of a public cloud are:
* Low barrier to entry.
* No upfront investment.
* A convenient pay-as-you go model.
* Virtually infinite scalability.
The cons include:
* Increased latency.
* Being costly for the steady-state usage.
* Vendor lock-in (though that might be a temporary thing).
An alternative to public clouds, known as private cloud, is to deploy a cloud on-premise for internal use by a single company. An example for that can be building a solution based on OpenStack or using VMWare vFabriq. Pros include performance and latency, familiarity of tools and technologies (for the cluster managers), and privacy/security. Cons include up-front investment, limited resources, and scalability
Lastly there’s the option of hybrid cloud—using both a public and a private cloud as a single solution. Hybrid clouds has the advantage of providing a good balance of flexibility and performance at the cost of increase. On the other hand, hybrid clouds represent more complexity and security challenges.
Cloud capabilities are, as mentioned above, delivered over the network. Cloud capabilities are delivered as a service and there are three main types of service delivery:
* Infrastructure as a Service (IaaS)—in IaaS, the cloud capabilities are basic building blocks like Virtual machines, storage, network bandwidth, and so on.
* Platform as a Service (PaaS)—PaaS cloud computing means that the cloud provider delivers infrastructure software components such as databases, queues, monitoring, and so on.
* Software as a Service (SaaS)—These are usually smaller companies that deliver complete business capabilities, for example, a sales force that delivers a CRM solution as a service.
OK, now that we’ve got the vocabulary sorted out, let’s take a look at the architectural implications brought in by the cloud.
Cloud and the fallacies of distributed computing
Peter Deutsch’s fallacies of distributed computing are base architectural requirements that you have to account for when designing distributed systems. The cloud does not get a free ticket here.
Table 1 Fallacies of distributed computing and how are they relevant in cloud setups
| Fallacy | What does it mean in the cloud |
| The network is reliable | No change—this is still a problem, especially in hybrid cloud solutions. If you have a real mission-critical app, you still need a disaster recovery plan, for example, backup in a secondary cloud provider. |
| Latency for zero | Latency has not decreased in the cloud, though by deploying in datacenters near your end-users, you can lower it. Cloud introduces another latency-related problem |
| Bandwidth is infinite | In private clouds, this hasn’t changed from traditional systems. In public clouds, it depends. For internal communications between deployed servers, it has been transformed into a cost problem. For clients connecting to your cloud application, it is the same old problem |
| Topology doesn’t change | If you assume this in a cloud solution, you’re in a real problem. The whole notion of elasticity means there’s no way the topology stays the same. |
| There’s one administrator | Like topology above, it is still a fallacy, just one that’s hard to believe someone would make. |
| Transport cost is zero | Still a problem; cost of moving data in an out of the cloud is more apparent than non-cloud environments because they come with a pricelist but the additional cost (performance, latency) on transforming data structures—for example, encryption—can still be hidden. |
| The network is homogeneous | The network is not homogenous; however, you don’t care as much since you can define the types of machines you need and get virtualized copies that match your needs. |
Table 1 shows that cloud computing doesn’t solve distributed computing problem but at least it helps in making some of the fallacies more apparent so you’re less likely to assume they’re not there. However, the flip side is that the cloud brings with it a couple of new fallacies to watch out for:
* Nodes are fixed — This means that any meaningful state should be persisted elsewhere on an attached or connected storage. On one project, we had a service hosted in Windows Azure. We hosted this service in two district setups—staging and production. (Actually, we had more for testing but that’s less important.) Windows Azure has this feature where you can do a virtual IP switch to move the staging server(s) to production; we used it and it worked great, except the staging service was still pointing to the staging data store and using the staging certificate store—not so good. We solved this by orchestrating the whole switch from another service that also sent events to synchronize the whole move.
* Latency is constant — This is a progression on the notion that the latency is zero fallacy. The fact that latency really is not constant means that if you send messages in an asynchronous manner you can’t assume they’d arrive in order. If you connect with user interfaces, you need to understand the variance and plan for it so that users would get a decent experience.
Fine, but how does all this relate to SOA?
Cloud and SOA
SOA is the architectural style that enables transition to cloud computing, especially for hybrid and public cloud scenarios. Table 2 below shows SOA effects and how they’re a good fit for the cloud.
Table 2 SOA traits that are good fit for the cloud
| SOA trait | How is good for the cloud |
| Partitioning of the enterprise/system into business | A service is a good sized unit to move to the cloud (as it is for moving to an external vendor). SOA present a complete business function. Service boundaries already take into account the fallacies of distributed computing and already internalize handling of messages. |
| Standard based message and contract communications | Encapsulation of internal representations rather than relying on shared data means that services moved would be able to operate isolated from the rest of the world while communicating only via the messages defined in their contracts. |
| Treating service boundary as trust boundary | When we want to move functionality to a public cloud, it greatly helps if our software already assumes that anything foreign is hostile and should be authenticated, validated, and so on. |
| Keeping services autonomous | Autonomy better equips services to survive on their own; it also helps them to keep operating when other service go out. |
A lot of the patterns are very relevant to cloud deployments and even more so for the cloud transition phase. Consider the following patterns:
* Service registry—Helps other services to know where to find services regardless of whether they’re local or remote.
* Servicebus—Helps in providing the location transparency. Location transparency is very beneficial in a cloud since new services might be spawned in a new node with new IP address or consolidated to a single node based on the load (elasticity).
* Identity provider pattern—A crucial component when services are spread across the enterprise and a cloud and users expect a single sign-on experience. This is even more important if you add REST to the mix where you may need to interleave WS-trust and oauth2 services.
* Request/reaction and inversion of communications—Asynchronous communication is more resilient than plain RPC and that’s a bug plus especially in hybrid cloud setups.
* Monitoring and watchdog—Always relevant but even more important when you don’t control the hardware.
* Service instance—Another pattern that can help with elasticity and scale out.
* Virtual endpoint—When running in the cloud, the endpoint in which services are delivered will most likely be a virtual endpoint whether we like it or not.
Summary
SOA principles and patterns are a very good match for the cloud. The division of business capabilities into autonomous components fit well both gradual transitioning to public clouds and hybrid cloud setups.
Pingback: Software Development Linkopedia May 2012
Pingback: Software Architecture Articles of 2012 Selection