DEV Community

Cover image for Dr. Werner Vogels on the Art of Being a Frugal Architect
Avinash Dalvi for AWS Community Builders

Posted on • Originally published at internetkatta.com

Dr. Werner Vogels on the Art of Being a Frugal Architect

Hello Devs,

In this blog I am going to share interesting insights shared by Dr. Werner Vogels at AWS re:Invent 2023 on 30th November 2023 in his keynotes. Let me take you through all insights.

3 Pillar of Frugal Architect :

  • Design

  • Measure

  • Optimize

Let's understand in details those 3 pillars of the frugal architect.

Cost is NFR ( Non functional requirement ) :

Cost is a close proxy for sustainability. Most of the times what overlooked while building product is cost. While non-functional requirements define how a system should operate, encompassing aspects like accessibility, availability, scalability, security, portability, maintainability, and compliance, cost often gets neglected in this process. Cost is important factor to consider while designing your solutions.

By considering cost implications early and continuously, systems can be designed to balance features, time-to-market, and efficiency

Systems that Last Align Cost to Business

Any durable system depends on how well its costs are aligned to the business model. It has walk hand in hand together. Any technical decisions has to take considering business aspect.

"Find the dimension you are going to make money over, then make sure that the architecture follow the money. "- COST-AWARE, Architectures 2012

Architecting is a Series of Trade Offs

Align your priorities while architecting your solutions or infra. Achieving a truly effective cloud architecture necessitates striking a delicate balance between business and technical requirements, aligning with your risk appetite and budgetary constraints. Frugality isn't merely about cutting costs; it's about optimising value. To achieve this, it's essential to establish your true willingness to pay for specific features and capabilities.

In architecture every steps you took is comes with trade offs.

Every engineering decision is a buying decision

Unobserved Systems Lead to Unknown Costs

He told one insightful story from Amsterdam. There were two buildings with similar structure. But one was getting more power consumption and other was getting less power consumption. Why so ?

Answer is in below image. Look at image carefully. One building was consuming more power for that meter was installed in basement and other building meter was installed after entering front door side. What you got from this ?

More you observe or analyse more you can save. Basement is place where we go occasionally so observation was few times vs hall way meter observation the point when you enter into house. This observation highlights the importance of careful observation and analysis in identifying hidden inefficiencies and opportunities for optimisation. Just as frequent monitoring of the meter in the hallway led to improved energy consumption, regular scrutiny of our architectural decisions and resource usage can lead to cost savings and enhanced performance. The more we observe and analyse, the more we can refine our infrastructure and deliver better results

Cost-Aware Architecture Implements Cost Controls

Define you tiers like tier1, tier2...tierN. Which are pieces of my systems need to be up and running. Decompose your application into small pieces of blocks and categories them by criticality.

Cost optimisation must be measurable and tied to business impact.

Cost Optimisation is Incremental

Making sure your systems are cost-effective is an ongoing process. It's not something you do once and then forget about. You need to keep checking your systems to find ways to make them even more efficient

In simpler words, imagine you have a garden. When you first plant the seeds, you need to water them frequently. Once the plants have grown, you don't need to water them as often. But you still need to check them every now and then to make sure they're healthy and not getting too much or too little water.

It's the same with your cloud systems. You need to make sure they're set up correctly from the start, but you also need to keep checking them to make sure they're not using more resources than they need.

There is always room for improvement… if we keep looking. The savings we reap today fund innovation for tomorrow.

Unchallenged Success Leads to Assumptions

"The Most dangerous phrase in The English language is : 'We have always done it this way...'" - REAR ADMIRAL, GRACE HOPPER

Rightly said. Tendency to become overconfident in methods, tools or programming language is dangerous. Don't assume whatever you are build today will best always. Swipe away that assumptions. Open up to do experiment. Come out of your disconfirm. Dr. Werner gave nice examples like "We are a Java shop" or "We are great at Rails" etc. This are dangerous assumptions. Lets avoid those and build better.

Conclusion

"Now, go build"

Some of the words or sentences I used were the way Dr. Werner wrote or talked about them to keep the same approach to what he wanted to convey to the audience. I hope you like these insights. If you have any feedback or comments, please feel free to drop them in the comment section.

References :

Top comments (0)