A lot of the sites for small and medium businesses rely on dynamic engines (such as ASP.NET, PHP, etc) to generate most of the content at run-time. This kind of typical setup requires expensive hosting (relative to a small and medium size company) and (if not designed properly) may not perform very well. I would like to argue that most of those sites could be served with static HTML pages generated offline at different time intervals (either fixed or on-demand intervals, discussed later) and a Javascript Client front end that communicates with a slim server side service whose only job is to store commands from visitors into a queue. The queue can then be read and processed by non-hosted computers, freeing the business from having to pay extra hosting fees for application server.
The costs are reduced by the following:
- Static HTML sites mean less power required.
- Queue storages are usually cheaper services than full SQL Databases.
- A slim service that just relays the commands from the user to the queue and from the queue to the user should require less power than a full blown Web Application.
Static HTML sites do not require a high end server to achieve great performance. In fact, static HTML sites can take advantage of CDN and client caching. Many cloud services such as Google App Engine provide a generous quota for static content. To generate the static site, one could use many of the static site generators out there, one example is Jekyll.
A lot of user interaction in a small or medium business’ (SMB) public site do not require the ACID properties of SQL Databases. A simple Queue can reliably ensure storage of the visitor’s request for future processing, for example, a customer’s request to buy a product only needs to be stored in the Queue for the off-cloud Application Processor to retrieve it from the cloud’s queue and then do what it needs to do to process the sale. Cloud SQL databases can be expensive (e.g SQL Server on Azure), but queues such as GAE’s Queue are inexpensive and have quotas for free usage.
By having as little code running in the cloud, the cost of processing minutes can be saved. In the customer purchase example, the code to process the sale does not need to live in expensive clouds, it could live in an on-premises regular computer that checks the queue every so often. The computer that does the heavy processing can also be placed on another cheaper hosted environment if that is required by the business needs. The point is that your public facing site (the front line of your business) is as quick as possible and your back-end services (that do not require real time responses) can be placed in inexpensive environments (on-premises or a hosting provider).
Obviously, an application must be designed to make reliable Application Processors that can scale horizontally (i.e. more Application Processors can be added without impacting reliability). The back-end database to which the Application Processors connect can still be a SQL ACID database, but it does not need to be in the cloud anymore. In the customer purchase example, the sale and its details would go to its normal SQL Database after processed.
In the next posts, I will be linking to examples of sites with content that take advantage of content generated at deployment time. I will also linkt o examples using slim services that take advantage of cheap or free code hosting such as Google App Engine and Azure Websites.
Comments