8 roadblocks software developers face

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.

Oracle’s Sun Deal Snagged in Brussels

Summary

Across the tech industry firms that used to have business alliances are now in competition and the courts are starting to step in. With the Oracle and Sun deal, it's interesting that in the U.S. the hurdle was Java, a main reason for the Sun acquisition and a product that many Oracle rivals use. In Brussels, the issue is MySQL and Oracle's the database software business and the fear that Oracle has little incentive to continue developing a product that could be disruptive to its core business.

Analysis

The tech industry is facing many hurdles as companies that used to have business alliances together are now competing in various parts of their business. And, as companies look to acquire other companies, the courts are starting to hold up the process as they hold off on their approval.

In the case of the Oracle and Sun deal, it's interesting that in the U.S. the hurdle was Java, the programming language and software development tools that are controlled by Sun and which Oracle has singled out as the main reason for its acquisition and a big issue was the fact that Oracle's rival IBM is a big user of Java.

In Brussels, the issue seems to be around MySQL and Oracle's the database software business because some Oracle rivals claim that the software maker would have little incentive to continue developing a product that could one day prove disruptive to Oracle's core business.

While all this is going on, Oracle is making inroads into the hardware business which is an area they traditionally haven't been in before. While the proposed $7.4 billion takeover of Sun Microsystems is uncertain amid antitrust scrutiny, Oracle Corp. is moving ahead with a new database machine incorporating both Oracle and Sun technology, and is no longer making database machines with Hewlett-Packard. (The earlier version of the machine was built by Oracle and Hewlett-Packard Co. and when it was introduced last year marked the first time in Oracle's history that the company sold computer hardware.)

Are the courts right to step in? Maybe and maybe not. I'd argue that you should let it all shake out in the industry and that some competition is good. Acquisitions are hard to implement as company cultures collide and channels to market need to be retrained. I find it most interesting that different courts are getting hung up on different parts of the business.

Google Noop project features JVM-based language

Noop language project is intended to encourage industry best practices and discourage 'worst offenses'

Google is hosting a language project called Noop, which initially targets the Java Virtual Machine and is intended to encourage industry best practices and discourage "worst offenses."

Noop is pronounced noh-awp, like the machine instruction, the Noop Web page says. It is in early stages of development and is being worked on by people within Google and outside of Google, a Google representative said.

[ Check out InfoWorld's report on different languages for the JVM. | Keep up with app dev issues and trends with InfoWorld's Fatal Exception and Strategic Developer blogs. ]

"Noop is a new language that runs on the Java Virtual Machine and in source form looks similar to Java," the Web page says. "The goal is to build dependency injection and testability into the language from the beginning rather than rely on third-party libraries as all other languages do."

In addition to dependency injection, Noop favors testability, immutability, readable code, properties, and strong typing. It also endorses executable, up-to-date documentation. "Dependency Injection changed the way we write software. Spring overtook EJBs in thoughtful enterprises, and Guice and PicoContainer are an important part of well-written applications today," the page says.

Automated testing, especially unit testing, is a crucial part of building reliable software, Noop advocates said. "Any decent software shop should be writing some tests, the best ones are test-driven and have good code coverage," according to the Noop page.

Offered under an Apache 2.0 license, Noop is opposed to statics, implementation inheritance, primitives, and unnecessary boilerplates.

Three ways are planned for using Noop source files: through a Java translator that produces Java source; use of an interpreter that reads and evaluates Noop code and compiled to Java bytecode.

Advocates of Noop believe maintained code is read more than it is written, so readers are favored. Enforcement of a public API separate from visibility of types and methods also is endorsed.

Noop joins other languages besides Java itself on the JVM, such as JRuby, which provides an implementation of the Ruby language; Jython, supporting Python development, and Scala.

Noop's philosophy on stdlib (standard library) includes picking the best implementations from other languages, using JodaTime for Data/Time APIs, and using util.concurrent for concurrency and exposing Google collections. Injection will be done in the same style as Objective-C.