Cloud computing is a model where the storage and computing capacity is provided as a service, usually on the internet, in a remote accessible fashion to heterogeneous parties.
The main drive to use cloud computing by these heterogeneous parties is cutting costs by the economy of scale and simplicity of maintainability. Maintainability is in essence the flexibility/changeability of a product/service during it’s life-cycle.
As a solution architect you are responsible to find the cheapest way to realize the current and possible future requirements of the business during the life-cycle of the product/service. Because cloud computing is about reducing costs, you should have a good look at it whether to use it or not.
The following part of this blog post describes several key choices to determine if and which cloud computing solution could be used for the product/service the company wants to provide. After the key choices, three cloud promises are described which have to be kept in mind while designing the product/service.
Choice between public/private cloud
Suppose a cloud (private or public) solution does not violates any of the corporate architectural principles, the following step in the investigation is to determine if a public or private cloud computing solution could fulfill the needs. The choice for private or public cloud will be mainly data security and privacy driven, like legal compliance, corporate principles, but also network latency and the available skills within the company to create and maintain a private cloud.
Choice between cloud computing groups (SaaS, PaaS, IaaS)
As Adé Mochtar described in his blog “on-cloud-3×3” cloud computing is traditionally divided into three cloud computing groups:
- Software-as-a-Service (SaaS)
- Platform-as-a-Service (PaaS)
- Infrastructure-as-a-Service (IaaS)
The third investigation step is to determine which cloud computing group meets the functional and possible legal requirements the best, against the lowest cost. It is advisable to start with the cloud computing group where the company has to do as little as possible, assuming that the core business is not provisioning servers. The figure below shows an overview what the vendor’s responsibility is and what the responsibility of the company using the cloud solution is. The figure shows the responsibilities that the company using the cloud solution has with:
- SaaS: no responsibilities,
- PaaS: only responsibility for the application and the data the application uses,
- IaaS: the responsibility of configuring the OS and middleware, software updates and licenses (in addition to PaaS).
Note that in all cloud computing groups the company remains responsible for contingency planning, the same way as it is for non-cloud solutions. So, for example, be aware that your cloud-provider could go bankrupt or suffer from a denial-of-service attack.
So as an architect it is advisable to first investigate the possibility of a SaaS solution, then a PaaS solution and finally an IaaS solution.
Suppose there is no SaaS solution which meets the requirements of the business, in that case you will have to look if a PaaS solution fits. PaaS platforms proscribe service limitations, runtime environments and frameworks. Important is to be aware of the risk of the potential “lock into” a particular cloud provider. It is possible to use e.g. CloudFoundry or Heroku as an open PaaS solution, which can run on different IAAS solutions. This way the risk of being locked into a cloud provider is reduced.
When a PaaS solution also does not fit, you’re left with the IaaS solutions. In most of the cases IaaS solutions give you enough freedom for meeting the business requirements and corporate principles.
Three cloud promises to keep in mind while designing a cloud product/service
Whether you build a product/service for PaaS or IaaS; if you want to take advantage of the cloud capabilities you need to give specific attention to at least the following cloud promises Elastic Scalability, Agility and SLA-driven.
Cloud environments allow businesses to serve larger audiences; solve bigger, more challenging problems; access incremental compute resources on-demand; and reduce the financial risk of new projects by starting small and growing as the need develops.
Even if the initial requirements do not specify much load, it is advisable to design your application architecture in a way that the application is scalable at all times. Technology and frameworks progressed in such a way that scalability nowadays can be fulfilled in a way that does not bring huge costs. Examples of these technologies are: stateless services, non-blocking IO, eventual consistency persistency (big data) etc.
Agility in the cloud means to be able to set functionality live, without high investments in hardware infrastructure and middleware. Deploying and scaling functionality is so fast and easy, because the necessary hardware/middleware is available on the fly. The main gap between idea and publish the idea in production, is building the product/service and testing the product/service. The focus of your architecture should be more on test automation, compared to a traditional non-cloud solution. When the product/service is in an early mature state, no manual testing should be executed before deploying new versions into production.
Clouds are managed dynamically based on service-level agreements that define policies like delivery parameters, costs, and other factors. Enterprises can so rely upon a service/application once it has been published.
Service level agreements usually also imply fixed and dynamic costs of the usage of your cloud solution. The agility and elastic scalability provides an opportunity to get better control over the costs and risks, e.g. automatic up and down scaling. Designing the architecture in a way that reduces the use of resources, helps in reducing cost. This frees up resources (like money) which benefits the overall business.
Even before the advent of the cloud, an application architecture should take requirements like scalability and availability into account. In practice this did not happen that often; “you could always change it later” (or assumed you could). However, it was never an option to ignore the ‘illities’. Choosing the cloud forces you to reevaluate your architectural design decisions and takes the opportunities and benefits of the cloud into the overall business equation.
Embrace change and, if possible, choose the cloud 🙂
Blog written in cooperation with Hans-JŠ±rgen Jacobs.