Amazon AWS

Packets-per-second limits in EC2

“Packets-per-second limits in EC2” is an interesting dive into network limits on the Amazon EC2. Even if you aren’t hitting any limits yet, this article provides plenty of useful information, including benchmarking tools and quick reference links for Enhanced Networking.

The conclusion of the article is:

By running these experiments, we determined that each EC2 instance type has a packet-per-second budget. Surprisingly, this budget goes toward the total of incoming and outgoing packets. Even more surprisingly, the same budget gets split between multiple network interfaces, with some additional performance penalty. This last result informs against using multiple network interfaces when tuning the system for higher networking performance.
The maximum budget for m5.metal and m5.24xlarge is 2.2M packets per second. Given that each HTTP transaction takes at least four packets, we can translate this to a maximum of 550k requests per second on the largest m5 instance with Enhanced Networking enabled.

API Platform – REST and GraphQL framework to build modern API-driven projects

API Platform is a framework for building API-driven projects. I came across this via this blog post that covers the recent release of v2.4. The list of features and components is quite extensive:

Read and write support for MongoDB
Read support for Elasticsearch
Message queues support via a number of brokers, including Amazon SQS
Server Push support for HTTP/2
Full compatibility with OpenAPI v3 (Swagger)
Automated admin interface and project documentation
A variety of components from the Symfony framework

I’m pretty sure that I’ll be taking this for a spin in the nearest future!

The Grand Theory of Amazon

As a heavy user of Amazon Web Services, I often find myself in deep discussions about Amazon company, its broad portfolio of brands, the way they make money, and their strategy going forward.

Admittedly, that’s not an easy area to understand, let alone explain or argue about. That’s why I really enjoyed this video. It is oversimplifying a lot of things, but it does a nice job of shedding some light on what is going now, where it is heading, and how it is similar and different to some other companies.

Building serverless apps with components from the AWS Serverless Application Repository

Last year, after attending the AWSome Day in Athens, I had a strong feeling that I’ll hear more and more about serverless applications and Lambda functions in the coming months. Turns out I wasn’t wrong.

As infrastructure moves from large dedicated servers through virtual machines to containers, so does the software, from large applications through libraries and components, all the way to individual functions and microservices.

“Building serverless apps with components from the AWS Serverless Application Repository” is just one recent blog post, illustrating how to utilize small components to build a serverless application. While the whole article is well worth a read, I found the link to AWS Serverless Application Repository particularly useful.

Scrolling through all the applications, I have to admit that they aren’t too many yet – a total of 435 at the time of this writing, and most haven’t been deployed widely (the most deployed one having only 28.9K deploys). But as with many other app stores and directories, this is a good start with many examples and some handy microservices already.

The most challenging thing for me, when it comes to microservices, is changing the way I think about applications. While I always try to build the smallest and simplest version first and then iterate it over and over, thinking of a collection of smaller functions and services doesn’t happen easy. I guess, like with everything, this approach needs time and practice to settle in.

Cloud Irregular: IAM Is The Real Cloud Lock-In

Vendor lock-in is an old and well discussed issue. Some people don’t care about it all, jump right in. Others avoid it like a plague. And then there are those who allow it, with some very careful considerations.

I have always been on the side of avoiding vendor lock-in by all costs. But lately, with all the SaaS offerings and cloud providers, I feel like the line becomes a lot more blurred.

Initially, when I started using Amazon AWS, I approached it exclusively as an IaaS, setting up my own servers in such a way that I would be able to move to another vendor in a heartbeat. These days, I’ve grown to trust Amazon a lot more. But I still feel uneasy about some of the lock-in.

“Cloud Irregular: IAM Is The Real Cloud Lock-In” is an interesting take on the cloud lock-in. It found the comparison of the Amazon IAM (Identity and Access Management) to the Microsoft Active Directory particularly insightful.

To illustrate this point, we have to look no farther than the nine-hundred-pound gorilla of the IAM jungle, which continues to be Microsoft’s ActiveDirectory. I’m not sure I even know what ActiveDirectory is anymore, to be honest. Is it a cloud service? A “hybrid identity” provider? A flippin’ Linux domain controller? The answer to all of those questions appears to be “yes, if that is what you want”, which is why AD implementations will surely keep an army of Microsoft “IT Pros” busy for a couple more decades.
Here’s what ActiveDirectory is not: easy to migrate off of.