X: what's your opinion on VTL templates vs direct lambda invocations with AppSync?
me: you should use VTL templates (e.g. for DynamoDB) by default until it's either impossible or the VTL is getting too complex
X: but why?
me: well, let's see..
me: you can do whatever you want with Lambda, that gives you a lot of flexibility, but also all the drawbacks
X: such as?
me: cold starts, esp for resolvers that don't see a lot of traffic or the complexity overhead for mitigating them (Provisioned Concurrency or lambda warmer)
me: and you also have to consider the operational limits specific to Lambda, such as the *soft regional concurrency limit, and the *hard limit of 500 new concurrent executions per min after the init burst capacity (3000 concurrent executions)
X: ok, fair point.. anything else?
me: yes, there's also the extra cost for invoking the Lambda function, plus the cost for monitoring that function (e.g. CW Logs and X-Ray)
X: aren't there any other upside for using Lambda?
me: there is, actually!
me: the AWS SDKs give you retry & exponential backoff OOTB; you can implement fall-back & circuit breakers to make your app more resilient to failures; you can do failure injection to proactively identity failure modes in your app
X: but you'd still prefer VTL by default?
me: yes!
X: why..?
me: because simplicity wins and most of the time good enough is good enough 🤷♂️ You should start with the simplest solution and make it more complex when you need to, not the other way around
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I sat down this weekend and had a look at my finances as I'm almost 5 months into my 2nd year as a full-time solo consultant, and noticed that my revenue streams have changed quite a bit over the last 3 years.
This is the result of a conscious effort to reduce my reliance on a few large clients, and also to offset seasonalities and other factors that can affect revenue and create a healthy mix of active and passive income streams.
Overall revenue has grown over time, and my largest client now accounts for less than 20% of my revenue. And I haven't seen too much seasonality to my work yet - summer was quieter because Europeans went on holiday, but it was still OK.
X: in light of last week's #AWS outage, should I make my app multi-region?
me: it depends.
X: on what?
me: how much did the outage cost you in lost sales, reputation cost, etc.? And how much are you willing to invest in improving your uptime in case of another region-wide outage?
X: erm... I'm not sure...
me: don't get me wrong, if you're a large enterprise, I expect you to be multi-region already! Hell, I expect you to be doing chaos engineering and proactively finding weaknesses in your architecture before disasters strike and force you into reacting.
me: but as we can see from these AWS outages, modern systems are complex, and even companies who like AWS who have invested heavily into resilience and are doing all the right things, 💩still happens
X: when would you NOT use #AppSync?
me: since AppSync gives you managed #GraphQL server as a service, so if you need a REST API instead then you won't use AppSync. Also, you wouldn't use AppSync if you need GraphQL/Apollo features that are not supported by AppSync
X: what sorta features are you talking about?
me: you can't define custom scalar types (e.g. LatLon is a popular one), and implementation-specific features like Apollo federations for schema stitching, or utilities like data loaders github.com/graphql/datalo…
X: ok, do you need them to build a product app?
me: no, you can absolutely build production apps without them, but these features can be very useful in some contexts, for example, Netflix uses federation heavily netflixtechblog.com/how-netflix-sc…
Editing my conversation with @lajacobsson for @RealWorldSls and there's a nugget of insight that I wanted to share with you about implicit coupling that we often overlook when using SNS with SQS.
The topic is usually owned by the publisher and deployed in the publisher's stack, and the subscriber would reference its ARN via a CloudFormation stack output or something, creating an implicit coupling there.
2/
You need message attributes to do filtering, but the publisher has no idea what the subscriber cares about (nor should it, loose coupling and all). So teams that own the subscriber have to ask the publisher's team to add the message attributes they need.
3/
I've gotten a lot of questions about "how do I become an AWS serverless hero?" or "what does being an AWS hero mean?" so I thought I'd share my thoughts here
Firstly, it's NOT a programme that recognizes expertise, it's a programme that recognizes your contribution towards the community - i.e. it's not about what you know, but how much you empower others.
And no, you don't need to be certified, certs don't help AFAIK.
2/
It's a great recognition - I love it, and it has definitely helped my career progression. But it's still just icing on the cake. Empowering others is rewarding enough on its own and has defined my career, with or without the heroes programme.
3/