This post explains how event-driven/serverless application architectures mark an important further evolution in the container technology that fundamentally enables large-scale cloud computing platforms.
Two complementary trends in application development have been driving the evolution of container-based platforms:
Decomposing large on premises applications into smaller ones that better support rapidly evolving customer experiences while leveraging systems-of-record still hosted on premises.
Creating smaller teams focused on quickly putting business ideas into practice as new, cloud-native applications that, by being independently and continuously iterated, and by strategically accessing cloud platform services like IBM Watson, more effectively engage end users.
Overall, the goal is to engage users in an expanding range of real-time situations.
We can already discern a spiral of customer expectations and app innovation that is pushing cloud platforms towards an edge where locative computing experiences meet the automated data flows of an Internet of Thing (worth $7 trillion by 2020). On that edge sits an event-driven, serverless form of computing that can treat both user-initiated and sensor-generated data as events upon which to trigger specific automated actions, including interactions with cloud services.
As a current example, GreenQ is a company that endeavors to provide more sustainable garbage collection by using IBM Cloud Functions to receive data from the sensors on their trucks. The company already has been able to bring as much as 50% cost savings to cities through optimization of scheduling, fleet management and routing.
Analysts at Enterprise Manage Associates (EMA) include the GreenQ solution as a case study in their 2017 serverless decision guide.
Containers advanced cloud computing beyond its origins in virtual machines. While container-based, platforms like IBM Cloud Functions (based on Apache OpenWhisk) abstract containers from the application development process. Freed from thinking about containers or underlying infrastructure, app dev teams can focus exclusively on writing code.
As a programming platform as a service, with a real-time container orchestration system, IBM Cloud Functions takes the further step of enabling developers to define events in the cloud to use as triggers for automatically executing small, independent pieces of code—called actions—that they write in a language of choice, leaving everything else to an engine that instantiates application code into appropriate containers as needed to execute the relevant actions, often in an interrelated sequence.
Being event-driven and streamlined for scalable high performance, serverless actions keep up with the workflow needed to service either a user’s quickly-changing, location-specific experience–as mediated, for example, by a mobile application that remains thin on the client device by sending data into the cloud for processing, or an IoT data feed that results in some specific customer benefit.
In being spurred to define new triggers and actions that take advantage of business opportunities implied in new system events, developers can become creatively agile in a new way, potentially accelerating the rate of application iteration to keep pace with the demands of mobile user experience as implied by insights generated through clickstream analytics. In an event-driven programming platform, the response of an application iteration to usability friction can happen at a level of granularity to which other container-based cloud systems merely point the way.
Let’s consider a few specific application examples. In executing actions with Cloud Functions, all three use a Cloudant database in the IBM Cloud to store data and Watson services to process that data.
BluePic: enhanced photo-sharing through cloud services
In this first example, BluePic, an iOS photo-sharing application written end-to-end in Swift, directly communicates with Cloud Functions via a REST API. In real-time, BluePic sends a photo to the cloud for analysis–aspects of the image are recognized and tagged–and then lets you share the results with other BluePic users.
BluePic uploads the photo to a web framework server, which writes information about it into a Cloudant database and sends the binary file into object storage. Following image upload, insert, and storage, the Kitura server makes a REST request into Cloud Functions to begin the asynchronous analysis.
Kitura invokes a main orchestrator action, which runs each individual Cloud Functions action in its own container and in a chain:
Read information about the image from the Cloudant database
Request image tagging/recognition data from the Watson Visual Recognition service on IBM Cloud
Request weather data from the Weather Company Data service on IBM Cloud for the location where the image was captured
Receive the results from the Watson and Weather services, merge the data and save it back to Cloudant
Make a request back to the Kitura server, which delivers updated data back to the client device using the Push Notificaitons service on IBM Cloud.
After an action completes, the orchestrator recycles the relevant container. And through this real-time container orchestration, Cloud Functions essentially chains together microservices to execute the server-side business logic that BluePic initiates with a simple file transfer. For more on BluePic, check-out the tutorial.
Skylink: expedited insurance damage claims through cloud services
This next example pertains to the use case of documenting damage for commercial property insurance claims. Consider a scenario where an insurance company must hire an aerial photography vendor to capture images of the damage, which is both costly in itself and subject to the delays of scheduling. Enter SkyLink.
This mobile application receives images captured by a quadcopter drone, saves that data into a Cloudant database–running on the mobile device–that automatically replicates data with its mirror in the cloud, thereby triggering a chain of actions:
Read image data from the Cloudant database
Request image analysis/tagging from the Watson Visual Recognition service on IBM Cloud
Receive and write the results of the analysis to Cloudant.
The entire workflow occurs in real-time, while the drone is still in the air. The application reduces the cost and time of acquiring the images, reduces the time of verifying that all areas of damage have been fully captured, and so reduces time needed to complete the damage assessment.
Dark Vision: analyzing and tagging frames in video streams
Like BluePic and Sklyink, this mobile application uses the Watson Image Recognition service to analyze and tag objects in images. However, the important difference is that Dark Vision does so based on a video source, and by using a Docker image of the ffmeg multimedia framework as an Cloud Functions action to extract the video frames that Watson analyzes.
Dark Vision triggers a main orchestrator action when a user of Dark Vision uploads a video. The orchestrator, based on the triggers connecting the actions in sequence, manages the containers needed to execute these other actions:
Read information about the video from the Cloudant database
Request a Docker image of ffmeg to extract images from the video and save each image in the Cloudant databae
For each image, read information about each image from the Cloudant database
For each image, request image/face analysis and tagging from the Watson Visual Recognition service on IBM Cloud
Receive the results from the Watson service and save it back to Cloudant
Push the image/tag data back to Dark Vision on the client device.
Ready to start working with Kubernetes? Want to build your Kubernetes skills? The five tutorials in this post will teach you everything you need to know about how to manage your containerized apps with Kubernetes.
We are excited to announce the availability of Kubernetes v1.14.1 for your clusters that are running in IBM Cloud Kubernetes Service. IBM Cloud Kubernetes Service continues to be the first public managed Kubernetes service to support the latest upstream versions from the community.