Tag Archives: Microsoft Azure Functions

Back to blog home page

Backand Expands Cross-Cloud Serverless Support With FnProject

Posted by on Nov 02, 2017

At Backand, we’ve always been a strong supporter of open-source serverless development. With our support for OpenFaaS, and strong integrations with serverless function providers, We strive to provide developers with the tools necessary to build out their serverless applications on any platform they prefer. In support of this, we’re excited to announce support for Fn Project, a fully-containerized serverless function platform. In this post, we’ll take a brief look at Fn Project and how it integrates with Backand. We’ll cover the Fn Project’s background, integration touch points, and additional notes on Backand’s multi-platform serverless functions.

Fn Project – Founded by Tech Titans

Fn Project is a new open-source initiative to ease the sharing of serverless functions. Started as an initiative with Oracle, it has since grown into a stand-alone project that is rapidly growing in popularity. Functions are built and deployed using Docker, providing maximum flexibility in the Fn Project platform as well as allowing for easy local development and testing of functions in Ruby, Go, Node.JS, and other languages – by focusing on a container-native approach, Fn Project allows developers to write their serverless functions in any language they prefer.

In addition to full support for Docker containers, giving you the flexibility to run your serverless functions on any platform, Fn Project is fully open-source. The project’s code is available on GitHub, and leverages Go to provide a performance computation environment. In addition, Fn Project’s ability to support AWS Lambda-formatted serverless functions gives you easy access to a local development environment for your serverless architecture, easing the pain of development and deployment.

Building on Backand’s Cross-Platform Support

The addition of Fn Project to the Backand platform builds upon our already strong support for serverless function integrations. As a proud supporter of OpenFaaS, you can easily tie your containerized serverless functions into a Backand application’s control flow, giving you the power and flexibility of Docker and Kubernetes while continuing to provide your development team with the power to focus on the front end of your application, reducing development costs while simultaneously increasing application flexibility.

The Fn Project integration builds on our extensive serverless function support. In addition to Fn Project, you can leverage Google Cloud Functions, Microsoft Azure Functions, or AWS Lambda easily. By tying these application components into your Backand back end, you can build out access management and control flow in your application that matches your organization’s security, removing the need for your developers to have access to vital components of your application infrastructure just to develop your application’s logic. When tied in with our cross-cloud storage support, you can use whichever serverless provider you prefer and ensure your developers have all of the tools at hand necessary to create dynamic and engaging serverless applications.

Integrating Fn Project with Backand

Backand’s Fn Project integration operates in a similar manner to our other serverless function integrations. Simply provide the Fn Project server’s address on the web, and an optional connection string, and you are ready to go. Backand will automatically detect serverless functions in your Fn Project server, and provide endpoints in your Backand API to easily call these functions from application code. Simply import the function into your project, and begin coding against it – it’s that simple.

Conclusion

At Backand, we’ve worked hard to be a leader in cross-cloud serverless development, and our support of Fn Project carries this approach to new heights. By seamlessly incorporating your Fn Project functions into your Backand application’s framework, you get the flexibility of a serverless architecture with the ease of use of Backand’s application platform. In addition, Backand’s existing support for cross-cloud storage, robust security architecture, and easy ORM interactions with the database platform of your choice give you the capability to fully operationalize your application’s serverless architecture. With Backand you can accelerate your serverless application’s development, providing greater value to your users while lowering development costs and improving application maintenance – all without the need for your own server.

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.