Increasingly, applications have been created to run within cloud environments.
For an application to work well in a cloud environment,
there are some additional considerations that need to be taken into account.
You may hear terms such as cloud native and born on the cloud,
which refer to applications that were designed to run on cloud platforms,
versus the more traditional or legacy applications
designed to run in a computer data center.
The design of a cloud native application,
includes much more than the function requirements the application must implement.
It takes into account the developer and automation tooling,
and automation used to implement and manage the application through its entire life cycle.
The migration between different runtime environments,
from dev through test into production,
the automated management of the workload and appropriate scaling
up and down of the application to cope with workload changes,
or the automated management of failures within the cloud infrastructure.
When designing a cloud native application,
there are a set of principles that are often used,
called The twelve-factor app.
These twelve factors, can be used as
guiding principles when designing applications for the cloud.
The original twelve-factor app work,
was completed some time ago,
but they still provide a good set of guidelines today.
I'm going to look at some of the twelve factors,
and discuss options for creating good cloud native applications in Node-RED.
As Node-RED, is a Node.js application using the express framework,
it does adhere to many of the twelve-factors guiding principles.
The version of Node-RED running on the IBM cloud,
has a few modifications from the standard version of Node-RED ,
that allows it to run as a cloud application.
There are a couple of areas you need to be aware of.
where your choice of node,
or the implementation of a flow,
can make the difference between having a well-behaved cloud application,
or an application that's not suitable for running as a cloud application.
Config: an application config,
is everything that is likely to vary between deploys.
With node-RED, it's easy to capture application configuration in a node.
Capturing environment specific configuration,
breaks the ability to use DevOps tooling to
automatically move an application between different environments.
Many nodes understand if they are being deployed in a cloud environment,
and will pick up configuration for bound services using environment variables.
However, many nodes do not.
You should be aware of any configuration you're capturing within a node red flow,
if the target for the application is a cloud environment.
Nodes often allow you to pass configuration properties with the incoming messages.
So it's sometimes possible to still use an environment variable to hold configuration,
and then ensure the configuration is passed from the environment variable into the node.
So no configuration is held within the node configuration.
Processes: execute the application as one or more stateless processes.
A cloud native application should not hold
any state in local memory or on the local file system.
You can use them briefly if needed during the processing of a single request,
but not to persist values between requests.
All state should be held by
a backing service that's available to all running instances of the application.
So it does not matter where a request lands.
All instances of the application should generate the same response.
There are many different storage options available on the IBM cloud,
and in week three,
we'll look at some of the common ones you may want to
use to persist data between requests.
In Node-RED, this does mean,
you need to be aware that currently the flow and
global context objects are in memory stores.
So they should not be used to store state.
The file system nodes are disabled by default in
the IBM cloud deployment of Node-RED using the boilerplate.
But if you decide you want to enable them,
you should be sure that you're not storing state on the local storage,
which could be lost during cloud scaling,
or error handling automated activities.
There is one consideration,
that's not explicitly called out in the twelve-factor app guidelines,
and that is the capability of services to handle
a variable number of clients representing a single application.
For Node-RED , you may need to look,
to verify if the node creator took cloud applications into consideration,
when developing the node.
If you take a social media or a messaging service as an example, will,
every instance of the application connected to the service,
get a copy of every message,
or is the backing service and the implementation of the Node-RED node
enabled to cope with multiple instances of an application,
all being connected and ensuring that only one instance receives each message.
As you move into week four of the course,
it's worth keeping in mind the requirements for
cloud deployment as you learn to develop your own nodes.
There are also a few areas where Node-RED needs to be modified to
make it easier to fit into a cloud native development model.
Code base: The code for an application,
needs to be tracked in a version control system.
While this is true of the Node-RED runtime itself,
which is held in a version control system, the flows are not.
On the IBM cloud,
they are stored in a NoSQL database,
and there's no version control system integration.
Build, release, and run: An application should have
distinct stages to take the codebase stored in the code repository through a build stage,
then onto a release stage or deploy stage,
and then finally, into running.
Again, the Node-RED runtime deployed
within the boilerplate does work within a DevOps toolchain,
and it goes through these stages.
The Node-RED flows do not.
Currently in a scaled environment,
the editor only works against a single running instance.
So when deploying, the changes are only made live to that single instance.
The updated flows are stored in the common NoSQL database.
But there's no mechanism to get all instances
to update their running a flow to the latest version.
Node-RED is still relatively young,
and there is an article on the Node-RED website called, A Roadmap to 1.0,
which sets out the plan to address many of the challenges developers have raised,
and also some of the shortfalls integrating Node-RED
into production environments and cloud environments.
As these new features outlined in the roadmap are implemented,
it will allow Node-RED to be run in
different ways to best suit environment it's running in,
and allow integration into DevOps tooling and processes.