When I started explaining my view of Cloud Computing as an extension of SOA (Service Oriented Architecture) someone didn't take it seriously.
I delivered some TOI sessions to increase the awareness on topics that Cisco was approaching in its transformation into a IT company: software architecture, distributed systems, IT service management. I reused some of the concepts and the slides that I created when I was a SOA evangelist.
The feedback was positive and generated a useful discussion, but I also got few comments like: "this is old stuff, cloud is different" and "don't be nostalgic".
After those days, indeed, I've seen many articles comparing Cloud and SOA.
And it is natural: both the architectures (actually cloud is a consumption model more that a architecture) are based on the concept of Service. To be precise, to offer and consume cloud services you need to build a SOA.
It is easy to understand: to begin with, the consumer of a cloud service wants to delegate the build, the ownership and the operations to a third party, that assumes the responsibility for the SLA.
The service is considered a function that someone else provides to you, and you only care the interface to access it (and the quality and the price). You are interested only in the protocol and the user interface - or the API - plus the URL where you get the service.
The actual implementation is not your business. The service (IaaS, PaaS, SaaS) can run on any platform, in any part of the world, fully automated or manual, implemented in any of the hundreds of programming languages. You just don't care, as long as they respect the SLA.
I delivered some TOI sessions to increase the awareness on topics that Cisco was approaching in its transformation into a IT company: software architecture, distributed systems, IT service management. I reused some of the concepts and the slides that I created when I was a SOA evangelist.
The feedback was positive and generated a useful discussion, but I also got few comments like: "this is old stuff, cloud is different" and "don't be nostalgic".
After those days, indeed, I've seen many articles comparing Cloud and SOA.
And it is natural: both the architectures (actually cloud is a consumption model more that a architecture) are based on the concept of Service. To be precise, to offer and consume cloud services you need to build a SOA.
It is easy to understand: to begin with, the consumer of a cloud service wants to delegate the build, the ownership and the operations to a third party, that assumes the responsibility for the SLA.
The service is considered a function that someone else provides to you, and you only care the interface to access it (and the quality and the price). You are interested only in the protocol and the user interface - or the API - plus the URL where you get the service.
The actual implementation is not your business. The service (IaaS, PaaS, SaaS) can run on any platform, in any part of the world, fully automated or manual, implemented in any of the hundreds of programming languages. You just don't care, as long as they respect the SLA.
Definitions
The most known definition of cloud computing is from NIST:
SOA is an architectural
approach that enables the creation of loosely coupled,
interoperable business services that can be easily shared
within
and between enterprises.
You can find a discussion of the SOA reference architecture (sorry, it's limited to my italian readers...) here. Also IBM has a good definition of SOA here.
SOA concepts that apply to Cloud
There are some concepts that you find in both the models: each one would deserve a dedicated post, or maybe a book. I will try to give some essential detail in this post.- The concept of Service: Consumer and Provider’s responsibility
- Distributed systems, where remote API are invoked over standard protocols
- Separation of concerns: interface vs implementation
- Interface and Contract
- Reuse and Loose Coupling
- Service Repository and Service Catalog
- Service Lifecycle
- Service Assurance
- Strategy and Governance
Basic detail
Distributed systems
A distributed system is made of components that are deployed separately, in most cases remotely. Each of them provides a lower level functionality that can be used as a building block for the solution of a business need.To inter-operate, they need connectivity and a well defined framework for sending and receiving data, managing security, transactions consistency, availability and many other non-functional requirements.
To make the development of such a complex system easier, the software industry has separated the concept of interface from the actual implementation.
The interface of a sw component specifies the functions it implements, the parameters it expects and returns, their format, the conversation style (sync/async) and the security constraints. It is an artifact that can be produced - and deployed - before the actual implementation is ready: you can generate a stub (or mock) component that always returns fake data, but at least it replies to clients allowing the end to end test of the architecture.
So different developers can split the implementation of the system in components that are built in parallel, based on the definition of the interface that they present to each other. The basic integration test can be executed against a stub, to ensure that the conversation works. This also helps rapid prototyping and agile development.
The separation of the interface from the implementation is fundamental when a distributed system is designed.
A Service = Contract + Interface + Implementation
The set of the above mentioned artifacts identifies a service.
As I stated, the implementation is not relevant for the consumer of the service - but it must exist, otherwise the service cannot be delivered.
The interface is the only visible part of the service, because the consumer will use that one. Depending on the service, it could be a GUI or the API that a client program invokes.
The most important part is the Contract: the agreement (generally defined in a document) defining who has the right to consume the service, the credentials, the price, the SLA, the constraints (e.g. the response time is granted up to 1000 transactions per second), and more.
A given interface could be offered with two distinct contracts, e.g. with different security requirements. Or different price, or different SLA, ect.
If you do that, a new service is generated (a different triple of contract+interface+implementation):
And of course you can differentiate the interface (e.g. sysnchronous vs asynchronous, that is pretty easy if you use a service bus). Also the addition of a new interface will generate a new service:
Reuse and Loose Coupling
The effort of building a service in a way that makes it reusable is bigger than just implementing a local component in a software project.Potential consumers of the service will trust it if it is robust enough, it scales, it is secure, etc.
You need to provide information on what the service does, how to use it, how do you support it.
So a business justification is needed for the additional effort to create a reusable service, both for internal usage (SOA) or as a cloud service.
The integration between service consumers and providers should not create tight dependencies, to allow for innovation and maintenance. Coupling refers to the degree of direct knowledge that one element has of another. The separation of the interface from the implementation plays an important role here, because one could change the implementation without affecting the published interface.
In case of major changes, versioning the interface helps.
See also these definitions of loose coupling on Wikipedia and Techtarget.
Service Repository and Service Catalog
I said that you need to provide information on the service and, eventually, market it. If potential consumers don't know that it exists, they will never use it. They also need descriptive info and technical details.This is true when you build services for the enterprise architecture, even more if you want to sell them in the cloud.
An important element of the Service Oriented Architecture was the Service Repository. A central point where all the artifacts produced by projects are exposed for reuse, complemented by the Registry offering a link to the service end points.
Now we have the concept of Service Catalog, managing the entire life cycle of a cloud service: from the inception to the decommissioning, passing through cost models and tenants management.
You can find a definition of a service catalog and its usage in this excellent free book: Defining IT Success Through the Service Catalog
Service Lifecycle
When a new service is created, you need to design its provisioning process - that could include fully automated or manual steps, including authorizations - its cost model, the management of the resources allocated for a tenant, the assurance of the quality of the service, the billing and end user reporting, the decommissioning and returning the resource to the shared pool.It is good to have tools to manage all these phases of the life cycle. A choice of CMS (Cloud Management Systems) is offered by Cisco, that have a solution for a ready to run cloud implementation with pre built services (Cisco Intelligent Automation for Cloud, aka IAC) and the just released Cisco ONE Enterprise Cloud suite, a flexible environment where you can create new services with a very little effort, in a bottom-up approach (from the infrastructure to the catalog).
Both the suites use Cisco Prime Service Catalog (PSC) and the front end. PSC is ranked very high by analysts when they examine the features of service catalogs on market.
Service Assurance
Monitoring the infrastructure is essential, if you are a service provider. But it is not enough, because you can't immediately correlate the health status of the infrastructure with the quality of the services that consumers perceive (availability, response time, completeness of the result...).More sophisticated tools are needed to report the services heath score to the Operations team and to the end users, and to allow troubleshooting.
Root cause analysis is the investigation of the ultimate cause for a service failure that could be due to software, servers, network, storage.
Impact analysis is the notification of the list of services impacted by a fault in the infrastructure, that helps the Operations team to restore the services before consumers complain for a violation of the SLA.
Strategy and Governance
IT governance provides the
framework and structure that links IT resources and information to enterprise
goals and strategies. Furthermore, IT governance institutionalizes best
practices for planning, acquiring, implementing, and monitoring IT performance,
to ensure that the enterprise's IT assets support its business objectives.
In recent years, IT governance has
become integral to the effective governance of the modern enterprise.
Businesses are increasingly dependent on IT to support critical business
functions and processes; and to successfully gain competitive advantage,
businesses need to manage effectively the complex technology that is pervasive
throughout the organization, in order to respond quickly and safely to business
needs.
In addition, regulatory
environments around the world are increasingly mandating stricter enterprise
control over information, driven by increasing reports of information system
disasters and electronic fraud. The management of IT-related risk is now widely
accepted as a key part of enterprise governance.
It follows that an IT governance
strategy, and an appropriate organization for implementing the strategy, must
be established with the backing of top management, clarifying who owns the
enterprise's IT resources, and, in particular, who has ultimate responsibility
for their enterprise-wide integration.
I discussed this topic with reference to SOA (only in italian, again... sorry) in SOA è solo tecnologia? and in
Enterprise Service Bus
The ESB is a core component in the SOA Reference Architecture. It has the role of a mediation layer between the consumers and the providers of any service, managing the match of available interfaces, the security, the quotas and - in general - the enforcement of the Contract.The ESB is the backbone of a Enterprise Architecture where new projects benefit from reusing already implemented services.
When you think about cloud, the public interface to available services is offered publicly to consumers. Very often, it consists in a set of API to provision and consume the services. A ESB is not strictly required to expose your implementation as a service, but it can certainly help.
Creating multiple interfaces, as long as new contracts are defined for a service, is just a few clicks activity. There are many ESB available as commercial products, next paragraph shows one example but the same capabilities are commonly available on the market and in the open source.
ESB Core Capabilities (courtesy of Mule Soft - http://www.mulesoft.com/platform/soa/mule-esb-open-source-esb):
- Service Mediation
Separate business logic from protocols and message formats for rapid, nimble development and long-term flexibility. - Service Orchestration
Coordinate and arrange multiple services and expose them as a second-generation composite application. - Service Creation & Hosting
Expose app functionality as a service and create an efficient standards-based architecture or host existing services in lightweight containers. - Message Routing
Direct messages based on content or predetermined rules and filter, aggregate, or re-sequence as required. - Data Transformation
Transform data to and from any format across heterogeneous transport protocols and data types or enhance incomplete messages. - Event Handling
Deliver synchronous and asynchronous events, transactions, streaming, routing patterns, and a SEDA architecture.
So are SOA and Cloud identical?
Of course not. They have a lot of common concerns, but while SOA was created to address IT and business needs in a single Enterprise context, Cloud is a wider model that offers commercial services across companies.There's still the private cloud model, where services are offered internally.
Here we have the same self service consumption model, so the automation of the provisioning is critical as well as the quality of the Service Catalog that you offer to consumers.
The most important lesson from SOA that we can reuse in Cloud is that the human factor is sometimes more impactful than the technology.
Change management is one of the key initiatives that help winning the resistance (both in the IT organization, when a new operational model is adopted, and across consumers that are offered a new way of using applications or implementing new projects).
A proper documentation of the services is key, and the definition of a go-to-market strategy before you start your journey is fundamental: technology should not be adopted because it's smart or because others are doing the same.
It should always be functional to business requirements and be aligned with the corporate strategy.
Technology is one thing that always changes and you get caught up with it whether it is basic IT or sophisticated stuff like cloud computing, Internet of Things or mobility. Either way, I like how you start things of by stating, history has it what we consider to be perfect and right in the technological world is soon proven otherwise and we should always expect that.
ReplyDeleteDonald Steadman @ Office PCS
Hey, I appreciate to your writing.
ReplyDelete