Cost Oriented Architecture of Cloud Applications

As I was speaking to a group of customers few days ago, one question kept coming back - the impact of the architecture decisions on the monthly charges. The operational expenses of an application deployed to Cloud can be significantly impacted by the architecture decisions. Typical Cloud storage costs around $0.15/GB/month. Imagine if one decides to store all the web logs (for behavior tracking) in such a storage. one can pay huge monthly bill because of this decision.

Similarly, if an eCommerce  application uses huge product catalog like that of a consumer retail web site, the merchandizing process can leave lot of retired products in the storage; unless data archival strategy is part of the core architecture, the opex of the application can dramatically increase as the time progresses.

Same principle can be applied to the growth of the transactional information in Cloud based applications. The event streams (system, application, business) generated through the instrumentation can start adding to the monthly opex if the architecture does not take into the account the cost implications. One may be better off by streaming those events out to an on-premise BI and problem management systems so that you may be better off by paying one time egress charges than the perpetual monthly storage costs.

The above is quite different for on-premise operations as there are no usage based fees. The data archival strategy is often an afterthought than the core part of the architecture.

So an architect transforming from an on-premise system space to the Cloud environment, need to be aware of the impact of the architecture decisions on the monthly bill.

I don't mean to introduce a new term but I think "Cost Oriented Architecture" is a fitting term that can be described through a collection of principles that will help architects create better Cloud based systems optimized for opex.

Here are a few random thoughts about the Cost Oriented Architecture for the Cloud:

• Archive your data to a less expensive storage
• Check the temporal growth of the reference and transactional data
• Weigh the impact of perpetual storage costs versus one time egress charges to stream the data out
• Events streams (system, application, business) resulting form the operations can be piped back to the less expensive storage
• For large eCommerce sites, the generated behavioral tracking data can have a huge impact on the monthly opex.
• Compression of text payloads wherever possible
• Trim the number of active web servers in a web farm based on the heuristics of the operations
• Use batch transactions if the underlying storage supports such a feature

 

- Hanu