David Linthicum recently wrote an article for InfoWorld called: Fix your applications before migrating them to the cloud where he discussed the importance of refactoring the architecture of your organization’s applications when moving them to the cloud to take advantage of the features of the underlying cloud platform. Linthicum says:
“Although most enterprises are reluctant to spend the money to redesign and rebuild applications, that fact is you’ll spend the money anyway: If you do not use your public cloud resources effectively, you’ll pay more to operate the applications. That accumulated cost is usually much higher than the cost of refactoring an application in the first place.”
It’s true that “Bad applications moved to the cloud will be bad applications in the cloud.” however the opportunity is greater than solving that challenge in our view.
Fram (the oil & air filter company) became known for its marketing slogan, “You can pay me now, or pay me later” most enterprises are reluctant to spend the money to redesign and rebuild applications, that fact is you’ll spend the money anyway. The business case is there, maybe a little foggy for some until the total cost of ownership is well understood.
In David’s article he goes on to say that most cloud providers will tell you that “lift & shift” is easy and a good idea (because it’s obviously a benefit to them) It’s true in our experience that unfortunately far too many providers have this practice.
We see our customers taking advantage of the classic “turning a problem into an opportunity” approach. Software that is designed to leverage the full extent of modern cloud (not just virtualization) technology perform better, are more secure, and cost less to run & maintain. The challenge is most organizations don’t want to pay to make that transition happen, and as a result cut budget where they really shouldn’t.
The underlying fact is that architecting applications for the cloud is fundamentally a different paradigm in software development. Here are some considerations for architecting your applications for the cloud:
Resiliency, Performance, and Security, are a function of software not hardware
Enterprises spend as much as their budget allows on high end enterprise hardware to maximize performance, redundancy and security. These organizations put the onus on the hardware layer to ensure that their applications are up and running well all the time. In the cloud, applications should be architected in such a way that the software is responsible for everything. Amazon Web Services refers to this as “pessimistic cloud architecture” that is, be pessimistic when designing your app in the cloud. Assume that things will fail. Build, implement and deploy for automated recovery from failure.
Best Practises
Decouple Application Components
Decoupling the individual components of your application is an important exercise in modern cloud architecture. Monolithic applications in the cloud expose you to risk, where all of the components of the application have dependencies on the others, the chances of a failure being catastrophic is more likely. Not only does creating asynchronous, loosely coupled systems help with uptime and performance, it also sets you up for the ability to horizontally scale individual mirco-service components as necessary.
Implement Elasticity & Automation
The API driven infrastructure that Cloud-A provides allows organizations to automate deployments of their applications in the cloud. This is an important consideration early on in your cloud refactoring/migration process, as it will enable efficient and scalable update deployments. One of the biggest features of OpenStack is that it is built on open standards, which prevents platform lock-in. Developing automation once early on in a platform agnostic way provides flexibility and the ability to migrate your applications to private clouds, public clouds or both (hybrid.)
There are many third party tools that assist with automation and configuration management such as Chef, Puppet and Ansible. More here: DevOps Tools for the Canadian Cloud
Tools for elasticity:
- Cloud-A API Driven Infrastructure
Implement Parallelization
If one server can complete a process in 6 hours, two servers can complete the same task in 3. The nice thing about cloud Infrastructure-as-a-service is that you can spin up infrastructure nearly instantly, on-demand and only pay for it while you’re using it. It is advisable to implement parallelization where it is possible when architecting an application for the cloud to disperse load, and maximize the fit of your provisioned resources.
Tools for parallelization:
- API Driven Infrastructure
- On-demand resources
- Utility billing model
- Load Balancers (LBaaS)
- Message Queueing (RabbitMQ, Redis)
Storage Option Flexibility
The cloud provides flexibility with storage backends for your applications. Cloud-A specifically offer two types of storage. SSD volume storage which can be mounted to VMs, and API driven Bulk Storage for objects which offers extremely scalable and redundant, but lower performance storage. The type of storage that your applications in the cloud uses is a very important decision to make early on in your planning. Choosing your storage backend is very much dependent on the type of the data that your application is storing, your requirements for scale and your budget.
Building Applications with Swift: The Swift Developer On-Ramp
Tools for Storage:
Moving Forward
We have laid out some important considerations for refactoring and architecting your existing applications for migration to the cloud, but we also understand that this might be disruptive and a steep learning curve. Cloud-A has developed a strong network of partners who can assist with consulting, architecture and ongoing management of your application on Cloud-A.