Across the public sector we’re beginning to see organisations eagerly adopt the opportunities modern technology provides by building and nurturing secure, high-performing and resilient services that put the needs of end users front and centre.
Behind those services is a wealth of infrastructure and architecture built to support the changing needs of ever-adapting civic services. But how do we make sure what we’re building is fit for the future? This is where AWS Well-Architected can help.
All things AWS Well-Architected
AWS Well-Architected is essentially a best-practice guide for cloud architects. It’s a great way of going through what you’ve built and how your AWS management is set up to make sure you’re doing it in a responsible way that’s also high quality. By following a simple framework, you can make sure you’re effectively reviewing your architecture design.
The AWS Well-Architected framework documents an approach that allows you to understand if a specific architecture aligns well with current cloud best practices. To support Solution Architects and Chief Technology Officers, the framework gives a consistent approach to evaluating systems against the qualities you expect from modern cloud-based systems. Though this may sound complicated, it’s actually pretty simple.
The review is built around 6 pillars:
- operational excellence
- security
- reliability
- performance efficiency
- cost optimisation
- sustainability
These pillars will be familiar to seasoned DevOps engineers and not come as a surprise, but the AWS Well-architected review moves it into the 21st century.
Let’s talk functional and nonfunctional
The review raises the importance of different aspects of your build. It focuses on both the functional features you need to build to make the service work, and also the nonfunctional architecture, where we think about things that will help us if the service goes down suddenly.
The type of questions it asks the development team to get them thinking more about nonfunctional parts could be:
- do we know if the service is working well?
- can we recover from disaster?
This is particularly important, but easily overlooked. When we think of cloud architecture, it’s easy to think only of what we’re building, but we need to make sure we’re giving equal focus to the other supportive stuff too. Leveraging those nonfunctional requirements is crucial and the review is a good way of making sure we’re doing it effectively.
To give an example, a client we recently worked with provides emergency services to people in the UK. They use digital tools in emergency situations and often have to work quickly. So if the performance of the digital tool is poor or it’s just flat-out broken the business impact is significant.
Through the review, we were able to make sure there were these crucial nonfunctional considerations and solutions in place. It’s very easy to focus on what features your service should have, but the context of the user’s working environment is not always a focus of the architecture leading to performance and reliability becoming a second-class system. The well-architected review helps us shift the focus a bit.
Benefits of a well-architected review
There are 3 main areas of benefit that I see in reviewing projects using the framework.
Reframing our retros
It’s really useful to have this ongoing technical review. In lots of ways, it’s similar to a retrospective. Often we’re focused on delivering: doing the stuff and getting the features out there in the world and improving ways of working. But this review adds a regular cadence of looking at what we build from a technical, performance, operational or security or perspective and asking penetrating questions.
This retrospective is a practice you actually do over several sessions. And then you record it in the AWS app. You keep track of your notes and the days you made them. You can revisit at any point and say “we were going to do this” or “this was a risk – have we solved it?”.
We don’t always do this type of architecture retrospective, and that’s where AWS Well Architected Review nudges us in the right direction. Asking have we forgotten to do some things or do we need to do more?
Knowledge sharing
There’s a bit of knowledge sharing in there as well. By doing these retrospectives and talking about what we’ve done and what we haven’t, people in the room can say “oh, I didn’t realise we did that”. Because people move around on projects a lot it’s good to do these check-ins.
It helps us all think a little bit more through the lens of support, and particularly what operational aspects we may need in place to help the team. It helps us think beyond just building the thing and getting it working. It’s a good thing for our team to do regularly and helps our software engineers to learn best practices for any future projects.
ROI is crucial
We’d be wrong if we didn’t mention return on investment. Taking on the well-architected review is great for organisations to help their design teams truly deliver a higher quality technical service. And bonus – it’s less likely to fail. Not only that, it also means having a service that’s easier to work on and much better understood by everyone involved.
Best practice for all
Ending on a high, what I really like about AWS Well-Architected is that more widely it can be described as best practice for all cloud operations. It takes the best parts of those good old-fashioned cloud ops practices that have been around for a very long time and gets rid of what’s not relevant anymore.
It’s clear, easy to work through and provides a really great framework for helping us evaluate architectures and implement scalable designs in the public sector.
If you want to learn more about how we can support you with AWS well-architected, please get in touch. Or if you’d like to learn more about the work we do here at Made Tech you can subscribe to our Made Tech Insights newsletter to get new blog posts straight to your inbox.
About the Author
Principal Technical Architect at Made Tech
