Words of wisdom: In software systems it is often the early bird that makes the worm.

Strong Web Application Architecture

Written by Marcel Folaron. Posted in Architecture.

This is what your web application architecture should be!

Every once in a while, I get to architect a new system, a web application, from scratch and every time I spend most of my days researching good architecture, trends and best practices about web application architecture. Over the years, I have learned that there are a few basic rules around architecting systems.

#1 Scalability

Ensure that your architecture can be scaled horizontally, across multiple servers and across multiple regions. That means that once your traffic goes up, you should be able to add and remove new servers as you (and your application) please.

#2 Availability

The architecture should support a high availability environment. What happens if one, two or three servers fail? What happens if a whole region fails? (that does happen: http://techblog.netflix.com/2011/04/lessons-netflix-learned-from-aws-outage.html )

#3 Security

Your architecture should expose only the minimal amount of code possible. Most of the back-end pieces should be hidden away. In addition to that, security of each system should be multi-layered. What happens if you hack one layer of the system? Do you get access to everything or just a small piece of the system?

#4 Extensibility

You should be able to swap out modules, change layers, and add pieces to your application without having to worry about the underlying data contracts you have in place. Extensibility should be easy and fun - you shouldn't have to worry about where you start or what you might break!

#5 Separation of responsibility

Your system should be modular enough that each piece of code has a set of responsibilities and not more. Your back end should not create front end code nor should your front end code include business logic.

So what does a good architecture look like?

The basics of a good architecture is to layer the application into multiple autarkic and autonomous applications that can be replaced individually and allow us to keep the application running while we are working on a specific layer. The communication between each layer should be a RESTful API call with JSON content. For the sake of a good example, we are going to discuss creating a cloud based music management application. We should be storing music in the cloud and be able to find it, add more music and extend our library to whatever size we need.

Why not use service bus or other service based architecture you might ask!
Good question. The reason for a RESTful API is plain and simple flexibility. Using service oriented frameworks like Microsoft WCF or JavaBeans ties two of our layers to a specific programming language and architecture (Java or C#). We want to be able to replace each layer independently and even use different languages that might be better suited for a certain layer.

The foundation of our application is a strong data layer. The data layer includes our data store, be it a database, main frame (yes they still exist), or any other data storage solution. I suggest using something like AWS RDS which offers all kinds of features, but its scalability and extensibility are among the best.

The next layer would be the service layer. The service layer handles the interaction with the data layer and should be the only layer that has access to the data. Within this layer, we would implement the Repository Pattern and the Unit of Work pattern to ensure we have an efficient way of talking to our data and handling our Business Entities right. There is no business logic in this layer. All we do in this layer is Create, Retrieve, Update and Delete (CRUD) to the data layer. The repository and Unit of Work pattern keep everything clean and organized. However, what we can do is separate our access points into different business objects. Using our music library example, this layer could have services like artists, songs, and genres. The service layer exposes multiple API calls but all of these are tied to a very simple system:

  • Services.app.com/get/author
  • Services.app.com/new/author
  • Services.app.com/delete/author

Each of these services would expect a JSON object in the POST parameter, parse this and do the rest.

The next layer would be the business logic layer. This is the layer that handles all of our application logic - including validating user input and data manipulation. In our music app example, this layer could handle search input, streaming services, and routing to different pages, etc.

Many applications stop at the business logic layer and implement some sort of MVC application (SpringMVC, Razor & .Net). However, I would like to go a step further and introduce an independent Front End Layer. Why not use the great MVC apps out there? Well, just like we didn’t want to use a service bus of any sort we want to make sure that our frontend is not bound by any frontend frameworks. Creating HTML based off of Razor or Spring MVC will tie our frontend to the Business Logic Layer and make it impossible to swap out. Instead, we should create a frontend that uses a JavascriptMVC framework like Angular or Knockout to make requests to the business logic layer. Again, all communication would be through RESTful APIs and JSON objects.

Here is a diagram of the different layers:

How is this Scalable?
Since each layer is a single application, we can use multiple servers for each layer that are controlled by load balancers. Based on how heavy the operations of each layer are, we can use 4 servers for our data layer and 2 servers for the business logic layer or vice versa. Traffic will show how many servers are needed but with our good architecture, we now have the option to scale horizontally infinitely (well almost…).

How does this have a higher availability?
Let’s say we have two servers powering each layer of our application. Even if each layer loses one computer (50% loss), we are still up and running. We would have to lose two servers in one layer to create problems. However, we can easily add caching layers between each layer to catch any downtime.

Why is this secure?
The only layers that are exposed to the public are the frontend layer and the business logic layer. Service layer and data layer are behind multiple firewalls and cut off from any direct access.

How is this Extensible?
The fact that we made sure all communication is being sent through RESTful APIs means we can swap out each layer or add to each layer whatever we want. We are not bound to any programming language, protocols or systems. We can use Microsoft WebAPI for the service layer, MySQL in our backend and NodeJS in the business logic layer.

How do we separate responsibility?
When working in bigger teams, you will work on different parts of the system at the same time. The bigger your team grows the more complicated a monolithic application gets. Everyone needs to know everything to be able to change a small part of the system. In our example, small teams can handle individual layers of the system without being overwhelmed by front end problems or business logic problems. The systems are easier to understand and different specialties can focus on their piece of the cake e.g. front end developers on the front end layer and data base engineers on the data layer.

What is your experience with architecture? How do you separate your applications? Let me know in the comments. 

Joomla SEF URLs by Artio