Question: Does the cloud require a new approach to software development? What tools are available to build new applications in the cloud?
Previously I broached the idea of adding a new Software Development as a Service (SDaaS) layer to the commonly understood three tier cloud infrastructure architecture standard. One of the transformational aspects of cloud computing is that it both integrates the entire IT stack so nicely, while at the same time allows vendors to slice it into very narrowly defined services. That is both its great strength and its great weakness. The advantage of this approach is that vendors are able to build deep expertise in a single knowledge area without having to worry about the underlying infrastructure. On the other hand, one of the hidden pitfalls of the cloud is the difficult integration across the plethora of vertical services that have developed and the lack of specialized cloud development tools. Now that cloud has become more widely accepted and more companies are interested in building customized applications in the cloud, it is time to define the SDaaS layer. I envision SDaaS as set of cloud optimized development tools designed to allow companies to build new SaaS services and/or easily migrate existing applications into the cloud.
In my mind, SDaaS rightfully belongs placed solidly between the PaaS layer and the SaaS cloud layers. It needs to be on top of the platform (PaaS) layer because modern software development tools and environments are should be independent of the operating system environment. There is still room for improvement. It is true that most applications do not depend on the platform that they run on, but that’s because they are thoroughly undemanding — not infrequently, because anything depending on sophisticated facility is done without. Many applications which could make good use of 64 bit word-size where it exists, for example, do not because it requires complicated conditional coding. Certainly things have improved. The development of large standardized libraries that transparently support and extend various facilities available on all platforms has helped a lot. Unicode, XML, XML based standards and other standards have done much to enable software to be independent of platform but it comes at a high cost
It should be that a Java library is a Java library regardless of whether it is on some flavor of Linux, Solaris or Windows. Yes, underneath there is an operating system, but as any systems administrator can tell you, most developers have little awareness of the underlying platform; which is exactly how it should be! We are not quite there yet, but abstracting the development tools will go a long way towards achieving that goal.
On the other hand, clearly, SDaaS should be placed below the SaaS layer because it supports the development of SaaS applications. SaaS services as they have evolved are defined as applications that are multi-tenant, configurable, not customized, and have a subscription based pricing model. The operative word is configurable user facing applications, not development environments. The SDaaS layer would need to include standards and libraries that address the particular needs of the highly horizontally distributed applications and cloud infrastructure.
Until recently, most SaaS applications have been developed using standard web services tools, but as the cloud application business grows and the technology becomes more sophisticated, there is a need for a set of development tools that address the particularities the cloud. With cloud elasticity and horizontal scalability in mind, SDaaS development tools need to have the following characteristics:
- More tools to support asynchronous transactions
- Transparent horizontal scaling capabilities
- Mechanisms to allow on-demand platform neutral delivery of services
- Baked in code security – we have been living with bolt-on application security for far too long.
- Support of applications in the run-time state to allow the creation of end-to-end development/test/production environments
What I am talking about is developing languages that would include functionality specifically for developing cloud software — not just libraries that provide classes to use the cloud and not XML schema that specify a semi-readable format for describing data or configuration. These work, but they are clumsy and frequently baroque. In thinking about what such a language would include, the most obvious thing that occurred to me was direct language support for async calls.
We are not starting completely from scratch. Some services currently available meet my definition of a SDaaS system. Microsoft Azure and other similar services, such as, AppEngine by Google and Force.com by Salesforce.com clearly are providing services and tools for building new applications and supporting existing software, but unlike SaaS (Software as a Service) these services are designed specifically to be used by developers. In future weeks I will be drilling down into the currently available SDaaS offerings in more detail.
About the Author
Beth Cohen, Cloud Technology Partners, Inc. Moving companies’ IT services into the cloud the right way, the first time!