Deploying Application with Cloud Foundry

In my previous post I have written about VMware Cloud Foundry, few days back I was playing with Cloud Foundry. Again, it looks very impressive and it seems Derek (Cloud Foundry CTO) team has done a fabulous job with this first PAAS offerning with Vmware. I have used and deployed my app with Google App Engine as well, and I have to say Cloud Foundry stand right there with Google App Engine and Amazon. In my view this will take lots of industry attention as it gets more mature and more and more folks will start using.

To give you an idea, it only took me 30-40 mins from the start to deploy this application. I have used VMC CLI tool to deploy this application. Spring STS also have plugin for Cloud Foundry, I might give it a try later on sometime. Here’s my first “Hello World” kind of application, which is deployed in Cloud Foundry.

http://hellovikascloudfoundry.cloudfoundry.com/

Here's my terminal output from my mac:

Vikas-Kumars-MacBook-Pro:~ Vikas$ bash
bash-3.2$ vmc target api.cloudfoundry.com
Vikas-Kumars-MacBook-Pro:~ Vikas$ bash
bash-3.2$ ruby -v
ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0]
bash-3.2$ gem -v
1.3.5
bash-3.2$ sudo gem update --system
Updating RubyGems
Updating rubygems-update
Successfully installed rubygems-update-1.8.5
Updating RubyGems to 1.8.5
Installing RubyGems 1.8.5
RubyGems 1.8.5 installed
=== 1.8.5 / 2011-05-31
* 2 minor enhancement:
  * The -u option to 'update local source cache' is official deprecated
  * Remove has_rdoc deprecations from Specification.
* 2 bug fixes:
  * Handle bad specs more gracefully.
 
  * Reset any Gem paths changed in the installer.
RubyGems installed the following executables:
            /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/gem
bash-3.2$ clear
bash-3.2$ sudo gem install vmc
Fetching: json_pure-1.5.3.gem (100%)
.......
bash-3.2$ vmc
bash-3.2$ vmc target api.cloudfoundry.com
Succesfully targeted to [http://api.cloudfoundry.com]
 Successfully logged into [http://api.cloudfoundry.com]
bash-3.2$ vi
bash-3.2$ lS
hello.rb
bash-3.2$ vmc push
Would you like to deploy from the current directory? [Yn]: y
Application Name: hellovikasCloudFoundry
Application Deployed URL: 'hellovikasCloudFoundry.cloudfoundry.com'? y
Detected a Sinatra Application, is this correct? [Yn]: y
Memory Reservation [Default:128M] (64M, 128M, 256M, 512M, 1G or 2G)
Creating Application: OK
Would you like to bind any services to 'hellovikasCloudFoundry'? [yN]:
Uploading Application:
  Checking for available resources: OK
  Packing application: OK
  Uploading (0K): OK   
Push Status: OK
Staging Application: OK                                                        
Starting Application: OK       

Elastic Caching Providers

In my previous post we have discussed about how to increase performace & scalability of web applications. Also, cloud based application growing day and night, I thought it would be nice to point out most of caching providing. In todays world we have different clients (web, mobile, ipad etc) for an application and as developer you have to make sure that your application handling users load, and these requirements have produced a diverse elastic caching market that includes not only the large vendors but some open source solutions:

Oracle Coherence and GigaSpaces eXtreme Application Platform (XAP) are the veterans. Oracle and GigaSpaces have the longest presences in the distributed caching market. Both offer elastic caching products today to both enterprise and Web customers, although mostly to enterprise customers. Oracle incorporates its Coherence product into two of its Fusion Middleware bundles but sells the product separately as well.

IBM and Terracotta challenge Oracle and GigaSpaces across the board. IBM and Terracotta (now Software AG) arrived later to the elastic caching platforms market but are challenging the veterans for both enterprise and Web accounts. IBM’s WebSphere eXtreme Scale will get attention as they came with XC10 device, IBM now has hit stride with the product primarily as an extension of architectures based on its WebSphere Application Server.

Terracotta makes its software available under both open source and conventional licenses, and it focuses almost exclusively on selling through developers. Terracotta expanded its offerings by buying Ehcache, a popular open source client-side product, and positioning Ehcache as the primary API to its elastic caching platform. As Amazon is one of the Elastic Caching Pioneer and they provides terracotta caching solution with EC2.

Spring GemStone is focused on big enterprise projects. GemStone has focused almost exclusively on large enterprise projects in financial services, defense, and intelligence. GemStone is a software industry veteran with a history in the Smalltalk language and object-oriented databases and has applied its expertise and technology to the problem of elastic caching. Gem Store will be integrated with other spring framework and Spring TC server (offering session replication at extreme scale), as per spring, other potential area to integrate with spring web flow to provide (transparent flow replication).

Red Hat JBoss is an emerging player. Red Hat’s JBoss middleware division has begun phasing out its distributed caching software (bundled with JBoss as JBoss Cache) and will replace it with the new Infinispan elastic cache. Infinispan is in a very early stage of commercialization, and I it to gain lots of attention from Java developers and eventually build a position in the market as a strong alternative.

Membase which is now part of CouchBase, provides distributed, key-value ("NoSQL") database management system optimized for storing data behind web applications. These applications are characterized by their need to serve many interactive users concurrently; they must create, store, retrieve, aggregate, manipulate and present data in real-time.

Now since we have listed most of the players from EC world. If I would have to choose one or two from above i'll go with terracotta or IBM as they provides more option for developer and their EC solutions seems to better compare to some other one.

Have fun with EC...

How to scale your application: Cloud & Cache

From last few days, I have been reading a book about "Web Scalability" and some intresting articles about “scalability”. In a nut shell, how to improve performance and better scale your application. With this post today I’m going to discuss some major choices to dramatically raise the scale of applications:

Scaling option # 1: Add servers to increase capacity. Add servers or virtual machines to cache user Web sessions, execute business logic, and process transactions. Each added server carries the cost of hardware, software, electricity, and ongoing management. Even if you buy more application servers, your database may then become a new bottleneck. Databases can be redesigned to scale up or out, but it is often very costly to do so. The new buzz, Cloud computing can deliver server instances on demand, but it cannot redesign your application code and data to take advantage of additional resources. And soon or latter one will realize and say, “We can’t just keep throwing hardware at the problem.”

Scaling option # 2: Re-architect the application for greater capacity. Redesign the application for greater capacity by sharding databases, going stateless, splitting functions, improving the layering and separation of concerns, and/or adding asynchronous processing, common services, caches at every layer, single-function appliances, etc. or thorowing new pattern to re-factor some or most of code will take lots of time and money. Most organizations find this remedy too slow to deliver results and sometimes too risky and expensive. Your management and more likely users will say “We’ve got a problem now — we can’t wait a year to solve it.”

Scaling option # 3: Add caches that scale easily. Elastic caching platforms add a fast, scalable, and fault-tolerant data-access layer that can be used to cache transaction results, user session objects, shared application data and other data. Most organizations find that elastic caches easily fit into existing Web architectures and improve scale at a lower cost than the first two options. Also since mobile development is on high right now, that area can really get advantage of cachine solution, as they can choose what object, variable to cache or not to cache. Once you use this solution no one will go back to previoud options.

If you didn’t get bored so far and reached here, Congrates!!! And by now it would have been clear to most of you, that I’m going with 3^rd option to gain scalability of web applications. Hopefully in coming days will post more about major caching players.

Cloud Foundry: Will it be better from existing PaaS?

Recently VMWare has launched Cloud Foundry, the world’s first open Platform as a Service (PaaS). Cloud Foundry is designed to help developers create applications within a "platform Cloud" or a "development Cloud."

As a developer you will be able to sign up and login and write code directly on a Spring or Rails environment. You can deploy your application on a Spring Source tcServer instance and make use of running database services like MySQL and MongoDB. For STS users, the easiest way to get started with Cloud Foundry plugin is by installing it into a pre-installed copy of Spring Source Tool Suite which can be found on the download page. For Eclipse users, Cloud Foundry plugin can quite easily be installed into plain Eclipse installations. To make sure that all dependencies can be satisfied during installation you should start installing the “Eclipse IDE for JEE Developers” package. This package can be downloaded from the Eclipse download page or from the Spring Source member distribution page.

Some benefits of Cloud Foundry might include:

· Multiple Frameworks – choices of programming models

Cloud Foundry provides a platform for building, deploying, and running cloud apps using Spring for Java developers. And support applications those are using spring framework for code wiring purpose or for resource configuration purpose, such as data source look up etc.

· Multiple Services- choices of services from VMware and third parties

o Cloud Foundry is open to multiple services including basic relational databases as well as broader choices like MongoDB, MySQL and Redis. Services provide data storage and other functions that can be leveraged by applications. Examples of additional service integrations will include VMware’s vFabric application services. The vFabric Cloud Application Platform includes open source Spring Development Framework as well as a set of application services including a lightweight application server, global data management, cloud-ready messaging, and application performance management capabilities.

· Multiple Clouds - choices of clouds for deployment

o Cloud Foundry provides choice of underlying deployment destinations including a public cloud service at Cloud Foundry. Cloud Foundry make this framework available as downloadable instance to run on other cloud providers like Amazon EC2, and other IaaS offerings technologies like Eucalyptus or OpenStack.

· Developers can deploy their applications to Cloud Foundry using their existing tools and with zero modification to their code.

· As any PaaS, Cloud Foundry allows developers to focus on applications, not machines or middleware.

· Most PaaS offerings restrict developer choices of frameworks, application infrastructure services and deployment clouds. The open and extensible nature of Cloud Foundry means developers will not be locked into a single framework, single set of application services or a single cloud.

Cloud Foundry supports:

· Rails and Sinatra for Ruby developers.

· Node.js which is an event-driven I/O framework for V8 java script engine on Unix-like platforms.

· JVM frameworks including Grails.

· JVM languages such as Clojure and Scala.

Cloud Foundry Architecture

Application execution engine is one of the core building blocks of Cloud Foundry Architecture. It’s an agent that runs on each node that actually runs the application. It acts as an automation engine for application deployment and lifecycle management. Also includes scriptable command line interface (CLI) that provides access to VMWare cloud application platform. Integration with development tools such as Spring Source Tool Suite(STS), Grails and Spring Roo for development. These tools utilize the Cloud Foundry client web services API and Spring Source artifact repositories to deploy applications under Cloud Foundry.

The pieces that make up Cloud Foundry architecture are:

· At the core the Application Execution Engine is the piece that runs your application. It’s what launches and manages the Rails, Java, and other language app servers. As your application is scaled up, application engine will launch an application server with deployed code. It can be launched on any suitably configured server, which then connects to the other servers in the PaaS and starts running user applications (the application execution engines can be configured to run a single application per server or multiple).

· The Request Router is the front door to the PaaS: it accepts all the HTTP requests for all the applications running in the PaaS and routes them to the best app execution engine that runs the appropriate application code. In essence the request router is a load balancer that knows about which application is running where.

· The Cloud Controller implements the external API used by tools to load/unload applications and control their environment, including the number of application execution engines that should run each application. As part of taking in new applications it creates the bundles that application execution engines load to run an application. One aspect of the cloud controller is that it is relatively policy-free, meaning that it relies on external input to perform operations such as scaling how many application execution engines each application uses. This allows different management policies to be plugged-in.

· A set of Services which provide data storage and other functions that can be leveraged by applications. Each service tends to consist of two parts: the application implementing the service itself (e.g. MySQL, MongoDB, Redis) and a Cloud Foundry management layer that establishes the connections between applications and the service itself.

· A Health Manager responsible for keeping applications alive and ensuring that if an application execution engine crashes the applications it ran are restarted elsewhere.

The following diagram summarizes the basic idea behind Cloud Foundry:

Developer Frameworks

Cloud Foundry Supports multiple framework like Spring for Java, Rails and Sinatra for Ruby, and Node.js. There is also support for Grails on Groovy and other JVM-based frameworks.

Application Services

Application Services allow developers to take advantage of data, messaging, and web services as building blocks for their applications. For Data Service, Cloud Foundry currently offers support for MySQL, MongoDB and Redis with other service integrations underway. For Messaging service, they will offer their own Rabbit MQ and other messaging services. Examples of additional service integrations will include VMware’s vFabric application services.

Initially they are going to provide multiple services provided by VMWare itself, and eventually, open it up to the ecosystem for third-parties (similar to Heroku Add-Ons or Salesforce.com AppExchange)

Clouds

Public, Private, VMware based and non-VMware based it up to the developer and organization as to where they want to run Cloud Foundry.

Finally, you'll notice there is reference to a "Downloadable 'Micro Cloud'". Micro Cloud is a single developer instance of Cloud Foundry. It provides developers with a personal PaaS that runs on their desktop. Micro Cloud is provided as a downloadable software image for VMware Fusion or VMware Player, as well a hosted image on selected cloud partners like you can run on an(e.g. Amazon Machine Image). The idea behind the Micro Cloud is to appeal mostly to developers and let them easily do development in any physical location, as well as easily load their app to a Cloud Foundry cloud when they are ready.

Cloud Foundry’s code is open source at github under the Apache 2 License.

https://github.com/cloudfoundry/vcap

I think it has potential to compete with other cloud providers. What do you think? Does Cloud Foundry have the potential to compete with likes of Google AppEngine or Amazon EC2?

Keys concept for Building Internal Cloud

Here are some important Key Ingredients for Building an Internal Cloud:

1.Shared Infrastructure. IT needs to understand how to configure the underlying storage and networking so that when it is brought together it can be shared across all of the enterprise’s different workloads. They also need to determine where in that shared infrastructure they should delineate between different users on that infrastructure. And also they need to fully understand their current infrastructure in order to re-use some of tis capabilities. Some keys area to consider like DB or Queue provision on their infrastructure.

2.Self-Service Automated Portal. It is essential to make sure that the compute cloud can be consumed in an easy form by both developers and IT professionals. There is a need for self- service capabilities, and for highly automated provisioning portals that provide the ability to add workloads without having to go through all of the many different steps of provisioning with the network and underlying storage.

3.Scalable. An effective cloud solution has to be scalable. IT organizations should think about boundary conditions in a more creative way, instead using the traditional models of scalability. As a new workload request comes up, they must determine where to provision that specific workload.

4.Rich Application Container. Clouds need to have a richer application container that will show the different interdependencies between components of the application, specifically those that take place between different virtual machines. This information help create the correct network subnets so that the storage will work well together and not be isolated from one another.

5.Programmatic Control. It is very common for a compute cloud to have programmatic control. Some of the more popular compute clouds on the market today have made good use of an API called REST. REST is a very simple HTTP- based protocol that provides the ability to manipulate stateful objects in a clear way. It's better to have organization which have Service Oriented Architecture (SOA), which provided you interoperability and easy to use services, and provide re-use and loose coupling between different applications within an enterprise.

6.100% Virtual Hardware Abstraction. Clouds need 100% hardware abstraction. This can include servers or other physical devices like storage. In a cloud environment, the user should be able to interact with the virtual machines and other devices through the user interface, verses actually changing physical infrastructure.

7.Strong Multi-Tenancy. Strong multi-tenancy involves extensive use of VLANs to isolate network traffic between different zones in the cloud. This is obviously critical in an external cloud, but also a common requirement in internal clouds, to make sure that authorized users have access to certain applications.

8.Chargeback. This may not be 100 % true when you are building internal cloud within organization, but its to have this practice as IT organizations must be able to create effective and accurate chargeback capabilities. For internal clouds, even if funds aren’t literally exchanged,, the ability to create transparency in costs and services can help justify expenses.

Web caching in the Cloud

This is the buzz word now in enterprise if you are trying to implement private cloud. I think this can be confusing to an extend, is it application caching side we are talking about or are we talking about caching in cloud?

For Applications there are solution like Eh-cahce or open terracotta or Extreme scale from IBM are some good solution.

Web application performance can be improved by caching frequently‐accessed data in high‐speed memory, instead of in databases, they can dramatically reduce response times, economically scale their sites, and substantially reduce the load placed on their databases, file servers, and other information sources.

Now lets talk about web caching in the cloud and some player in this space. Memchached and Gear6 (which provides enhanced solution)

The open‐source distributed cache system Memcached has quickly become the standard for web caching, particularly for operators of dynamic, high‐growth web sites. Memcached stores frequently‐used data in DRAM instead of in databases, providing response time improvements of 100x or more.

It is not surprising that many large organizations are interested in both cloud computing and Memcached web caching, since they offer complementary advantages in cost savings, flexibility and ease of management. But they too have evolved in different communities, largely in isolation from one another, and they do not operate together as seamlessly as might be desired.

As an example, the ability to rapidly scale applications up or down in size is a key advantage of cloud computing, but standard Memcached does not accommodate it very well. Changing the size of a Memcached cache tier causes the cache data to be flushed and then rebuilt, this typically causes degradation in site performance, and causes spikes in the demands on source databases and file servers. Rebuilding the contents of a large cache tier can take hours, and site performance may not be restored to normal until the end of the rebuilding process.

You can read more about Memcahed and Gear6 and MemCahed can be dowloaded from

Download MemChached