AWS and Barriers to Entry | ✉️ #58

Illustration for "MKDEV DISPATCH #58" with a smiling man holding a cat, with text "AWS AND BARRIERS TO ENTRY" on an orange background, paper planes, and a paper plane thought bubble. Illustration for "MKDEV DISPATCH #58" with a smiling man holding a cat, with text "AWS AND BARRIERS TO ENTRY" on an orange background, paper planes, and a paper plane thought bubble.

Hey! 👋

re:Invent is just around the corner, and I am thinking what I would like AWS to announce this year. AWS releases hundreds of big and small features during whole year. Expectation always is that on re:Invent something truly big is going to be presented. And then, there is always some kind of theme during this event. Last year it was AI. This year, most likely, it will be more AI. And this is fine.

But I was thinking a lot about how AWS makes less than obvious why customers should use one of their services. One of the good ways to explain this is to provide a comparison with a competitor. I love how Hashicorp is doing this. Do you want to know, why you need to use Terraform? Well, perhaps you already know Ansible, CloudFormation or Chef, so it will be easier for you to see how Terraform compares to these tools.

With hundreds of AWS services, I think many of them would really benefit from comparisons like this. For example: CodeArtifact vs Artifactory, AWS ClientVPN vs {Any corporate VPN}, Kinesis vs Kafka. Next step? Provide a migration path from one of the alternatives to AWS service. Perhaps, I really want to move away from my self-hosted ElasticSearch cluster, but I am really not sure how do I migrate to AWS OpenSearch Serverless. If AWS would provide at least a concept of a migration plan, it would be a great starting point.

Instead, we always have to dive deep into the docs, learn about all features of a particular AWS service and then do the comparison ourselves, building different points of references in our heads. And then, with the differences and similarities understood, build a migration plan, perhaps with the help of some semi-abandoned open sources scripts.

All of this is, of course, part of AWS marketing team’s job, that is working hard on another dozens new announcements for weeks to come. And for comparisons and migrations paths, we’ll have to rely on ourselves, that is - the community.


What We've Shared

  • How to Create a Healthy Team Environment. Here's a part of episode 49 of DevOps Accents, but with all of our faces on display.

  • DevOps Accents #50: GPUs in Cloud Infrastructure with Veronica Nigro from mkinf. What is the place for GPUs in the modern Cloud environment? How did we come to them being so integral for AI and is the naming now a bit confusing for general public? What can we expect from this area? Our guest for episode 50 of DevOps Accents is Veronica Nigro, the co-founder of mkinf, a company providing access to distributed GPUs worldwide.


And on the website we have two articles from Kirill:


What We've Discovered

  • What Platform Engineering Meant for Adidas’s SREs: Adidas shares how platform engineering helped them and which particular aspects of the new platform enabled the teams to ship faster and better.

  • How we reduced our cloud spending by 20%: Duolingo shares their journey on reducing AWS bill. Unsurprisingly, the strategy for small and big companies are very similar, at least at the beginning.

  • How WebSockets cost us $1M on our AWS bill: A rare case of how some real lower level application optimizations result in significant savings. In most cases, fixes are much higher in the chain, but in this case analyzing sys calls and memory usage actually halved the CPU usage for Recall.


Oh no!

We're late for a week this time! We know and we are sorry. You will get the next dispatch as usual, in two weeks from now :)


The 59th mkdev dispatch will arrive on Friday, December 13th. See you next time!