Architecture for the Cloud; Tips to Build and Deploy Your Cloud Based Applications
The cloud and cloud-based solutions are here to stay. This will continue to drive business solutions for a long time. Why? Clear and measurable benefits below i believe are the top 4 reasons :
1. Almost zero upfront infrastructure investment
2. Just-in-time Infrastructure
3. More efficient resource utilization
4. The possibility of usage-based costing on your back office applications
Cloud is a disruptive force. However, the cloud’s “Achilles heel” is a lack of integration with the rest of the enterprise. Realizing its full potential relies, for the foreseeable future, on integrating data in the cloud with on-premise applications and databases.
Today’s enterprise cloud initiatives require decoupled data systems working together , without the need for personnel and other resources to set up and maintain them , making integration key to a successful deployment.
Most companies cannot and will not abandon their previous IT investments to make the leap to the cloud all at once. Instead, there is more likely to be a gradual shift in business processes to the cloud over time, similar by nature to a perpetual proof of concept.
As the cloud delivers on its promise, more processes will be shifted to this computing model. Complexity and diminished ROI will be the consequence when long-term strategy and goals are not implemented in advance. Put simply: integration needs to be a forefront, not on the afterthought of your project strategy.
Always design for failure, be a pessimist when designing architectures in the cloud; assume things will fail. In other words, always design, implement and deploy for automated recovery from failure.
In particular, assume that your hardware will fail. Assume that outages will occur. Assume that some disaster will strike your application. Assume that you will be slammed with more than the expected number of requests per second some day. Assume that with time your application software will fail too. By being a pessimist, you end up thinking about recovery strategies during design time, which helps in designing an overall system better.
If you realize that things fail over time and incorporate that thinking into your architecture, build mechanisms to handle that failure before disaster strikes to deal with a scalable infrastructure, you will end up creating a fault-tolerant architecture that is optimized for the cloud.
Questions that you need to ask: What happens if a node in your system fails? How do you recognize that failure? How do I replace that node? What kind of scenarios do I have to plan for? What are my single points of failure? If a load balancer is sitting in front of an array of application servers, what if that load balancer fails? If there are master and slaves in your architecture, what if the master node fails? How does the failover occur and how is a new slave instantiated and brought into sync with the master?
Just like designing for hardware failure, you have to also design for software failure.