As cloud-computing matures, we can see the emergence of various layers of web services, operating at different levels of abstraction, serving different market needs. Take the category of web application creation/hosting, for example.
Consider the EC2 service from AWS: it provides what may be called "virtualized hardware" as a web service. The fundamental virtualized hardware unit is an industry standard x86 server (with specified CPU/RAM/Disk capacity), capable of hosting a Linux binary image. The Linux image can include any kind of program, written in any language available on Linux. The "any kind of program" part is important, as you will see shortly. This provides the most flexibility for a professional programmer, but if your program goes into an infinite loop and occupies 100% of its virtual CPU, AWS will simply let it burn up the CPU-hours - after all, there is no way for them, even in theory, to know if your infinite loop is intentionally coded or a bug.
The second type of service is what Google App Engine announced yesterday. It provides what may be called a "hosted middleware framework", with the middleware stack having only Python language bindings today, with other language bindings to follow in future. Even when multiple languages are eventually supported, this type of service is quite different from Amazon EC2, because the middleware framework imposes specific constraints on the kind of program that can run on the service. Specifically, Google App Engine service is limited to running what may be called "provably halting programs" (or it will simply be forcibly halted the environment!) - short-running web applications that support the "page oriented computing" model - i.e service a HTTP request with a response and stop. Stand alone programs using multiple threads, such as a web crawler, are not supported. The flexibility lost by the developer comes with a huge benefit. Because of the constraints imposed by the middleware framework, Google can make much stronger guarantees of your application availability than Amazon can - Amazon can guarantee the availability of their virtual CPU, but cannot guarantee your application availability. The service abstraction of App Engine still needs a skilled programmer to create applications, but the effort required is less than what Amazon would need, with the trade-off of a more restrictive programming model.
Finally, Zoho Creator. This provides a service which lets users develop database driven web applications, with the service being accessible to regular users, as opposed to only trained programmers. It starts with a easy-to-use form/view builder interface, and then for more complicated logic, eases the user into the Deluge scripting environment. This scripting environment is intentionally kept very simple, so as to make the system accessible to a large number of users. Much like Google App Engine, Zoho Creator sits on a specific middleware stack, along with its constrained programming model, and its associated benefits/constraints for the application. But rather than exposing the middleware stack as an API only, Zoho Creator provides a higher level of abstraction through a development environment that is accessible to the casual non-programmer - so creating complex views, plugging in validation logic etc. are much simpler. As an aside, I want to mention that, in principle, it would be possible to layer Zoho Creator on top of Google App Engine on top of Amazon EC2.
I hope this post has demonstrated how the cloud-services market is increasingly becoming sophisticated with various kinds of tiered services serving different needs. Each type of service brings with it a different abstraction, a different programming model, and of course, its benefits and constraints.
Comments