We know that your environment changes constantly. Your teams spin up new instances and experiment with managed services. So how do you manage change and keep up with user demands?
We talk about the well-architected review. It’s starting to gain popularity in the software industry. Grady Booch tweeted about it. He is a fantastic software architect who has done a lot of pioneering software engineering. Grady says it’s good that AWS, Azure, and Google offer guidance on building with their well-architected reviews. But he also warns that when cloud providers talk to you about being well-architected, it comes with a bias toward their products.
Cloud provider bias and well-architected reviews
There is an inherent bias among cloud providers who are investing in these frameworks. They will have a particular leaning towards their ecosystem and services. There’s a big but here! You’ll find that they are broadly applicable. The exciting thing about the AWS framework is if you squint at it sideways, you can extract the implementation details. And focus on the principles and values behind delivering a well-architected solution. You can abstract considerable value, even if you don’t embrace the services aligned with that cloud provider.
You can run well-architected reviews independently.
I have run well-architected reviews on non-AWS, but I work primarily with AWS. But I’ve run pillars, like the operational excellence pillar, with squads not working directly in AWS. It’s the collaboration, questions, mindset, and thinking that is good. And they are reasonably consistent across whatever tech stack or platform you’re leveraging. There will always be a bias toward the cloud provider as you will work within certain constraints or conditions when working on one platform. The questions are very similar. And the answers may be different. But even just asking those questions is hugely valuable. And as long as you apply it to your context, you can get much value.
Helping non-technical colleagues to understand architecture
I remember having discussions with people who were asking what architecture is. They needed to figure out what architecture was and were trying to redefine architecture. With less technical colleagues, you need to give them a definition of what architecture is. Also, I remember presenting a comparison of the three cloud providers to prove that well-architected is a thing and not just something I made up! And from the comparison, I found that all three cloud providers had roughly the same stuff.
AWS drives forward through principles or tenets. But a lot of the principles in the framework are applicable elsewhere. It is a clear framework that you can reuse. Azure is like a wizard, as it takes you on a path, which is good 90% of the time. But what happens if that’s wrong for you? And Google was excellent, but the bar was relatively high. It’s hardcore SRE, or we don’t want to talk to you. The culture of each provider comes through with the framework, which is interesting. But they are all excellent frameworks.
If you leverage AWS, you are going to be EDA.
I think the statement that being well-architected comes with a bias toward our products is fair. With AWS, if you leverage a lot of AWS services, you’re going to be EDA. So that is going to bias you toward operating in specific ways and leveraging certain modes of communication. Whether it’s Kinesis, EventBridge, or SQS SNS to connect things, it’s a statement of fact. If you’re going into these spaces, you will work a certain way. If you are leveraging AWS in the cloud, you need to be working in EDA, and you will be biased toward leveraging those services.
With Google, I am interested to see why they focus so much on SRE. There may be a requirement on squads to look after resources when they are up because it’s more container oriented. The folks at Google believe that customer success is through proper SRE and operational excellence. A lot of the SRE principles came from Google. We’ve met people who put original work together while they were at Google.
Should you ask a cloud provider to do a well-architected review?
A cloud provider will write a framework in their language. And it will have a bias toward their products. So you need to see that difference. Second, if you ask a cloud provider to do a well-architected review of your product, you will get a solution architect from that cloud provider to come in and do it. And all they know is their products. So if you get an AWS solution architect to review your product, they’ll start recommending AWS products. That is a significant learning.
The lesson is that it’s not the framework but the process you put around it. And the process does not need to involve the cloud provider. We can run that ourselves. And we can apply the framework ourselves. It is a significant shift to use well-architected as a benchmark to self-assess. You need to be brave and apply your context. Let’s ask these questions, run this process against our workloads, and see what lessons we can learn. And where can we learn, measure and improve?
Establish your feedback loop.
The great advantage of doing this yourself is that you establish your feedback loop. So you’re seeing what works, what doesn’t, and where your gaps are across all the pillars. And where you should be investing your time and your team’s time across the org. If you bring in somebody external, they lack the context. And they’re not going to be part of that feedback loop. Plus, it is quicker. I can talk to somebody about ‘well-architected,’ and we can decide to do it that afternoon. You don’t need to bring an external person in and get them up to speed. And end up with a considerable delay.
The accessibility of the frameworks
One great thing about these frameworks is that they are publicly accessible. They are not in a secret magic book on a vendor’s desk that only high-paying customers can read. These things are moving to commodity status. They’re commodity capabilities that you can google. And you can enable and empower teams to do this themselves. They can ask these questions because they are freely available. And you can read about it in our book, along with enabling teams to do it themselves with a bit of guidance and advice.
That’s important because if the team needs help, somebody senior can come and help them. If you need more help, you can bring the cloud vendor because you’re working on the same framework. In other words, we’re doing this pillar and need help with these three questions. The cloud vendor can go straight because there’s a benchmark there.Common language is critical. Because the org delivers well-architected solutions, the cloud vendor can determine what that means for them and their colleagues.
How can you combat cloud vendor bias?
You can combat bias when you use Clarity of Purpose, which is Phase 1 of the Value Flywheel, with the well-architected framework. Your focus will be on solving the problem with the tools you’ve got at your disposal. And you’re able to leverage tools faster and more efficiently. The bias works to your advantage. It isn’t something your architect does to you; the team should embrace an iterative and incremental process. We’ve written about this a lot in our SCORPS process, which is also in the book. It doesn’t need to be a big, scary thing that an architect from on high comes down and imposes on you. It can be a beneficial learning and enablement tool.
The well-architected tool becomes your benchmark.
You need to constantly self-assess. Slight continuous improvement paves the way to significant gains. Well-architected is the benchmark we baseline ourselves against. And we revisit that every couple of weeks to check how we are against it. That’s how you build world-class squads, teams, and outcomes. Give Grady Booch a follow on Twitter. Search for ‘Grady,’ ‘Well,’ and ‘Architected’ to find that tweet and discussion.
Our SCORPS process is in our blog. There’s an excellent post that Mike put together. The book has a good chapter on applying a well-architected set of instructions based on that continuous improvement idea. And again, it goes back to the Long Term Value phase of the Value Flywheel. I’m glad Grady Booch is getting some attention because it is a vital topic. We need to do much more to educate people on how important this concept is because architecture is ambiguous for lots of people.
No matter what cloud you are in, seek out their well-architected guidance. Don’t custom-build your approach. This stuff’s been hardened and proven across 1000s of implementations. It has been battle-proven and road tested. You’re getting learnings from hundreds of solution architects in the field who are on that framework.
So that’s the craic. Those blog posts are on TheServerlessEdge.com and in The Value Flywheel Effect. So follow us on Twitter @ServerlessEdge and at Serverless Craic on YouTube.