“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.
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.
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.
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.
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.
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.