The Cloud Flavor Trade off from a Business Quality Attribute Perspective.

Cloud platforms offer many different ways to implement and support business functionality. This business support is the ultimate goal and is leading in how guidelines and rules apply to the implementation choices of cloud solutions.

Business support needs of systems are described in functionality and quality attributes. Both influence the decisions what and which cloud platform, service and implementation to select.

There are many quality attributes for systems, this list and the severity vary per system. A common list of quality attributes is:

• Availability
• Scalability
• Agility
• Interoperability
• Maintainability
• Manageability
• Performance
• Reliability
• Security
• Modifiability
• Testability
• Deployability ( twelve-factor methodology )
• Recoverability
• Portability
• Billability (Pay per efficiency)

Per cloud category (IaaS, PaaS, SaaS) the support for these quality attributes differ.

When these cloud categories are mapped to amount of support on these quality attributes an overview can be made on how much effort it will take to realize a certain level for this quality attribute. With a certain bandwidth because there are other decencies.

With an overview of the effort, it will take to realize a certain quality attribute for the different cloud categories a tradeoff can be made what to select for a cloud system. And, while many cloud systems are a blend of categories, an overview on which parts of the system more effort needs to be taken to realize the same quality level.

Next to IaaS, PaaS and SaaS there are more categories. Containers, Azure Service Fabric and Cloud Foundry are technologies which require a host to make their capabilities to systems available. Another category is the Serverless systems, like Azure Functions and AWS Lambda.

Let’s look at them through the eyes of business quality attributes.

Availability.

Availability defines the proportion of time that the system is functional and working. It can be measured as a percentage of the total system downtime over a predefined period. Availability will be affected by system errors, infrastructure problems, malicious attacks, and system load.

IaaS, realize a certain level of (High) Availability with IaaS takes some effort. The network needs to be setup, load balancers, multiple VM’s, loads of ground work. It is interesting to look at these ARM templates for High Available NodeJS cluster, MongoDB or Redis Cache servers.

For Containers availability is easier as IaaS, assuming the container host is already in place. The network, load balancer and all magic what needs to be done to get availability for IaaS is in the container host. Adding more of the same containers will make the system more available, with the benefit of only partly upgrading the availability. But, there goes some effort in the controlling and making these additional containers to run and to get the host and its maintenance components high available too. See High Availability Architecture and Apps with Docker Datacenter (DDC)

Azure Service Fabric comes with high availability out of the box, also when the host is already there. Service Fabric is an orchestrator of microservices across a cluster of machines. The Service Fabric cluster contains all the infrastructural needs for high availability, like the load balancer and multiple VM’s. The orchestrator will manage the lifetime and health of the services in the cluster.

Cloud Foundry can be compared with containers from an ‘effort availability’ perspective, add more of the same apps will make the system more available. CF comes with default capabilities for managing instances, tools for availability. The CF Health Manager takes action when instances die, availability zones take care of the traffic and more. This makes orchestrating the instances easier. Read: The Four Levels of HA in Pivotal CF.

For PaaS, the effort to implement High Availability differs mainly on what PaaS service is consumed. The most common PaaS services for running Web or API applications have capabilities out of the box for High Availability. It is often only a matter of configuration to make a PaaS offering scale automatic (Configuring Auto Scaling with Elastic Beanstalk). For recreating failing instances, auto healing or disaster recovery of instance some more effort needs to be taken.

Azure Functions, AWS Lambda, Google Cloud Functions are Serverless platforms. As Aws mentions, “Just upload your code and the Serverless platform takes care of everything required to run and scale your code with high availability”. No additional effort needed. Monitoring of functions does require some additional effort, not for the underlying platform but for the functionality the functions support.

For SaaS offerings, Availability depends strongly on how the SaaS offering is hosted and what are the offerings, the SLA the SaaS provider offers. So no effort to change the availability, although some SaaS providers offer capabilities to influence it a bit. For example, the CDN and Express Route configuration option for O365.

Notes:

• A system will not exist of a Serverless platform only.
• There will be a blend of IaaS, PaaS and probably SaaS for systems.
• The ‘hosts systems’ do require their own availability settings, which takes effort too.
• …

Security.

Security will always be a big effort for systems, no matter what cloud category.

From a security perspective, IaaS surrounded with traditional networks for security can be of a good security level. There is a lot of experiences how to configure this kind of environments. Compared with cloud-native systems like PaaS and Serverless where ‘no network’ is the default, the effort is lower.

Cloud native systems require a different kind of security via authentication, encryption, and other technologies. For example, when making the connection between a WebApp and a Database secure, username password with https isn’t enough. Authentication of access by the App via Active Directory with certificates and an Azure KeyVault is more secure but also require more effort to accomplish.

Modifiability

An important quality attribute for cloud systems, most companies adopt the cloud to gain more flexibility, more capabilities for change. How much effort will it take to change the implementation, make new capabilities available according to the business needs, and adopt new cloud capabilities quickly

For sure it depends highly on the type of capability and implementation, but when looking at the deployment capabilities, rolling forward and zero downtime upgrades there can be made a differentiation between the categories.

Billability

Costs, how efficient is the system billed (not effort to take to pay). The big differentiator is the flexibility of the pay per use support within the different categories.

For IaaS, machines can be shut down, manually or automatic when not used. Putting them in an idle state with lower costs.

For the ‘host required’ cloud categories the pay per use scenario isn’t that efficient. The host will always be there, with the surrounding support tools, no matter how many containers and services are hosted. When looking at a default Cloud Foundry instance on Azure which contains 50 cores this efficiency is pretty hard to reach with smaller systems. Service Fabric requires at a minimal 5 VM’s.

PaaS and Serverless are really adopting the pay per use efficiency. Where serverless is even more efficient with the pay per execution, while PaaS often has a continues running component.  SaaS is a completely different league in this area, although it depends on the offering. A pay per month license is most common.

Portability.

How easy can business functionality be moved from one platform to another? Sometimes needed for failover, often for the good feeling of not having a vendor lock-in.

IaaS runs on every platform, the platforms exist out of it. Portability between platforms should be easy for functionality hosted on IaaS. Copying or provisioning a new IaaS instance on the different cloud platform, with the proper automation, should be done in seconds. The challenge is the surrounding configurations and dependencies. IP addresses, networks, connection strings and databases make the portability a bigger effort.

For the ‘host’ cloud categories portability is baked in the system. Cloud Foundry is built with it in mind. Just make the host available on another platform and copy past, redeploy the containers and services on the new host. While the hosts are all built on VM’s this shouldn’t be hard. Still some network address effort to do.

The additional arrow for the host categories visualizes how much effort it will take to move to either another host system (from Service Fabric to Containers) or from host category system to cloud PaaS (Cloud Foundry to PaaS). The effort is harder as moving IaaS and as PaaS due to the dependency and used capabilities of the hosts. For containers to IaaS, the effort will probably be lower because the container is an OS like a VM.

Serverless is probably very hard to port to other platforms. Although AWS Lambda offers Node.js, Java, C# and Python as a language to run the functions and Azure Functions .NET, PHP and NodeJS, but the triggers, connections, scaling, monitoring etcetera are that tight to the platform the moving from AWS Lambda to Azure Functions will probably result in a rewrite (never tried it).

PaaS offerings are supporting many programming languages, which makes them more portable as often expected. With Microsoft joining the Linux Foundation and Google, Samsung the.NET Core foundation write once run everywhere is very close. A .NET Core application can run on any platform, the same as a NodeJS one. This results for example in API’s which can run on any platform consuming any backend and exposing their methods on any gateway.

New solutions for any developer, any app, and any platform.

The Tradeoff.

What Cloud category to choose for your system. The tradeoffs are difficult to make. One important note is that probably not the cloud platform choice you make will be leading in the success in getting the agility and innovation the business wants, but how people are working together on the result and are able to release the system and follow the 12-factor app methodology. This together with the architecture of the whole system (probably in services) will be big influencers of the success. (see: Stay Relevant).

• IaaS takes a relative big effort to setup, use and evolve. IaaS isn’t really cost efficient, although switching on and off VM’s and creating new VM’s on the fly is getting easier as cloud platforms evolve. Azure added an easy scheduling mechanism behind every VM within Azure, for teams to use and be cost efficient with IaaS. Adopt IaaS only when all others are not viable, maybe due to security considerations or due to old box software which can’t handle another cloud offering.
• Platforms which require a host to run, for example, Docker Host, Azure Service Fabric Cluster, and Cloud Foundry Bosh, have the benefit that when the host is available on multiple Cloud Providers or On Premise that the system can be ported to another location. This makes the development, test flow very easy and gives the business a less vendor-lock-in feeling. A drawback of host-based platforms is the cost efficiency of the host, that piece must always be there, must be on and must be operated and maintained.
  A host does bring additional specific capabilities to the platform it runs on. An Azure Service Fabric Cluster brings the specific capability to orchestrate state full and stateless services in a reliable way. Docker the distribution, re-use and scaling of containers and Cloud Foundry brings easy provisioning, operation and monitoring of IaaS and PaaS services to platforms. This specific capability again also has a drawback, it is harder, maybe impossible to port the business functionality to another platform without the host.
  Host-based cloud platforms are only interesting when the needs (and finance) of the business system fits the specific host provided capabilities. Take a close look at them when the effort it takes in plain cloud platform to fulfill the quality attributes the business system require.
• PaaS (and Serverless) are rich serveries with many capabilities which fulfill many quality attributes for an efficient pricing model. The growing amount of PaaS services offered by cloud providers makes it possible to pick and choose the best service for the business system needs. Security requires with many PaaS services a bigger effort due to the no-network principle. The possibility of the most common programming languages to run on any platforms, makes a portability easy, although it depends strongly on the PaaS service used, for The Web, API and worker processes it is easy.
  PaaS solutions are a good choice to start with. They are cost efficient and due to the richness, they often require a low development and operational effort.

Disclaimer.

I’m not an expert on all platforms. I could have missed an important quality attribute which shines a new light and brings some other thoughts. Please add a comment when I need to add one. Also, when you think a thought is a complete wrong, an arrow should be lower, higher, smaller, wider add it as a comment.  I’m also curious if I need to add an additional Cloud Flavor.