Heads in the cloud today

I heard a comment a couple of days back saying that the performance testing will die because of the cloud. Theres a couple of things with this - but, before I get to them I will put some cards on the table. I'm a performance tester so I obviously have a bias for my profession. Secondly, I don't hate the cloud. What I can't stand is cloud sales people saying that its going to solve every and all peformance, capacity, and scalability problem.

So:

1. Bad software is bad software no matter how much cloud compute you throw at it. You really think that full table scan is going to be fixed by adding another 4 cloud servers? How about adding another 40GB of heap to your JVM and provisioning more virtual RAM to get around that frequent and nasty full gc problem you're seeing? Cloud is not going to help in those situations.

2. How's your network infrastructure? Do you have enough capacity accross you net facing infrastructure? How's your firewall capacity looking at the moment?

3. Business systems do not scale linearly. Adding more cloud capacity will eventually hit the point where you are either paying for ever diminishing returns - or you get to the point of retrograde performance, and you might not realise until its to late. Lets say we have a system where 5% of the code needs to execute serially - i.e. its waiting on IO, a database lock or something else...what impact does adding more cpu have? Well, not as much as you might think :

Thats using Amdahls law, assuming a fixed problem size where a portion of the code must be executed serially (i.e. we're waiting on a database lock). Gustafsons law is much kinder to us because that assumes that the parallel bit of the system scales linearly and the serial part does not increase with the increasing size of the problem. So far, what I've seen in business systems are those that scale in accordence with Amdahls law - or worse the universal scalability law which is when you try the 'add more cloud' a system that needs to synchronise shared states. The the more parallel resource you add, the slower things go because we are now having to maintain state (crosstalk) accross n(n-1) things as well as having a serial bottleneck (contention).

4. Are you integrating with on-prem systems at all? If so how? APIs perhaps? Thats great! But have you considered that a new point of loading has been introduced which is probably quite different to what has been previously encountered (also, how sensitive is this to latency?)

5. What are you moving up to the cloud and what sort of resource is it expecting? Deploying your application and web servers - sure ok. What about something like batch processing though which requires fast access to IO and a decent chunk of CPU? When do your batch processes fire off exactly? After all, the cloud is basically "someone elses computer" so you might need to buy some dedicated provisioning to ensure that your batch process that absolutely positively needs to finish on time isn't running concurrently with peak processing for another one of the cloud providers clients. How much does that dedicated ultra super diamond encrusted platinum hosting cost by the way?

The cloud is not a bad idea, what is a bad idea is having it seen as a panacea for all of a systems performance problems through the simple expediency of adding more 'cloud'. If more resources were the solution to performance problems, the role would have become extinct before it even was a thing. For certain workloads it provides an excellent cost effective solution. Its not the death knell of performance testing though.