Over recent years, major software developers have started offering their applications in the cloud. In the cloud model, instead of selling their software, they’re simply charging customers based on usage, turning themselves, to some degree, into utilities. The promise to customers is easy scalability and low infrastructure cost. The promise to the software companies is both a chance to upgrade their offering at any time and to make those upgrades immediately available.
This pay-as-you-go model also allows enterprise developers to reduce their capital expenditure (CAPEX) on building data centers without reducing their ability to innovate and come out with new offerings. And in the current troubled market condition, it allows organizations to pay for actual usage rather than build to handle the worst-case usage scenarios as most data centers are today. For the developer, potential cloud platforms include Salesforce, Amazon, Microsoft’s Windows Azure, Google’s App Engine, IBM’s DB2 on Demand, and VMware. Smaller companies are emerging to simply the management process and provide easy scale up and down based on market needs: RightScale, FastScale, and CA’s Spectrum Infrastructure Manager.
But we haven’t yet seen similar investment in the applications frameworks and development tools. If we expect to see the current cloud infrastructure filled with applications and being used to the max, we need to see developers building new apps for the cloud and porting over existing apps. So why are developers stalling?
Here’s an overview of some key difficulties they face when moving to the cloud:
1. If you’re an application provider, your customers expect to be able to run your applications on many different platforms, whether on a departmental server, an array of blade servers in the data center, hosted with external on-demand data center provider, or on one of the market’s cloud offerings. Unfortunately, clients assume any application they buy into should be able to support those multiple target run-time environments, but the reality is that those different platforms have different characteristics. You can’t simply write once and deploy anywhere. For example, if you want to move your app from a Microsoft-based server to the Google App Engine, you’ll probably will end up with a complete rewrite of your application.
2. The next issue is how the new cloud paradigm, tools, and application programming interface (API) blend with a software developer’s internal technologies and skills. Starting with application modeling and prototyping tasks, all the way to the deployment and maintenance phases, it’s critical that whatever platform a development company works with internally can also support the development, deployment and management of the cloud application. If not, developers may be forced to turn to ad-hoc alternatives that could end-up requiring additional expensive investments.
3. We cannot omit the skills issue. Assuming enterprise developers today are heavily invested in .Net or Java, do we expect them to learn new development language and frameworks, like the current proposal from Google App Engine that expect developers to write with Python (some support for Java as well these days, with promises to expand support for Java and other languages) or to learn new frameworks like Ruby on Rails? Or should they continue to develop using existing skills in .Net/Java platforms?
4. Another looming question is, how do you leverage investments in existing interfaces, user experience, data structure, and application logic when moving an app to a new platform? Is it possible at all, or does the existing application have to be completely rewritten? Alternatively, does a developer give up on the efficiency that’s being offered with the promise of cloud computing?
5. With optimization, can a software developer’s application framework take advantage of the run-time environment to run natively and connect natively to the different cloud services? Or do will the app just run as an isolated instance on a shared infrastructure with an optimized billing mechanism?
6. What would be the operational costs of an application in the cloud? Does the development company have tools to asses those costs? Can it minimize the amount of bandwidth consumption in order to lower its runtime fees or make sure it serves the largest number of concurrent users on lowest costs?
7. With regards to the discovery of the different cloud providers’ API and services, are those automatically discovered, or should developers assume they need to develop their own calls for each service, using different API’s syntax?
8. Lastly, there’s the question of flexibility and transparency. Developers may like to realize the true economical benefit of the cloud and move their application from one platform to the other without the need to change any line of code. We need to push for true abstractions of proprietary interfaces within the standard development platforms.
The quest for a true cloud application framework, open enough to allow developers to make full use of existing code and skills, is probably at its infancy these days. But the requirements are clear, and once they’re met, we’ll see more developers step forward and invest in developing and migrating new and existing applications to the cloud to cut expenses both for themselves and for their customers.
In addition to my company, Gizmox, there are a number of other players working on solutions of various kinds, including Potix, which is trying to devise a solution for the Java-based community (where Gizmox focuses on the .Net community), and Appcelerator, which provides a bridge between web development skills and the enterprise market.
No comments:
Post a Comment