5. Three-tier Applications

To conduct commerce and offer services online in the early days of the web, you had to build a lot of custom software. You may have had to write a web server, or at least write extensions to an existing one, so that you could process user input. And if you expected traffic, you needed a way to queue up requests for handling by the back end system.

To contact your customers, you probably had to hack together an interface to an email system. With few commercial email systems available to interface with, you probably hosted your own sendmail, a program with notorious configuration challenges.

Oh, and you want to collect payment for products and services? Then you need to interface with a payment processor as well.

All of this effort left little, if any, time for nice things like:

• Translating your site into multiple languages (“it’s English-only for now…”)
• Continuously backing up your customer data in case of a database crash
• Profiling response time and considering upgrading your servers
• Deploying multiple servers behind a load balancer for resilience and scalability
• Building a replica of your entire system at a second site to which you could fail over by a simple DNS update in the event of a disaster

The “three tier applications” of the 2000’s were powered by either commercial off-the-shelf (COTS) software (e.g. IBM’s WebSphere application server and DB/2 database) or nascent open source software (e.g. Apache HTTP Server and MySQL).

The most common open source configuration of that time might have been the “LAMP” stack: Linux, Apache, MySQL, and PHP.

With your open source or commercial software installed, a process that took you only a week or two, you could focus on site content (writing HTML), order handling (writing PHP or maybe Perl), and collecting revenue through payment processors.

When your business was up and running, you could consider those “nice to have” items. Your web server supports content in multiple languages; it has a configurable email interface; it works with a load balancer (a separate piece of software); and it supports various techniques for High Availability and Disaster Recovery.

Investigation questions:

1. What is availability? How is it measured? What is considered High Availability?
2. What is disaster recovery and how does it differ from High Availability?
3. How does a load balancer work?
   a. What does it do?
   b. Where does it fit into a network design relative to firewalls?
   c. With a load balancer in the system architecture, where are the two ends of HTTPS connection in an online shopping session?
   
4. A load balancer in a three-tier application may need to scale as the system load increases. Scaling up is always one possibility. Could it scale out instead? How?
5. How does the database in a three-tier application scale as the system load increases? Scaling up is always one possibility. Could it scale out instead? How?

Topics for discussion

• Which problems are nicely and neatly solved by a three-tier application?
• What are the weak points of the three-tier design?
• The open source movement has been a catalyst for the growth of web-based commerce. What are some pros and cons of using an open-source software stack to build your application versus buying “on-premise” software versus deploying on a cloud?

Further Reading

TBD.