Moving applications to the cloud is where things start to get interesting. That’s because applications designed for traditional IT infrastructures are fundamentally different than those designed for cloud. After all, cloud isn’t just cheap virtualization. Applications really need to be re-architected for the cloud, otherwise all of cloud’s benefits won’t be realized.
Commercial, off-the-shelf applications and traditional, legacy applications are tightly coupled to the infrastructure on which they run. Web services, for example, are hard-coded to the database servers. The upside is that transactions will run really fast. But if any component breaks, of course, the whole application will go down. That’s why there are a lot of redundancies, multiple clusters, etc.—all of which are expensive.
Cloud, on the other hand, has a very different design philosophy. Applications written natively for a cloud are loosely coupled. A web service doesn’t have to be directly connected to a database server. Instead, it can be connected to a message bus. Red Hat, by the way, offers its JBoss A-MQ, a standards-based messaging platform that enables enterprise applications to exchange information. By loosely coupling the applications to databases and using a message bus, if there’s a failure, the message bus will continue to try and deliver its “message,” a mechanism that lends itself to capacity on demand. Of course, this can slow down performance, but there’s always an opportunity to tune the infrastructure and improve the performance. Just look at Google. It is ridiculously fast.
Commercial, off-the-shelf applications typically don’t understand “loosely coupled.” But that doesn’t mean organizations should avoid moving to the cloud. I suggest starting with those applications that are typically better equipped for virtualized environments, including Web services and presentation and front-end services. Once those are done, organizations can begin reworking traditional apps that aren’t cloud-ready.
In addition, it is important for the IT department to recruit people from multiple teams: networking, storage, application development, even specific business units. Reworking the application architecture requires collaboration.
By the way, this is a follow-up to a previous post I wrote, – Determining the right foundation for a successful OpenStack cloud. Share your best tips for determining the right foundation and application architecture for OpenStack in the comments section below!