The future for Solution Architecture

I spend a lot of time at the moment doing things like capacity planning and telling people how many servers to put into their cluster. To my mind this sort of thing is how the world used to work and the future (looking from where we are today) is PAAS (Platform As A Service). In this blog I'll try to explain why I say that...

Platform As A Service - confusion

Lot's of people, including large enterprise companies, get confused when we talk about PAAS. There appears to be a definition emerging which we can agree on - I'll point you to wikipedia for an abstract version of that definition.  I'm going to discuss what the features of a PAAS actually mean to you and me and where it will, I believe, lead us to.

IBM PureApplication Systems v BlueMix

I take these two systems as comparables because I know them well from my previous experience. However, there are lots of solutions out there in their style. I'm going to try to explain the difference between these two systems and then declare that a variation on the BlueMix style is the future. So, here goes...

PureApplication

IBM PureApplication systems tooling allows you to, literally, draw a server architecture. The tooling allows you to drag'n'drop icons representing things such as an Application Server or a Database on to the canvas. You then press the 'deploy' button and magically (cough) that topology is created for you in a runtime environment.

As you get cleverer with the tooling you can draw lines  between those servers. Those lines represent relationships between the servers. For instance, if you have drawn a WebSphere Application Server on the canvas and told PureApplication systems tooling to deploy a specific war file on to that system; then PureApplication will check inside that war file for 'dangling' references e.g. if the meta-inf files declare that the WAR file requires a datasource to be defined and bound to it. The lines that you then draw between the WAS and the DB are resolving those dangling references i.e. telling PureApplication that, at runtime, PureApplication should create a data connector from the WAS to the DB and bind them for you.

OK, so that's cool. However, let's move on to scaling policies. As well as defining relations between servers IBM PAAS also allows you to define scaling policies i.e.  how and when to scale the system up and down. Now, let me be clear, I love scaling policies; they are making life simpler. Scaling policies are allowing me to not have to understand how to scale the server they just ask me when PureApplication should scale the specific server on my behalf. They allow me to say things like 'When the CPU has been at least 90% for three minutes add a WAS node to the cluster'. On the face of it that's quite cool. But, wait.... Let's have a think about this - how did I know that the CPU had to be at least 90 % for three minutes before it should scale. Hmm, well, I was probably a really skilled WAS administrator who had run this system and had recognised patterns of CPU behaviour. I had worked out that it wasn't e.g. the Database that was the problem but that it was the WAS that needed scaling up. I've gone from a system that took away the requirement for me to understand how to cluster WAS nodes into a system where I have to still understand when and how to get around bottlenecks and scaling issues. I am merely programming the PureApplication with my hard-won skills.

Let's compare this with the likes of BlueMix.

BlueMix

BlueMix is IBM's re-badging of Cloud Foundry. They have added to the code-base, they host it for you and they update the nodes for you. But it's not proprietary code (They may have some proprietary code in there but I believe it's still mainly Cloud Foundry). Therefore, everything I say here can be applied to Cloud Foundry.

The key thing for me about BlueMix is that I don't have to declare when to scale my system up. It will do it automatically for me. This has changed the problem of scaling from one of me understanding the problem into me having to pay IBM to find out the problem and fix the problem on my behalf. I've effectively changed the problem from being one of my time and skills into one of my money (how much can I afford to scale).

The Future of PAAS

At the moment the algorithms IBM and cloud foundry use are pretty dumb but they will improve. The core problems of scaling come when one has a multi-layered architecture. At this point the auto-scaling policies have to understand relationships between servers and the applications that are running on them.

For instance, if we imagine a front-end application running on an application server, connecting via MQ to a back-end mainframe. A dumb algorithm may just see the CPU on the MQ increasing and think that the MQ needs to scale. However, the real problem is that the queue depths are increasing which means that the application is either producing messages too quickly or the back-end mainframe application is consuming them too slowly. If that back-end application is actually not the problem but a Database that it uses is slowing it down or perhaps a network then scaling of the Application will not help.

These are all very complicated algorithms which can even change at different times during the workload. When PAAS can solve problems like those (and I'll try to blog about my experience in that space one day). then that is the future that I want.

Conclusion

The BlueMix style PAAS environment is the first generation of what I would call the smart-policy systems. It is, as far as I can see today, the beginning of a new style of platform where it's all about the code and not about the platform, the platforms architecture or the platform management. 

Yes, someone has to do that management but it's not going to be you, the guy who just wanted to get something working.