Danilo Poccia

Thank you all for the interesting discussion!

I hope you will enjoy the book, and be inspired to build something new!

Best,
dp

Jeanne Boyarsky wrote:First, a big thanks to Danilo Poccia for being here to promote the book AWS Lambda in Action.

The winners are:

Lucian Revnic
Miles Davenport
paul nisset
Lanny Gilbert

Please send your snail mail address to bookpromotion AT javaranch DOT com. To ensure the quickest response, please provide the following:

Your name (first and last - preferably the one you use on CodeRanch)
Email
Country (needed even if requesting an e-book)
Address
Phone Number

Also, please include the following as the subject of your Email.

Book Promo Winner - AWS Lambda in Action - Tuesday, January 3rd, 2017


Image from unknown

As noted in the Book Promotion Eligibility Requirements and Legal type stuff, the winners have 8 days to submit their information. Within 3 days of receipt of your email, we will reply to let you know we got it. If you don't hear back, the goat might have eaten your email. Please let us know by posting in the Ranch Office so we can check on it. Once you have received your copy please let us know by editing the Book Promotions Winners Page and updating the 'Status' column to say you have it.

Thanks and congrats to all the winners.

To make it more "real" and see some code, I'd like to share this tutorial, excerpted from the AWS Lambda in Action book, to build a web app using Lambda functions and the Amazon API Gateway:

https://medium.com/@danilop/aws-lambda-calling-functions-from-a-web-browser-338fbcb6a44d

You can find a live demo of what described in the article here:

https://simplewebsite.eventdrivenapps.com

Let me know if you find it interesting ;)

Best,
Danilo.

paul nisset wrote:Hi,

What is the difference in deploying a typical JEE web application using AWS Lambda versus the standard AWS deployment process ?
I don't currently use either . I currenlty deploy to a remote server by dropping in a war file to a remote Tomcat or JBosss server.

thanks,
Paul

Hi Paul,

with AWS Lambda, you can't deploy a typical JEE web app. To do that, without having to manage the infrastructure, there are other AWS services, such as AWS Elastic Beanstalk.

For different programming languages, there are open source projects that make it easy to migrate a typical app to AWS Lambda. For example, "lambada" is a REST framework that implements JAX-RS API and lets you deploy your applications to AWS Lambda and API Gateway with a very little effort:

https://github.com/lambadaframework/lambadaframework

With AWS Lambda, you deploy functions, that take an event in input and can (optionally) provide an output. Functions can be called synchronously or asynchronously, and be triggered by events: for example, an image is uploaded by a mobile app to Amazon S3 and a Lambda functions is triggered to process the image, extract the metadata and index that in a database, and so on.

To get a broader picture of serverless apps, I'd suggest you to have a look at chapter 1 of my book (it's free to read) or at the live demos that I put online here:

https://awslambdainaction.com

I hope this helps!

Best,
Danilo.

Mauricio Mena wrote:What to know more about the importance of having an API Gateway when you are running serverless architecture, is a requirement to manage the functions you have, it is a pattern, best practice or we are allowed to not have one in our system.
What are other ways or organize or even orchestrate our service layer running AWS Lambda?

How we can manage the inventory for our existing functions in AWS there are preexisting tools or just amazon console?

Hi Mauricio,

lots of very good questions here!

You can call Lambda functions directly via the AWS API / SDKs. There are SDKs for a lot of different programming platforms, including Java, Python, JavaScript (in the browser and Node.js), PHP, iOS, Android, etc.

If you want to decouple the client application (for example a native mobile app, or a single-page JavaScript app running in the browser) from the serverless back end, then the API Gateway is a very good way to do that, so that you don't need to use AWS API / SDKs in the client app.

Another useful use case is when you have a legacy back end that you want to migrate (completely or partially) to serverless: in that case you can put the API Gateway in between and then move what you want to AWS Lambda one step at a time.

If you want to provide a standard Web API to your users, so that they can use your back end to create new applications, or integrate their applications with yours, then having an API Gateway is a must.

To orchestrate the execution of multiple Lambda functions, you can use the recently launched AWS Step Functions, using a JSON language to describe their relations:

https://aws.amazon.com/step-functions/
https://states-language.net/spec.html

However, my preferred approach is to favour choreography to (strict) orchestration, so using triggers to execute Lambda functions in response to events is what I'd try to do first.

To manage Lambda functions, their life cycle, or just get a list/inventory of them, you can use again the AWS API / SDKs, or even simpler the AWS CLI. With AWS everything is programmable.

For example, using the AWS CLI to get a list of Lambda functions is as easy as running this command:

aws lambda list-functions

The output of the previous command is JSON or (if you prefer) a more human-readable format.

Let me know if this helps!

Best,
Danilo.

Miles Davenport wrote:Hello Danilo,

I wanted your advice on the best way of keeping an Aws Lambda warmed up.

I understand that the first time a Lambda is called, the Serverless "environment" is warmed up, with a slight delay before code is executed.

To avoid this situation happening repeatedly, where there are surges of events, can you please recommend a strategy, which works, but is cost effective.

A heart beat which calls the Lambda every N seconds may be effective, but may also be costly.

Your thoughts are welcomed.

Thank you.

Miles.

Hello Miles!

If your code is "small" and you're using an environment that is fast to start (such as JavaScript, Python) you usually don't have noticeable delays.

To optimize for the first invocation, try to keep the code you upload small, for example removing dependencies that you don't really need. This is a programming paradigm that is different from a normal JEE environment, where you have few long-term executions.

Other than that, my suggestion to keep a function warm is to call it every 5 minutes, for example using another Lambda function that you schedule via CloudWatch Events. You may create a sort of "ping" event that the function intercepts at the very beginning of its execution, to recognize these "keep alive" calls, and then terminates quickly. BTW, this is obvious but deserves to be noticed, a single function can call multiple functions.

If you use this techniques, you have less than 9,000 very short invocations per month, the cost of which is zero as you'd fall within the AWS Lambda free tier (1M invocations per month).

In my experience, first time invocations are more of a nuisance in test & dev than in production, where the workload itself keeps the function(s) warm.

Let me know if that helps!

Best,
Danilo.

Lucian Revnic wrote:Hello,

What are your recommendation on motivating the operations team about migrating their infrastructure to AWS Lambda?

Also, what is your suggestion on a working process/tools where sys admins (non-developers) and developers can work together, if possible, on the same features.
For example non-developers prefer graphical tools meanwhile developers love to write code. What is the common ground for the two persona to work together?

Thank you,
Lucian

I really think Dev and Ops should work together, and have common goals and responsibilities. AWS Lambda can be used to provide a new feature (you don't need to migrate everything at once) or to automate an operational task (backups, data syncs, service discovery, etc.). Recently, AWS Step Functions have been introduced to coordinate complex tasks using multiple Lambda functions, together with tasks running on traditional platforms, and there is a nice GUI to visualize the result.

So I think the common ground is two fold:

- using AWS Lambda to (further) automate operations
- using AWS Step Functions to have a visualize the workflow

Lanny Gilbert wrote:I took some time and quickly scanned the first chapter from Manning's site, as well as the AWS lambda site.
From what I could tell from that quick read, seems that AWS Lambda provides (more or less) the same functionality as AWS, but in a simpler manner using containers.
Is that fairly close?
Thanks!

You're welcome! Simplification is definitely one of the big advantages of AWS Lambda. The use of containers is part of the solution, but the fact that you can put your code, and create a function, without having to think of how many containers (zero, one, or more) will be used to support that function, is one of the reason people started to use the term "serverless" in this case. You really can focus on logic (functions) and data (that can trigger functions), and not managing infrastructure or containers. AWS Lambda provides an environment where prototyping a new feature is easy, and deploying that feature in production doesn't require to refactor it.

Salil Wadnerkar wrote:I work in a typical backend heavy web application with apache solr and redis for quick searches, and DB caching. And our main web app calls services - all hosted in AWS. What benefit does AWS lambda offer in this setup, and secondly, how we can rearrange the pieces to derive greater benefit from AWS lambda service?

Well, this is a broad question, and I don't know the details of your app or where the new features are going, so I am taking an open approach. With AWS Lambda, you don't have to manage scalability and availability. For example, if there is a new component to be added, you can isolate it in a function so that scaling/managing a new feature (that can be successful, or not) is independent from the rest of the architecture.
In this way, you are setting the right path to adopt (or at least try) microservices. As an additional benefit, if you can easily react with you logic to event in your infrastructure (such as a new file is uploaded on an S3 bucket, or an item is written/updated on a DynamoDB table).
I have also seen a customers that have their architecture already in place, starting using Lambda functions to automate infrastructure-related activities, such as backups, data synchronisations, configuration management, etc. In those cases, you'd probably stay within the AWS Lambda free tier (1M invocations and up to 3.2M seconds of execution time per month).

Magnus Eriksson wrote:What is the current status of container reuse and load performance when using Java for lambda programming?

Some time ago I did try making Lambda functions in Java but the first time the function was loaded it took several seconds to get a response. Has this improved?

How often must the function be called in order to keep the container loaded?

Usually, I see that as an issue more in development/test environment than in production, where the load is higher. As a rule of thumb, if you execute a function at least every 5 minutes, then the container is not de-provisioned. You may schedule a "ping" call (for example, using CloudWatch Events) to do that in a easy way.

You may also try to keep your Lambda functions (JAR, in the case of a Java function) small, to reduce the startup time, removing dependencies that are not really required: for example, logging libs, or complex libs that you only use at 1% or their capacity.

Mohamed Iqzas wrote:I am not aware of AWS except that it is a cloud platform for hosting applications.

Do we need to have only coding skills to develop applications using AWS lambda, or do we need some networking or configuration skills to host an application using AWS Lambda?


Sorry if the question looks very silly.

No question is silly, only answers can be ;)

AWS is a broad platform of computing, networking, storage, and AWS Lambda is a service that allows you to create applications without being a cloud expert, you just need to know one of the programming platforms supported by the service (currently Node.js, Python, Java/JVM, C#) and you can write functions that executed on demand (directly or via a Web API), or triggered by events (for example, a mobile app uploads a picture and you can trigger a function to process that).

Using multiple functions together, you can build the backend of a web, mobile or IoT application. You may give a look at the first chapter of my book, it is free to read and gives an overview of what you can do, and how to do it. In the book, I focus on JavaScript/Node.js, with most examples also provide din Python.

Campbell Ritchie wrote:Welcome Good to see you here.

Thank you! Let me know if I can be of help... Happy to be here!