Picking the web application architecture best suited to your unique needs is vital.
In this post, I am going to talk about a few of the most common web application architectures you are likely to come across. Every web application has its own unique set of requirements and constraints so the architectures I will be listing here are just general examples. Your app might suit one of the architectures below, a hybrid or something completely different. This list is by no means exhaustive. I have explicitly excluded asynchronous architectures as that is a topic all on its own.
I’m also assuming your app has at least some server side logic and connects to some kind of database.
This post is part of a series, if you haven’t seen the previous posts in this series, you can find them here:
Single Web Server
This is by far the simplest web application architecture and is hardly ever enough for a production application. Your HTTP server and database server live on the same machine behind your firewall. The advantage of this kind of setup is that it is extremely simple and is great for the early stages of a project where you don’t have any real users yet. The largest disadvantage is that you have a single point of failure. Single points of failure are places in your architecture where a single machine going down will cause your entire application to stop working. If you need to do a deployment or something goes wrong with your server, users will not be able to access your application.
Single Web Server With Separate Database Server
In this web application architecture, we start to separate the HTTP application server from the database server. Once again, this is not yet suited for a production application. You still have a single point of failure and can’t re-deploy your application without taking it offline. It does however set you up for a web farm and other more complex architectures.
Web Farm
With this architecture, we are starting to eliminate the HTTP server as a single point of failure. We do so by introducing a load balancer. Load balancing will distribute the incoming request between 2 or more servers. This spreads the load and also reduces the risk of a catastrophic outage by allowing multiple redundant servers to handle the workload. It is important to consider the fact that your load balancer might become a new single point of failure so a highly available load balancer is a good idea.
In this architecture, our database is still a single point of failure. If your database goes offline for some reason, you are still left with an application that is unable to service your users.
Web Farm With A Database Cluster
By introducing a database cluster, we eliminate the final single point of failure in our architecture. For any mission critical production system, this is probably the simplest configuration that allows for a robust highly available system. I have intentionally left the details of the clustering vague as there are many many ways in which you could cluster a database. MySQL and MS SQL Server have their way of clustering while No SQL databases like MongoDB do it slightly differently. The important thing to understand is why you would want to cluster. The exact technical details of how to go about setting this up differs depending on the technology you are using.
Web Farm With Dedicated Application Servers
For more complicated scenarios where you have multiple subsystems and/or 3rd party systems (this is often the case for medium to large size corporates), you might start introducing application servers. Each web front end communicates with one or more application servers behind an additional firewall. For the sake of simplicity, I have included only 1 application server per web server but it is quite feasible to have many application servers per web server. Often, these are split by function for example payroll, billing, CRM etc. Splitting your solution up in this way allows you to keep the complexity of each subsystem lower.
Having an additional firewall allows you to create a DMZ (demilitarized zone). The purpose of the DMZ is to add an extra level of protection between potential intrusion from the internet and your internal systems. If a hacker were to compromise your web servers, she/he would need to get through an additional firewall to gain access to highly sensitive internal data and systems.
In this architecture, each HTTP server is mapped to a specific set of application servers. This eliminates the need for additional load balancers so it is slightly easier to set up infrastructurally. It does however bring a whole set of problems along with it. Configuration is more complicated and it is hard for the load balancer balancing the HTTP servers to know if a downstream app server is offline.
Web Farm With Load Balanced Application Servers
This architecture is very similar to the previous one except that it introduces another load balancer. This simplifies configuration because all your HTTP servers can use the same IP address for each application server. It also makes scaling out easier. If one of your application servers is running near capacity, you can add more instances to the cluster to help cope with the workload. In almost all cases, it is desirable to have a load balancer between your HTTP servers and your app servers.
Conclusion
While these examples should give you a small taste of the forces acting on your architecture, it is just that, a small taste. The important thing to remember is that each decision is a trade off. More redundancy at the expense of simplicity. Easy configuration at the cost of flexibility. You need to understand your environment and needs to be able to make the optimal trade offs for your situation. There is no such thing as a universally “good” architecture. There are only architectures that are appropriate or inappropriate for a specific set of constraints. These constraints evolve and change as your system grows and your user base grows so you should periodically re-visit your decisions and ensure they are still valid.
The post How to become a web developer part 5 : Web application architecture appeared first on Aesthetic IO.
Since I was young I always preferred teaching myself to learning from a structured syllabus.
This didn’t always make me popular with my teachers. I guess sleeping through the whole of Romeo and Juliet in an English class doesn’t make a great impression. On the other hand I formed an obsession with always researching something.
Over the years these obsessions would jump from topic to topic ranging from physics to lean manufacturing. Photography to functional programming. Cognition to physiology and strength training. Kitesurfing to fire poi. My obsessions may be random but are always led by my curiosity.
Over time I noticed that I was forming connections and finding patterns in unrelated fields and using knowledge I gained from studying the rudiments of things like cognitive psychology when trying to figure out why I was seeing certain behaviours in the teams I was working in.
I'm interested in communicating those underlying principles and connections in a way that is useful to others.
I have been working as a programmer, architect and manager for the last 12 years so there is a strong bias to helping junior programmers and software development teams improve.
I focus on underlying principles and not technologies.
Submit an article or tip
