How might the role of QA change in hybrid cloud architectures?
To set the context, let us first define a hybrid cloud architecture. To us, a hybrid cloud architecture implies the following:
1 – Micro processes & functionalities are managed by distinct solutions ( workloads) on public and private clouds
2 – These processes interact with each other via RESTful web-services / API’s
3 – A significant % of processes are managed by solutions that are hosted on public clouds ( proprietary clouds such as Workday / Salesforce cloud or virtualized clouds such as cloudfoundry/AWS etc )
A transaction, by corollary, is an orchestration of these micro-processes linked via web-services /API’s.
How does this matter from an assurance perspective?
1 – A primary issue to consider is change management. By their very nature, release complexity in hybrid cloud architectures is significantly increased by the need to plan multiple release windows catering to the release schedules of the solution vendors.
2 – Next, is the complexity of having business users make rapid set-up and configuration changes to support their ever growing business needs.
3 – A third layer of complexity is added by extended use of mobile apps for consuming some of these micro processes, all configurable services and not using the web as the primary medium of interface.
So what gives?
Traditional QA is focused on functionality and fit for use. In a hybrid cloud architecture, a significant onus for functionality and fit for use will be handled by the solution vendors themselves.
A critical aspect that needs to be considered is that process flows( & by corollary transactions) are accurate and timely (within SLA) 100% . Hence, process assurance.