Design patterns for cloud architecture

Cloud is expensive. So are microwave ovens. i.e. if you keep them running even when you don’t need them.

• K8s promises to address this by providing a framework for capacity management.
• But promise doesn’t translate to actual cost savings.
• Capacity planning is a hard problem and continues to be even with K8s (albeit a little less hard).

Most cloud costs are inflated and to have a meaningful impact on your $$, you need to have leverage to negotiate the price list.

• Identify the largest contributors towards your $$.
• Do capacity and data modeling.
• Negotiate hard.
• This one thing will have the most significant impact on your spend.

Lost opportunity cost.

• Quick turnaround for business/product requirements possible on cloud.
• Faster MVPs translate to faster iterations and thereby better dev productivity without having to worry about infrastructure plumbing
  Cloud enables such use cases seamlessly
  Catch:
  • It is important to realize that these MVPs may not be most cost optimal and built and designed solely for the purpose of unblocking a business opportunity that far outweighs the $$ spent on technology powering it.
  • Define the pivot point wherein MVPs will need to graduate to something that addresses these concerns.

Cost of moving out when things go wrong.

• Costs associated with Cloud are not just $$$ on the invoice, but debt companies incur in building dependencies on one cloud/only cloud.
• Imagine your cloud provider having a massive outage/negotiations fall through/anything else that makes you want to change.
• But your orchestration is so hard wired that you don’t have a choice and are at the other party’s mercy. At that point you pay whatever’s the price ($$, reputation, inefficiencies).
• Multicloud/hybrid clouds shouldn’t be an afterthought but a design goal.