I want to talk about cloud, this is rare for me as I normally hate to talk about the cloud (we'll leave that discussion for another day). What I would like to look at specifically is how to help move existing applications to the cloud.
For some existing workloads moving to the cloud is hard, regardless of if we are moving to IaaS
. One of the reasons this is hard is that we have a lot of complexity and steps to get this applications deployed and running. To compound this the steps are intimately tied to the infrastructure landscape the app is deployed to. So it makes perfect sense that changing that infrastructure landscape is hard, full of risk and something organizations can try to put off.
We can start to solve this by using a Application Release Automation (ARA) tool, if we choose it carefully. An ARA tool primarily helps us put applications components and configuration on to targets, this can be binary code, connection configuration, database updates, queue definitions, web service end points etc. It doesn't really matter the particular type of components right now, just that we have them. So the idea starts with our tool; we set this up so it can install our application to its current target environments automatically. In pretty much all ARA tools we will do two things to make this happen:
- Define our application in the tool, usual we have a package for each version of the application. This will contain all of the artifacts and also confutation items to make the application run.
- Environments where we can deploy these application packages too.
Once we have done this we can deploy our applications to the environments. Certainly with a model based ARA tool, such as XL Deploy
we don't need to perform and specification of the "how". As long as the application and environment components are supported XL Deploy will take care of what steps it has to take and what order to run these in. (If there are unsupported components XL Deploy is based on a plugin architecture and is easy to extend, this tutorial gives a good overview
). This is a key first step, if we are going to move a workload to the cloud, a workload where deployment methodology is tied to the target environments we need to decouple that, implementing model based deployment automation helps us with that.
So our second step is to move to the cloud, but we need to think about how we want to do that, all at once or piece by piece. The nice aspect of this type of automation is that is supports a number of different use cases. We could start by just moving some specific aspects, maybe we start very small with static web content and our front end web servers. A model based ARA tool supports this with no problem, it doesn't really care if the targets in an environment are on premise or in the cloud. With XL Deploy you just need to be able to interact with this target somehow, so SSH, WinRM, any web service flavor, etc. We don't even need to define a new workflow or steps for this, the tool takes care of the changes and figures out the new deployment plan. Of course we can go big bang to and move the whole app to the cloud if we want.
Quite rightly, deployment issues are one of the items we need to solve on a journey to the cloud, among many others I've consciously ignored here. But solving the deployment issue shouldn't be difficult and implementing tooling to help with this will have benefits without a cloud move. Example general benefits of ARA are quicker and more reliable deployments, full audit trails, resistance to application and environment change. XL Deploy is an ideal tool to implement for this precisely due to the model based approach, we can change environment or application without having to change a workflow, and if we can do that it makes it much easier to see the cloud as just a different environment and not a scary whole new world only for new applications.