Cloud Native Computing Foundation CloudNativeDay 2016 (Toronto), 6 Sep 2016

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cloud Native, Event Drive, Serverless, Microservices Framework - OpenWhisk - Daniel Krook, IBM

Description

Cloud Native, Event Drive, Serverless, Microservices Framework - OpenWhisk

Cloud computing has been a game changer in a number ways and the emergence of serverless computing/architectures is just another example of what cloud tech has been able to achieve. Serverless is about abstracting users away from servers, infrastructure, and having to deal with low-level configuration or the core operating system. Instead, developers make use of single purpose services and elastic compute platforms to execute code.

In this talk we are going to discuss open source serverless platform OpenWhisk. OpenWhisk provides a distributed compute service to execute application logic in response to events. There are several key architectural concepts:
Triggers: A class of events emitted by event sources.
Actions: Encapsulate the actual code to be executed which support multiple language bindings including
Docker Containers Rules: An association between a trigger and an action.
In this talk we are going to discuss the rise of Serverless architecture to compose solutions using modern abstraction and chaining.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.

A

All right, thank you. Thank you. um So my name is daniel crook. I'm a senior software engineer in the ibm cloud organization. um So today I'm going to talk about serverless, architectures event, driven programming and a new open source project called openwhisk that supports those type of cloud native applications.

A

Okay, so my goals here to really help you understand this emerging model and position it in terms of what we've seen in cloud computing to help developers create applications faster, better and cheaper than they have before and then I'll go into.

A

How openwisk helps that happen? What the programming experience looks like and how to get involved, what it can integrate with and uh and move forward from there.

A

So has anybody here heard of openwhisk, yet okay, and has anybody had a chance to use it on the hosted environment on bluemix?

A

Okay got a couple people. I expected that. I hope that for that actually, okay, great okay. So let's kind of set the stage for this. Let's what is it about serverless computing, that's just so compelling and why it's grown so explosively. In the last 18 months, the goal of developers has always been to get the brand new value that they're creating out and deployed to production as quickly as possible.

A

So, 10 years ago, if you remember from dan's presentation the keynote to get from point a to point b, you had to go through an operations layer to provision hardware deal with the configuration.

A

Do the capacity planning before you even got to the point where you ordered the hardware and 10 years ago we saw the first amazon services come out, so moving us from bare metal up to virtual machines and, more recently, we've seen what really has been the trends that created cloud native computing, which is the container technology deployed as microservices in order to to close that gap even further between writing the code and getting it in production and new serverless architectures really are just an evolution of that right, they're addressing the same goal, which is to get code from the developer to production as quickly as possible, so that allows them to focus even more purely on the code.

A

That's running and less and less about the operational concerns of making it stay up or making sure it survives load load, huge spikes in load. Things like that and and the corollary to that is that they're losing more control. Over the platform for better or for worse right, their their seed in control in order to get more control over delivering that business value um and, as we've seen, cloud evolve and lots and lots more adoption of cloud. There's many more new types of workloads, emerging workloads that are looking for an event-driven architecture.

A

It's no longer just http rest apis for microservices that are being deployed to the cloud. There's all sorts of different analytics applications, things that need to be triggered by changes in data. A new order comes into a database. Some new action needs to be taken on that. You've got the internet of things where there's lots and lots of new devices being attached to the networks and those are emitting lots of data and there's traditional batch jobs. There's still analytics jobs that are moving more and more to the cloud.

A

So you need to have still that schedule, type of action where it's run, maybe off hours or at night, but you're you're still needing some sort of cloud platform to help. You do that and scale up. As that workload does its processing for maybe the hour and then just goes away the 23 other hours and, of course, mobile applications are growing as well, and these require scalable back ends.

A

We did a customer poc with the video gaming company, ea fire monkeys angel mentioned in the keynote where, when they deploy an application, they know the curve of the adoption and when it's going to tail off 10 days later, they just don't know the magnitude of that it could be. A thousand users could be a million users.

A

So there's these new types of workloads that are being brought to the cloud that need cloud infrastructure and as people are learning, even as they adopt cloud native applications, there's still that gap of what happens when you move it from working on a developer, workstation out to production right. So there's a common um diagram.

A

That's been shown um docker in development, docker and production, where your only concern is the docker run time on your developer laptop, but once you work your way into production, you need to start thinking about when you deploy those containers, how you break down those services, how you make them highly available and how you distribute them. There's a whole nother set of concerns that come with those cloud native applications, so that can increase the cost to deploy applications and, of course, make things a little harder to manage.

A

Of course, solutions like kubernetes are designed to address these problems, but there's always some some question when you're moving to production. How best to do that.

A

The other compelling thing technical trend around serverless architectures is cloud native and microservices.

A

You've probably been told over and over again should be designed in such a way that they meet 12 factors for cloud native applications, and many of these it's it's difficult to address these as the developer that just wants to push code to production. So what a serverless architecture can do is that if you look at those 12 factors, the serverless platform can handle most, if not many, if not most, of the operational related concerns.

A

So the developer is still focused on the code base and its dependencies in many ways, but configuration discovering other services doing the build release process designing on a stateless model, around processes, port, binding, concurrency and life cycle of those applications can now be handled by a serverless fabric.

A

There's still, of course, development parity processing that there's a bit of a life cycle around the code. That's naturally going to be in the domain of the developer.

A

Another reason that serverless becomes compelling is that the the models of traditional cloud computing, where things are always on, may not be the right match for those particular workloads that only run occasionally during the day and may only run in response to certain events. So there's a mismatch between some of the cloud models for particular types of applications that an event-driven programming model can address.

A

And that, and by matching a cost model better to that, where the application is only billed for the specific time that it's running in terms of milliseconds, rather than by the gigabyte hour of memory reserved, you can get a greater linkage between what your code is doing and what you're paying for.

A

So it makes a a closer match and and of course, serverless, isn't a magic bullet for all sorts of applications. There's always going to be a need for platforms of service infrastructure, service and any other type of service, but this may be a better match for those emerging event, driven workloads, okay, so taking all those those technical trends, those capabilities that are emerging.

A

These new types of workloads that are now ready to be run on the cloud and combine that with a compelling cost model, and this is why serverless is becoming so popular and there are so many new options emerging almost daily in terms of hosted services or frameworks to help you make take advantage of them.

A

And so that of course, is something that ibm is very interested in doing as well, so we released an open source project. We announced it about six months ago named openwhisk.

A

And, in a nutshell, it's it provides that platform that lets you take advantage of a serverless architecture by uh hosting code that can execute in response to events.

A

And people who have been playing around with some of the existing uh hosted providers like amazon lambda, um though there you should be familiar with the same type of model, writing code, connecting it to triggers and executing logic and and and so forth. How openwisk is different from that is that it's naturally built as an open source project to be polyglot.

A

So it's got built-in support for not only javascript but java python, the swift programming, language and obviously javascript itself, but it's built in such a way that it can be extensible which I'll get to in a few other slides and, of course, it's open source with an open ecosystem of partners getting involved, and it's also something that you can not only rely on something like bluemix, a hosted provider to run for you.

A

But you can, if you want explore it, if you're a business partner or a another cloud provider to take it and run it in a public environment, or um you know, in some sort of mixed model, where some logic may reside internally inside of a firewall and other services can be bursted out to a provider.

A

Okay and again, there's more and more workloads that are fitting. This event-based model there's a couple of use cases. I've got at the booth that I can show, but mobile back ends right. So building the automatically scaling back ends as games and apps become popular, creating standing up in a devops pipeline where code is checked into a repo github. Can fire off an event that compiles that application and gives you a resulting good or a bad output?

A

And, of course, there's big data analytics and also event driven and finally microservices right, traditional traditional microservice http backed rest microservices.

A

Okay, so let's take a look into how openwist comes together, the primitives that drive its architecture. So there's three letters if you remember anything about openwhisk, it's these three primitives that you're working with as the developer uh data sources.

A

uh The are the sources of your events, those are called triggers and those are matched to actions or functions which run inside of the openwhisk runtime and the declarative mapping that allows you to associate a trigger to one or more actions or an action to one or more triggers is called a rule, and these things all are packaged put into units called packages for reuse, so triggers can be any type of event that can be a web hook from git.

A

You can have device reading coming from an iot device over mqtt or http user input.

A

So if someone is just uh creating data in a social network, any sort of hashtags or things like that can kick off a notification and, as things are tracked or users go through um virtual reality, I don't want to be the guy that says: pokemon go like everybody else, but you take an application like that.

A

Where there's there's triggered events that can also be used and the the developer focus is on the action that what you want to do, based on the data that comes from those events, so you're writing an event handler in response to those those triggers and because openwhisk is polyglot, you can write in four supported languages, and all you need to do in your action is simply implement. Basically, one function, signature here in javascript, it's just a main function and accept a params object and you can work with the data that comes in there.

A

Any return out. You can return, optionally run asynchronously, but you can return data in a sequence to another action down the line as.

A

A

um So, besides those built-in runtimes for java, javascript node and the swift programming language, what's something that's very unique to openwhisk- is that you can also, if none of those support what you want to do. If you want to write actions in go, if you want to write them in php or any other language, you, the open source openwhisk can be extended to provide those runtimes or you can just bring a doc or container to openwhisk.

A

And as long as you implement a similar signature, openwhisk will inject the events into your code and allow you to participate in an action sequence in a polyglot manner. If you need to.

A

And those actions again a very extensible model of being able to chain these together to produce different logic and to further help. You enforce a micro services design where you have lots of little pieces of code, doing independent actions that can be reused that can be relied upon by other actions.

A

And then the rule that ties it all together, so you can map many triggers to one action from different data sources. For example, you might want to have one action reply to something that happened in github and slack or you might have an action like a notification service that can be that can be called from different triggers and they in turn can be called different actions as well.

A

Okay and the package is this construct supported by openwhisk to bundle those triggers those actions and um the rules together? Well, the triggers and actions mostly and the instance of openwhisk that is running in the ibm cloud, the bluemix cloud. It's already got a bunch of pre-built packages specific to things that we have there, such as watson, but the open source version also has packages for couchdb, which is a which can also be run in a hosted cloud and environment. So there's some pre-provided packages there as well.

A

There's third-party packages for connecting to, for example, kafka, grab messages off there. There's the get package provided for web hooks, and then you have the ability, as a developer, to assemble your own package of feeds and actions and publish those to the world for people to use. So they can reuse your code either within your own organization, or provide those open source yourself to develop an ecosystem around this.

A

Okay, so with those concepts in mind, let's see how this this comes together: uh the openwhisk execution model. It starts with an event being driven into the system. Those triggers are have been associated to an action by a rule, so the openwhisk core engine knows that there is a rule that should be fired. uh It pulls these pieces of code from the internal wisc repository and instantiates them to respond to that request and then execute them and return the response and then just go away.

A

And so using this model, you've got the event triggers that come in from cloudant or any of these, the pre-built in packages, but any triggers really can come in and and again fire off. Events within within an openwhisk system.

A

um And you know those those traditional microservices still the web-based rest ones. um You can map uh an api service to the openwhisk system, um so you can use, um for example, tool like api connect within bluemix. You can use a third-party provider like apogee, or you can even write your own sort of proxy that that implements a rest api and you in turn can call whatever uh trigger behind the scenes. So there's several different ways to do that, and those in turn um will invoke.

A

So uh you know your crud web services can then be mapped onto one or more actions. uh However, you've designed them inside of openwhisk itself.

A

Okay, there's a use case that I've been working on in the iot space to really show how openwidths can come together to to implement some business value for an appliance retailer, um so improving their customer service. uh There's a video I produced for it. You can find that at the bitly url in the top left.

A

I call it open fridge um so in this iot uh use case, a smart refrigerator that has a bunch of parts within it, such as a water filler filter, can emit readings about the status of that device and it can emit those through, for example, mqtt to the watson internet of things platform up on the bluemix cloud, and those messages can be tied to open wisc actions to do analytics on them and and produce any series of different decision trees about what to do next.

A

So in this example, if that refrigerator needs a new refrigerator needs a new filter, you can have an action that checks to see that it is within the threshold of needing to be replaced, create an order in the data, create a report about that in the database, and another action can then go ahead and um check to see if the customer is in warranty and automatically ship the part if they are notifying them through a push notification or just an email that that part is on its way, and so how this use case is broken down into into an open whisk environment.

A

Is that there's a package for watson iot? That has those sorry on that side on? Has the the package for the mqtt broker that whenever there are messages that come in, they could be linked through a feed which is the trigger mapping to that action?

A

So, for example, here we have the analyze the reading see if the filter life is less than 20 percent, if so store it in the database for processing the trigger of that being inserted into the database is linked by the changes trigger to a create order function, and so what that will do is look at the appliance, look up its customer and compare the data to see if it's in warranty and if so automatically create the order and ship it and if they're out of warranty, it may still create that database with a different state flag, and this in turn would trigger a notification that says: there's an order here.

A

Please go approve it on your mobile device with touch id or something to link it to a payment system and that same alert customer function. That action can also be mapped to a nightly alarm trigger uh that basically lets. Somebody know that their warranty may be expiring in in two weeks, so it notifies them there and there's also packages for for cloudant and for sendgrid to facilitate that integration. So you can assemble these these applications. These event driven applications.

A

Okay um and so to set up those actions so openwhisk, the open source project provides a cli uh on the hosted bluemix there's also a web ide, um but within with the the developer workflow of creating those actions is that they would um write the javascript function here.

A

It's analyze, service event, dot js named analyze, service event and given a cloudant, a set of cloud and credentials that are injected as parameters to that function, and then I can iterate on that outside of outside of the actual messaging environment, by invoking it directly with some sample code and getting the logs directly sent back to me in a synchronous manner, so that I can test that my logic works and once I'm happy with that, what I then do is use the whisk command line tool to subscribe, a trigger to the type of messages that I'm looking for from an mqtt broker, and I use those- and I link that trigger to my action by creating the rule in the final example there.

A

So those how those are how the perimeters come together.

A

Okay, so let's take a look at that's the developer perspective on openwhisk, so let's just take a quick look at how the the open source project has basically been approached and designed.

A

So again, it's it's designed in such a way that it's, it's really extensible by offering you know a bunch of built-in languages, but also the hooks for creating those. So in the case of the php example, we had a meetup in new york city where one of the developers of openwhisk came in someone asked for you know if it could be extended and he opened two files.

A

He opened um an invoker source code and another another component with an open, open, open whisk uh made two changes and just for the proof of concept, took a docker image that had a php runtime in it, linked that in pulled that into a repository, and he had an open, whisk environment that supported php.

A

So it's it's built to be like that and obviously with docker um any arbitrary binary. um It's it's been designed to already build on the whole community of excellent, open source. That's out there and ends licensed under apache too so you'll see in the light blue.

A

Most of those are already existing best of breed components, building blocks for cloud native applications, so in this case a user requesting, for example, the developer, pushing code through the openwhisk api through those command lines, they can interact with it all at an end point uh the triggers that come in.

A

They also affect that rest api that that um that the openness runtime provides a controller will check any sort of credentials needed so in a multi-tenant hosted system ensure that whoever is requesting that action, whatever triggers calling it has the rights to do so, and the controller will then look at its registry of actions available. The mappings and put them on a kafka queue and within those boxes below are a whole bunch of docker hosts that will take that code inject it into a container, execute it and return the results.

A

So it's been designed for for high performance. I don't have the latest numbers, but it's a very efficient system, uh very good at concurrency and responding in pretty good millisecond values and um again the it's being built on docker there on those on those docker hosts. um There can already be a pool of running containers uh that can be reused by the same tenant if actions come in fast enough um or otherwise help improve the improv. The performance of the system.

A

Okay, so um we are, in the early days of serverless, there's still lots to be learned: there's a ton of best practices to kind of figure out to figure out how best to empower developers to create these new types of vendor and applications. But the promise is certainly there of the new cost model. The efficient cost model, as well as all of these brand new applications coming online.

A

So um with serverless, it really holds that promise of helping developers build things faster, better and cheaper and we're hoping that openwhisk develops a large ecosystem around it to support those workloads for these emerging workloads for these these event-driven applications. So we invite you to get involved.

A

If you go to openwist.org that'll, take you directly to the github repository there's an openwhisk organization, there's an open list project and several different repositories, for example, for the collection of third-party packages.

A

We've got slack on the developerworks open. We've got a channel openwhisk we've seen participation from lots of interested other companies.

A

It's been great to see those grow daily and if you just want to get started with playing from a developer point of view, instead of worrying about the open source underlying fabric itself, if you go to bluemix.net you log in just look for openwhisk, it's probably going to be on the masthead and that'll show you how you can start experimenting with some sample code, working with the web, ide and and also looking at the monitoring so open source wisc gives you the log stream that you look on the cli, but within the bluemix environment you can actually see the correlation of actions, uh the messages that have been admitted and things like that.

A

Okay. um So if you're interested I've got I'll, be at the booth, the rest of the day so stop by and please do get involved with the.

A