Thursday, April 06, 2006
The Interstate Highway
When building roads, engineers take a lot of things in consideration: expected volume of traffic, expected load on the roads, expected length of the roads, and special terrain conditions. Much like software that spans a lot of domains -- like enterprise systems -- a solution shoud be chosen based on the expected volume of transactions, how much processing will need to be done, how much data will have to be dealt with, and special domain requirements.
For systems that are meant to serve a lot of users at any given time, and perform as robustly as possible, and minimize down time certain architectures fit the bill better than others. Let me enumerate some of these architectures that in a lot of ways, are like Interstate Highways -- high reliability, high scalability, and robust.
Three-Tier Web Applications
There are a lot of these enterprise solutions that use this architecture where the front end of the application (usually a web site, or a special client application) interfaces a middle tier holding the "business logic", and the back end usually a database management system. This architecture proves to be robust and scalable since each of the three tiers can scale as necessary -- based on demand and actual circumstances. These systems are managable too, since the different roles of the solutions are made self-contained and de-coupled from each other to a certain extent.
However, this architecture proves to be single minded -- or a better term would be domain directed. When you create web applications that use the three tier approach, usually the functionality required is programmed in the middle tier. This means you have a bungalow in between two bungalows tied together with different connectors.
This solution is attractive for clearly targeted applications such as e-commerce systems, online community sites, and content management systems. They make sense because they're essentially a three part house (or a three layered house), or a two lane highway which expands to the sides only.
Distributed Systems
A distributed application or distributed system is one where the functionality of the solution can be located in different non-dependent locations/systems where each other the functionalities may or may not be related. This allows the solution to scale well as new functionality is required, and a well-designed system for service discovery and registration is used to coordinate these different services as well as made available to different users of the system. Distributed application design allows developers to access a central service brokerage system to which service providers (which may replicate the services of each other, or provide completely different services) can register.
The main down-fall or issue in this system is the central brokerage system which becomes a crucial point of failure for the whole design. This may be side-stepped or circumvented by directly accessing the service provider in an end-to-end fashion, however this approach will make clients completely dependent on a single service provider. This end-to-end coupling is a potential point of failure which is not a solution to the original problem.
This system however is most effective in non-mission critical applications where flexibility is valued more than reliability, and maintenance is covered by different domains of influence. This system can be likened to a system of streets and side streets where a common avenue runs through all possible connections. In these systems, the avenue may be circumvented but ultimately they serve a purpose of keeping the system of streets connected.
The Hybrid
Combining the best of both the Three-Tier Web Application and the distributed system allows users to enjoy the flexibility of the distributed design, and the robustness of the three-tier design. This basically works by making the tiers distributed systems -- allowing for flexible service usage and registration -- at the same time clearly delineating an interface between the tiers in the original design.
Another hybrid of this system is making the service providers in a distributed system part of a three-tier web application architecture. This means each service provider is essentially a front end in a three-tier system where the middle tier can scale to the demands of the front end. This also allows the service providers to replicate the front end such that it can serve more users at any given time.
Only by determining the requirements in terms of flexibility, maintainability, reliability, and robustness will the right architecture for systems be determined. These decisions are usually made before hand, especially when the requirements are being determined. Making the design decisions at the start also allows the developers to gauge how much work will be done, and thus how much time it will take to come up with the system.
Knowing what to do first allows you to decide how to do it. What you need will dictate what you should be done, and what you know or don't know will dictate how you'll do it.
For systems that are meant to serve a lot of users at any given time, and perform as robustly as possible, and minimize down time certain architectures fit the bill better than others. Let me enumerate some of these architectures that in a lot of ways, are like Interstate Highways -- high reliability, high scalability, and robust.
Three-Tier Web Applications
There are a lot of these enterprise solutions that use this architecture where the front end of the application (usually a web site, or a special client application) interfaces a middle tier holding the "business logic", and the back end usually a database management system. This architecture proves to be robust and scalable since each of the three tiers can scale as necessary -- based on demand and actual circumstances. These systems are managable too, since the different roles of the solutions are made self-contained and de-coupled from each other to a certain extent.
However, this architecture proves to be single minded -- or a better term would be domain directed. When you create web applications that use the three tier approach, usually the functionality required is programmed in the middle tier. This means you have a bungalow in between two bungalows tied together with different connectors.
This solution is attractive for clearly targeted applications such as e-commerce systems, online community sites, and content management systems. They make sense because they're essentially a three part house (or a three layered house), or a two lane highway which expands to the sides only.
Distributed Systems
A distributed application or distributed system is one where the functionality of the solution can be located in different non-dependent locations/systems where each other the functionalities may or may not be related. This allows the solution to scale well as new functionality is required, and a well-designed system for service discovery and registration is used to coordinate these different services as well as made available to different users of the system. Distributed application design allows developers to access a central service brokerage system to which service providers (which may replicate the services of each other, or provide completely different services) can register.
The main down-fall or issue in this system is the central brokerage system which becomes a crucial point of failure for the whole design. This may be side-stepped or circumvented by directly accessing the service provider in an end-to-end fashion, however this approach will make clients completely dependent on a single service provider. This end-to-end coupling is a potential point of failure which is not a solution to the original problem.
This system however is most effective in non-mission critical applications where flexibility is valued more than reliability, and maintenance is covered by different domains of influence. This system can be likened to a system of streets and side streets where a common avenue runs through all possible connections. In these systems, the avenue may be circumvented but ultimately they serve a purpose of keeping the system of streets connected.
The Hybrid
Combining the best of both the Three-Tier Web Application and the distributed system allows users to enjoy the flexibility of the distributed design, and the robustness of the three-tier design. This basically works by making the tiers distributed systems -- allowing for flexible service usage and registration -- at the same time clearly delineating an interface between the tiers in the original design.
Another hybrid of this system is making the service providers in a distributed system part of a three-tier web application architecture. This means each service provider is essentially a front end in a three-tier system where the middle tier can scale to the demands of the front end. This also allows the service providers to replicate the front end such that it can serve more users at any given time.
Only by determining the requirements in terms of flexibility, maintainability, reliability, and robustness will the right architecture for systems be determined. These decisions are usually made before hand, especially when the requirements are being determined. Making the design decisions at the start also allows the developers to gauge how much work will be done, and thus how much time it will take to come up with the system.
Knowing what to do first allows you to decide how to do it. What you need will dictate what you should be done, and what you know or don't know will dictate how you'll do it.
