reInvent 2020 is coming to an end. A lot of new launches have happened since I published Part 1 of this series. Because digesting all the different updates takes time and a lot of coffee, I thought I’d help you out a little.
Following is a curated list of things that I found most important; matters related to architecture, scalability, reliability, performance, resiliency, devops, and security — anything that caught my eye, and I hope will satisfy yours.
AWS Fault Injection Simulator is a fully managed chaos engineering service that makes it easier for teams to discover an application’s weaknesses at scale in order to improve performance, observability, and resiliency. Chaos engineering is the process of stressing an application in testing or production environments by creating disruptive events, such as server outages or API throttling, observing how the system responds, and implementing improvements. Chaos engineering helps teams create the real-world conditions needed to uncover the hidden issues, monitoring blind spots, and performance bottlenecks that are difficult to find in distributed systems. …
While reInvent just started, the first keynote from Andy Jassy has had a lot of new launches. I know that digesting all the updates takes time and a lot of coffee, so let me help you.
Following is a curated list of things that I found most important; matters related to architecture, scalability, reliability, performance, resiliency, DevOps, and security — anything that caught my eye, and I hope will satisfy yours.
This is hands-down my favorite launch!
Amazon S3 now delivers strong read-after-write consistency automatically for all applications for any storage request, without changes to performance or availability, without sacrificing regional isolation for applications, and at no additional cost. …
I want to express my gratitude to my colleagues and friends Ricardo Sueiras, Matt Fitzerald, and Boaz Ziniman for their valuable feedback.
A list of my operational excellence related blog posts.
It takes three interconnecting elements to operate the technology we build successfully. First, you need to have the right culture. Second, you need great tools. And third, you need complete processes.
Part 1 of the series covers the cultural side of Operational Excellence (OE) and examined Amazon’s culture in the context of its Leadership Principles (LPs). Part 2 discusses the role that tools play in achieving OE. Part 3 covers the final aspect to operational excellence — processes — or what we call mechanisms.
Below is the AWS Summit 2020 recording of my presentation on this topic. For more details, read the blog posts…
Large-scale distributed software systems are composed of several individual sub-systems-such as CDNs, load balancers, and databases-and their interactions. These interactions sometimes have unpredictable outcomes caused by unforeseen turbulent events (for example, a network failure). These events can lead to system-wide failures.
Chaos engineering is the discipline of experimenting on a distributed system to build confidence in the system’s capability to withstand turbulent events. Chaos engineering requires adopting practices to identify interactions in distributed systems and related failures proactively, and also needs implementing and validating countermeasures. The key to chaos engineering is injecting failure in a controlled manner.
In this post, we present a simple approach for fault injection in systems utilizing Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Elastic Container Service (Amazon ECS), and its integration with a load-testing suite to validate the countermeasures put in place to prevent dependency and resource exhaustion failures. A typical chaos experiment could be generating baseline load (traffic) against the system, adding latency to all network calls to the underlying database, and then validating timeouts and retries. We will explain how to inject such failure (addition of latency to database calls), why validating countermeasures (timeouts and retries) under load is essential, and how to execute it in an Amazon EC2-based system. …
First of all, I would like to thank everyone in the AWS Community in Australia and New Zealand and the AWS Heroes who have helped put this event together.
In particular, Augustino (aka Gus), Peter, and Nathan , the AWS Heroes, and John our OBS Ninja. All have done an amazing work building this Community.
Thank you!
A little reminder that if you plan to share your day with others on social media, please use the hashtag:
#AWSCommunityDayANZ
A few years ago, I did a talk called ten lessons from ten years on AWS.
That was at the Community Day in Bangalore, India. Back then, there wasn’t any COVID virus, so I traveled there — and I loved it. …
I’d like to express my gratitude to my colleague and friend Arni Birgisson for his valuable feedback.
Since I published my blog series Towards Operational Excellence, I received a relatively large amount of feedback. But one question, in particular, stood out.
“Can you share an incident postmortem template?”
In this blog post, I will share an example incident postmortem template, which I hope will help you get started. I will also share some DOs and DON’Ts that I have seen work across a wide variety of customers — both internally in Amazon, and externally.
A postmortem is a process where a team reflects on a problem — for example, an unexpected loss of redundancy, or perhaps a failed software deployment — and documents what the problem was and how to avoid it in the future. …
I’d like to express my gratitude to my colleagues and friends Jason Byrne and Matt Fitzgerald for their valuable feedback.
I recently did a two-hour webinar dedicated to chaos engineering and got a lot of great questions from the audience. In this mini-series of posts, I take some time to answer them.
If you missed the webinar, you could access it on-demand from the link below. And if you have questions you would like me to address, feel free to ask me directly on Twitter :-)
One of the most commonly asked question with regards to Chaos Engineering is:
“How to safely inject failure in your application?”
That is probably the most important question out there. …
I recently did a two-hour webinar dedicated to chaos engineering and got a lot of great questions from the audience. In this mini-series of posts, I will take some time to answer them.
If you missed the webinar, you can access it on-demand from the link below. And if you have questions you would like me to address, feel free to ask me directly on Twitter :-)
Who’s the best set of people to start looking into chaos engineering in a team?
How can performance engineers drive chaos engineering ideas?
In general, whose responsibility is chaos engineering? …
About