Ever since I started working on the Amazon cloud, I was stuck with one thing - not being able to scale the web applications dynamically. To be honest it didn’t even strike me until companies like Rightscale and Scalr started to come into the limelight. Until that time I was just trying to imitate the existing environment, just migrating to Amazon cloud. When I saw the demo of Rightscale and Scalr, I thought it was amazing, to be able to scale the applications dynamically with the click of a button. They have done a wonderful job of automating a whole lot of stuff without getting into the boxes and just using their web based administration application. So I thought what would it take to do a step 1 of what they do - automatically scale up or scale down an instance. I used simple shell scripts to make that happen. I created a white paper that explains the approach and what the scripts do. The white paper assumes Nginx is used for load balancing a web application and Nagios for monitoring the instances. The solution involves dynamically adding a new instance to the Nginx configuration for load balancing and adding the Nagios configuration for monitoring the new instance. It also removes the configurations from Nginx and Nagios when the instance is brought down.

Click the button below to download the zip file containing the white paper and the shell scripts.

This is just a first step to scaling the applications dynamically. It would still require someone to decide when the application needs to be scaled up or scaled down. But once that decision is made it is just a matter of bringing up or down the instances and the rest of the stuff is taken care of.

Feel free to pass on your comments and feedback.

A common ignorance with new developers (sometimes even the experienced developers) is the ignorance towards how the developed code would perform in a production environment. There are several architectural as well as implementation specific parameters that needs to be kept in mind while developing an application. What might look like a perfect system while testing on a local servers could actually fail miserably on a production environment. Obviously these are not function errors rather non functional, for example slow response time, bad user experience etc. Many of such things could be avoided if some of the non functional requirements are kept in mind during development as well as testing. One such key area that developers often miss is the parameters around network. On one hand is the ignorance about it but on the other hand is knowing them wrong or having misconception about network and the effects of it. The eight fallacies (mistaken belief’s) of network are,

1. Reliable Network - Even though one would be choosing a data center to host the application, it is very important to understand what the data center offers in terms of the network reliability and availability. The availability the data center promises becomes your application’s default availability. So assuming that once the application is hosted in a data center, doesn’t mean that there will be reliable network connection 24×7x365
2. Zero Latency - Your application’s response time includes time for information to travel back and forth between the client and the server. There is no teleporting happening. The more the information has to travel, there would be more back and forth communication because the entire information doesn’t travel in one packet. So it is important to keep in mind what you send and receive and if it is optimized.
3. Infinite Bandwidth - The network bandwidth determines the capacity of a system to transfer information over a network connection. Too many connections beyond the bandwidth can support could also lead to slow response and connection time outs. Like how your intranet setup environment will not allow you to connect beyond certain number of connections, so would there be a limit on your production environment. Get to know the bandwidth the data center guarantees for your system and calculate approximately the number of connections the system can handle given the bandwidth.
4. Secure network - While this can be enabled based on what protocol you use (HTTPS for example) this is not default. The data center could provide protection to who enters the servers, but not necessarily the information carried over the network.
5. Unchanged topology - Topology is arrangement of node elements and the links between them. When your application is clustered and/or you share the network with other systems in the data center, understand the topology and how the nodes are connected. Also for better inter connectivity the topology need not be the same always.
6. One administrator - Unless you have setup your own production environment and you are all in all everything, understand that it will not be one administrator managing all your network. There could be many who would be involved in managing the network and ensuring the network is most reliable and available. Ensure that there is good support team that can manage network in the data center round the clock. If your application has a global presence, then all the more you will need your application available throughout a day.
7. Zero transport cost - Network utilization is not a fixed cost usually. Your data center puts a restriction on usage for a fixed cost and then usage beyond that would be charged. This possibly would help you to realize that the bandwidth you had originally opted for is no more enough. Also your data center gives little flexibility by not cutting down connections exactly when the connections to your system cross the bandwidth limit.
8. Homogeneous network - The network may not be dedicated in entire to your application. There could be several other applications or tools that could be consuming or think about the interoperability with other systems from your application.

Keep all of the fallacies above in mind ensures that you plan your network capacity properly for the application and ensure that your application doesn’t get affected because of it.

The Barcamp event at Hyderabad was uneventful, rather should I say very eventful. The sessions focused on technology, product demos, blogging, startup and entrepreneurship. The sessions started happening in single track with topics related to technology. I was second in the list and talked on “Building Low Cost Scalable Web Applications - Tools & Techniques”. Even though my session was cut off, there was lot of people who came to me afterwards, wanting to know more about it and wanted to get in touch with me for their project needs. I was also requested that I present the session again as there were questions, but I couldn’t make it as the other sessions took time until evening. One of my major expectations of Barcamp was to network with people and that did happen and I am quite happy about it. One of the most interesting sessions and the one I liked most was of Saifi Khan’s talk on “Open Source Development Model”. It was a very good presentation and Saifi was able to hold the attention of the audience throughout his session with his wit and analogy of explaining things even though he took about an hour and half to finish his topic.

The lunch break at Barcamp degraded the whole flow, as the meal at Google was sumptuous with so many varieties that the venue became like a food show people trying out everything. To top it off the distribution of the ‘goodies’ (the freebies for the participants) happened after lunch and it became more chaotic. After this there were very few who still retained the energy to listen to more sessions. Nevertheless, since Barcamp is organized by, run by, presented by and attended by users it was an event that brought people together from various sectors and helped in networking.

For those of you who want to look at my presentation here is the link to SlideShare. For those of you who want to see everything in one picture here is my mind on the topic. Couple of photos here at Flickr. Thanks Harish for capturing the moments.

If any of you would like to discuss about the topic or have any questions, feel free to drop me a mail via rramesh at techmasala dot com.

In software architecture, defining and implementing Non Functional Requirements (NFR) impact the degree of satisfaction of the stakeholders of the system. Non functional requirements determine the Quality of Service (QoS) of the system. QoS has a huge impact on the quality of the system in terms of how well the system is able to satisfy the behavior (functional requirements) of the system. To achieve the QoS, the implementation of the NFR depends on how SMART they have been defined, where SMART refers to, Specific, Measurable, Attainable, Realizable and Traceable requirements.

QoS is not only applicable for architecture but as an individual for all of us. It determines how much of quality of service we provide in what we do. Hence working harder is not enough but working SMART’er is very important. Let’s define SMART in terms of an individual’s quality of service.

• Specific - One should know what are his/her roles and responsibilities clearly. Specific also refers to Scope here. The more you deviate from the scope of work, the more confused you will be and will lead to chaos in planning, prioritizing and executing. Simply put you don’t want to be “Jack of all trades, master of none.”
• Measurable - Completing a work is one aspect. The other aspect is how effectively the work has been completed. That would require defining a quantifiable objective that can be measured in what has been done. This leads to benchmarking yourself and determining where you stand in terms of effectiveness in what you do.
• Attainable - Defining a goal for the task you are performing and making sure that it is achievable is important to confidently proceeding in performing the task. Clearly differentiate between what is possible versus what is not possible. Time, Money and Resources are the three quadrants that play a crucial role in identifying what is possible versus what is not.
• Realizable - This defines what is expected out of what you are doing. Essentially this is the end result of what is being done and what the stakeholders expect out of your work. Remember there cannot be any task or work without stakeholders. Even if you are working on something that you are going to use, you are still a stakeholder and would have expectations. I am sure you would want something best for yourself. So if the stakeholder is someone else they too would want the best outcome.
• Traceable - There is a lesson to learn in everything we do. These lessons build the experience and expertise factor. Tracing back what is done, what went right and what went wrong will result in a collection of what to do’s and what not do’s. Remember making a mistake is OK but repeating it is not OK. A mental imprint of events that affect our emotional mind is there with us throughout our life. But that may not be always the case in the tasks that we do in our career. Hence keeping a document of lessons learnt might be very handy as you move ahead. That could also become a reference for others to use without wasting time going through the same mistakes.

There are some professions where physical effort is more needed than the mental effort. These professions could be more mechanical in nature. In such environments working harder may be sufficient. It is not the same case in software industry where mental effort plays a major role than (almost no) physical effort. While working harder is important, it is just not enough to be successful and to grow. What is needed is to work SMART. So don’t just work hard but work SMART.

This post is part of “Foundations” series of posts.

Before the development starts and before the design is done for the project the technology stack for the system has to be clearly identified. While a simple programming language could be selected to complete the system and often that was how it was couple of decades back these days we are more into higher level of abstractions that allow us to focus on just the problem. For example to develop a web application one doesn’t need to write an application server that has to handle the request and response and many other low level functions. Imagine if we were still stuck with how the trend was couple of decades ago probably I wouldn’t be writing this blog post now.

OK the point is now we have lot of tools, technologies and frameworks (TTF - is not a known acronym but for the sake of this post) that we can one off use them and not worry about taking care of so many low level details. Because these TTF go through the same process as any other project would go through to make it free from critical errors. But a task that still remains is the selection of the tools, technologies and frameworks that will aid in effectively building the system. The selection not only includes if the TTF meets the specific needs of the system but also how it can integrate well with other TTF’s with not much friction. Before the TTF’s can be selected the primary language(s) under which these TTF’s would work is as well as important. This by itself should be thought through with some of the performance requirements of the system and most important the skill set available within the organization. The selection process of the TTF’s should include not any lesser than the following.

Meets good enough requirements - While logically one won’t select a TTF that doesn’t meet all of the requirements of a system be aware of TTF’s that can do more than what is needed. While selecting such a tool may not affect the behavior of a system but it could choke the environment loading what is not required. Trying to find a tool that meets the requirement exactly maybe difficult but look if the TTF provides a way to use only those components required through plug and play or load what is required.

Environment Support - A TTF is also a program and requires an underlying environment that supports it. The TTF should support the language or the operating environment under which the system is deployed. The important point is to look for the supported versions and also look at the release notes for the specific platform.

Integration - As I mentioned earlier if there are more than one TTF’s involved and if they have to talk to each other look for compatibility. If they operate under different environment then a middle tier that can help bridge the TTF’s maybe required or look if the TTF’s provide support to talk over the network in technology-agnostic language such as XML.

Cost - The budget allocated for project and how much of it can be spent for the TTF’s is an input here. While open source TTF’s has been blooming crazy for every known area, there are few areas where commercial ones still hold the upper hand. The cost comes into picture in such an instance. Also the support provided could vary depending on open source or commercial (again depending on the package if commercial) which by itself is a criterion (see next point).

Support - What type of support is available for a specific TTF? Look for community forums, developer forums, discussion boards and any other groups other than the support provided by the company if any.

Help documents - Look for the help document provided by the TTF and how extensive it is and how easy it is to refer, use it.

IDE (Integrated Development Environment) support - Does the TTF provide any plugins for the IDE (selection of IDE if one doesn’t exist for the organization by itself has to go through certain criteria’s) the development team would use.

Tests - These days some of the TTF’s bundle with certain tests that asserts the proper functioning of the TTF. Look if one is available for the TTF you are evaluating.

While it is not an exhaustive list and there could be additional checks pertaining to specific requirements the above are some of the points to look for. Said that the selection process by itself is not something systematic or has any formula to select or not select. Such a selection process requires some experience and insights either from experts who have gone through it or from the past experiences. Sometimes failures teach better lessons.

Representational State Transfer (REST) architecture is a set of architectural principles that help in representing the state and the transition in web application in terms of application’s domain using standard Uniform Resource Identifiers (URI).  The URI’s represent the state of an application and is translated by the browser, server or application to the internal needs. For example traditionally a URL like http://www.somesite.com/orderdetails.jsp?user=xyz&order=1234 represents a request to the application to bring back the order details for the user xyz for the order number 1234.  This URL is more constrained to the internal methods of sending a HTTP request rather than a request representing an order request.  In REST the order detail state in the application for user xyz for the order number 1234 would be represented as http://www.somesite.com/user/xyz/order/1234. A significant advantage in such a representation and access mechanism is the easy to understand URL. This can be followed throughout the application including the transitions through hyper links.

REST was formally defined by Roy T Fielding in his work on Software Architectures. It is worth mentioning that Roy T Fielding was also one of the co-founders of the famous Apache HTTP Server. The Web 2.0 era has graciously welcomed REST with open hands and is one of the highlights of the web sites that apply it. The hot Ruby on Rails has built in capability of REST. Java/J2EE technology by default did not have support to REST but a lightweight framework like Restlet can be used to achieve this. The FAQ section has good information about Restlet and references to REST. For not so technical readers, take a look at this blog article by Ryan “How I Explained REST to My Wife“.

Thanks to my friend Kanmani for bringing to my attention this article “FareCompare Ready to Soar With Migration to Java SE 6” in java.sun.com which is a case study of FareCompare.com, a company that posts updated airfare information much ahead of other airfare information sites.  FareCompare had to compare 300,000 to 400,000 city pairs, each with anywhere from 30 to 100 airfares, every day of the year, eight times a day, while maintaining historical databases. The case study highlights the architecture of FareCompare application and how it uses the latest JSE to achieve that high performance. A feel good factor read for Java fans.

Consider a system that has multiple applications for satisfying different purposes, for example Yahoo or Google.  Yahoo or Google have a suite of products catering different needs. But to use these services all one is required is to have one user id and it works for all the suite of applications.  The solution is to have a Single Sign on (SSO) Service.  A SSO Service acts as an interface to a set of subscribed application that needs user authentication and authorization.  An application that has signed the contract with the SSO can request to authenticate and authorize a user credential which could be shared across other applications.  This decouples the authentication and authorization features from the applications and could be handled by the SSO service in a secure manner.  With Yahoo or Google the suite of applications belong to one enterprise, hence the service could be internal and all the applications could be accessing this service centrally.

But the emerging Web 2.0 trend is to move out the enterprise services and use the internet as a platform to share these services not just within one enterprise but many.  When I saw MyOpenID it is evident that the web world is definitely moving in the direction of moving enterprise services outside of the enterprise. It is going to definitely make life easier as there will be one central point of access for specific information and redundant information is not spread across. Another advantage is that applications and systems can use common services and can just focus on the specific business problem.  Though what level of information is to be shared and the level of security is a big question to be answered convincingly.