Planning serverless apps

Review the runtime support

Cloud Functions provides standard runtimes to execute code. But, because the Cloud Functions service is serverless, you're not limited in the runtimes that you can use. You can create custom runtimes by creating your own custom Docker image to package your code.

Architect your code

You might need to make some tweaks to your existing code for it to run in IBM Cloud® Functions. If you don't have your code yet, keep these things in mind as you write it.

1. Componentize your code.

   If you already have an app that you want to make serverless, consider how you might need to break your app apart into smaller pieces. Each function contains a set of triggers for code that you want to run. For example, if an issue is created on GitHub, run this JavaScript code. If your app contains several of these events or actions, consider separating them into different functions.

2. Use IBM Cloud services instead of frameworks.

   Instead of using frameworks to make capabilities available in your function at run time, you can choose IBM Cloud® services. Many common tasks that frameworks help you to complete are available as services on IBM Cloud®.

   For example, instead of using a framework for authentication, try IBM Cloud® App ID. If you need external file storage, try IBM Cloud® Object Storage.

   If the capability that you want to incorporate is not available as a service on IBM Cloud®, you can always integrate that capability with feeds and APIs too, without the need for frameworks.

3. Verify that your code meets the system limits.

   Your code must fit within the system limits to run. For example, if your packaged code is larger than 48 MB, you might need to continue breaking it down into smaller pieces or packaging it as a Docker image.

   Applications that contain many third-party modules, native libraries, or external tools might hit this limit. If you create a .zip or .jar package action that is larger than 48 MB, you must extend the runtime image with dependencies. Then, use a single source file or smaller archive than 48 MB. For example, by building a custom Docker runtime that includes necessary shared libraries, dependencies are not required to be present in the archive file. Private source files can still be bundled in the archive and injected at run time.

4. Determine the parameters that must be injected into your code.

   In serverless actions, data is supplied by adding parameters to the actions. Parameters are declared as an argument to the main serverless function. Most commonly, these parameters are credentials for a service, but they might be anything that makes your code reusable with different triggers.

5. Verify that the structural requirements for your code to be used in a function.

   Whether you have an app already or plan to develop a script to use, your code probably needs a few tweaks to make it consumable by IBM Cloud® Functions. The code itself must meet some structural requirements, such as the input parameters and the output results. It might also need to be packaged into a single file that includes all its dependencies.

Determine your event source

Think about your function in terms of the event you want to happen to trigger code to run. Maybe you want code to run on every commit to a GitHub repository. Or maybe you want your code to run every time that an update is made in a Cloudant database.

After you choose an event to trigger your function, review the packages that are already available to use. You might be able to use one to simplify your function development. If not, you can create your own package for your event source.

You might need to go back to your code and make some revisions based on your event selections.

Organize deployments across environments

Decide how you want to deploy your functions across environments, such as development, staging, and production environments.

Because Cloud Functions is a Cloud Foundry-based service, you can manage the deployment of your functions in the Cloud Foundry organizations and spaces that are provided for you in IBM Cloud. To organize your functions across these environments, you might choose to create one organization per function. Then, create a space for each environment you need. Instead, you could also have one organization for each environment and create a space per function. No matter how you arrange your organizations and spaces, choose a structure that you can use to effectively manage your function entities.

You can also use namespaces to isolate resources. Each IBM Cloud space contains an Open Whisk namespace by default. You can group entities, such as actions or triggers in a namespace, and then create Identity and Access (IAM) policies to manage user permissions for that group.