Amazon EC2 Mac instances for macOS
For years, AWS only supported its EC2 instances to run on Windows and Linux. MacOS has not been considered for the fact that the investment was too large for a rather limited use case: the operating system only runs on Apple hardware because of Apple’s licensing terms and the customer demand was simply not enough. Now, in 2020 AWS has apparently reached a scale that it can pursue and realize new services like this.
The licensing-limitation was overcome through collaboration with Apple, which deployed thousands of Apple Mac mini computers in their own datacenters. Amazon EC2 Mac instances are powered by the AWS Nitro System, which makes it possible to offer Mac mini computers as a fully managed compute instance with VPC networking and EBS storage integration, as you are used to with EC2 instances.
Interesting, because..?
The Amazon EC2 Mac instances open up a whole new world for Apple developers. Since some processes only run on macOS, like applications for iOS, tvOS and Safari, building, testing and maintaining these apps was done on own Mac hardware before this release. If you are a developer of iOS and other Apple apps, you can now make use of the managed infrastructure of AWS and leverage benefits like scalability and elasticity, but you will also have access to the extensive range of AWS services, to bring building your Apple applications to the next level.
AWS Lambda support for container images + upgrade to 10 GB memory
This announcement actually consists of several new features for AWS Lambda, so for ‘Lambda-lovers’ it has been a good week. To start off, it is now possible to use Lambda to run your applications via Docker container images. Moreover, you will have up to 10 GB RAM memory for your Lambda functions to use. Clearly, these two updates are meant to work together for more convenience and flexibility in using AWS Lambda and enable transition from container services to serverless microservices.
Interesting, because..?
Because of a lot of reasons! For one, AWS Lambda has supported programming languages like Python, Node.js, JavaScript, but never PHP, a language that quite often is used. Applications running on PHP could be deployed on AWS using EC2, ECS (which means creating clusters, AutoScaling groups and load balancers) or Lambda, but you would have to include a Lambda Layer for libraries and dependencies. With container image support, you can create a Lambda function and include the code as an image (from e.g. Amazon ECR) just like you would do with .zip packages; so no other infrastructure resources or Lambda Layers required. Also, you can develop and test your Lambda functions locally using Docker tools and via Amazon’s open-source lightweight web-server, Lambda Runtime Interface Emulator (RIE), you can enable your function packaged as a container image to accept HTTP requests.
The upgrade to 10 GB memory for Lambda functions allows you to deploy much larger applications, e.g. with dependencies on extensive libraries and programs, in a serverless way. This is interesting because you can now use the simple interaction ánd the low costs of AWS Lambda for more use cases. Because of the accompanying CPU-scaling, you will also have access to up to 6 vCPUs, making it possible to optimize your functions for multithreading which can drastically reduce your execution time (and invocation costs!). Moreover, with the release of Advanced Vector Extensions 2 (AVX2) support for Lambda, you can benefit from improved performance for demanding workloads like machine learning inferencing, media processing, high performance computing, scientific simulations, and financial modeling. Do note that the Lambda execution time still has a maximum of 15 minutes.
Another interesting announcement is related to AWS’ not so subtle, but impressive move to the ‘edge’. AWS is bringing AWS services (read: Amazon hardware) previously limited to AWS Regions to other locations to reduce latency and improve performance of applications using these services. Accompanied by the earlier release of single/dual-server AWS Outposts units and 15 new Local Zones near highly populated areas, AWS now has enabled Amazon Elastic Container Service and Elastic Kubernetes Service to run anywhere; with the fitting name, you might have guessed it, ECS/EKS Anywhere.
Interesting, because..?
The answer to this is two-fold. The first reason is that running ECS or EKS applications in your local datacenter reduces latency, in case your end-users are located closer to your datacenter than to one of AWS. This will help you to get maximum performance from your applications, looking at quick response times. If your applications require this low latency, e.g. for operations that require near real-time access to rapidly changing data, and you want to make use of Amazon’s proven and managed container orchestration service, ECS/EKS Anywhere might be something for you. Compared to AWS Outposts, this service is much cheaper, since you are using your existing hardware to integrate it with. And that is the bridge to the second reason why ECS/EKS Anywhere is interesting: because it uses your already existing hardware. A lot of companies have invested or are still investing in on-premise hardware and are actually spending more on on-premise than on cloud. So it is reasonable to imagine that companies want to make use of this investment for a while still. AWS acknowledges this and ECS/EKS Anywhere meets you halfway in this regard, to run the AWS service on your own hardware, but also function as a gateway to other AWS services.
Announcements made in the last seven days that did not make the cut, but are certainly worth checking out are:
- Amazon Aurora Serverless v2 - Instead of doubling capacity when scaling, it adjusts in fine-grained increments to provide just the right amount of database resources for an application’s needs.
- Amazon ECS Deployment Circuit Breaker - ECS customers can now automatically roll back unhealthy service deployments without the need for manual intervention.
- Amazon EBS gp3 volume & EBS Block Express – 20% cheaper than gp2, first general purpose volume type that allows you to configure IOPS independently from disk size & new io2 volumes for workloads with high reliability requirements.
For all else that’s new, check out the re:Invent 2020 Announcement Page!