Most of the sophisticated web application frameworks create monolithic applications. These frameworks include Grails, Rails and Django. As DHH has pointed out, you can scale monoliths to very large sizes. Simply breaking up a monolith because service oriented architectures are the current fad is not a recipe for success.
The problem with monolithic software is that it can consume more resources than an architecture with distributed components. This resource cost is directly reflected in Amazon Web Services bills.
nderground has a monolithic model-view-controller architecture created with the Grails framework. Currently nderground consists of about 20K lines of Groovy and Java code (which does not include many hundreds of thousands of lines of infrastructure support from Java libraries, Spring, Hibernate and Amazon Web Services). Converting nderground into a fully distributed “service oriented architecture” would be difficult from a development point of view and would be much harder to maintain and debug.
There are some pain points in the nderground architecture than can be turned into services running on Lambda. These are:
- Email support
- Image scaling and rotation
- Image display
nderground sends email notifications when someone in the user’s Karass (group) posts on their board, adds a comment or posts photos in their gallery.
Although sending email is not processor intensive, there is latency as the email transaction completes. This can tie up a threat in the Tomcat web server. When lots of users are posting on ndergroud, this can deplete the web server threads, which slows down the web server performance experienced by the user.
In order to avoid impacting web server performance, I built a threaded email service which adds a non-Tomcat thread for each email transaction. However, this is still consuming memory and overall system thread resources.
When images are downloaded, a thumbnail and a scaled version of the image is created. Images from mobile devices may also have to be rotated to correct their orientation. These operations are processor intensive and can result in forcing the Elastic Beanstalk load balancer to add more EC2 resources.
Image display is similar to sending email in that it is not processor intensive, but can have high latency since it ties up an HTTP transaction and the associated thread. For example, if images are displayed on a relatively slow Internet connection on a mobile device, more EC2 resources may have to be added to provide more web server threads.
Each of these three services can be defined as an isolated service and implemented using Amazon Lambda. This does not require “tearing apart” the monolith, but simply moving existing functionality into a distributed service.
The payoff for moving these services to Lambda is, I hope, lower AWS costs and higher performance, since Lambda scales smoothly. It should, for example, be faster to instantiate a Lambda instance than a new EC2 instance running Tomcat and the monolithic nderground application.
