Starting AppScale

This post is written assuming you already have a machine or a VM image with AppScale and AppScale-Tools installed. If you don't please refer to my previous post on "Setting Up AppScale". 

We use AppScale-Tools to start, manage and terminate AppScale instances in various environments. The inputs we should pass into the tools differ slightly based on the environment in which we want to start AppScale. If you're going to deploy AppScale without the help of an IaaS layer like EC2 or Eucalyptus, then you're responsible for manually starting up the required machines or VMs. For an example if you're going to run AppScale on the Xen hypervisor, then you should first start your AppScale Xen images manually. Similarly if you're going to run AppScale over VMWare Fusion, you should start your AppScale Fusion images manually. Once the instances are up and running note down their IP addresses (assuming that the instances obtain IP addresses from a service such as DHCP). As an example lets assume you have 3 VM instances up and running and their IP addresses are 192.168.1.10, 192.168.1.20 and 192.168.1.30. With this information we should compile a simple YAML configuration like this:

--- 
:controller: 192.168.1.10
:servers: 
- 192.168.1.20
- 192.168.1.30

Lets call this file ips.yaml. This configuration instructs AppScale to use one machine as the controller and the rest as ordinary nodes. The controller (aka head node) operates as a load balancer and a ZooKeeper leader. The other nodes will assume the roles of application server and DB server. In this case both server nodes will assume the application server and DB server roles. Therefore we end up with an application server cluster (of 2) and a replicated DB cluster (of 2) fronted by a single load balancer. You can further fine tune how AppScale assigns roles to machines by changing your ips.yaml file. For more information regarding the role placement configuration please refer the "Placement Support" article on AppScale wiki.

Once you have your ips.yaml file you can start deploying AppScale on the VMs. First create a SSH key-pair so that AppScale-Tools can login to the relevant machines remotely. This is done by executing the appscale-add-keypair command.

appscale-add-keypair --ips /path/to/ips.yaml

This will prompt you to enter the root passwords for each of the machines specified in your ips.yaml. Once this step has completed you can fire off AppScale using the app scale-run-instances command.

appscale-run-instances --ips /path/to/ips.yaml

This will start the AppScale daemons on each of the machines and initialize the AppScale PaaS. At some point you will be prompted to enter an email address and a password for the AppScale admin account. Just enter any email address or password for this. You can later use these credentials to login to AppScale management console. (For more details on deploying AppScale over a virtualized cluster setup refer the AppScale wiki)

If you are deploying AppScale over an IaaS layer such as EC2 or Eucalyptus, then you don't need to start the VMs manually nor you need any ips.yaml file. All you need is the unique ID of your AMI or EMI provided by your IaaS provider and the security credentials to interact with the IaaS. In case of EC2 you will need your AWS access key, secret key, AWS private key and X509 certificate. You can get these from the security credentials page of your AWS management console. If you're on Eucalyptus you can download a zip file from Euca admin console which contains all the required credentials.

Using these credentials you should first setup some environment variables.

export EC2_CERT=~/mycert.pem 
export EC2_PRIVATE_KEY=~/mypk.pem 
export EC2_ACCESS_KEY=my-access-key 
export EC2_SECRET_KEY=my-secret-key

In case of Eucalyptus you can simply source the eucarc file found in the downloaded credentials file.

source eucarc

With these environment variables in place you're ready to go. Simply execute the app scale-run-instances command as follows.

appscale-run-instances --min 1 --max 1 --infrastructure ec2 --machine ami-52912a3b --keyname app scale_test --group app scale_test

This will start a simple 1-node AppScale cloud in EC2. If you want more instances in your PaaS, simply adjust the values of min and max flags. For deployment on Eucalyptus change the value of infrastructure flag to 'euca' and provide a valid EMI ID for the machine flag. Here's the command for a 10 node AppScale deployment over Eucalyptus.

appscale-run-instances --min 10 --max 10 --infrastructure euca --machine emi-12345678 --keyname app scale_test --group app scale_test

The values of keyname and group flags will be used to create a keypair and a security group in the respective IaaS environment. Therefore make sure they are unique for your EC2/Eucalyptus account. Note that when running in a billed environment such as EC2, the machines spawned by AppScale are billed against the EC2 credentials provided (the credentials that we set as environment variables). AppScale spawns m1.large instances which cost about 26 cents an hour.

An AppScale deployment could take several minutes to complete. In environments like EC2 and Eucaplyptus, deployment times over 10 minutes are not uncommon. This delay is primarily due to the VM bootup and initialization overhead of IaaS environments which cannot be avoided. Once the AppScale deployment is complete AppScale-Tools will spit out a URL that you can use to check the status of the AppScale deployment:

The status of your AppScale instance is at the following URL: http://ec2-107-22-124-143.compute-1.amazonaws.com/status

Simply copy and paste the URL into your web browser to view the AppScale status page.

In my next post I'll explain how to deploy applications in an already running AppScale PaaS.

Setting Up AppScale

The AppScale installation procedure is already well documented in the AppScale wiki. Therefore this blog post only serves as a summary and a refresher of the most important steps. The installation of AppScale usually boils down to creating a virtual machine (VM) image for the environment in which you intend to deploy AppScale. For an example, if you wish to deploy AppScale on Amazon EC2, then you need to create an EC2 AMI with AppScale installed on it. If you wish to run AppScale on Eucalyptus, you will be creating a Eucalyptus EMI with AppScale on it. Similarly you can create AppScale VM images for other virtualized environments (eg: Xen, Virtual Box, Fusion etc). The only exception to this is when you want to deploy AppScale without a virtualization layer. In that case you can directly install AppScale on the host operating system.

As of the time of writing, AppScale is only supported on Ubuntu Lucid 10.04 Server Edition. This is common to all the target environments. Therefore regardless of the virtualization layer you intend to use, your AppScale VM image must be running Ubuntu Lucid 10.04 Server Edition. However we will start supporting newer versions of Ubuntu pretty soon therefore I'd recommend you to refer the AppScale wiki to find out about the latest OS supported by the system. 

Once you have procured your Ubuntu Lucid image you can boot it up and start installing AppScale on it. First login to the VM as root. We will use the command-line Git client to pull the latest AppScale source code on to the VM. But first we need to install the command-line Git client.

apt-get install git-core

Now clone the AppScale and AppScale-Tools repositories to the home directory of root.

git clone https://github.com/AppScale/appscale.git

git clone https://github.com/AppScale/appscale-tools.git

If you want to pull any recent bug fixes or improvements, simply pull the AppScale testing branches. You can do this by adding "--branch testing" flag to the above two commands. Once you have the two repositories checked out, simply change into the appscale directory and run the following command to kick off the build process.

bash debian/appscale_build.sh

AppScale build can take about 20-30 minutes depending on how fast your Internet connection is. Once the AppScale build is complete check for a directory named /etc/appscale. This should contain a subdirectory named after the version of AppScale you just installed and this subdirectory should contain a collection of text files named after different database engines (eg: cassandra, hbase etc). If these files are in place that's a pretty reasonable indication that everything has gone according to the plan. Now change into appscale-tools directory you checked out earlier, and run the same build command as above to start building the AppScale command-line tools. This shouldn't take more than a few seconds. 

You are now done installing AppScale on the VM image. You can now go ahead and start bundling/packing the VM image for your target environment. For an example if you're going to run AppScale on EC2, you can start the AMI bundling process now. The actual procedure for bundling and uploading VM images will depend on your target environment.

It is particularly trivial to setup AppScale in the EC2 environment. The EBS technology of Amazon makes it absolutely simple to create AMI images with AppScale. Here's all you have to do:

1. Start a fresh Ubuntu Lucid 10.04 EBS image (eg: ami-1634de7f). If you start this VM as a m1.large instance the whole thing will be over much quicker.

2. Run the above described procedure to checkout and build AppScale on the EC2 instance.

3. Login to your AWS management console. Right click on your EC2 instance and select the "Create Image (EBS AMI)" option from the menu that appears. This will start bundling your AppScale AMI and it will be available for deployment within several minutes.

It is sometimes necessary to create VM images with only the AppScale-Tools. In this case you may only checkout the AppScale-Tools source code and build it. However you will have to install a few additional libraries manually.

apt-get install openjdk-6-jre

apt-get install ruby

apt-get install rubygems

apt-get install ruby1.8-dev

gem install json

This should enable you to run AppScale-Tools on your VM image.

In my next post I'll describe how to start AppScale and deploy applications on the AppScale PaaS.

Flexible Cloud Computing with AppScale

I recently started contributing to AppScale, an open source project aimed at developing a scalable Platform-as-a-Service (PaaS) solution. AppScale project was initiated by UC Santa Barbara with the intention of implementing an open cloud PaaS that would enable more research and studies in the area of cloud computing. But over the years AppScale has evolved rapidly gathering a wide range of features and now many enterprise users are finding it useful as a platform that facilitates private, public and hybrid cloud deployments. 

One of the most attractive features of AppScale is the flexibility it provides to the cloud administrators and cloud application developers. Cloud administrators can deploy AppScale on a variety of infrastructure setups. It can be deployed on virtualized computing clusters based on solutions such as Xen and KVM. AppScale also runs on Infrastructure-as-a-Service (IaaS) solutions such as Amazon EC2 and Eucalyptus (It is worth mentioning that Eucalyptus also started out as a research project in UC Santa Barbara). Also if needed AppScale can be deployed directly on physical hardware without the support of any virtualization service. AppScale also comes with a Ruby API and a set of command line tools that can be used to deploy AppScale clouds on any of the above infrastructure setups with minimal human intervention. A single shell command is all it takes to deploy even a 100-node AppScale cloud. To make this process even easier, I recently implemented a new web UI component which allows users to deploy AppScale without bothering about the infrastructure complexities at all (more on this in a future blog post).

As a PaaS offering, AppScale exports a wide range of services for the cloud application developers to use in their applications:

• Datastore - Persistent storage for application data. Generally operates as a replicated key-value store with support for range queries and transactions within entity groups.
• Namespace - Facilitates segmenting data into multiple partitions. Can be used in scenarios where certain data items need to be separated from each other (e.g: Production data vs Test data)
• Memcache - Distributed cache. Useful in developing stateful applications and improving application performance.
• Blobstore - Persistent storage for large data objects and files.
• XMPP - Provides instant messaging capabilities to AppScale applications.
• Channel - Allows pushing data into client's JavaScript code.
• Users - User account creation and profile management.
• Mail - Facilitates sending e-mails from applications.
• Images - Supports programmatic manipulation of images.
• URL Fetch - Facilitates consuming local and remote REST APIs.
• Task Queue - Facilitates asynchronous execution of long running jobs.

All these fundamental services are fully API compatible with Google App Engine (GAE). Therefore any GAE application can be deployed on AppScale with zero modifications. This has two very interesting outcomes for the users. First it makes it absolutely simple for the users to migrate from GAE to their own private or hybrid cloud offering based on AppScale. Second, it allows developing applications for AppScale quite straightforward as all GAE APIs are very well documented and comes with a powerful SDK. As a result AppScale has managed to gather a large number of sample applications and a very large developer community actively writing apps for AppScale in very quick time. Just like in GAE, applications can be developed in Java, Python or Go for AppScale. Another interesting aspect is that AppScale allows using a wide range of database systems underneath its Datastore API. Currently supported database systems include Cassandra, HBase, Hypertable, MongoDB, MemcacheDB, MySQL cluster, Voldemort and Redis. This is one area where the flexibility of the AppScale architecture can be observed clearly as it enables cloud administrators to setup AppScale with any one of these database solutions depending on their application requirements and organizational standards.

One thing that should be stressed is that AppScale is not just about running GAE applications. It facilitates deploying a wide range of other applications in the cloud too. This is mainly enabled by Neptune, a software overlay that runs on top of AppScale. It's comprised of a domain specific language that allows developers to execute any arbitrary program in the AppScale cloud PaaS. These programs may include standalone programs written using any arbitrary language, MapReduce jobs and high performance computing applications developed using technologies such as MPI, UPC, X10 and StochKit. The ability of AppScale and Neptune to execute high performance computing applications in the cloud has attracted a lot of attention from the scientific research community as it enables executing long running resource intensive tasks on the cloud using as many nodes as required thus greatly reducing the task completion time and eliminating the need to procure expensive server grade hardware.

On top of all this flexibility, AppScale also provides excellent fault-tolerance and autoscaling capabilities. All the critical services such as the database and the application server can be easily replicated for high availability. ZooKeeper is used to keep track of all the active services and nodes, and automatic failover is performed upon detecting failures. The AppScale autoscaler component keeps track of resource utilization and system performance related metrics, and spins out new nodes dynamically as the demand changes over time. Autoscaler is another very flexible component in the AppScale architecture, in that it allows cloud administrators to engage custom autoscaling policies depending on their application performance and scalability requirements. Some of the built-in autoscaling policies include HA aware autoscaling, QoS aware autoscaling and cost aware autoscaling. If needed more than one autoscaling policy can be engaged at once with an administrator defined priority arrangement. 

One of my personal favorite features of AppScale is its placement support. This is the ability of the PaaS to smartly place cloud services given a set of nodes. For an example if we start an AppScale instance  using three nodes (that is 3 physical or virtual machines), it will place an application server component and a database component in each of them. One of the database components would act as the master and the others would act as slaves. Automatic data replication will be enabled among all database components. One of the three nodes will be designated as the head node and the load balancer and ZooKeeper will be deployed in that node. Note that AppScale attempts to use the nodes in the most optimal manner possible by replicating all the critical services. The actual placement strategy however is also configurable in AppScale. But if the administrator does not explicitly state a placement strategy, we can rely on AppScale to figure out a suitable placement strategy on its own. 

If my introduction of AppScale has intrigued you to try it out, feel free to grab the latest stable source from our github repo. Detailed instructions on building the source and creating your own AppScale machine images can be found in the following wiki pages:

• Setting up an Ubuntu Lucid image for Xen or Eucalyptus: http://code.google.com/p/appscale/wiki/ImageCreationLucid
• Installing AppScale on a machine image: http://code.google.com/p/appscale/wiki/ImageSetupViaBzr

If you need a more ready-to-roll distribution of AppScale to take a quick look, check out our public EC2 image ami-52912a3b which is preloaded with AppScale 1.6.3. If you already have an EC2 account, you can simply setup AppScale command line tools on your computer and start an AppScale instance in EC2 using the tools and the above AMI.

I will roll out a couple of detailed blog posts on setting up AppScale in the near future, so stay tuned.

Busting Synapse and WSO2 ESB Myths

Paul Fremantle, PMC chair of the Apache Synapse project and CTO of WSO2, has written a very interesting blog post addressing some of the myths concerning Apache Synapse and WSO2 ESB. As of now both projects are quite popular, mature and have a very large user base including some of the largest organizations in the world. Surprisingly there are still some people who believe that these projects do not fall under the category of ESB (Enterprise Service Bus) implementations. In his latest post, Paul gives a clear and complete answer to all these misbeliefs, and backs it up with a wide range of facts.

ESB is one of those things in the IT world which don't have a proper standard definition. The best definitions I've come across attempt to align the term along the following cues:

• An architectural construct that provides fundamental services to complex architectures
• An entity that acts as a hub connecting many diverse systems
• A central driver that facilitates Enterprise Application Integration (EAI)

Apache Synapse and WSO2 ESB pass with flying colors on all the above criteria. They provide an array of fundamental services to the systems and architectures that rely on them.  Some of these basic services are:

• Message passing, routing and filtering
• Message transformation
• Protocol conversion
• QoS enforcement (security, reliable delivery etc)
• Logging, auditing and monitoring

Because Synapse and WSO2 ESB do such a good job providing these fundamental services, they can be used to integrate a large number of heterogeneous systems in an enterprise setting. As Paul has also pointed out in his post, Synapse and WSO2 ESB are currently used in hundreds of production deployments all around the world to connect various applications, implemented using various technologies (both open source and proprietary) running on various platforms (Windows, Linux, .NET, J2EE, LAMP, cloud..you name it). In other words Synapse and WSO2 ESB are widely used as centralized drivers that facilitate EAI. The configuration model of Synapse and WSO2 ESB is so agile and powerful that practically any EAI pattern can be implemented on top of them. In fact there are tons of samples, articles and tutorials that explain how various well-known EAI patterns can be implemented using these 'ESB implementations'.

One thing that I've learnt from writing code to Synapse is that it has a very flexible enterprise messaging model. Support for any wire level protocol or any message format can be easily implemented on top of this model and can be deployed as a separate pluggable module. During the last few years, I myself have contributed to the implementation of following adapters/connectors on various occasions:

• FIX transport
• SAP transport (IDoc and BAPI support)
• MLLP transport and HL7 message formats
• CSV and various other office document formats
• Thrift connector
• Numerous other custom binary protocols based on TCP/IP

This is just a bunch of stuff that I've had the privilege of implementing for Synapse/WSO2 ESB. I know for a fact that other committers of Synapse and WSO2 ESB have been working on supporting dozens of other protocols, message formats and mediators. Thanks to all this hard work Synapse and WSO2 ESB are currently two of the most powerful and feature-complete ESB implementations anyone will ever come across. Also the existence of connectors for so many protocols and applications is a testament to the agility and flexibility that Synapse and WSO2 ESB can bring in as ESB products.

Another aspect of Synapse/WSO2 ESB that has been questioned many times is their ability to support RESTful integrations (Paul also addresses this issue in his post). This confusion stems from the fact that Synapse uses SOAP as its intermediary message format. Without going into too many technical details, I'd just like to point out that one of the largest online marketplace and auctioning providers in the world uses Synapse/WSO2 ESB to process several hundred millions of REST calls in a daily basis. The new API support we have implemented in Synapse makes it absolutely simple to design, implement and expose RESTful APIs on Synapse/WSO2 ESB. In fact I recently published an article which demonstrates through practical examples how powerful RESTful applications can be implemented using Synapse/WSO2 ESB while supporting advanced REST semantics such as HATEOAS. The recently released WSO2 API Manager product which supports exposing rich web APIs with support for API key management is also based on Synapse/WSO2 ESB.

I think I have made my point. Both Synapse and WSO2 ESB are two excellent ESB choices if you're looking to adopt SOA or enterprise integration within your organization. Their wide range of features is only second to the very high level of performance they offer in terms of high throughput and low resource utilization. Please also go through the post made by Paul, where he has explained some of the above issues with low level technical details. I particularly like his analogy concerning Heisenberg's principle of uncertainty :) 

How to GET a Cup of Coffee the WSO2 Way: An Article

Since we implemented REST API support for WSO2 ESB (and Apache Synapse), we have received many requests for new samples, articles and tutorials explaining this powerful feature. I started working on an end-to-end sample for API support somewhere around March but didn't have enough cycles to write it up. Finally, after a several months delay, I was able to submit the finalized sample and the article to WSO2 Oxygen Tank last month. Now it has been published and available for reading on-line at http://wso2.org/library/articles/2012/09/get-cup-coffee-wso2-way

This articles starts with a quick overview on the REST support provided by WSO2 platform. It describes the API mediation capability of the ESB in detail providing several examples. Then the article explains how a complete order management system can be constructed using the REST support available in WSO2 ESB. This sample application has been inspired by the popular article on RESTful application development titled "How to GET a Cup of Coffee" by Jim Webber. Webber's article describes a hypothetical application used in a Starbucks coffee shop which supports placing orders, making payments, and processing orders. The sample described in my article implements all the major interfaces and message flows outlined by Webber. I have also made all the source code and configurations available so that anybody can do the same on their own machines using WSO2 middleware. To make it even more interesting I also implemented a couple of user interfaces for Webber's Starbucks application. These UI tools are also described in my article and they can help you better understand how the applications communicate with each other using RESTful API calls and how their application states change according to typical HATEOAS principles.

Towards the latter part of the article I discuss some of the advanced features of RESTful application development and how such features can be implemented on top of WSO2 middleware. This includes some very important topics such as security, caching and content negotiation.

I hope you will find this article interesting and useful. As always feel free to send any feedback either directly to me or to dev@wso2.org.

Turning Over a New Leaf

Last month I said good bye to a fantastic career at WSO2. I joined WSO2 on April 2009 as a Software Engineer and worked my way up the ladder to become a Senior Technical Lead. Most of my time at WSO2 was spent on WSO2 ESB, WSO2's flagship product. I also contributed to Carbon, the core platform on which all WSO2 products are built, and also implemented a number of cross cutting features which are currently used in multiple WSO2 product offerings. Towards the latter part of my WSO2 career I was mostly working on improving the REST support in WSO2 platform and implementing the WSO2 API Manager product. The WSO2 API Manager 1.0 release that went out in early August marked the end of my career at WSO2 (at least for the next few years).

My time at WSO2 has been a great learning experience. I learned and mastered  a variety of technologies like Web Services, SOA, cloud computing and API management. I got to travel to many countries and had the privilege of  meeting and working with some of the largest IT organizations in the world. Above all I had a lot of fun working with the team WSO2. It's truly a great organization with some of the smartest and coolest people I've ever had the privilege of working with.

This month I'm starting my Computer Science graduate studies at University of California, Santa Barbara. I'll be doing distributed systems research with prof. Chandra Krintz at UCSB Mayhem lab and RACE lab. Popular open source cloud platforms like Eucalyptus and AppScale were originally designed and developed in these labs, and so currently I'm spending some time on getting up to speed on these platforms. You will see me blogging about these technologies time to time over the next few days. Wish me luck :)