In my last couple blog posts I outlined the difference between an IT-oriented versus a user-oriented cloud. An IT oriented cloud is one where infrastructure is provisioned to facilitate the installation of the application as and when a new instance of that application is required. It consists in the automation of the provisioning of the appropriate number of virtual and/or physical machines with the right configurations and the connection of those through secured networking with appropriate storage capacity. The installation of the target application can also be automated. But ultimately you speak about the installation of an application for x users.
Let me take an example that we all know. If you are part of IT and have to provision an exchange server for 5000 users, an IT oriented cloud will do the job. It will provision the right amount of physical and virtual servers, set-up the databases, the connections between the systems and install the appropriate exchange modules in the right place.
Exchange is now available and you can start configuring users. In this case you request an application.
But what if you happen to be a manager in the business and have a new employee starting on Monday? You may want to make him feel at home in his new job by setting-up his mailbox and sending him a welcome message even before he is really onboard. You provision one mailbox. In most cases there is no need to provide more hardware, to install software, just to configure the mailbox of one user on an already provisioned environment. Obviously, if your request happens to be for the 5001st mailbox, the environment may have to provision a second exchange environment, but this hidden from you. You request a service.
Cloud Enabling Legacy Applications
Let’s now assume you did set-up a private cloud environment. The first question is now, which applications you transfer to that cloud environment, legacy applications or new developments? And it’s a real good question.
If you decide for legacy applications, you may want to think about choosing applications that will truly benefit from cloud. There might be two main reasons why an application might benefit of moving to cloud. The application may have varying usage patterns requiring quick ramp-up and ramp-down of capacity over time or the application may have to be configured for many users. The cloud may not add that much value for applications that have a stable, consistent usage.
The first can be addressed with a cloud in which you can provision applications; the second requires the provisioning of services. Let’s review at what characteristics the application needs to respond to in both situations.
I suggested it makes sense to migrate an application with varying usage patterns to cloud. Why? We all have our frustrations when an application responds very slowly due to the number of parallel requests. Cloud can address this by initiating a second instance of the application when performance degrades. Using a load balancer, requests can be routed to either of the instances to ensure appropriate response times.
Now, what I just wrote bears with it an assumption. And this assumption is that multiple instances of the application can run together without affecting the actions performed by the application. If your application is a web server, managing the display of multiple web pages, there is obviously no issue at all. But on the other hand, if your application is an order management system, things may be a little more tricky. You will need to maintain one single database to ensure all users have access to all orders in the system. So, the first question is whether your application is the bottleneck or the database. In the latter case, creating two instances of the application won’t solve the problem. You will first have to work on the database and maybe create a database cluster to remove the bottleneck. Once that is done, if the problem remains, you may look at creating multiple instances of the application itself.
Now, realize that the duplication of the application in case of increased traffic may require you have a flexible licensing scheme for the application, the used middleware and potentially the database. Ideally you would like a pay per use model in which you only pay license fees when you actually use the software. Unfortunately, many ISVs have not developed that level of flexibility yet in their license schemes.
From an automation perspective, you will have to develop the scripts for the provisioning of an application instance. Ideally you will equip that application instance with a probe analyzing its responsiveness in real time. You will then develop the rules when it makes sense to create a second instance. With that second instance will come the configuration of the load balancer.
All this should be transparent to the end-user. It’s the IT department that manages the instances created, including the automated or manual shut-down of instances when they are no longer needed.
Service provisioning requires a much greater adaption of the application. Indeed, now you expect to perform automatically a number of tasks typically performed manually by the service desk. So, the first point to check is whether a way exists to initiate the configuration transactions via API’s or any other means. Can the appropriate information be transferred to the application? Is it possible to get the actual status of the request back at completion, etc?
Indeed, to set-up the service provisioning, you will have to create a number of workflows that automate the different processes required to configure a user, to give him access to the environment, etc.
When the business user requests the provisioning of a mailbox for example, he will be asked to provide information.
That information will then be automatically transferred to the application so the configuration can take place. In return, the application will provide the status of the transaction (succeeded or failed, and in that case preferably the reason of the failure), so the cloud platform can inform the user and retain the status and the necessary information to access the service once provisioned.
What is important here is that the “services” delivered by the application are accessible. Often companies create web services to interface between the cloud environment and these applications, shielding the users from changes made in the applications. This allows them, once the application is encapsulated, to transform it and make it more cloud friendly without the user being aware of the changes implemented. You may want to think about such approach if you plan to transform or re-architect your application to make it more cloud friendly.
Obviously some applications may have both characteristics (variability in workload and user configurations), in that case both questions should be asked.
Should I start with cloud enabling legacy?
Having discussed the two key reasons why you want to bring an existing application to the cloud, the question remains, should you start with taking an existing application and transform it, or should you rather keep your legacy environments as is and surround it with new functionality specifically developed for the cloud? Frankly, there is not one answer to this question. It really depends on where your application is in its lifecycle. Obviously if you plan to replace that application in the forseeable future, you may not want to take the time and effort to adapt it. On the other end, if this is a critical application you plan to keep for quite a while you probably would. Make sure of one thing though; build any new functionality with cloud in mind.