Architecting Enterprise Applications for the Cloud – Learning the New
Whatever one may define Cloud and associated IT machinery involved as, Cloud Computing is here, well settled! Its impact resulted in financial models that balance between Capex and Opex, and more importantly in business models which allow organizations to restructure themselves by expanding beyond their pre-set boundaries and creating finer and innovative connections. However, in this post, I’d like to cover more on the impact of Cloud on existing technologies and what we, as architects, should consider.
Architecting for enterprise applications typically meant taking non-functional requirements (NFRs) such as scalability, availability, security, performance, maintainability, etc. into consideration. With Cloud coming into picture, I see a lot to learn in each of these fields and more.
Before getting into what that can be, I just want to recap that Infrastructure-as-a-Service (IaaS) provides outsourcing the infrastructure whether it be for development or production, Platform-as-a-Service (PaaS) provides for hosting platform-specific applications and Software-as-a-Service (SaaS) provides for “product-services”. Scope of enterprise applications include mainly those built for IaaS and PaaS, which will be the scope of my discussion here.
Though IaaS-hosted applications still need to be architected for NFRs as non-Cloud ones, there are additional factors that need to be taken into account. Though application architecture itself may not have a huge impact, dynamic provisioning and load balancing of Virtual Machines (VM), native high availability, VM crash/restart mechanisms can be taken advantage of, i.e., these are generally provided by the Cloud provider.
Network architecture is an important aspect that is affected for IaaS-hosted applications, particularly in hybrid solutions and will need to be reviewed. We also need to look at deployment architecture changes. For e.g., a database server, in an on-premise setup, may be well behind a DMZ or a second firewall, whereas it may be directly accessible on a public Cloud, hence, needing additional thought for security.
Architecting for or migrating to PaaS-based platforms has many more implications. First, the platform itself is most likely to provide native API support for various functions beyond what an IaaS provider does. Minimal effort is involved in architecting for scalability. It is great to note that applications will be able to inspect the platform environment for performance and scale automatically.
They may utilize service management and monitoring API rather than having to build from scratch. They may also take advantage of various other PaaS services, such as security services, storage or caching services, Content Delivery Network (CDN), and so on to build on. However, we must take much more care in architecting solutions around such services as they are much more de-coupled than in a typical on-premise system.
PaaS based services also push for enhancing existing architectural styles or bringing in new ones. They also act as drivers for new design patterns. For instance, to me, four maturity levels of SaaS were pretty sacrosanct. However, with native scalability of platforms like Windows Azure (and this is quite valid with other platforms), SaaS maturity level 3 which assumes that tenants share a single server, seems invalid on PaaS Cloud!
One more key aspect architects need to address is the thinning boundary between deployment and development. Development teams now have much better understanding of and access to the infrastructure since the infrastructure attributes of IaaS and PaaS are clearly published.
Finally, most of the Cloud providers charge us on rented services, based on say, size of a DB, number of transactions, etc. Hence, architecture should also address keeping the overall cost of the solution low. A few examples include merging presentation and services layer of a web application (since it can anyway be scaled out) to reduce instance count or choosing an inexpensive non-relational storage, as against expensive Cloud-RDBMS, for non-transactional data if possible.
To summarize, architects need to review various aspects when architecting for Cloud. Secondly, PaaS-based applications have other things concerning us when moving to Cloud than IaaS based applications.
One Response to “Architecting Enterprise Applications for the Cloud – Learning the New”