I was recently looking for articles that describe how to build custom Slack bots and commands. I found several informative articles that describe using Serverless technology for this purpose (see this, this and this for examples). These blogs contain a lot of details, but they also cover a lot of steps.

I want to introduce you to Nimbella Commander as the better, faster, and easier way to build Slack bots and Slack commands. Nimbella Commander requires no new accounts to set up, no command-line tools to start, and you will be done creating your first Slack command in seconds.

One-click, two commands, and profit. I challenge you to find a better, faster, or easier methodology. …


Nimbella is serverless made easy.

This article demonstrates how to build a stateful web application using Nimbella. I will use a Stock Trading application as the running example, and highlight how a developer can build the complete application, consisting of a frontend and a stateful backend. This application mimics the functionality of a transactional application that buys and sells stocks. We won’t be dealing with real money or real stock transactions.

Before I describe the application architecture, let’s go over what you won’t have to do as a developer. You won’t have to configure cloud storage for your frontend static assets (HTML, CSS, and JavaScript), or configure a content delivery network (CDN) to serve the application from the cloud. You also won’t create any infrastructure for your backend, operate any servers, or even configure a database to be backed up and secured. …


How Serverless Computing is Shaping the Cloud

Serverless computing, ushered in full force with the introduction of AWS Lambda, is the foundation of a cloud-native transformation that is ongoing in the industry. It is the way cloud applications are being built and will be built for the most part in the future.

An example of serverless computing that I’ll focus on here are Serverless Functions: units of code that execute in response to events. As a developer, you create your functions in the cloud and they execute in response to events.

  • You don’t scale the servers because you didn’t provision any. Yet your function executions will scale with demand: more events, more functions executed in parallel. …


Serverless computing with functions fundamentally reduces the amount of code you develop and deploy for cloud applications, eschewing the “server” parts, and allowing you to focus on just your functions. For a cloud native application, where functions are APIs, an integrated API gateway handles the routing of events and REST requests to your functions.

If you’re not yet familiar with serverless functions, I recommend my article on creating serverless functions using Apache OpenWhisk. …


It is common for a web based service to provide a service level agreement (SLA) which specifies the level of up-time the provider strives for. The SLA constitutes the terms and contract between the provider and the user. In the case when the provider cannot meet the stated up-time guarantee, the user is typically entitled to some form of a credit.

For functions-as-a-serverless (FaaS), also known as serverless functions, the traditional SLAs used for web services do not apply in the same way. …


Connecting Travis CI to Slack Using Apache OpenWhisk

In this article, I show you how to use Apache OpenWhisk to create a serverless application that is composed from serverless functions. The functions are created and deployed as OpenWhisk actions. Similarly, the composition itself is an OpenWhisk action. This is particularly noteworthy in that compositions, therefore, may be further composed, leading one to develop reusable and modular serverless function-libraries.

The serverless application that I describe here is a Travis CI-to-Slack bot. It reacts to Travis CI build notifications and performs the following tasks:

  1. fetches and analyzes the build and test logs,
  2. generates Slack notifications for the failed tests aimed at contributors. …


Serverless computing frees developers from infrastructure management. Instead, developers focus on their business value and managing the business critical assets — the code. Infrastructure security, scalability, maintenance, availability, monitoring and the like are managed by the cloud provider.

Functions-as-a-service or simply functions is one of the building blocks for serverless computing: a developer can deploy a REST API by deploying a single function to the cloud. The function is reactive, and runs automatically in response to events. Moreover, the number of function instances scales automatically whether handling 1 event or 1000.

Functions and more generally, serverless computing, are disruptive technologies. Today, companies large and small are investing and innovating rapidly in this space. For those of us already immersed it, we are at the fast moving frontier for a new model of computing. …


The execution of functions that run in a serverless cloud is opaque for the most part. In general terms, when a serverless function is invoked, the platform accepts the request and provisions resources before it executes the function. We can refer to the duration between accepting the request and the start of the function execution as the “system time”. The system time along with the “user time” (i.e., the time consumed executing the function) contribute to the total time it takes to service a single function request.

In the cloud, the serverless platform has almost total visibility into the system and user times and can aggregate this information systematically. Such information can enable performance analysis that is often central to improving the efficiency of applications, cloud native or not. A service like AWS X-Ray is one way to address this problem, for applications locked into AWS that is. …


Apache OpenWhisk is a readily extensible serverless computing platform that supports functions authored in many programing languages including Node.js, Python, Swift, Java, and PHP. The set of supported languages extends beyond these five however, and includes Go as well as other compiled languages. In fact, a feature of OpenWhisk that has been around for some time, but not well documented, is its support for native binaries. With a native binary, any executable that is compatible with a standard OpenWhisk container may run as a serverless function, also known as an action.

The native binary approach affords you more languages to choose from for your serverless applications, such as Go, Rust, C and C++ to name some. Not to mention, you can also bring your own Docker container and run it as a function. …


functions are APIs and APIs are functions

Serverless functions are a fast, convenient, and cost-effective way of developing cloud-native applications. Within minutes, it’s possible to deploy functions to respond to events such as webhooks or REST API requests.

Functions as APIs: Using the shell for IBM Cloud Functions — a new client for working with Apache OpenWhisk and the IBM Cloud — it is convenient to create actions as APIs via web actions. The example below shows a function in Node.js that produces a simple HTML response.

Image for post
Image for post
Using the IBM Cloud Functions Shell, deploying a function as an API is a one liner. Adding “.http” suffix on an action name “fn” inside the shell automatically turns the function into a web-accessible endpoint.

It is often the case that several functions must be composed together to create larger serverless applications. For example, a convenient way to secure APIs built out of functions is to compose the business logic (e.g., fn) with an authentication layer. For the latter, I’ll create an auth action to check for the presence of a token with a predefined value. Failure to specify the token will result in an error. …

About

rodric rabbah

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store