Tag Archives: AWS Lambda

Back to blog home page

AWS Lambda vs. Microsoft Azure Functions

Posted by on Sep 13, 2017

In this article, we compare two function-as-a-service providers: AWS Lambda and Microsoft Azure Functions. We’ll look at the brief history of each, and compare and contrast their features.

Why Work with Multiple FaaS Providers?

One of the crucial components of any application’s reliability plans is what to do when a provider goes down. If AWS is unresponsive, or Google Cloud has a bug, how will your application be affected? Applications that take this into account in their design will often need to rely upon federation of third-party functionality, in order to ensure maximum reliability. When developing Function-as-a-Service apps, the federation options are limited to a small number of providers. As stated, in this post we’ll examine AWS and Azure.

AWS Lambda

AWS Lambda is a Function-as-a-Server serverless code execution platform launched at re:Invent in 2014. Building upon the concepts of containerization, AWS Lambda uses the AWS machine architecture to reduce the scope of containerization, letting you spin up and tear down individual pieces of functionality in your application at will. Functions run on Amazon Machine Instances, which are immutable web server objects that can be instantiated quickly in response to dynamic API requests. By leveraging multiple AWS services and functionality, you can build an entire application without having a true “server-side” set of code to manage.

Microsoft Azure Functions

Microsoft is one of the newer players in the Serverless realm. While they have offered significant Platform-as-a-Service functionality for several years, it wasn’t until March of 2016 that they entered the Serverless App environment with the launch of Microsoft Azure Functions. The addition of these on-demand server-side functions augmented the Azure platform with the ability to run arbitrary code in temporary execution environments.

Supported Platforms and Languages

One of the first items in any evaluation of a serverless provider is what languages are supported. Both AWS Lambda and Microsoft support Node.JS, Python, and C#, for example. However, AWS Lambda provides further support for Python and Java, while Azure Functions provides support for F# and php. Additionally, both run on different execution platforms – AWS Lambda is built of the AMI, which runs on Linux, while Microsoft Azure Functions run in a Windows environment.

Which language you choose is a question of which languages your development team will be productive in, and as such the cross-section of Node.JS, Python, and C# support should meet the needs of the majority web development teams. However, it is important to note that both Amazon and Microsoft are continuing to expand their language support offerings, and this likely won’t cease until all providers are pretty close to language parity. As such, if your chosen vendor doesn’t support your chosen language, then it may not be as drastic of a setback as you’d imagine in a more traditional server-based application. For the purposes of federation of third-party functionality, though, it’s important to pick a language that all platforms in your application’s architecture support, so that you can minimize the work necessary to port the code between different function-as-a-service providers.

Supported Triggers

Both AWS Lambda and Microsoft Azure Functions offer dynamic, configurable triggers that you can use to invoke your functions on their platforms. With AWS, these are sent from other AWS services – you can configure an API trigger using API Gateway, a dynamic trigger on a DynamoDB action, a file-based trigger based on Amazon S3 usage, and so on. With Microsoft Azure Functions, you’re given a similar set of triggers. They allow for access via a web API, as well as invoking the functions based on a schedule. Microsoft also provides triggers from their other services, such as Azure Storage, Azure Event Hubs, and there is even some support for SMS-triggered invocations using Twilio.

There’s no clear winner here, since what is a deal breaker for one application could be a desired trigger feature for another. As such, it’s important to be aware of what options you have available and, when working with federated services, it is doubly important to ensure you can enforce similar patterns of behavior between the disparate platforms. Addressing this problem comes at the design stage, and should be taken into account when building out your application’s architecture.

Other Differences

As with any comparison of offerings between two different companies, there is never going to be complete overlap of functionality and approach. When comparing AWS Lambda to Azure Functions, this is no different. One difference is in the availability of the functions. AWS Lambda spins up a new instance if a function has been inactive for a period of time (usually around 10 minutes). While future calls within that 10-minute inactivity window will use the same instance if they are able, that first call after a long period of inactivity will result in a noticeable delay before the function responds, as AWS needs to spin up a container with the appropriate resources to execute your application. Microsoft Azure Functions, being built on top of Azure Web Jobs, are also subject to this restriction, but due to the underlying architecture this hot/cold divide seems to be less pronounced in the Microsoft ecosystem.

Another difference is in organization. AWS Lambda functions are built as standalone elements, meaning each function is essentially its own independent program. Azure Functions, on the other hand, are grouped together in an application. This allows multiple Azure Functions to share a single set of environment variables, for example, while AWS Lambda functions need to specify their environment variables independently. However, this also affects how application resources are allocated to functions – AWS Lambda provisions memory per-function, while Microsoft Azure provisions memory per application group. Again, there’s no “right” or “wrong” here – just two different approaches to what is essentially the same feature set.

Conclusion

Working in a serverless environment can save your organization effort when compared with a traditional client-server approach, but is not without its own unique reliability quirks. As such, it’s important to have a full understanding of the platform being used to provide your app’s server-side business logic, whether that is a Linux-based platform like AWS Lambda, or a Windows-based suite of services like Microsoft Azure. The beauty of serverless development is that, with minor changes, the code you write for one service should be portable to another with little effort – simply modify some interfaces, handle any input/output transforms, and an AWS Lambda Node.JS function is indistinguishable from a Microsoft Azure Node.JS Function. If your application is dependent upon a specific provider, however, it can pay to tie yourself more deeply into their ecosystem by leveraging service-provided triggers to execute your app’s logic.

+++

Interested in Serverless? Check out Backand. One platform to develop and run complete serverless applications.

Back to blog home page

Introducing: Lambda Launcher

Posted by on Jul 13, 2017

We’re pleased to announce the release of Lambda Launcher! Lambda Launcher was built by Backand to make it easier and more productive for your organization to use  AWS Lambda functions. We built the Lambda Launcher after experiencing a number of pain points in our usage of AWS Lambda, and wanted to share our knowledge (and the work we’ve done) with the rest of the serverless world.

Lambda Launcher makes using AWS Lambda functions painless, giving you an easy way to share your vital Lambda functionality with the rest of your organization. Sign up for your free Lambda Launcher account today! More details below.

Note to existing Backand users: Lambda Launcher is already built into your Backand account. To get started with it, inside your Backand app, go to Functions & Integrations > Functions > External Functions > select the Lambda Launcher tab.

Why do we need it?

One of the main challenges faced by AWS Lambda developers is how to effectively invoke Lambda functions from within a properly-secured execution context. With the default tools, you’re stuck to either granting every user access to your AWS dashboard, or writing a small web application that individuals looking to run your functions can use as their entry point. Recognizing this, we’ve developed the Lambda Launcher – a free, easy-to-use tool for running Lambda functions.

Own Your Functions

The Lambda Launcher connects to your own AWS account, allowing you to manage the billing while we manage the execution. We use a restricted IAM policy that only needs permissions to read and execute your Lambda functions. When using the Lambda Launcher, you retain full control over both your Lambda Functions and your AWS account as a whole – and you can revoke the Lambda Launcher’s access at any time by simply removing the IAM user.

Easily Import, Run, and Debug

The Lambda Launcher gives you an easy-to-use interface to run your Lambda functions from outside the AWS console. You’re provided with the capacity to save and configure parameters, an easy button to use when triggering your Lambda functions, and a log of the recent function runs performed. This web interface saves you the trouble of having to write your own, and also gives you an alternative to simply adding more users to your AWS account.

Control Function Security

As the Lambda Launcher is built on top of Backand, you also get a full application security suite with the Launcher. You can restrict access to functions by user, managing precisely who has access to your business’ vital Lambda functions. You can use the built-in robust user authentication schema that is built on the OAuth 2 standard, or use custom security actions to tie your function security into the rest of your organization’s access control mechanisms.

We hope you enjoy the Lambda Launcher and would love to hear your feedback! How can we improve it? How do you use it?

Back to blog home page

The Pros and Cons of AWS Lambda

Posted by on May 31, 2017

AWS Lambda revolutionized the serverless application landscape. Before, serverless implementations were limited to choosing a cloud provider for your application’s back-end functionality. With Lambda, Amazon pioneered a new development paradigm – Function-as-a-Service. In this post, we’ll give a brief overview of AWS Lambda, and then discuss advantages and disadvantages of using the service.

Continue reading

Back to blog home page

From Zero to Serverless With Backand, Part 1

Posted by on May 30, 2017

This post is the first in a series in which we’ll walk through creating a serverless app using AWS Lambda and Backand. This post will cover serverless app architecture, the project we’ll be building, and what Backand has to offer.

Why Serverless?

Traditional web apps give you a lot of flexibility but have high costs. From hosting, to maintenance, to security, maintaining your own server for your application can be expensive and time-consuming. It is also highly technical work that requires an expensive DevOps organization to manage effectively.

Serverless architectures save much of this time-consuming and expensive work.

What is a Serverless App?

While serverless architectures have been around in some form or another for several years, it was the launch of AWS Lambda at re:Invent 2014 that truly kicked off the trend – and the buzzword.

Serverless applications are not truly serverless, but rather outsource the provisioning and hosting of an application’s functionality to a third-party provider. This manifests as a number of different patterns: from dynamically launching Docker containers with your app in an on-demand fashion, to deploying only single functions that have their output combined together by a client-side app that serves more like a service orchestrator than a traditional web application.

The two predominant paradigms in serverless app development are single-provider serverless apps and Function-as-a-Service (FaaS) serverless apps. A single-provider serverless app simply replaces the server in a traditional client-server application with a third-party API. The developer in this application uses administrative tools with the third party to construct their data model, manage their app’s business logic, and secure their application. Much of the traditional server-side logic is moved to the front-end code, or emulated via features like server-side code execution.

Function-as-a-Service serverless apps take this a step farther. Instead of working with a single monolithic backend provider, the app is broken into individual functional areas. These functions are then uploaded to a service like AWS Lambda, and called via triggers – the most common being AWS API Gateway. The provider handles the challenges of making this code always-available, scaling the code in response to demand, and securing the execution and operation environment. While this preserves the server-side component in a more understandable and controllable fashion than a sole-provider serverless app, it requires a lot of error handling and service orchestration code to be implemented on the client side, bloating the client app size.

Serverless Tech Architecture

The summary graphic above highlights the primary differences between the three approaches. It’s important to note that this list of web application architectures is not exhaustive. Translating other architectures to a serverless pattern might require some work to ensure all functionality is covered and will vary in complexity based on the underlying app.

In the rest of this series, we will focus on sole-provider serverless, but it’s important to note that the two serverless patterns are not mutually exclusive. You can use a single-provider architecture with a Function-as-a-Service app, for example, or you can mix-and-match patterns by incorporating other third-party providers to supplement functionality in your application.

So, What are We Building?

In this tutorial, we’ll build a simple ToDo list application. We’ll implement an interface that allows a user to log-in, manage their to-do items, then log out. We’ll take an iterative approach, starting with the most basic code that we can to accomplish the task. In fact, some articles in the series, like this one, won’t require any coding at all. That’s the power of a serverless development platform. We’ll be using Backand to provide the server-side functionality, but the same concepts can be applied to any serverless platform.

What is Backand?

Backand is a powerful serverless development, deployment, and hosting platform. Backand replaces the server and database in a web application, allowing developers to focus on their front-end code. By leaving the headaches of the server to Backand, development teams are free to focus on application functionality without having to be distracted by deployment and configuration tasks.

Backand also allows you to bring a pre-existing SQL database. It uses SQL reflection to analyze the DB structure and dynamically build a REST API around it. Backand also provides several tools that address the shortcomings in Function-as-a-Service serverless applications, such as simple deployment and debugging of AWS Lambda functions. Using these tools, developers can focus on their application’s look, feel, and behavior – leaving the security, scaling, and configuration aside.

Step 1: Creating a Backand Application

The first step of creating a serverless application is to register and create an app. With Backand, it’s as easy as 1-2-3:

1 – Register for a free account at https://www.backand.com
2 – Create your application by giving it a name, a description, and then hitting the “create” button.
3 – There is no step 3! Your application is ready to go with a basic data model.

As this tutorial will stay somewhat superficial, we won’t need to make any changes to the application we create at first. The default data model for every Backand application consists of two objects: items, and users. We’ll use these to implement a basic to-do list, and modify the schema as we move forward.

Next Steps

Now that we’ve reviewed serverless architectures and created a Backand application, we’re ready to start coding! The next post in this series will cover designing a UI, and connecting the client-side code to Backand to retrieve a list of items. Posts that follow will then cover CRUD functionality, user authentication, and more. By the completion of this series you’ll have both a healthy understanding of serverless development, and a sample application to add to your portfolio. Tune in to our next post for more details or, if you’re impatient, hit the docs at https://docs.backand.com to get started on your own.

Note: This Article was first published on DZone.com.

Back to blog home page

Accelerating Serverless Development: The New Backand UI

Posted by on May 16, 2017

We’re excited to announce our new serverless-focused user interface. It makes it easier to get what you need out of Backand – be that data storage, AWS Lambda management, user security, or any of our other features.

In this post, we’ll walk through the concepts behind our new UI and offer a preview of a couple new features we’ll be launching along with the new UI.

Continue reading

Back to blog home page

Webinar: How to Build an AWS Test Harness

Posted by on Apr 04, 2017

AWS Lambda is a powerful tool for federating your application architecture and reducing operational costs for web apps with sporadic activity. However, while many of the interfaces to work with AWS Lambda functions are intuitive, the process of debugging the code as it runs necessarily has some holes. In recognition of this, we’re hosting a webinar, that goes through some of the tools we’ve used to greatly ease local development and deployment of AWS Lambda functions. We’ll cover the Lambda function prototype, the tools available for troubleshooting by default, a test harness we’ve built for local debugging, and finally deploying a Lambda function using our CLI.

Join the session on Wednesday, April 19th at 11 am PST

Overview of AWS Lambda

The webinar will give a brief overview of AWS Lambda for anyone not familiar. We’ll discuss the supported languages, the details that are shared on the execution environment, and we’ll look at how Lambda functions can be invoked. This will focus on Node.JS Lambda functions.

Troubleshooting AWS Lambda

In the webinar, we will also discuss how to troubleshoot and debug AWS Lambda functions. There are some built-in tools for debugging Lambdas, but they fall short of what a competent developer will typically need. We’ll discuss the mechanics of a Lambda function, and what kinds of tools are available for debugging out-of-the-box. We’ll also discuss the shortcomings of this approach.

Creating a Lambda Test Harness

Once we’ve addressed some of the challenges of implementing Lambda functions, we’ll discuss some potential solutions. During this session, we’ll work on creating a test harness that you can use to execute your code. We’ll cover mimicking the call structure of AWS Lambda invocation, and discuss some helpful techniques.

Deploying via the CLI

We’ll finally discuss Lambda deployment in the webinar, demonstrating one technique for deployment using the Backand CLI and Custom Node.JS actions. We’ll walk through what deployment entails, and how you can circumvent some of the trickier parts of the integration (like API Gateway and other triggers).

Conclusion

Our AWS Lambda Test Harness webinar will cover a lot of introductory material on Node.JS AWS Lambda functions. We’ll cover how these functions are built, how to structure your code, and how to debug it locally. We’ll also cover how you can easily deploy and call your Lambda functions from your application, using Backand’s Custom Node.JS Lambda Actions. Sign up so that you don’t miss this introduction to AWS Lambda functions!

Join the session on Wednesday, April 19th at 11 am PST