Services via port binding

on

This is Rule VII from The Twelve-Factor App.

That is, Web apps need to use a reverse proxy like nginx or the like. To see why this important, let me give you a brief background: Historically, Web apps are executed inside a Web server container. For example, PHP apps might run as a module inside Apache HTTPD, or Java apps might run inside Tomcat (courtesy: Twelve Factor App). The Web apps are tightly coupled with a Web server.

Why you should decouple a Web app from a Web server?

1. Efficiency

From Peter Smith, author of “Professional Website Performance”:

Nginx (pronounced “engine X”) appeared on the scene in the mid-2000s, and although initial uptake was slow because of lack of documentation, it has quickly gained in popularity. Many surveys now show it to be the third most used web server (behind Apache and IIS), and it is particularly popular for high-traffic sites. Nginx’s structure is notably different from Apache’s. As you have seen, Apache uses processes or threads (depending on the MPM used), each of which use significant resources (not to mention the overhead involved
in creating and destroying child processes). By contrast, Nginx uses an asynchronous, event-driven model, which removes the need for each request to be handled as a separate child/thread. Instead there is a single master process with one or more worker processes. The performance impact of this change is huge. Whereas each additional Apache process consumes an extra 4 MB or 5 MB (if the likes of mod_php have been loaded, this figure will be more like 15+MB) of memory, the impact of additional concurrent requests on Nginx is tiny. The result is that Nginx can handle a huge number of concurrent requests — much more than Apache, even with the newer threaded MPM.

2. Separation of concerns

Static apps (client-side)

When you decouple the presentation layer of a Web app from its business logic layer, the former can be served simply as static files and the latter can be architected as Web services (RESTful). Better yet, front-end development (HTML/CSS/JavaScript) can be written by one team and back-end development by another. Static files are downloaded once and can be cached resulting in faster performance compared with server-side pages (like ASP/JSP/PHP) that are dynamically rendered on the client-side. See staticapps.org for more
information.

Web services (back-end)

With Web services, you are no longer confined with the constraints of a Web server. You are no longer thinking in terms of Web sites. Instead, you design your back-end such that you can easily replace your HTML front-end without breaking functionality. Web services go beyond Web sites. Just look at Amazon Web Services. It redefined IT infrastructure by exposing compute/network/storage functionality as programmable Web APIs. Its AWS management console is just a window to what lies underneath. Now if you’re thinking Web application development has gotten more difficult with Web services, think again. You don’t have to assume the role of a Web server because there is a reverse proxy. You can delegate serving static files to a Web server to offload tasks with your backend Web apps. However, you are now concerned with health checks of your backend apps (like restarting crashed apps). Fortunately, there are open source tools to do just that (see Hipache for example).

Advertisements

Subjectivity aside, leave a reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s