Tag Archives: Serverless

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

Incorpoating Backand in a Native Android App

Posted by on Jul 13, 2017

In this article we’ll look at how to connect a native Android application to a Backand back-end using HTTP calls. We’ll cover configuring the connection headers, authenticating with Backand, sending requests, receiving responses and other Backand SDK functionality.

Continue reading

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

The 4 Serverless Conferences You Don’t Want to Miss

Posted by on May 26, 2017

The concept of serverless architecture has been gaining steam over the last year or so and this has led to a handful of conferences either completely dedicated to the topic or with a heavy focus on it. There’s no better way to learn more about the advantages and developments related to the serverless trend than to hear it from experts. We’ve put together a list of can’t miss conferences that will bring together some of the top minds and companies leading the serverless evolution.

Serverlessconf.io: The Title Says It All

This event surely won’t disappoint the serverless-oriented developer. The first leg of Serverlessconf took place last month in Austin and the speaker lineup of 40+ people delivered some truly innovative sessions, not to mention the 5 hands-on workshops which received rave reviews. One of the most interesting things to note from Austin, however, was the range of definitions of ‘serverless’ and how they differed from presenter to presenter. This comes as no surprise as serverless is still in its infancy or as Charity Majors called it ‘the toddler years.” If you didn’t make it to Austin, don’t worry as the conference will also be held later in the year in London, New York, and Tokyo and the team at Serverlessconf said they would announce the dates for each upcoming location soon so stay tuned.

QCon: Learning from Expert Peers

QCon has been a fixture on the scene for the last 10 years, and every year the conference gets even better. In 2017, there will be 3 more QCons: New York (June 26-30), Shanghai (October 19-21) and San Francisco (November 13-17). Each event – a 3-day conference followed by 2 days of workshops – features 15+ tracks and 100+ speakers from leading companies including Google, Slack, Netflix, GitHub, and Twitter. All of the conferences are peppered with talks and workshops focusing on building and running serverless apps and the benefits of serverless infrastructures.

MuCon: All about Microservices

MuCon, brought to you by Skills Matter and scheduled for November 6-7 in London, focuses on microservices. When designing flexible systems that meet ever-changing business needs, microservices are an important part of any architectural approach. This conference keeps that in mind and focuses on discussing emerging technologies and innovative approaches. The keynote speaker for 2017 will be Russ Miles, an expert in software delivery processes.

AWS Re:Invent: Amazon, Enough Said

If you’ve never attended AWS Re:Invent, you’re certainly missing out on one of the best developer conferences of the year- hosted by Amazon, we’d expect nothing less. Although only the 2017 dates for the Las Vegas-based conference have been released (mark November 27-December 1 on your calendar now), if this year’s conference is anything like last year’s, you’ll be in for an educational treat. We’re sure that there will be a handful of sessions focusing on serverless architecture again this year, but the question remains as to who will be presenting. In any case, make sure you get your seat well in advance as these packed lectures filled up quickly in the past. And, of course, the most anticipated part of this conference comes from AWS’ new product announcements. We can’t wait to hear what the company will be unveiling.

Bonus: Can’t Travel, Find Something Local

We know that not every company or individual has the budget to hop on a plane and pay for tickets and the expenses that accompany these top-notch conferences. And, while conferences may bring together the cream of the crop, some of the speakers may be based in your local city and attending a Meetup near you. These more intimate gatherings are no less important, and the networking alone makes these small scale events well worth attending. Here are some of our favorites but if none of these cities is your hometown, you’ll find more than 90 Serverless Architecture Meetups hosted around the globe.

If you’re on the West Coast, check out the San Francisco-based Serverless Meetup which gets together once a month and is over 1100 strong or the younger LA-based Meetup.

Serverless London Meetup group is 1000+ members strong and gets together on the first Wednesday of every month to discuss everything and anything related to serverless. If you’re in the city and interested in building web, mobile and IoT apps using serverless architecture, this group is for you.

Serverless NYC has been going strong since 2015, now with over 400 members. They meet up every few months to discuss topics around the development, deployment, and maintenance of distributed systems in the cloud without provisioning servers.

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

Upgrade Your Apps to Work with Our New Serverless SDK

Posted by on Mar 02, 2017

This post is a quick guide to upgrading your existing Backand-powered applications to work with the new Backand Serverless SDK we announced a couple of weeks ago. We’ll cover the changes made in the SDK, and explore the steps you need to take to get your Backand application up and running with the new API.

What’s changed?

We’ve made a number of changes in our new SDK that make developing against Backand faster than ever. Here’s a brief overview of what changed:

  • Streamlined authentication, making it easier for you to authenticate your users.
  • Improved the process for registering with – and signing in via – social media providers with the addition of new SDK methods.
  • Greatly improved the method in which you interact with Backand objects. Gone are the days of needing to manually construct a URL – simply specify the object name as part of a clearly-named function call to the API, and we handle the complexity for you.
  • We have also streamlined our response data, allowing you to work with the results of calls to your Backand back-end in a more straightforward manner.

And on top of all this, we continue to offer the same secure, scalable, and responsive backend-as-a-service that we always have!

Converting old app code to the Serverless SDK

Next, let’s look at what steps are needed to change a Backand application to work with the new SDK. For reference, we are basing this code off of our base Ionic starter app – see it on the Ionic marketplace at https://market.ionic.io/starters/backand-simple.

Step 1: Add new SDK to bower.json

First, you’ll need to add the new SDK to your bower file.

Step 2: Update Script includes in index.html to include the new SDK.

Start with removing the old SDK by commenting out – or deleting – the following line:

Then, replace it with the new SDK links:

Or, use the CDN files:

Note: You may want to check your dependencies directory for any lingering versions of the old Backand SDK – this can cause cache issues due to competing HTTP Interceptors. Simply remove the old folder from the appropriate directory in your project.

Step 3: Update the user authentication method

User authentication is largely unchanged, with a few notes below:

  • If you have previously disabled anonymous auth in your app, you can re-enable it using Backand.useAnonymousAuth(). This value defaults to true, so if you do not modify the default value you do not need to make any changes.
  • We’ve added new social media authentication functions: socialSignin, and socialSignup. Please note that while some of the examples in our github repos – and some of our documentation – used socialSignUp to refer to the specified function in the Backand SDK, this is no longer valid – the “up” will not be capitalized in the new SDK.

Step 4: Update the method used to detect unauthorized users

The getToken() method has been expanded, to use a promise. Originally this method would return undefined when a user was unauthorized, but this functionality can now be managed via the promise method. In the new SDK, the getToken() method is not as prominent as it was in previous versions, and you are likely to not need it as you work on your app.

Step 5: Change $http usage to use the Backand SDK REST methods:

The Serverless SDK features wrapper methods that can be used in place of the direct HTTP calls used in the previous method. Here’s a quick comparison of the old SDK’s HTTP communications, as compared to the new function-based Serverless SDK:

Step 6: Update data result usage

The old SDK would use code similar to the following when handling responses from Back& API calls:

The new SDK does not store the results in a nested data member, but rather in a root data element. The old SDK stored the response contents in a root property, meaning that the actual data was a subset of this data property – hence the use of result.data.data in the old SDK. With the new SDK, you no longer need the extra level of disambiguation, and can store the data in your application’s object with the following code:

Conclusion

In this post, we covered the Backand Serverless SDK. We touched briefly on the features the new SDK has to offer and walked through the process necessary to convert an existing Backand-powered app to the new API. Most importantly, though, is that we built this SDK based on your feedback, and we want more! Connect with us via social media (Twitter, Facebook), or on StackOverflow, or even directly via comments on our Git repos and contacting customer support – we’d love to incorporate your thoughts and suggestions into the next version.

Don’t have a Backand account? You can get one for free