Imagine a world where you do not need to create a VM or Container or even a full blown application back end for your mobile/web app.
The backend service is just a few lines of code that gets trigerred by some event such as a change in data in the database or an email or even an HTTP/s call from a handheld device.
A traditional back end for the mobile/web requires the app developer to create a backend application that receives requests from the mobile/web applications. The backend application may be hosted in the cloud either using the PaaS or the IaaS compute option. Recently cloud platform vendors have started to offer a new compute option that I like to refer to as the Event Driven Micro Computing. This compute option compared to the PaaS/IaaS model provides many benefits for some of the common use cases implemented in the mobile/web backends.
At a high level think of a scenario where your developer needs to update the sales dashboard everytime a purchase is made by the customer on a ecommerce website or mobile application for which the back end is implemented on PaaS/IaaS. The traditional (or common) way this ancillary function is built is by coding the dashboard-update-function as part of the core application. Every time a new KPI/Metric needs to be added to the dashboard, the core application code is touched thus leading to higher cost of change, risk of outage and higher complexity of the core application.
Using the Event driven micro compute option the developer can create the dashboard update function by writing the dashboard update function that is independently hosted and managed with this new event driven compute option.
So the obvious question is what about the invocation of the code? This compute option allows the developer to associate the service with an event that triggers the execution of the service. Example of event is an insert (or update) of the database table or a message in a queue or an email, as you can see there are multiple event sources that can trigger the code.
Today this compute option is available on Amazon AWS cloud as Lambdaservice, on Bluemix as the OpenWhisk service (announced on Feb 22 2016 @ IBM Interconnect conference), on Google as Cloud Functions. Each of these services offer a wide variety of events and a choice of programming languages in which the event processing may be coded. Technically these services may be leveraged to create full blown backend applications for the mobile or web.
The cloud platforms guarantee that no matter how big the spike in load is, an instance of your service will be available at all times to take care of the incoming request. There may be a safety throttling policy (peak load) applied by default, to prevent unintended scenarios but that may be removed by making a request to the provider. Example is AWS Lambda that has a default safety throttle set at 100 concurrent execution per account per region.
With the traditional backend implementations it is common to have multiple containers or VMs for resiliency. The event driven computing takes a different route the application owner does not have to explicitly create and manage multiple instances of the service, rather the platform guarantees availability of the service instance at all times.
With the traditional PaaS/IaaS model application owner needs to pay for the resources that they are using on the cloud platform. The back end applications need to stay up and available irrespective of whether there is incoming traffic or not. Dynamic scaling (pro-active & reactive) may be utilized to optimize the cost but there is still going to be a standing cost associated with the minimal resources needed for your application. The event driven services offers a different pricing model. Typically the pricing model is based on two factors (a) Number of times the service is executed (b) amount of time it takes to execute the service. This leads to higher cost efficiencies as resources are not used up in and charged for in the standby mode.
Many developers are excited about microservices. This new compute pattern inherently provides a way to implement microservices architecture. Each of the event driven service may be a microservice that is responsible for one specific task only.
Data processing examples
- Video file processing - use uploads the file to object storage. Storage event is fired and video file is processed for various form factors asynchronously
- Data transformation - database insert/updates generating a database event leads to processing of data e.g., transformation or generation of reports
Application backend examples
- RESTful API for processing incoming requests from the mobile/web front end. E.g., list of products offered by the company
- Microservices for building highly de-coupled business functions. E.g., initiate a customer complaint workflow
IoT backend examples
- API for the data received from IoT sensors
- Realtime alert generation
Please go through the platform SLA and technical specifications for the services before deciding whether such compute option is aligned with your backend application's needs and use cases.