Posted by : Amber Marfatia
So, what is the difference between developing an application to a product versus developing an application to a service. Application you write
on premise is written to a piece of software purchased, installed and configured on a piece of computer hardware that you privately own.
The application you write in the cloud is written to a set of services that are available to you as well as the public to exploit.
An application written to work on-premise will work with no or very less changes even on cloud - that is what is claimed by the hosting co. but then are we really taking the advantage of cloud or are we just taking advantage of improved infrastructure?
In the cloud you have the same capabilities that you have on premise: authentication services, application services (Cache, messaging, etc.), database services, and availability services, to name a few. But you also have significant new opportunities such as ability to scale on demand and the cost benefits of pay-as-you-go on commodity hardware. If you desire you can develop your application to these services similarly to how you wrote your on-premise application and for the most part it will work.
So, let us explore which all features if taken care of or are well thought of to take true advantage of cloud infrastructure.
Maximizing the performance, scalability and manageability of cloud applications written for Windows Azure requires architecture and coding to exploit the unique features of the cloud platform. Examples include:
- Capturing application telemetry throughout your code so you can proactively react to the applications behavior in real-time.
- Exploiting scale-out of compute and storage nodes for great scale or utilizing multiple data centers for greater availability. Designing your application to grow through deploying new “scale units” (groupings of compute, storage, and database) allows provisioning for both planned and unplanned growth.
- Tolerating any single component failing while ensuring the app continues to run. The best cloud applications in the world support this but it does require you to write your application expecting a potential component failure and responding to that outage in real-time without notable impact to the end user.
- Leveraging cache for data retrieval whenever possible, and spreading database requests across a number of separate databases (shards) to support scalability and maximize performance.
So in the context of MS Azure, one can take advantage of:
- Configuration – configuration files are key to helping make management of your application seamless
- Logging – the logging of application, event and performance telemetry
- Data Access – this is actually two components: a) retry logic for database commands and connections and b) sharding using a custom hashing algorithm
- Caching – writing and reading user data into/from cache and using distributed cache for session management.
- Scheduling - background worker role to collect telemetry data every minute and move it into a custom ops database in SQL Azure
- Reporting –reporting on the telemetry collected into the SQL Azure ops database
- Application Request Routing (ARR) – technology in IIS for routing users to multiple hosted services (application workload load balancing)
- Deployment - to ensure that availability is not impacted and configuration settings are done such that deployment does not need code changes.
- Security for data and application separations by adopting appropriate patterns.
One can think of following as thumb rule for best practices:
- MVC 4.0 web application providing scalable user registration and login against a shared database with distributed cache integration
- Multi-cloud service deployment, using Application Request Routing (ARR) to transparently leverage multiple cloud services for additional scale and reliability
- Query-able operational data store, with scheduled tasks for collecting and integrating application and server performance/health metrics.