HNHacker News
TopNewBestAskShowJobs

talawahtech

1,163 karma · joined September 3, 2015

[ my public key: https://keybase.io/talawahtech; my proof: https://keybase.io/talawahtech/sigs/c2anvf11_7xGywbo2VIosdPQRjJm94WVUWr3w9D4g_M ]
submissionscomments
talawahtech··on New for AWS Lambda: Use Any Programming Language and Share Common Components
Several related lambda announcements to around structure/reuse as well:

1. Lambda Layers - Reusable components that can be shared across lambda functions (covered in the linked article)

2. AWS (Serverless) Toolkits for PyCharm, IntelliJ & VS Code - https://aws.amazon.com/blogs/aws/new-aws-toolkits-for-pychar...

3. Nested Applications Using the AWS Serverless Application Repository - https://aws.amazon.com/about-aws/whats-new/2018/11/sam-suppo...

talawahtech··on New for AWS Lambda: Use Any Programming Language and Share Common Components

  We are making these open source runtimes available soon:
  C++[1]
  Rust[2]

  We are also working with our partners to provide more open source runtimes:
  Erlang (Alert Logic)
  Elixir (Alert Logic)
  Cobol (Blu Age)
  N|Solid (NodeSource)
  PHP (Stackery)
There is also native Ruby support as well[3]

1. https://aws.amazon.com/blogs/compute/introducing-the-c-lambd...

2. https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws...

3. https://aws.amazon.com/blogs/compute/announcing-ruby-support...

talawahtech··on Firecracker – Lightweight Virtualization for Serverless Computing
The FAQs on the Firecracker website[1] specifically address the difference between Firecracker and Kata Containers. The main thrust being that they have decided not to use QEMU and have instead chosen a much more minimal "cloud-native" oriented approach that deliberately abandons certain features in order to gain greater security, efficiency and agility going forward. They also decided to implement it in Rust.

Based on the the responses I have seen from non-Amazon employees with experience in this space[2][3][4], it looks like their approach is solid.

It should also be noted that one of the main architects of Firecracker was formerly the project lead for QEMU[5][6]

1.https://firecracker-microvm.github.io/#faq

2.https://twitter.com/bcantrill/status/1067326416121868288

3.https://twitter.com/jessfraz/status/1067286831287418881

4.https://twitter.com/kelseyhightower/status/10672947809488322...

5.https://twitter.com/jessfraz/status/1067282499938721792

6.https://twitter.com/anliguori/status/1067293131366785024

talawahtech··on Firecracker – Lightweight Virtualization for Serverless Computing
Theoretically, if container start up times are around 125ms it should be possible to achieve this with Fargate + Knative's "scale to zero" functionality[1]. AWS is already working on improving Fargate/Kubernetes integration.

[1] https://cloud.google.com/knative/

talawahtech··on Firecracker – Lightweight Virtualization for Serverless Computing
This is huge! It basically removes the VM as the security boundary for something like Fargate [1]. This should lead to a significant reduction in pricing since Fargate will no longer need to over provision in the background because VMs were being used even for tiny Fargate launch types.

It should hopefully eliminate the cost disparity between using Fargate vs running your own instances. Should also mean much faster scale out since you containers don't need to wait on an entire VM to boot!

Will be interesting to see what kind of collaboration they get on the project. This is a big test of AWS stewardship of an open source project. It seems to be competing directly with Kata Containers [2] so it will be interesting to see which solution is deemed technically superior.

[1] https://aws.amazon.com/fargate/ [2] https://katacontainers.io/

talawahtech··on AWS Amplify Console
This is useful, and long overdue. Trying to deploy a single page app or static site using S3 + CloudFront is way more complex than it should be. Trying to automate deployment using CodePipeline is a real pain. By the time you start to think about cache invalidation, most people have already given up and started looking at Netlify or Firebase hosting. The fact that they handle things like atomic deploys and password protection for dev branches is icing on the cake.

I do wish the data transfer pricing ($0.15/GB) were a little lower, though it is the same as Firebase hosting who I guess they are positioning themselves against. The pricing is simpler that CloudFront pricing which varies by region, but ends up being a worse deal for those whose customers are primarily in North America ($0.085/GB on CloudFront) and a better deal for those in India ($0.17/GB) and South America ($0.25/GB). Push come to shove, if you need to reduce costs I guess you can always try sticking Cloudflare in front of it and seeing what the performance looks like.

They are still not doing a great job on the product marketing side of things though. Why is it called Amplify Console instead of Amplify Hosting? In my opinion they should really just take a look at how Firebase positions their suite of products. Amplify Framework, amplify-cli and Amplify Console is a confusing and counter-intuitive mix.

talawahtech··on Bandwidth Alliance: sharing the benefits of interconnected networks
This is an awesome initiative. The fact that AWS isn't on board is disappointing, though not terribly surprising.

I don't even think it makes sense to hold out hope for future inclusion given that AWS has a competing product and makes a ton of markup on their bandwidth charges, but I would love to be wrong about that.

talawahtech··on C5 Instances for EC2 Now Available
Pricing seems to be about 15% cheaper than C4 with slightly more RAM and the same ECU equivalence
talawahtech··on Serverless Comparison: Zappa vs. Chalice
The first two paragraphs of this post come across as unnecessarily defensive and combative. Amazon released a product and then released an open source preview project to make that product easier to use. They even mention other similar projects (including Zappa) in the project README.

To hint at malice "...it felt like their interface and even their presentation of the product was a direct rip-off of our efforts" and then say "I don't want to attribute any direct malice" seems disingenuous. I feel like those fist two paragraphs could just be cut.

Many people have found the Lambda + API Gateway combo useful, but cumbersome which is why so many different projects have sprouted up to fill that gap e.g. https://github.com/serverless/serverless and https://github.com/claudiajs/claudia

Even AWS themselves have multiple preview projects in the same vein. There is another one just for Node.js that is designed to work with existing apps that were built for the Express framework https://github.com/awslabs/aws-serverless-express, so less lock-in there I guess?

It fine to promote the benefits of Zappa vs Chalice, including the fact that it avoids lock-in, but honestly the way the author approaches the comparison leaves a bit of a bad taste in my mouth.

← PreviousPage 3 of 3