Disclaimer: This article is based on the professional experiences and intends to provide the raw and authentic experience wrapped with WAR recommendations for reviewers – what to do and what not to.
Quite a quarter with 8 WAR (Well-Architected-Review)!!! It was an enriching experience to conduct these reviews as it allowed me to learn multiple architectures & operational practices.
A fair amount is already posted on the AWS WAR program structure and its purpose to help achieve resilient, secure, and optimized infra. You can get detailed information about the WAR from the official website. I intend to share my experience and views on how to conduct a worthwhile WAR; and responses to some of the “sixty-four-dollar questions”.
Wrap your (reviewer) minds around the program
WAR needs the commitment of the reviewer far more than that of the attendees. The very reason that a team has agreed to spend their 3-4 hours on the review exhibits their confidence in the program structure. They are looking further to refining the architecture of their workload using the recommendations of WAR. It is thus of the first magnitude that we do the following before the review to ensure that we have wrapped our minds around the activity. Here is what I do (and some recommendations for you too),
- I don’t trust my knowledge, and hence I read again and again to revise the concepts of WAR; the pillars that it covers, and the objective that it intends to deliver. Read the presentation and rehearse it well before the presentation. As a reviewer, this is your best chance to convey the importance of WAR to your clients, so better do a job like ‘Jobs’ in the presentation!
- Study the questionnaire of WAR unfailingly every time before the review. It is like bracing the perspective of the WAR questionnaire. Don’t be surprised to learn and understand a newer dimension to the same question as you revisit the pillars. With every revision, it becomes fairly more meaningful than earlier.
Get your mitts on the application that is under review
- Make a bid for an architectural document, process documents, etc.
- In case if it’s inaccessible, make sure you understand the application by conversing with one of the team members before the review starts.
“Two” is company, howbeit, “three” is not a crowd
The more the participants, the merrier it is during the review. It’s important to have stakeholders, cutting across decision verticals, participate in the WAR. To conduct a thorough review mandate that app owner, infra architects, developers, finance, security team, InfoSec/Compliance team, all are present during the review.
I have conducted some reviews with a room packed with up to 7-10 representatives, and these were some of the most exciting reviews with excellent outcomes. Learning about how cloud should be architected is the most crucial objective of this program.
One workload at a time for a better review
Make sure you answer the query: Why just one application, why not the entire AWS infra?
- Application owners across the complete AWS infra will be different. You practically cannot review all of them at the same time.
- Every application may have exclusive architectural requirements and needs to be looked upon in its own context.
Best practices are always a function of cost
We can’t have all the applications with different commercial budgets magnified under a generalized idea of WAR. WAR discussion has to be specific, and expected outcomes should also be in line with business needs and budgets; which may be inversely proportional.
For example, a critical workload couldn’t be placed in an HA (in spite of being a suggested practice) if the budget doesn’t allow to do so. As a reviewer, I have always captured my comments to ensure that the right practice is clearly conveyed along with cost implications.
If the recommendations aren’t implemented, the risks, as well as the reason for keeping the risk open, should be known and acknowledged by all. This is purely my understanding and maybe a deviation from the intended objectives of WAR.
Suggested Reads: AWS RDS database should not have default master username
Why does AWS have WAR Authorized Partners?
The AWS Partner ecosystem consists of certified and audited organizations with diverse experience in handling complex workloads. They have a team that is trained by AWS Professionals as WAR Leads, thus ensuring that the review is delivered with the right mix of experience and knowledge. They act as extended arms of the AWS Solution Architects team, making the outreach more effective.
Also, the WAR tool is available on the AWS portal can be used by anybody, but the idea is to add a perspective that is neutral to the context around which the infra was deployed.
Does AWS WAR review recommend to consume more of AWS cloud services?
Yes, but No!
WAR recommendations may undoubtedly point at the use of an AWS service; but that is simply because the solution to an identified gap can be achieved using native capabilities; instead of a third-party solution. So, why not?
The idea is not making your workload consume more services; it is merely to put it in best posture using native capabilities such that the business objectives are well aligned with the digital transformation objectives.
Are you an Auditor from AWS?
Nope, not at all. WAR is a learning activity and not an audit at all. It helps the owners across verticals of infra, security, apps, DBA, and finance & procurement, to understand and learn the best practices of AWS Cloud.
We do not conduct these reviews to find fault; but to bring out the best practices of deploying workloads on cloud. It is for all stakeholders to learn the process of running a workload; and continuing to run it with the best posture across the five pillars of Security, Reliability, Performance, Cost Optimization, and Operational Excellence.
I hope this was an interesting and informative read. Please share your experience of WAR reviews, if you have conducted or participated in one of them.