Tag Archives: Function-as-a-Service

Back to blog home page

On-premises Serverless with Backand and Kubernetes

Posted by on Nov 21, 2017

Projects like kubeless.io and FnProject give you a lot of flexibility when working with serverless functions. Coupled with Kubernetes, you can easily build a FaaS offering for your IT organization that can scale as needed within the secure confines of your organization’s technology infrastructure. However, if you’re looking to build a fully serverless application, local access to a FaaS install is only a step along that path. This is where Backand comes in. Backand lets you build an on-premises serverless platform, letting you embrace serverless development on your own terms. In this post, we’ll look at some strategies you can use to build out your organization’s serverless platform with Backand, providing you with a full suite of serverless capabilities built on a tech stack managed internally.

The Shortcomings of FaaS-Only

While an on-premises serverless stack provides a powerful resource that meets your security standards while leveraging your existing IT infrastructure, a platform with only support for serverless functions is lacking in several vital components for fully serverless applications. The first is file storage – many serverless applications require data storage and processing capabilities, and as such a fully-serverless platform on-premises needs to also have support for some kind of cloud storage. While a database server will generally be a stand-alone machine or cluster, you’ll need to devise a way to get your database talking with your serverless functions if you want to have a robust, non-trivial web application. Finally, to complete our platform, we’ll need solutions for any of the other bits of functionality considered standard in a web application – logging, routing, and hosting, for example, are vital to a production-ready web app. In order to address these shortcomings of an FaaS-only approach, we’ll look at a couple technologies we can use to create an on-premises serverless development platform.

Building a Serverless Platform with Backand and Minio

While serverless functions are phenomenal for reducing IT support needs for bits of common functionality, they are not in themselves a sufficient platform for building web applications. You’ll need to build out a platform to tie your serverless functionality together. To manage this, you’ll need both storage mechanisms and a platform to manage your full suite of technology assets.

We’ll address these shortcomings in two parts. The first involves installing Minio, and AWS S3-compatible cloud storage solution built to run on your local stack using Docker and Kubernetes. By using Minio, you gain access to localized file storage with similar operability to S3, allowing you to store these files within the secure confines of your organization’s network. Furthermore, as Minio’s API is S3-compatible, you can easily leverage the same tools you use for your Minio install on a live solution built on top of S3, giving your developers the power to switch between online and offline paradigms as necessary.

While the above has given us an interface for functionality, and a full cloud storage solution deployed within your trusted IT stack, we’re just about ready to provide internal developers with a fully-functional serverless environment. The final piece is a local install of Backand. The team at Backand has been working hard on containerizing and operationalizing our revolutionary ORM and security architectures, allowing you to use a local install of Backand as the platform that can unify all of your stack’s serverless technologies into a single, easy-to-use interface. Built on top of Docker and Kubernetes, Backand has all of the hooks necessary to tie into local database instances, local FaaS installations, and your local Minio host, providing your organization with a full on-premises serverless platform that can be guaranteed to meet your organization’s security and availability needs.

Exploring Use Cases

One of the challenges with serverless platforms is in identifying how to fit the technology approach into a larger development organization.To help with this, we’ve explored several use cases for on-premises serverless support. These focus on several different problem areas: cost, security, and resiliency. If you’d like us to explore additional use cases, please don’t hesitate to contact us at support@backand.com.

Full On-Premises Serverless

One of the common complaints leveled against serverless function providers is that you have no control over the security of your functions as they run. Google, Microsoft, Amazon, Oracle, and others have an impressive track record when it comes to security, and have ingrained best practices that reduce risk and mitigate attacks, but these security requirements may not meet the standards of your organization. Using a fully on-site serverless solution, you can rest assured that you have full control over your application’s serverless platform, securing the product to the standards demanded by your organization.

Increasing Resiliency with an Internal Fallback

Despite the massive resources of large tech organizations offering serverless platforms, problems still occur from time to time. In a traditional provider-hosted approach, such as a tech stack built entirely on top of AWS, when these outages occur you are left with a non-functional application and angry users. With Backand, Minio, and your on-site FaaS solution of choice, you can easily recover from a failure of a major service provider, using your own technology stack as a fallback. Simply adjust a configuration setting, and your application’s can switch instantaneously from running against your cloud provider’s solution to running against your own local installation. Couple this with data retention policies, regular backups, and a slave environment that tracks the main production environment as closely as possible, and these transitions can be nearly seamless.

Using a Serverless Install for Smoke Testing

With FnProject, Minio, and Backand all operating in a fully containerized solution, you now have the capability to fully replicate your tech stack both quickly and at low expense. Leveraging the flexibility of these technologies lets you build a development environment that mirrors your production environment almost exactly. As the underlying technologies are server-agnostic, running in a containerized ecosystem, you can install your full tech stack anywhere. This makes creating a smoke test environment a snap, and gives your developers the added peace of mind of knowing that the production environment their code runs on will share the same characteristics as their local testing environment.

Quick White-label Development

One of the advantages of a containerized approach to application development is the ease with which you can deploy an entire platform. This gives you the capability to quickly and easily deploy your application in a number of different environments. This approach can greatly benefit software resellers, allowing you to provide a fully-functional, fully-customizable solution that can be deployed in seconds on any appropriate tech stack. If you couple this with a conscious approach to configurability in your application development, you can quickly develop an application that can be rapidly switched to a different look and feel simply through the replacement of art and localization assets. This gives you the capability to provide an easy white-label resale solution, allowing your customers to brand your application to their desires, and enhancing the attractiveness of your product to potential sales opportunities.

Conclusion

With a fully-containerized stack, your application has a lot of flexibility when it comes to physical hosting location. By building a local serverless platform on top of Minio and a FaaS solution like OpenFaas, FnProject and kubeless.io, you can expand that flexibility to also include your organization’s internal IT infrastructure. This gives you all of the flexibility and benefit of a cloud architecture, while still giving you the capability to secure and protect assets to your exacting standards. With Backand, your platform can be responsive, highly-scalable, secure, and most importantly it can integrate deeply with the rest of your technology stack, letting your organization embrace serverless development on your own terms.

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.

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?