horgix.fr
Staff SRE at @payfiteng.bsky.social & Maître Raclettier — Mostly posting about conferences & tech — 🔧 Automation, ❤️ Open-Source, ⚙️ Rust, 📣🎙️ Conferences {organizer, speaker, frequent attendee}
— Mandatory « I use Arch btw »
494 posts
158 followers
129 following
Regular Contributor
Active Commenter
comment in response to
post
Plus some tips, and more on Cargo Culting.
(why does the cargo cult mention makes me want to scream "Platform Engineering" ? 😅)
Closing words: look into residuality theory and building anti-fragile systems !
comment in response to
post
Même bateau ici : titre similaire à ce que j'ai déjà présenté à d'autres conférences sur la gestion d'incidents (même à DevOps REX peu après toi en décembre dernier !), mais _beaucoup_ plus de contenu présenté différemment en 3h, ça fait du bien d'avoir le temps de couvrir le sujet complètement :D
comment in response to
post
Note that these answers are not coming out of nowhere - this is mainly made possible thanks to our existing internal documentation as well as the awesome resources/guides available on payfit.com/blog/categor... 🙂
By the way, the model is Claude Sonnet (3.7) from @anthropic.com as of now!
comment in response to
post
Wrapping up with the actual Rust code handling it, including... macros to generate the Rust types from the GraphQL schema o/
See github.com/JeremieRodon... for more :)
Great talk, now I want to give the Rust + AWS AppSync combo a try too !
comment in response to
post
In the end, the JS resolver is still faster than the Lambda one in Rust.
(VTL being _aux fraises_)
comment in response to
post
Turns out my click spam skills are apparently quite OK - super useful skill to have in real life (no) 😂 First among a packed room (why does my brain value that...)! Love the interactive nature of the benchmark 🙂
Disclaimer, I didn't get to pick the team, wouldn't have picked Python otherwise -
comment in response to
post
Rust type definitions and GraphQL schema look super alike to eachother.
So let's play a live game to test the resulting performances of having Lambdas written in Rust as AWS AppSync resolver compared to other options!
comment in response to
post
What to pick for the resolvers?
- VTL looks super painful and limited
- JS quickly results in the need for complex to maintain Pipeline Resolver
- Lambda resolver saves the day... and why not write them in Rust for better safety, efficiency, etc.? 😄
comment in response to
post
With #AWS AppSync, getting subscriptions to notifications through GraphQL wesocketsm is as easy as just adding an '@aws_subscribe' mention in the @graphql.org schema
comment in response to
post
While AWS AppSync and API Gateway have a lot of similarities especially in their integration with other AWS services, they otherwise have some feature differences - for the worse on AppSync side, beside the obvious REST vs GraphQL.
With GraphQL assessing both client-side schema and notifications.
comment in response to
post
Love the vibe of the talk so much, we can feel the passion of both the speaker, essentially doing all that out of curiosity and to explore things, or the audience where the person beside me is writing Rust for a personal project right now :D
Love the @rust-lang.org community altogether! 🦀
comment in response to
post
Overall solid guidelines if one want to provide sandboxes while limiting the risk of it becoming too slippery.
I'd favor a "provide freely, nuke frequently" approach rather than making it complicated to get access to though, but I guess that varies depending on your org constraints and risks!
comment in response to
post
Automate as much as yo ucan:
- Stop EC2 instances & scale down databases when unused
- Use AWS cost anomaly detection in cost explorer to be warned if necessary
- Use AWS Budget to control costs evolution
Also:
- Limit access to the AWS Marketplace
- Limit to some instance sizes
comment in response to
post
- Use AWS Macie for PII detection
- Ship AWS Cloudtrail traces to a security team to ensure nothing too weird happens
- AWS Cloud Intelligence Dashboards to better understand usage
And random other bits to use to ease your life when providing sandboxes:
- Cloud Custodian
- Prowler
- AWS nuke
comment in response to
post
- Consider the sandboxes as something totally outside your system, especially for data security, because there _will_ be some misconfiguration and you don't want your real data in there
comment in response to
post
Some guidelines on the provided guidelines:
Get an "owner" tag on everything through:
- Tagging policies
- SCPs
- AWS Config rules
comment in response to
post
On one hand, I agree with the "people need to be responsible on their usage" part.
On the other hand, having to provide approved reasons for sandbox usage and get managerial approval (to accept the costs) seems the kind of thing that could get in the way of actually experimenting spontaneously
comment in response to
post
Kinda the same question at PayFit 😅 But I think we'd happily give up on maintaining / keeping up-to-date various controllers & components in order to focus the time & energy spent on that on other things with more value for the users of our internal platform. We may share publicly our ADR on that? 🙂
comment in response to
post
Keeping it DRY and maintainable :)
The multiple levels to override values seems like a hell to reason about and figure out what's actually being picked from where though
They didn't try EKs AutoMode yet - but soon! Fun how we have the same approach and plans at @payfiteng.bsky.social
comment in response to
post
"Avoid running Karpenter on Karpenter-managed nodes" haha yeah, good call :D
Not trying to avoid the same for ArgoCD though: after it's setup with Terraform, ArgoCD is used to re-deploy itself
comment in response to
post
Interestingly, they have a dedicated VPC per EKS cluster and a single ALB per cluster to expose services running there. And they most likely have more clusters than we do at @payfiteng.bsky.social
comment in response to
post
A toute fin utile, en français il existe le très bon talk de Hugues Lepesant à @breizhcamp.org à ce sujet: www.youtube.com/watch?v=9NBU...
comment in response to
post
Hop: bsky.app/profile/horg...
Même si c'est très partiel, avec ce qui m'est venu en tête en premier
comment in response to
post
En vrac, que ce soit cloud ou numérique+(géo)politique: @titimoby.bsky.social @jlandure.dev @waxzce.org @pierreb.bsky.social @reesmarc.bsky.social @noyb.eu
comment in response to
post
Randomly found the handle of the second speaker that I missed mentioning: it was @boredabdel.bsky.social !
comment in response to
post
Yep, the Barcelona 2019 design was super nice too, it's the one I actually really wear frequently among all the 2018-2025 #KubeCon #CloudNativeCon t-shirts! (wish I had a picture at hand)