Developing Microservices and APIs on Bluemix Acme Freight. IBM Code Tech Talk JULY 12,

Transcription

1 Developing Microservices and APIs on Bluemix Acme Freight IBM Code Tech Talk JULY 12, >> Good morning, good afternoon, wherever you may be. We want to welcome you to our series of tech talks. The series is taking a new direction with our IBM code tech talks, IBM journeys tech talk. This is a, IBM is about developer, IBM has taken seriously role of developers. The developers are the new king makers. Indeed you are, so IBM has been focusing lately on developers, have been creating a number of assets, number of resources for developers. One of them is our website, IBM code, which is a site that is presently written for developers, allowing you to solve problems quickly, providing you some code and things that will allow to respond quickly and the journeys are all about that. Today we have a great journey that we want to show you. It is about creating, using APIs to develop microservices, using BlueMix, and we call it the Acme Freight journey. We have on the presentation, we have Joe Sepi and Sai Vennam who created that journey. They will take you through that journey. It is our very first journey tech talk. And looking forward to hearing what they tell us. Without any further ado I turn it over to them. Joe and Sai you have the mic and camera. >> Great. Thank you. Hi, everyone. Thanks for joining us today on this webinar, talking about Acme Freight. My name is Joe Sepi, and I'm a developer advocate for the New York City team with IBM. Joining me today is Sai Vennam, Developer evangelist for the API connect team. Today we are going to walk through Acme Freight, a best practice sample application with a technology stack based entirely within BlueMix. The application is built around microservices and APIs. So we will explore what that means and why this approach is useful. Of course we will dive into the technologies that power the Acme freight application, including LoopBack, the open source Node.js API framework that was created by StrongLoop which is now part of IBM, as well as OpenWhisk which we will dive into, serverless framework API connect, cycle management tool and BlueMix. We will hit a couple other technologies along the way, but let's get this started since we only have an hour. Let me share with you where you can find the journey and how

2 it's broken up. As you can see the URL there, developer.ibm.com/code. This is one of the journeys that we have available. The Acme Freight application kind of overarches a couple of journeys. So this one here is the one unlocking enterprise APIs and the other one is for making apps smarter with serverless. With the sophisticated application like Acme Freight, important architectural decisions, the important architectural decision was to break it into these kind of different microservices, and the glue that pulls it all together is BlueMix. I'm going to turn it over to Sai to talk about microservices and BlueMix. >> SAI VENNAM: Hi, everyone. Thanks for the introduction, Joe. I'm Sai, developer advocate for the API connect team. I want to go ahead and get started by introducing microservices, the concept of microservices as well as BlueMix, why they are such a perfect fit. I'm sure you know what BlueMix is. A great many of you know what microservices are. To put it simply, it's an approach to app development where a larger app is made up of smaller services. This isn't something brand-new that is completely new to the landscape. Microservices is actually a subset of service-oriented architecture. I'm sure many of you may be familiar with this architecture. It is more of the legacy thing and IBM generally used to do this quite a bit. The big difference between microservices and service oriented architectures, service-oriented architecture generally in the past was monolithic applications, very large apps, they were still services that made up this monolithic app and they talked to each other through componentized structure. The difference was there was a lot of difficulties when you have such a monolithic application. For example, you might imagine one of the pieces of your application was responsible for serving the website, the static files. You know that your website is going to get a lot more traffic as an example. It would be very difficult to scale only the front end of your application, while keeping the other end. Basically, it would be nonsufficient and be much more expensive to actually scale up traditional service-oriented architecture applications. Microservices fixes those problems by having each one of the services that make up the broader application be individual and separate applications. I also want to quickly reference the 12 factor app. I don't want to go over all of the twelve factors right now. But whether you are a developer, manager or you just want to learn what a modern application should look like once

3 it's architected, I would definitely recommend checking out 12 factor.net. The twelve factor app approach goes over twelve factors of creating a modern application. To highlight one of them, processes, the processes twelve factor basically says your application should be made up of one or more stateless process. This is very important for microservices. Being able to rapidly upgrade certain piece of your application or having fault tolerance, if one of your applications were to crash to come back without having corrupted data, these are the kinds of considerations that you need to keep in mind when developing microservices. By having completely stateless processes, you can start achieving that. The reason why microservices and BlueMix is a great fit, one of the biggest things with microservices is you get to pick the right tool for the job. You wouldn't use a drill to push in a thumbtack. Just like that you wouldn't use something like a traditional WebSphere application deployment for a simple crud API application. Due to this with BlueMix we have chosen the right language and the right tools for the right applications. When we created Acme Freight we kept this in mind. As a polyglot platform BlueMix supports Node.js, Python and Java. In addition it supports multiple compute options. Traditional applications can be deployed on Cloud Foundry, Docker application or Docker container you can deploy as well. Finally the newest available feature on BlueMix is serverless actions via open Web. Basically OpenWhisk, being able to trigger code, trigger actions as a response to some sort of event. Acme Freight, I think as a best practice industry application, we wanted to use the best possible technology for each piece of the application. Now I want to pass it on to Joe who is going to quickly go over why APIs are important and specifically in the landscape with BlueMix and microservices. >> JOE SEPI: Thanks, Sai. Why are APIs important, specifically for microservices? There are a few reasons, many really. But I'll go over the three that we have here. One, there is a clear contract negotiated between the service itself and the consumers who will make use of it. This removes any ambiguity and complexity between the components allowing them each to focus on their area of concern, and providing a interface for them to interact. Of course this isn't one-to-one relationship, it can be many to many relationship. This clear contract allows these components to keep their complexity behind their interface, and as long as that contract isn't affected, work can take place behind the scenes without any consumers

4 needing to be aware of such changes to the underlying applications, this allows teams to be Agile in their development lifecycle. We can make use of third party APIs to enhance and enrich our applications, perhaps getting geo data or social connections or what have you. You may want to make your services available to the public as well. So as long as there is a well defined contract that remains consistent and reliable, changes can be made behind the facade of the API, without the consumers of your API ever knowing or ever needing to know that that work is going on. I want to share a couple of real world examples from my experience. When I was with New York Times we were replatforming the NYtimes.com website and were lucky to have a microservices style architecture in place. I say website but NYtimes.com is a conglomeration of many different applications coming together to deliver the content. Because of the separations we were able to, one replatform in stages and only replatform the pieces that were need of replatforming. Two, we were able to work in silo'd applications without disturbing the other components. Then another example I have is working at adobe on a green field application where we were able to start fresh from the outset, we had all the different areas of concerns separated and even though we were a small team, we were able to iterate on the different aspects of development independently of the rest of the work happening. As we continued on and brought on more team members, the work continued with speed and agility, knowing that the lines between the application components were clear and distinct. Back to you, Sai. >> SAI VENNAM: Okay. I want to introduce the industry that we are targeting with Acme Freight. The journeys that we are going to be going through, the content that we released and the demos that we are going to be doing today are all centered around the application Acme Freight. With it, we targeted the supply chain management industry. We did so because we didn't want to make a toy application. We wanted something to be like a real life scenario, when people came and checked out our code, we didn't want them to think this is just like a POC. We wanted to address a real problem. We chose the supply chain management industry. We are hoping that the technology that we showcase with Acme Freight could potentially one day disrupt the entire industry. To introduce some of the difficulties with traditional supply chain management software, it's complex. Even with a modern ERP system, standing for Enterprise Resource Planning, there is still a lot of complexity for designing an application for supply chain.

5 Lots of choke points and bottlenecks. There is variables that every single step of the way, truck drivers that are taking shipment, shipments that are delayed, inclement weather events. These are variables that you can't rely on, on a human control to address. Having a computer automatically or at least helping the end user figure out things would be ideal. A lot of those smart tech that is out there, lots of cognitive capabilities or cool IoT devices haven't made it into the space yet. We want to fix that. Let's imagine you are a retail company and you have got a supply chain management software. A massive storm hits. Thousands of people who put in their orders are not getting them in time. This leads to unhappy customers and losses for your company potentially. When we were developing the application we thought to ourselves, how can we plan for situations like this? Can we train our systems to prevent this happening in the future? That is exactly the kind of mind-set we had when we started developing Acme Freight. I'll pass it back to Joe who is going to quickly demo Acme Freight. >> JOE SEPI: Great, thanks, Sai. Acme Freight uses cognitive and Cloud to roll out a innovative solution to their traditionally complicated problem. I'll demo the application. But let me first intro the company and the app itself. Acme Freight is a logistics vendor who is responsible for the shipment of critical and time sensitive medicines. Their app can manage distribution centers, retail locations, trucks and partners as well as share realtime information about shipments to their customers. It ingests weather data from the weather channel API on IBM Cloud to detect disruptive weather events along planned delivery routes. The app uses cognitive APIs to suggest optimizations to Acme Freight's resource planning and routing. Let's check this out. I'm a logistics coordinator working with Acme Freight. I log into my dashboard. This is what I see here. You can see the retail locations which are the green map markers, I click on one. We can view some important information about that location, including shipments and weather forecasts and such. The distribution centers, the orangish stars, which show their outgoing shipments, and then the trucks which are the purple trucks there, obviously, they give a lot of valuable information there, including since this one in particular is IoT enabled, it can provide realtime data about the shipments. Okay. Let's simulate a storm and see the application respond. This is where things really come together. You can

6 see the circle there where the storm is affecting the area. These are the recommendations that the application has given back to us. I'll dive deeper into how this comes together. But I wanted to show you the application in action. We have a mobile app and that can onboard drivers, to help us reroute shipments and such. But for right now we are going to stay focused on what we see here. I'll turn it back over to Sai to talk about the key aspects of the architecture. >> SAI VENNAM: Thank you, Joe. I want to quickly highlight some pieces of the architecture. This is definitely simplified down for this talk. We want to really highlight the things that we are going to be talking about today. Starting at the right side, the end user, this is whoever is accessing the application, probably a logistics coordinator in the case of Acme Freight. The first thing they see when they hit the application is a Web Page served by the UI application. This is a status files application built using react frameworks. It is again all static files meaning HTML, JavaScript, CSS, no back end really. This is a pure front end application that is being accessed. It does use Node.js locally to help out with development. But once deployed it's purely static files. It is stacked by a Python controller. This is a microservices pattern called BSSA or back end, sorry, BSF, which is back end for front end. What that means is it's controller serves all the back end requests that the front end might need to make. As an example, when we first logged into the Acme Freight application, it shows a list of all the retail locations, shipment centers and everything like that. Obviously that isn't static files. It needs to be retrieved from somewhere. The front end application has to make the request to the controller, which figures out where to get that back end data from. It takes it and massages it in a way that the Web UI can present it. The Web UI outputs that to pointers on the map. The Python application, it talks to a API gateway you notice. This is new. In a previous architecture this API gateway was not here. The controller was directly speaking with the back end microservice. We found out that this wasn't a good way to do things. Any time that we updated one of the back end microservices we would have to go into the controller and redeploy it. It led to a lot of problems for us. In addition we have to manage multiple authentication tokens, one for the database, one for the OpenWhisk action. It wasn't cutting it. We inserted this API gateway layer. I'll stress about why this is important later. But for now to summarize, the API

7 gateway abstracts away all the back end logic into simple Web end points. All behind a single API key. It provides excellent documentation. As a controller developer, you can go to the developer portal and see all the endpoints that are available, subscribe to them and start getting them right away. I don't need to know anything about where the back end microservices are hosted. >> Quick question. Before the API gateway, was the controller exposing APIs through REST also, or was it something, some other protocol? >> SAI VENNAM: Even before using the API gateway, all communication between applications were still APIs. By introducing the API gateway layer, we added things like a single location for security, single key for security rather and single location for accessing API endpoints, a developer portal, additional advantages, data ops protection, date limiting, that kind of thing, but yeah. Hope that answers your question. >> Yeah. Thank you. >> SAI VENNAM: Moving on, we had just covered the API gateway. The API gateway actually needs to know how to access those back end microservices. This is all done in self-serve graphical interface, and we will demo that later today. But before I get too much into that, I want to introduce the two back end services that we have. We have ERP on the top, Enterprise Resource Planning, that is a LoopBack application. I know I haven't introduced LoopBack yet, but that will be the first demo today. You need to know this application exposes data source data as APIs. Basically imagine crud operations that you would do against the database create, read, update, deletion of entries. It exposes them as API endpoints. That is the ERP side. A quick side note, it actually can directly integrate with secure gateway to expose LoopBack data or database data from a OnPrem system. For the sake of the demo it's a post [inaudible] on the bottom side we have OpenWhisk. We will demo that today. The OpenWhisk side handles the intelligence recommendations, when we simulated the storm OpenWhisk gets kicked off, it says there is a storm, let me see if any of the shipments are going to be delayed. It finds out and then it suggests alternative shipments that would make it in time. All of this would have required slow human processing power. Instead it's done by lightning fast OpenWhisk algorithms that we have developed. Without further ado, after going over this architecture, I want to jump into code, some demos and show you guys how the technology works. To introduce, I'll start with the ERP application. The ERP

8 app is based on LoopBack which is a lightweight Node.js framework. It is completely open source. LoopBack is part of StrongLoop, a company that IBM acquired about a year and a half ago. Since then, we have been integrating it with API management solutions. We have created this new thing called API connect. LoopBack addresses one core part of the API connect platform, which is the creation of APIs. It allows you to quickly build out Node.js applications which you can connect to back end data sources, and then expose access to that data source as simple APIs. Enough talk about that. I'm going to actually jump into LoopBack and show you guys how easy it is to get started. The first thing you need to start working with LoopBack, I'm sharing my terminal here, let me make it a little bigger, okay, the first thing you need to work with LoopBack is Node.js. With every Node.js installation also comes MPM. MPM is the packaged manager for the Node.js programming language. With those installed and now we want to get LoopBack, if we went to the LoopBack website, it will probably tell me to do MPM install, use the package manager to install globally the LoopBack CLI. Personally I like CLI, it's great, but personally I like using GUI. API connect has a development toolkit which has LoopBack incorporated within it. Instead of installing the LoopBack CLI, I'm going to instead install API connect. API connect is a IBM offering that covers all the time management landscape but today we will focus on the create aspect of it. For that it's completely free. You don't need to worry about creating anything but a BlueMix account. I would run this command now but it takes five to ten minutes. I already have it installed. To prove it, I'll run API C-V and it should come back in a couple seconds, it tells me I'm running on 5071 which I believe is the latest version right now. Let's get started with creating a first LoopBack application. I'll create a directory called tech talk LoopBack. I'll change directories into it. I'll run the API C LoopBack command. What this is doing, it is going to scaffold out a basic LoopBack application for me. It has questions though. What do you want to call it? Call it tech talk LoopBack. I want to use the latest version of LoopBack. It gives me a few basic applications I can start with. But for the sake of this I'm going to start with a empty server. It created JavaScript files and JSON files. Now it's running MPM install. If you are familiar with node, you know that what this is doing is fetching all the dependencies that my Node.js app needs to actually run. This keeps my code small and my dependencies although large are not part of the actual build process; sorry, the deploy process. It looks like it installed dependencies. It tells me next

9 steps, change directory to your app. I've done that. You can create a model or you can compose it with API connect. I think I'll do that. I'll run the API edit command. It should launch a new window with local token. There we go. I'm going to give this a second. What we see here is a locally running Node.js application which allows me to develop a LoopBack application. Yes, I'm using Node.js app to create a Node.js app. (chuckles). Once you get over that, let's look at this UI. The first two tabs are products and APIs. That covers more of the API management side of things. Let's jump to models and data sources which is more of the create side. First thing I want to do, I want my LoopBack app to connect to a database. I'll say create a new LoopBack data source. We can see it's a number of connectors, I can connect to MongoDB, all these different options. For now I'm going to stick with in memory DB. Save that. I want to jump to models. Models is a LoopBack concept. Essentially it allows you to find the type of object that you want to store in the database. Jumping into the models tab, I want to start creating new types of objects I want to store. Let's keep this one simple. I won't make it complicated. Say I want to create a new LoopBack model called car. I hit new. Give it a second. We have a name car and it's connected to the database that I created. Down here is a list of properties. Let's start creating them. One of my properties, let's make it a mate and a string, make, model, string, one more for year, and that is the number. That is all I need to do. So far, this is a simple model. I don't want to make it too complicated. I'm going to go ahead and hit save. Believe it or not that is actually all I need to do for creating my LoopBack application. Let's see what got created for us. I'm going to go ahead and hit the run button down here which is going to start up my Node.js application, the LoopBack app locally. In a few seconds, it should say running. We will give it five or ten seconds. It started up the application. It says running. Great. It's running my application. Let's see what APIs are available for me to work with now. I'm going to hit the explore tab. This presents me documentation of all the APIs that just got generated for working with that database I specified and the model I created, car. We can see things like create a new instance of a car or find instances of cars. Let's start with find, to demonstrate. Within this UI I can execute a call, get on all the cars I stored in the database. You should expect to see nothing here

10 because I haven't stored anything yet. But yeah, we see a empty array. Scrolling back up, let's create a new car. Jumping down here, to car.create, this one is going to do a post request to the running LoopBack application I have locally. Scrolling down I'm going to hit generate. Say Lexus RC I don't need a password and ID, it will automatically generate it for me. I call operations. It looks like it stored that. Let's quickly make another one. Make a Toyota Camry Another 200 okay, it says it stored it. Let's go back to the car.find function that we called earlier and it came back with a empty array. Calling it one more time we should now see the two cars we stored in the database. There we go. Basically what we just demonstrated is that we can take a database and then very quickly demonstrate or generate crud APIs for working with that database. No longer do we need to work with SDK or anything. Imagine working with MongoDB we now have working API end points or connecting up to that DB and making, storing elements. To prove that really is a running app, I'm going to hit the application URL. There we go. We get that JSON of the two cars that I've stored in that database. Let's take a look at a more complicated LoopBack application. Let's look at the one that we use in Acme Freight. Going to the ERP app that we have for Acme Freight, cloned all the code, we can see it looks similar. It is still Node.js application, running API C edit on this one. We are going to see a more complex LoopBack app. Give it a second here. We will go to the models. Instead of a single car, that is all of these that Acme Freight application needs, looking at a shipment, we can see that there are a number of different properties that a shipment needs, things like shipments humidity, temperature, where is it coming from, where is it going to, when is it going to get there. All of these are important aspects of LoopBack application for Acme Freight. Obviously this is still running locally. But let's look at the one that is running in the Cloud. Here we see the Acme Freight ERP application running on BlueMix.net. We have a Swagger for it here, we can see all the different endpoints. I'm going to log into the set of endpoints using the user access control. I copied that JUIC. I'm rushing through but all I'm doing is logging in, so that I'm able to access my end points. I get a token. I accept the token up here. Now I'm able to actually access the shipments and so let's call this get shipments method. You can imagine that the Acme Freight front end application would call the same API to get the list of

11 shipments that are available. Try it out and there we go. We see all the shipments that are in the Acme Freight application. To show you what it looks like in the actual running Acme Freight demo, that Joe demonstrated earlier, we can see all the shipments that are available. You can see them in AS format which is basically the UI documentation. To summarize, we went over the LoopBack piece of the architecture, jumping back to aspects I'm going to show you guys, went over the LoopBack piece of the application which is responsible for pulling out all the things about shipments, retail locations, that kind of thing. We want to get through the number of different technologies that make up Acme Freight today. This is one of them. Now I want to pass it on to Joe who is going to cover the OpenWhisk side of things and how that is being used in Acme Freight. >> JOE SEPI: Great. Thanks, Sai. I'm sharing now. Hopefully you can see my screen. Thanks for the LoopBack demo. I'm a huge fan of LoopBack. I hope everyone was able to follow a long with that quick demo and see how awesome it is. I'm going to talk about OpenWhisk now, a events driven model for building apps that scale on demand. It's flexible and easily scalable. It's a polyglot application development, open sourced under the Apache Foundation, IBM created it along with Adobe and open source, it's deployable to any open stack environment. It is not just on BlueMix, you can run this anywhere you can run a open stack environment and in containers and such. Let's get into some of the details here. This slide I find very illustrative of how serverless works. I should caveat that term as well. Obviously, there are servers still involved, but you are only paying for the time that a server is running. So you have these small snippets of code that when a event happens, an instance is brought up, your code is run and that instance is immediately destroyed. You only end up paying for that small amount of time that your code is executed and that is where this surplus term comes from that you are not sitting there, you don't have a server sitting there waiting to execute the code. We will look at that in a little more detail in a minute. On the slide, you can see, on the top left, things start with packages and feeds. These packages provide integration with external event sources such as weather API which is what we use in Acme Freight, or there are great tutorials on connecting serverless... (audio breaking up). And of course Watson has great packages as well. Triggers associated with those feeds, fire when a event occurs, and

12 developers can map their actions or their functions, their small chunks of code to triggers using rules. Anyone can create a new package for others to use and developers can write their actions in any language. As you can see on the slide there, there is first class support for Python, Java, Swift, Node.js and JavaScripts and you know, other languages can be run within a Docker image. Of course, the open source runtime can be extended to support new first class languages as well. I wanted to bop through some screens here. I was going to do a live demo but I figure this would be the easiest way to get us through it quickly. This is OpenWhisk on the BlueMix platform. If you go to the OpenWhisk page this is what you will see. You will see that you can either start developing in the command line or you can start creating actions within the GUI which is what we are going to walk through right now. If you click start creating now, you are given these two actions that you can start to play with. I'm going to get into the hello world with params action here. This is the interface for interacting with it. I want to zoom in on the code here. As you can see, this is simple JavaScript, and this is typical for an action where you will pass in params and basically return from it. If I run this action. (audio breaking up). I'm given the option to customize my params, my inputs. If I run with this value, here I see the screen, resulting screen... (audio breaking up). What was invoked, the time, but I think the important thing here, and I know this is a small snippet of code, but you will see that it was completed in 657 milliseconds. We build for a hundred milliseconds. (audio breaking up). You are charged for, so but the important part is that you are not charged for the time spent bringing up the instance and tearing it down. You are only billed for the time your code is actually running. (audio breaking up). I grabbed the screen shot from another presentation that I have, to show you some of the rich monitoring that you can do with the BlueMix UI here. The other thing I want to, on the bottom right, the REST end point is live, just by using it in BlueMix. If we click into that, we can see some of the options that we can use to invoke [inaudible] (audio breaking up). Illustrates how you can get started here. If I use the curl example, and I deliberately cut off some of that, so nobody gets my tokens and such, but you can see the response...

13 (audio breaking up). What was sent in, and the time and success and all that stuff. I wanted to quickly highlight the important part of the actions within Acme Freight. This is, if you go through the GitHub this is the recommend action. This is what pulls all of the other, there are six or seven actions in there, and this file pulls them all together in this async Waterfall promise. As you can see here by comments at the top of each block, we clean up first. We get the list of retailers. We identify retailers that are affected by the weather events, and we retrieve their stock and their shipments and we recommend what we think would be a better route. Then we persist that recommendation. A lot of underlying logic is abstracted out into the other actions that are included in the repository. But I wanted to show you how that all comes together. Why do we use serverless for Acme Freight? The model of reacting to a weather event is perfect for serverless, in that it's a event driven model. Based on that without events OpenWhisk actions are kicked off, if this, then that, sort of model, where when the action, when the trigger happens, the actions are run and then we end up creating this recommendation, and then like I was saying before, when there are no storms happening, no costs are incurred. So when a heavy storm season happens, we are able to easily scale up in terms of cost and execution. It's really a great model for responding to weather events with an Acme Freight application. With that, I wanted to touch on API management, and why we would need it in our larger API Acme Freight application. I think that the list can actually be quite long, and I don't want to get into each bullet point here. But you can manage security, orchestration and routing, you can have a single interface or entry point. I know someone mentioned that is also, can be a single point of failure. But as long as you architect it with high availability and scaling, then that shouldn't be an issue. You get great analytics and logging, authentication, especially if you are going to open up your services to third party developers, be able to authenticate and weight limit and do all that enforcement is important. Also doing blue green deployments, canary releases, circuits breakers for error thresholds, things like that. API management is the smart way to implement a robust application. With that, I believe I turn it back over to Sai for BlueMix API management demo. >> SAI VENNAM: Okay. Definitely API gateway, such a core

14 part of our architecture, really clean things up. (audio breaking up). [inaudible] you may remember [inaudible] a little drawn out. (audio breaking up). Deploy the BlueMix, number of steps, you get the portal going and get the API key. I want to stress that this has been very very streamlined for BlueMix applications and APIs, particularly for OpenWhisk actions as well. When Joe was demonstrating the how easy it was to create a OpenWhisk action, we notice that when you create a new action, and you have the code there, an API is automatically very instantly created for you, for actually triggering that OpenWhisk action. So you have that single API, OpenWhisk provides a API key for accessing it. But that is not quite good enough for us. What if multiple people wanted to use our OpenWhisk actions, we wouldn't be able to separate API keys with specific users. What if we had a malicious user that keyed off our API. We would end up with massive charge on our account. Those are just two of the reasons of why we want to set up API management for our OpenWhisk actions. Without further ado, what I've got here is the OpenWhisk UI, within this we have got all the endpoints that OpenWhisk needs to actually, or rather Acme Freight needs to do the recommendation. What I'm going to do is switch over to the -- I'm already here, on the APIs tab, where I can take an existing OpenWhisk action and click a API gateway in front of it. First things first, it says create a OpenWhisk API. I'll hit that button. (typing). Here we go. It says create a API for OpenWhisk. API name, I'll say Acme demo API M, time management. We will put the base path, slash API. Now we can start creating operations. (typing). It says, which package contains the action [inaudible] there are five different actions. For Acme Freight now we are using only the recommend action. Sorry, actually it's a retrieve action. All I need to do is set up a path, set up the verb which is a post and set up a retrieve action. And hit save, and actually I'll set up one more for recommend. I can't remember whether application uses recommend or retrieve. I'll set up a API M for both. We have created the two operations that we want APIM to manage. Slash retrieve end point is going to trigger the retrieve action, same thing for recommend. Scrolling down here, yes, I want authentication, API [inaudible] I'll stick with API key only. Scrolling down, I

15 don't want to enable rate limiting yet but it's a flick of a switch. User authentication, I'm okay with API key, I don't need Google auth. Finally browser applications can call it, which is what we want, we want the Acme Freight browser to be able to call it. Go ahead and hit save. This experience is more streamlined than if you had used API connect before, I was able to set up API management for my OpenWhisk action. Scrolling down, we can see analytics, API indications that have happened, and even the security that has been enabled. When I hit the sharing tab and generate a new API key, I'll call it controller key because my controller application is what is going to be using this end point. Just like that I was able to create an API key. It even gives us an API portal link. Let me copy this key, open up the portal, and here we go. We see it's open API specification base explorer, very similar to what I showed you before in the LoopBack demo. We are going to go ahead and run a couple of these commands. Just to make sure that everything is wired up correctly, I know I'm supposed to put something in the body but I don't have all that information off the top of my head. I'm going to hit call operations, comes back empty, as expected. The other one, post recommend, I want to try this one as well, put in my API key. Supposed to be something in here, I'm going to call operations, and I [inaudible] it is expecting me to put something in the body but that is fine for now. Okay, we have ran through, set up the API for OpenWhisk actions, completely secured, other than the fact that 1,000 viewers can see my API key (chuckles). We have got the API key and we have also the URL that we need to configure in our controller application. The next step is going to be, we set up API in front of the application, meaning the previously working endpoints are now going to be broken. If I went to my Acme Freight application, and I hit simulate storm, it's going to hang and hang, or other, it should have -- let me try one more time. Log in back end, one second. Simulate storm. Well, maybe it hasn't secured those end points yet. That is okay. Regardless, we need to configure our controller application to use the new portal URL and API key. Actually I think it did break, I was expecting it to break. We see that the UI is unloading properly so that is good. Essentially we protected our previously unprotected OpenWhisk endpoints, and so now the application isn't working. What we need to do is basically configure our controller application, the one within Acme Freight, to use this new APIM browser. To do so, I'm going to switch context. This is my

16 build pipeline. I want to quickly talk through this in a second. I want to kick off this deploy state so it's running while I talk. Let me jump in to the configuration for the deploy. I'm going to add a couple of additional properties that my application is expecting to read, open API key. Yep. I should have made that a secure property. Let me try that one more time, secure property. OpenWhisk API key, then one more text property, OpenWhisk API URL, let me grab that real quick, this guy right here. Quickly ensure that I have the right key. Okay. I'm going to hit save. What I just did there was set up a couple of environment properties for my application to deploy. Once I hit save, I'm going to kick it off and quickly go over the new UI that I haven't talked about yet. That is kicked off. Taking a step back, while that is running, I want to quickly go over this UI that we have got here. This is a pipeline that is set up all through BlueMix and basically allows us to manage the deployments of Acme Freight. The way it works, we have a couple of code -- let me post that, there is four microservices, four different GitHub repos and each has a delivery pipeline. Controller code base has controller pipeline. Each of the microservices are deployed separately. It's easy to get this Toolchain set up for yourself. Go to the Acme Freight repository. Scrolling down to the GitHub read me, one click button deploy, if you click the create Toolchain button it will not only deploy all of Acme Freight in your own BlueMix organization, but it will set up this entire delivery pipeline. The power of this pipeline is cool, whenever I make a commit to any of the git repos it will figure out which has a commit and send off a event, the pipeline will get triggered and newly deployed application with my new changes. A couple notifications, that is telling me my controller pipeline has successfully completed. Essentially that means my controller app is now, instead of talking directly to the OpenWhisk action it's actually going through an API gateway, so it gets all the benefits like it has things like rate limiting, secured API keys, all those things in the list that Joe had mentioned. Actually it is not quite done with the build yet. The cool thing about the pipeline, I can hone in on any specific application, jump into the deploy process, and see exactly where it is within the status. It's running a little slow right now. Might be because I'm uploading my screen. This is 99 percent completed. Scrolling down, looks like it's just waiting for the application to get started. Give it a

17 few more minutes. It says the application has started. And done, all right. I'll jump back to the Acme Freight application, I'm going to log out. At this point everything should work smoothly. I'm going to hit log in. We see the UI, that is how we had gone through earlier, the shipments, distribution centers, retail locations, simulate storm. Give it a minute here. Of course, the second I hit log out it had finished. Try one more time. I'm getting a little impatient. I feel like five seconds feels like eternity. There we go. This time it was instant. We see the storm, we see the recommendations. Everything seems to be working well. To prove that our API indications are going through OpenWhisk, and management layer we set up, let's jump back to the view, scrolling down, this has a update. I'm going to refresh my OpenWhisk API's view, jump into here. We should see analytics from those recent indications from that application. Yeah, at 10:55 which is right now, we made two indications, basically when we hit simulate storm, we get analytics. It tells us there was a post at exactly this time, it took 278 milliseconds, so you can imagine in a more robust production application someone can monitor this and say someone had a request time of three seconds, they are probably not happy, we can dig into it and figure out not only who is actually accessing the app but also get some really introspective data and debug why it was taking so long. To overview, I'm getting towards the end of my time, we took the OpenWhisk actions responsible for -- let me pull up -- we took OpenWhisk actions that were responsible for generating recommendations. We put a API gateway in front of it. We went into our delivery and deployment pipeline and configured the controller to use the brand-new API gateway URL and API key, so that this became possible. Now at this point no one can access our back end OpenWhisk end point. Those are completely secured. Nobody knows about them. If they want to access them they have to go to the gateway, they have to come to me and say, I want to use those OpenWhisk gateways, do you mind creating a API key for me? I jump into the UI, create a API key for them and send it over. I give them a portal link. They can figure out all the APIs that are available and start working with them right away. Okay. I think definitely towards the end of our time here. I'm going to pass it back to Joe. >> JOE SEPI: Great. Yeah, to summarize here, we have gone over a couple aspects of the Acme Freight application. One of the key take-aways from this architecture and this webinar is to choose the right tool for the job. In our instance, as Sai was going over here, we use Node.js and LoopBack to expose our

18 enterprise resources behind an API connect gateway. We chose OpenWhisk for our cognitive serverless recommendations engine. BlueMix brings us all together for us very nicely a single platform to develop microservice-based applications. With that, we will kind of wrap things up. I hope you check out the journeys. They have been posting links in the chat. Check out the Acme Freight application. You can run it yourself as Sai showed with the one click Toolchain button, which is awesome and powerful. I suggest you click on that button and see it in action. We have great tutorials out there around all of this. Sai's Twitter and as well as mine are up on the screen. Feel free to reach out to both of us. Thank you very much. We appreciate it. >> SAI VENNAM: Thanks, everyone. I know that there are a lot of questions. I have a couple minutes. I'm going to try to answer as many as I can. Looking through the Q&A list at the top, I see, the UI is static file, it could have been deployed as any runtime like liberty or JS. Actually for static files you want to use the static file build text which is a engine X based build pack so you don't need a runtime, the advantage of that is it allows you to have a lightweight application. Next up we have got when will the controller be a bottleneck, is there a way to fail it with load. The great time about the applications is you can set them up with auto scaling. The controller, a hundred percent right, would be a bottleneck, but the great thing is you can set up auto scaling with BlueMix. When the memory is getting too high, it will automatically scale [inaudible] the way we have it set up as a gateway, it wouldn't cause any problems. >> Thank you very much, Joe, thank you, Sai, for that great presentation. It captures the imagination of the participants, it did mine. We want to continue those great tech talks. The next one is going to be on July 26, at the same time, and we are going to string two journeys about IoT, one about TJ Bot and the other about correlating slides and augmented reality. Those are going to be great presentations again, like today. Some people who are familiar with those presentations now you can see that we are going to the next level, because Joe and Sai talk about LoopBack and about serverless OpenWhisk. Those were individual tech talks that we had. We are putting them together in this new initiative that we are really going to show things working the way they should. I encourage you to join us and those series. We are going to have some open source tech talks but we are going to be focusing more on journey tech talks. The next ones are going to be the one on July 26. Thank you for your time and look forward to seeing you

19 next time. Thank you, Joe, thank you, Sai. Until the next time. Good-bye. (end of meeting at 11:01 a.m. CST)