Suddenly the cloud happened. OK it wasn’t that sudden, but the discussion points that surround the now much-debated issue of migration to the cloud appear to initially concentrate on what we might consider to be more ‘surface level’ issues such as compliance, security and cross-platform cross-device delivery.
But these challenges are technical trials in their own right. For us to consider these as surface level concerns then surely we need to go one-step deeper and one louder up the developer’s scale of granular application integration issues.
Blind faith playing with fire
Any assumption that the "write once, run anywhere" adages of old will extend fully to the cloud’s service-based model of computing delivery are nothing more than a combination of blind faith playing with fire.
So is it simply a case of wrapping a cloud-compliant shell around applications so that they can still function and breathe at 40,000 feet? Or is there a more pressing need to rewrite, recompile, remodel, restructure, re-architect and redeploy our applications to the SaaS model?
We know that some cloud computing progression will not involve migration as such, ie the more flexible working model of processing and storage capacity creates an opportunity (an almost incumbent responsibility if you like) to ‘innovate’ rather than migrate – and it is at this point where new completely applications may be born unto the world.
But what about integrating physical applications with cloud-based services – where should we start?
Companies such as Virtustream talk about the possibility of taking physical applications to the cloud without rewriting them. "Over 80 per cent of the world’s business applications are legacy-based today, written before virtualisation and the cloud, and as a result fear has been preventing many businesses from migrating their applications to the cloud. Virtustream can use its patented micro-VM (µVM) technology to wrap around legacy application and even assure cloud performance, without the need for re-writing them,” said the company’s CEO & CTO Kevin Reid.
"Fear over where data is ‘up there’ and concerns of being in breach of compliance still holds people back, but we can identify where all data is, down to the node and spindle as well as offer commercial SLAs on based on workload performance,” added Reid.
But this statement sounds like a strange claim to make doesn’t it? ie 80 per cent of the world’s business applications are legacy-based. Surely 100 per cent of the world’s business applications are legacy-based!
Legacy software is just software that still works after all. Regardless, there are some more fundamental considerations for applications being integrated into cloud services that we need to address first.
Cloud is the web
Despite the promises of the shrink-wrapped automatic application migration specialists, if a cloud application is to truly flourish and operate at 100 per cent of its potential workflow capacity then it needs to be engineered for the cloud environment it will be housed within. To clarify, considerations of platform, language, database and more now come to the fore.
Does your company’s chosen cloud environment and hosting provider predominantly support .NET, but you are faced with a challenge because the majority of applications to be migrated happen to be Java-based? This is not ideal. But over and above questions of platform or even whether a particular application’s database is supported in a new cloud migration, there are application ‘controls’ that can make cloud application integration troublesome.
It is important to question what kind of management and/or monitoring tools any given enterprise-level application will use. Remember, the cloud is the web and this means that web apps will always work best in the cloud. There is no carte blanche guarantee that any single app monitoring tool will integrate seamlessly to the cloud.
Surely then we should view cloud application migration and integration as part of the initial cost of a cloud deployment right? Microsoft is it pains to explain its Azure rating structure saying that, "Pricing an application for Windows Azure depends on a number of factors such as the network traffic load, input/output characteristics of the application, and volume of data processed to by the application." But the company also goes on to specify that when calculating the cost to your organisation; remember to include direct Windows Azure costs during development and testing.
So logically (I hope you feel this is concrete logic) we move into the realm of ‘enhanced’ and ‘advanced’ cloud toolset technologies. For some application builds, a (comparatively) regular migration may be on the cards. But in the many coloured world of cloud application tools, we find that (at the high end) scope for advanced application and database services does indeed exist.
Xeround cloud database for MySQL-based applications is available through one such enhanced offering: the Rackspace Cloud Tools Marketplace. This is a catalogue of third-party developed applications available for the Rackspace Open Cloud. According to a news statement from Xeround, through this marketplace customers can browse, review and connect to cloud solutions focused on management, monitoring, application deployment and a host of other areas.
The holy trinity of cloud migration
Although somewhat corporately-tuned and polished in terms of press statements, Xeround CEO Razi Sharir describes this July 2012 announced delivery option as, "A robust solution for running MySQL in the cloud with no installation, configuration or management overhead.” Corporately-tuned and contrived or not, Sharir’s mentions three crucial factors here ie installation, configuration and management, surely the holy trinity then of cloud migration.
So can we move onward from this holy trinity if we list ourselves as true believers to this creed? The fact is that a firm’s business processes will almost certainly change once a cloud migration has been undertaken. Some for the good, brought about as conscious improvements that were identified before the physical applications in question were identified as potential cloud candidates. But some for the not so good, or at least some for the different; however, Business Process Management (BPM) in the cloud is another subject for another day.
Forget the apps, it’s all about the API
As the on-demand service-based model of computing takes hold on business, the question of what app is brought to bear when and where is still important; but it is not as important as the question of which API (Application Programming Interface) is available when so that cloud apps can indeed talk to each other in a way that is compliant, clear and above all platform independent. In the world of cloud, platform-specific equals platform horrific.
Diane Mueller is a cloud evangelist at ActiveState working on the Stackato enterprise private PaaS Platform. Mueller asserts that there are in fact no formal standards describing cloud interoperability - specifically, an application’s migration requirements. She sums up the programmer’s predicament in a way that even the non "dependency and scripting" aware CIO/manager will appreciate…
"There are some standard practices (like adding a "requirements.txt" file containing modules and packages lists to the app root), but they do not offer enough detail about data services and cloud-configuration dependencies that your app will require to scale securely and run on the (new) cloud. Several cloud-orchestration and scripting approaches - such as Right Scale, Enstratus, Dell Crowbar, Puppet, Chef - ease the burden of repeat deployment to the same cloud, but no equivalent models exist for porting an application to a new cloud model,” says Mueller.
So then as much as we find movements like OpenStack and CloudStack striving for open source flavoured open standards in cloud computing, as we said at the start, these initiatives do not (at this stage at least) offer enough insight into cloud portability and the integration of physical applications with those in the virtual space.
From this point forward it is going to take more than steering committees, special interest groups or even industry consortiums backed at the OpenStack level. The industry will follow success in best practice as defined by software application developers themselves; so there is indeed an opportunity here to do this right – we’re just not sure when it’s going to happen.
