Cloud architecture: there are no brokers

Cloud architecture: What is the difference between a cloud broker and a cloud provider?

Recently, I have done a deep dive into the NIST cloud definitions, as we are revising the cloud computing course www.cloudessentials.net.

The NIST definitions identify a number of actors in the cloud ecosystem (see NIST SP500-292 Cloud Computing Reference Architecture). Two of these are the cloud broker and the cloud provider. To me they look pretty much the same.

Let us have a look at the definition of cloud provider:

A cloud provider is a person, an organization; it is the entity responsible for making a service available to interested parties. A Cloud Provider acquires and manages the computing infrastructure required for providing the services, runs the cloud software that provides the services, and makes arrangement to deliver the cloud services to the Cloud Consumers through network access.

And this is the definition of cloud broker:

A cloud broker is an entity that manages the use, performance and delivery of cloud services and negotiates relationships between cloud providers and cloud consumers.

The similarities are that both the provider and the broker manage delivery of services and have a relationship with a cloud consumer. The idea is that a broker shields the consumer from aspects of the cloud provider, and adds value of its own, by enhancing, aggregating or arbitering other cloud services.

But what distinguishes the broker from the provider? I would argue that the apparent differences are immaterial. There is a hidden assumption that is untrue, in my opinion.

A cloud broker is likely to have no physical assets, but a lot of cloud providers at the SAAS level have no physical assets either. A typical SaaS or PaaS provider is likely to use services from other providers to augment its own assets. For example: Smugmug uses Amazon’s new DynamoDB to deliver its photosharing function, and Disqus, the commenting system, is used on a lot of other SaaS providers as well.
In this sense, such providers are brokers themselves.

So the punchline is: there really are no brokers, because every broker we can think of is also a cloud provider, and most providers are also brokers.

Run your business from the cloud

My business friend Henri Koppen and I wrote a little book on how to get started as a user of cloud computing services. You will find the book here.

We list the stuff any typical company does with IT, like mail, documents, customer relations, website, projects, and digital sales. For each of these we list one or more cloud based tools we use ourselves.

You will also find a chapter on pitfalls and considerations, stuff to be aware off unless you want to get burned.

Listen to this brief interview I did with Henri, and then follow this link to learn more about the book.

Cloud Architecture, some examples

Cloud architecture is similar to classic IT architecture, but there are important differences. Classic IT systems are built up from software components installed on in-house servers. Cloud computing solutions and applications, in contrast, are built up from services and service providers.

Even if you only want to use SaaS (Software as a Service) solutions, it is unlikely that there is a single cloud application provider fully servicing your needs. At the very least, you will want to think about what happens when your cloud provider stops servicing you. This means that in addition to the cloud application, there is also another service or component capable of serving as a back-up solution. 

An example of such a simple architecture would be a webmail provider like Gmail or Hotmail, combined with a periodic download of all messages to the user’s PC.

IT architectures tend to be depicted as diagrams that show how various functions are allocated to components. An architectural choice might be where to put management of user identities and credentials. The diagram can then act as a model for subsequent application selection, development and deployment.

Two architectures may deliver the same functionality to its users, while differing in their capability to withstand failures of components or providers or comply with security regulations. Other quality criteria include pricing, flexibility and agility. It is therefore an architect’s job to explain advantages and disadvantages of the alternative architectures.

For more examples of architectural questions when using Software as a Service, consider the use of a CRM (customers relationship management) system, such as Salesforce or Insightly. Where will you manage the identities of your users? In the CRM, or in your staff database? How can the data that a potential customer enters on a website be entered in the CRM? How will you drive an email list out of the CRM? How will you integrate mobile applications? You might have all of these as a function in your CRM, but that is not necessarily the best idea in the context of your wider application portfolio.

Platform as a Service solutions bring their own questions: what data formats will be supported? XML, JSON, REST, or other (if you don’t know what these are, I have made my point anyway)? How are transactions going to be monitored for performance over this chain of components? How will version upgrades of external services be managed? As an example of a PaaS solution, consider the back-end of an e-commerce site.  This needs to integrate with payment and shipping providers, and maybe  retrieve customer details, such as credit rating and location.

Infrastructures as a Service solutions finally, introduce entirely new levels of complexity. Compared to other cloud models, the technology components such as servers, storage and networks, are more visible. Some of the complexities of traditional infrastructure management, such as housing and networking, are radically reduced. However, to take full advantage of cloud computing requires control of automatic scaling up and down of infrastructure resources. It just is not your daddy’s web server anymore. Shrinking deployment times from weeks to minutes implies much more heavy automation of capacity management and server provisioning for example. In ITIL terms, this implies thorough automation of the CMDB (Configuration Management Database), to name one task.

Stay tuned for more articles on cloud architecture.