Software engineering using SaaS on Cloud computing

Cloud computing is one of the most important trends in the Internet industry. For a market overview the BVP website is a great place to start. The report: Bessemer’s Top 10 Laws of Cloud Computing, gives a detailed perspective over the Cloud business, and the companies that are driving Cloud innovation. But if you want to understand Cloud technology in practice, the best approach is to sign for the software engineering online course from Armando Fox, and David Patterson.  The course is available on Coursera or edX. You can also buy the book: Engineering Long-Lasting Software, An Agile Approach Using SaaS and Cloud Computing.

The course teaches software engineering using SaaS on Cloud computing, highly productive tools and frameworks (Model-View-Controller), and Agile development. In practice the course enables students to take a SaaS project from conception to public deployment using the following technologies: 1) Server side: Ruby on Rails, 2) Client side: HTML, CSS, AJAX, 3) Deploy using cloud computing: Heroku, AWS. The professors have done a great job in providing videos and other resources (e.g.: Virtual Box software) to support the understanding of the course concepts.

In this post I would like to focus on the book chapter 2, which refers to the architecture of SaaS applications. Using altitude as analogy, the following notes illustrates important structures in SaaS at various levels:

  • 100.000 feet, Client-Server Architecture: SaaS web apps are an example of the client-server architectural pattern. Pc+browser is the client and a Pc+WEBrick (or Apache/IIS) is the server. The server is specialized to handle large volumes of requests, and in a SaaS environment is where most calculations are made. An alternative is to have JavaScript client programming where the complexity moves to the browser (e.g.: Google Docs). An example of alternative architecture is peer-to-peer where every participant is both a client and a server (e.g.: BitTorrent)
  • 50.000 feet, communication – HTTP and URIs: web browser and server communicate using HTTP and TCP/IP protocols. TCP/IP permits to create a link between the user PC and the server. While the link is created, HTTP defines the rules for the dialogue between the client and the server. At this level, other 2 important aspects are DNS and Cookies. DNS permit to use an URI (uniform resource identifier) instead of IPs. A Cookie is a piece of data sent from a website and stored in a user’s web browser while a user is browsing a website. When the user browses the same website in the future, the cookie can be retrieved to notify the user’s previous activity. This is needed because HTTP is a stateless protocol. The Web is primarily a client pull client-server architecture. Is interesting to know that with HTML5 there is some support for server push architectures
  • 10.000 feet, representation – HTML and CSS:   If the web browser is the universal client, HTML is the universal language. HTML is a markup language interpreted by the browser to display content. CSS (Cascading style sheets) enable the separation of document content (written in HTML or a similar markup language) from document presentation. To understand these concepts in a more practical way, you can watch the following videos.
  • 5.000 feet, 3 – Tier Architecture & Horizontal Scaling: Web apps are structured as three logical tiers. The presentation tier usually consists of an HTTP server (e.g.:  WEBrick, Apache, IIS). The HTTP server forwards request for the dynamic content to the logic tier supported by an application server that support one or more Web application frameworks. In the book, the framework is Rails, and the applications software is Rack. Rack can speak directly with WEBrick; Apache instead would need more software applications. There are other alternatives like Google AppEngine, which runs Python or Java. Being HTTP a stateless protocol, application data must be stored in a persistent tier (e.g.: SQLite, MySQL, PosgreSQL). Cloud computing permits scaling the presentation and the application tier using load balancers. Scaling the persistent tier is more complicated.
  • 1.000 feet, Model-View-Controller (MVC) architecture: an application organized according to MVC consists of 3 types of code. Models contain the code that manipulates the data in the storage tier. Views present the information to the user and permit to interact with the app. Controllers select the appropriate models depending on user actions on the view. In MVC SaaS apps, every view interaction will call a controller that will select the proper model. Other apps structure can be used, but the best fit for Rails is MVC. Ruby is the language used for the model and the controller, while Haml is used to create the views
  • 500 feet, Active Record for Models:  every application need to transform the data manipulated in to stored data. In other words the in-memory data need to be transformed in a storage representation (this process is called serialization or marshalling). The problem of structure storage is not new, in 1970 a solution was offered via RDBS (relational database management systems), where data is stored in tables. In the Rails framework the pattern used for storing data is Active Record. In this architecture each entry (single instance of a model class) corresponds to a row in the RDBS table. In Active Record pattern, each model has built-in behaviours that directly operate with the database using four commands:  create, read, update, and delete (CRUD). An alternative to Active Record is Data Mapper
  • 500 feet, Routes, Controllers and REST: In Rails each controller action is handled by a particular Ruby code in a controller file. Therefore each HTTP request must be mapped to the appropriate controller that will execute the Ruby code. In Rails this mapping is called route. An HTTP request consists of both an URI and HTTP request method (GET, POST, PUT, DELETE). If the HTTP request is self-contained and includes all the information to satisfy the request, it’s said RESTful (Representational State Transfer). Rails generates RESTful routes by default
This entry was posted in Tech. Bookmark the permalink.

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s