The hidden costs of serverless

This article represents the opinions of Amiram Shachar, CEO of Spotinst.

Serverless architecture is the next step in the evolution of computing power. The reasons for taking the leap are clear:

  • You will save time: No more provisioning, managing, or thinking about how your application will scale up or down. Not only won’t you need to deal with implementation upon deployment, but all the time you spend dealing with the infrastructure afterwards will again be yours to spend on further innovation.
  • You can save money: In a Serverless world where you pay-per-trigger, you don’t need to write on/off scripts, plan reservations, or plan for spikes. You just pay for what you use.
Serverless is the next step in the evolution of computing power

Like the jump from on-premises to the cloud, the move to Serverless is more or less inevitable. Also like the jump from on-premises to the cloud — this move could come with some surprising bills.

https://read.acloud.guru/the-hidden-costs-of-serverless-6ced7844780b

Advertisements

How to use AWS Fargate and Lambda for long-running processes in a Serverless app

AWS dropped so many serverless announcements at re:Invent, the community is still scrambling to make sense of them all. This post is all about AWS Fargate.

In this article, I will show you how to create an end-to-end serverless application that extracts thumbnails from video files. But, oh no, processing video files is a long-running process! Whatever will we do?

This is where Fargate comes in.

TL;DR A Docker container does the processing -> The container extracts the thumbnail and uploads the image to an S3 bucket -> The container is managed by AWS Fargate. All functionality is triggered from AWS Lambda functions and contained within a serverless application written with the Serverless Framework.

https://serverless.com/blog/serverless-application-for-long-running-process-fargate-lambda/

AWS AppSync – GraphQL as a Service

Day two at re:Invent 2017 was incredibly packed, crowded, and exciting. My favorite announcement so far is the new AWS AppSync, as it aligns with one of the most promising (yet somehow controversial) design principles adopted by the serverless community: GraphQL.

If you are not familiar with GraphQL, we recently explained how to write GraphQL Apps using AWS Lambda, and hosted a webinar about the Love Story between Serverless and GraphQL. Here’s a quick look at what you need to know about AWS AppSync.

https://cloudacademy.com/blog/aws-appsync-graphql-as-a-service/

Managing AWS Lambda Function Concurrency

One of the key benefits of serverless applications is the ease in which they can scale to meet traffic demands or requests, with little to no need for capacity planning. In AWS Lambda, which is the core of the serverless platform at AWS, the unit of scale is a concurrent execution. This refers to the number of executions of your function code that are happening at any given time.

Thinking about concurrent executions as a unit of scale is a fairly unique concept. In this post, I dive deeper into this and talk about how you can make use of per function concurrency limits in Lambda.

Understanding concurrency in Lambda

Instead of diving right into the guts of how Lambda works, here’s an appetizing analogy: a magical pizza.
Yes, a magical pizza!

This magical pizza has some unique properties:

  • It has a fixed maximum number of slices, such as 8.
  • Slices automatically re-appear after they are consumed.
  • When you take a slice from the pizza, it does not re-appear until it has been completely consumed.
  • One person can take multiple slices at a time.
  • You can easily ask to have the number of slices increased, but they remain fixed at any point in time otherwise.

Now that the magical pizza’s properties are defined, here’s a hypothetical situation of some friends sharing this pizza.

Shawn, Kate, Daniela, Chuck, Ian and Avleen get together every Friday to share a pizza and catch up on their week. As there is just six of them, they can easily all enjoy a slice of pizza at a time. As they finish each slice, it re-appears in the pizza pan and they can take another slice again. Given the magical properties of their pizza, they can continue to eat all they want, but with two very important constraints:

  • If any of them take too many slices at once, the others may not get as much as they want.
  • If they take too many slices, they might also eat too much and get sick.

One particular week, some of the friends are hungrier than the rest, taking two slices at a time instead of just one. If more than two of them try to take two pieces at a time, this can cause contention for pizza slices. Some of them would wait hungry for the slices to re-appear. They could ask for a pizza with more slices, but then run the same risk again later if more hungry friends join than planned for.

What can they do?

If the friends agreed to accept a limit for the maximum number of slices they each eat concurrently, both of these issues are avoided. Some could have a maximum of 2 of the 8 slices, or other concurrency limits that were more or less. Just so long as they kept it at or under eight total slices to be eaten at one time. This would keep any from going hungry or eating too much. The six friends can happily enjoy their magical pizza without worry!

https://aws.amazon.com/blogs/compute/managing-aws-lambda-function-concurrency/

A Decade of Dynamo: Powering the next wave of high-performance, internet-scale applications

Today marks the 10 year anniversary of Amazon’s Dynamo whitepaper, a milestone that made me reflect on how much innovation has occurred in the area of databases over the last decade and a good reminder on why taking a customer obsessed approach to solving hard problems can have lasting impact beyond your original expectations.

“Dynamo: Amazon’s Highly Available Key-value Store” received the ACM SIGOPS 2017 Hall of Fame Award

http://www.allthingsdistributed.com/2017/10/a-decade-of-dynamo.html