It was the mid-1990s. Y2K was beginning to get worldwide attention. The first graphical internet browser, Mosaic, had paved the way for Netscape and Internet Explorer. And Yahoo was in its heyday as a search engine.
One night, back then, I remember waking up shortly after midnight with a terrible earache. Ouch!
Considering the power of the Internet at the time – with its hypertext markup language being the standard – I fired up my trusty modem and dialed into the Internet to look up ear infection on Yahoo. A list of standard results popped up. I clicked on the one that said ear infection symptoms and causes. I was taken to what appeared to be a medical journal since I didn’t fully understand the words they were using. But I knew I was on the right track. There were two close-up pictures: one of a healthy ear cell that was brightly colored and plump; the other of an unhealthy cell that was black and brown and deteriorated.
I may not have comprehended everything, but I was completely stunned by a sentence that appeared in bold within the text on the page: “If the infection persists, the ear will fall off.”
This sent me into a panic! Alarmed, I screeched to my wife, who was sound asleep in the next room, “Hurry, take me to the ER, my ear is going to fall off!”
Startled from a sound slumber, I heard her quickly pounce out of bed and get dressed. In her tired state, she struggled to find her car keys and slip on her shoes. While she was doing that, I held my left ear with my left hand and clicked on the next page; that’s when I realized my mistake. Before me were two pictures of corn. Once picture was a healthy ear of corn on a stalk brightly colored in yellow, the other a sickly ear of corn about to fall off its stalk.
“Never mind,” I yelled to her. “My ear’s not going to fall off. I was looking at an ear of corn! It’s ok, you can go back to sleep.”
I knew at this point that an earache was the least of my problems. As I heard my wife storm down the hall, I knew I was in trouble. I felt her ominous presence behind me when she asked “which ear is in pain?”
I timidly pointed to my left ear. She took a tight grip of it, twisted and gave it a good yank. “How does it feel now?” she retorted.
Actually, it did feel better.
Since the days of my earache, the power of today’s internet browsers has opened up a whole new business model known as Software as a Service (SaaS). Instead of the static pages of the 1990s with very little user interaction, we have more powerful dynamic browser technology.
The technology back in the ’90s did not lend itself well to robust applications on the Internet. However, that all changed with the evolution of the browser. Technologies such as JavaScript, Dynamic HTML and XML are now available to provide users with robust interfaces that include such elements as menu selections, edit boxes, tabs and tooltips. However, from a user point of view, that would seem to be all that is needed to run applications on the browser, such as Customer Resource Management, Financial systems and Enterprise Resource Management. But just as there was more to the “ear” than what I saw on that Web page 15 years ago, there is more work that goes on behind the scenes of a SaaS application than meets the eye.
To really provide a successful SaaS model, applications need to be engineered in a certain way, with three distinct tenets in mind:
- Statelessness
- Load Balancing
- Multi-tenancy
Statelessness
Back in the old days of software development and server platforms, systems were written to run on a server dedicated to the application; they were known as stateful applications. If a particular task hung the system, all users on the server suffered response time issues. In my opinion, one of the failures of companies porting their legacy systems to the SaaS model was the inability of their architecture to handle such a scenario. Building an application from scratch to run on multiple servers requires the application be stateless. This means the interaction between the user’s browser and the application is disconnected multiple times during the session. Session information is maintained within the user’s computer to allow (recall the cookie concept) the server responding to the request to understand who the user is and what functions were being performed. This all happens with the user unaware of which server is responding to her request. The bottom line is that if a server suffers response time problems, a user can be directed to another server to handle future requests, once again with no impact to the user experience. This group of servers running the same applications is sometimes referred to as a sever farm. The SaaS provider maintains the server farm at their hosting site.
This leads to the next tenet.
Load Balancing
So when a request from a browser enters the SaaS hosting site, how does the system know which server will honor the request? This is accomplished through another server that is known as a load balancer. The function of this server is to check the health of all the servers in the farm. By knowing the state of each server the load balancing can pass the request to the server running with the least amount of work load. This ensures excellent response time for all users, regardless if one server is not feeling well at the moment. There are also additional benefits to this model. One is that the SaaS provider can add new servers to the farm during peak demand. Another is the ability to remove a server that may need maintenance with no impact to the user.
We next move on to the data component.
Multi-tenancy
Once again back to the olden days, if you needed to add another database you typically had to have another instance of the application attached to the new database. So in the simple scenario of a single database on a single server, if you have 500 customers each with their own database you would need 500 servers! Now comes multi-tenancy to the rescue. In this model applications are designed in such a way as to share common code with multiple databases. A single instance of the application can send and receive database requests to the appropriate customer database. In the example above, the 500 databases can reside on one server attached to a farm of application servers, monitored by a load balancing server. Pretty neat stuff!
The point is, the growing sophistication of Internet browsers has indeed facilitated the SaaS model; but also, the underlying technologies that happen at the SaaS hosting site – unbeknownst to the end user – also makes the SaaS model possible. When it comes to Software as a Service, there truly is more than meets the end user’s eyes.
