VP Cloud at @CaylentInc. We're hiring! Formerly @pytorch, @awscloud, @mongodb, @SpaceX. Opinions are my own.
Sep 29, 2023 • 17 tweets • 6 min read
Now that @awscloud Bedrock is GA, I'll share some of our initial learnings. Read the blog post for all the details, but I'll also thread some things here.
#BuildOnBedrock
🧵
I’ve been working with @awscloud’s #Bedrock service for a couple of months now at @caylentinc, and I’d like to share some of what I’ve learned. 🧵
First, I was wrong. Remember my skepticism from April when #Bedrock was first announced? Well, nothing fixes skepticism like hands-on-keyboard experience. I’m convinced this service is a game changer. It puts AWS in the lead for #GenAI.
May 7, 2023 • 5 tweets • 2 min read
This is completely false. I was there.
I have him muted but 50+ people have sent me this nonsense and asked for my comment... so I've conceded.
The record needs to be corrected. He's completely incorrect and I have receipts. 🧵
Daniel was an L5 engineer who had literally zero visibility into AWS leadership. I have no idea why he's crafting this absurd narrative that AWS leadership was pushing lambda. Half of them had no idea what Lambda was.
An edge spot market incentivizes all the right behaviors by providing an abstraction mechanism over real estate, energy, and silicon.
What would this look like in practice? Who are the key players? 🧵
> What would this look like in practice?
I am a developer at a software company and I want to deploy my software and data as close (latency wise) to my target consumers as possible.
My software is likely containerized. My data is encrypted using my own keys.
Mar 8, 2022 • 16 tweets • 2 min read
I just rewatched @primitivetype's re:invent talk on AWS Networking:
This is required viewing for AWS folks. I've put my notes from the talk in a thread below.
AWS first 5 years: 4 regions
AWS next 5 years: 7 more regions
AWS last 5 years: 14 more regions
AWS n+1 years: 9 more regions coming soon (or 8 now?)
Oct 22, 2019 • 5 tweets • 1 min read
Had a consult with a principal engineer today and they brought up something that might be obvious but I'm repeating it because it wasn't obvious to me:
Just because you can make something more performant doesn't mean you should. Why? (thread)
If I can build a system capable of handling millions of WS connections on a single container that's great right? But do I really need millions? If I do need millions do I really want, in the case of a failure, to re-establish millions of connections on a new set of containers?
$ aws s3 cp s3://ec2-instance-connect/cli/ec2instanceconnectcli-latest.tar.gz .
$ pip install ec2instanceconnectcli-latest.tar.gz
$ mssh instanceid
Link to docs: docs.aws.amazon.com/AWSEC2/latest/…
Automatically setup on amazon linux 2 - can be installed on other machines:
$ sudo yum install ec2-isntance-connect
Feb 18, 2019 • 8 tweets • 2 min read
(Thread)
One of my favorite things about teams at AWS is that they all have these little subsections on their internal wiki pages:
"Our Tenets, unless you know better ones":
Each one is typically an extension of an existing Leadership Principle but expanded specifically for the unique challenges and skills of that team. amazon.jobs/en/principles
