Re:Invent 2023 Reflections
“Failures are a given and everything will eventually fail over time” - Werner Vogels
I’m not 100% sure if it was the talks I signed up for, or if it was a motif this year at Re:Invent. I’m glad to have heard it so many times as it’s stuck and I now have something I can point people to that sums up the need to build “defensively”.
This bit isn’t hidden knowledge but I feel isn’t typically spelled out. Each Availability Zone is its own isolated deployment of the AWS cloud (for region-based services). Usually, the advice is “Deploy to multiple zones for resiliency” but after years in the space, I don’t remember anyone stating that as the reason why. Spelled out it’s a no-brainer, but it also supplies a lot more nuance than just “deploy more than one of everything to at least two zones”.
Up until last week (as of 12/3/23) I would say I’ve been something of an AI pessimist. However, after getting hands-on with services like SageMaker, and Q, and seeing how products are starting to leverage it as part of their solutions, I’m starting to see where it could come into play.
If providing consistency to your users is the goal, working in cross-functional teams is hard, but working in silos is even harder. This topic is very cyclical, so putting my finger down at any one point feels difficult still. But in short, you have to examine what brings you together. If being the best “Ops” team is what brings the people together, then that’s what you’ll get. Regardless of if that’s what your end users need. But when working “cross-functionally” the problem is what brings your people together. Then you’re significantly more likely to get results that are also aligned with the problem rather than with some internal discipline.
Something CDK specific, understanding when to use the various dependency strategies for things is vital. I’m not going to go into it at length here, as I think I’m going to turn this topic out into its own post. From what I’ve gathered, this is one of the hardest parts of using the CDK, as there’s a lot of “magic” surrounding them. So understanding when to use the magic versus when to hop out and be explicit will save you from lots of headaches.
For all the solutions the cloud has to offer, nothing replaces talking to your customers and building what they need. Seeing fancy architecture diagrams may be what gets the builder in you going, but what use is a hammer without a nail? So make sure there’s a nail there first before you start swinging.
You can ignore cost. But it is not ignoring you. So if cost isn’t at the forefront of the decision-making process, you probably aren’t doing enough to manage it. For more on this, see Dr. Vogels’ keynote from this year.