 Hi, thanks for joining us. Continuing part two of our microservices talk. And in this session, we'll be talking about deploying infrastructure foundations. My name is Sean Murakami. I'm with IBM Cloud, and this is Andy Bodang. So we're going to talk about what infrastructure foundations means in relation to the 12 Factor Act. But first, I want to talk about applications in general and when we're developing these microservices and applications, most applications today utilize one or more network resources and services. They tend to consume platform services to help enrich and enhance the capabilities of the application. But there are two types of services from a platform perspective. First, we can think of these as dependent services. So these are the services that help maintain the persistence and data of your application, things like databases, identity, and object storage. And the other set of services are the services that help support the integrity of the application, the things that help operators and developers understand what's going on. These include monitoring, metering, and logging services. So I'm going to talk a little bit about the 12 Factor application methodology. And the infrastructure foundations are composed of three of these. And these are highlighted here. First, we have the backing services, logs, and administration process. And I'll go over a brief overview of all of these. And finally, we'll show this in practice with the BluePick app that Manuel also had mentioned. First, we start off the admin process and management. While we develop these microservices, we want to ensure that the developers have the capabilities to quickly provision and utilize resources. We don't want the platform to stand in the way of accelerating their development process. So these should be consumed via APIs in a self-service manner that can provide these resources in an on-demand way. So these APIs should allow the developers and consumers that are trying to do these developments of these micros services to help tune and tweak and enhance or decrease the resources from compute resources, like memory and CPU, to network and storage. In addition, monitoring and metering play a very important part in a microservices architecture. You want to ensure that you monitor everything, even though you think that you may not need at that time. Because when things are going great, who cares what's really going on behind the scenes? But when things go wrong, it's really hard to understand what things are happening, especially in a decoupled microservices architecture. There could be events coming from one service that may or may not be related to another. So gathering a lot of information is key to help triage and help find the root cause of what's really going on with the composition of the app. The monitoring also helps avoid cascading failures. As I said, one service may impact another service. And at the end, the user only sees that your application is not working. So ensuring that the health and the lifecycle of the various services that are being consumed by your application is very important. The metrics help identify the health of the app, things like the reaction time or response times your user is interacting with your application. But the metrics also help give the operators and developers a sense of what's going on. The model resources that these applications are consuming help the operators and developers increase the resources as needed before the end user sees any issues. So it's very important that the platform provides these capabilities to help prevent future errors and ensure the integrity. But along with these events, we want to make sure that there's a well-defined process of how to handle them. So what happens when a service goes down? Or what happens if a number of nodes start failing? The alerts and events that are generated by the metrics and meeting components should provide insight to the people that are going to be triaging that event. In addition, logs from their application to services should provide additional insight to how your application is being used. As a developer, you don't want to have to know where your logs are going. It should be easily ingrained into the platform. What I mean by that is, as a developer, I should be able to focus on my application, know that there's a logging function, and in the end, I should be able to consume them from a centralized location. All the logs, because we have a lot of different services and applications running in these environments, they should be all aggregated and consumed and centralized, where a developer or an operator can go in, look, and inspect. If things are healthy, do I need to make changes in certain areas? And they should be easily searchable. If you have a lot of services, a very complex application can be consuming many services. So it's very important that we're able to assimilate the different events that are going on there. That provides a baseline for analysis and analytics of your application running in the platform. Finally, we'll talk about backing services. Now, this is really the key to help enrich your microservice application. Backing services should be treated as a decoupled state. What I mean by that is that you, as a developer, should know or have the hope that the services are available when you need them, so that when you do development, that they're dynamically linked into your application. The resources are critical, but all of the app logic should treat them as a dynamic bind. And they should be consumed as a well-set of defined APIs and consume this cure matter, typically wrapped as an application token or a service token. And the key point here is that, as a developer, I shouldn't have to worry how they're deployed or how they're managed because these services are typically managed by SMEs. Some examples of this. We start with data stores, things like databases, relational, document or graph, or file storage. So think of applications that maybe it's a gaming application. We need to store game state. We could use Object Store there. Or if it's a multimedia application, we can store images or video content in your Object Store. Messaging services help enhance the communication between your application and one or more services using message hubs in a Pub-Sub manner. Or if you need to consume messaging services to help reach out to your customers or your users by using push notifications. Security is always a big concern around services in the platform. That's why we want, as a developer or an operator, ensuring that these, ensuring that the services and applications are isolated in a secure way using various methods like proxies and API gateways. To also enhance the experience, single science, identity management, such as single sign-on, can help enhance the experience. You don't want your users to be logging into various services just to get a particular type of feature. And finally, the platform should also help you enhance what you've developed. Say you started an application as a simple web app. And then you want to extend that to maybe a mobile application. The platform should be able to give you that capability to easily transport a very simple web page to a mobile client. And then an additional enhancement, things like adding text-to-speech or image recognition can really help your application and user base grow. So from what I talked about, we really want to show you how it's done firsthand. And these are going to go over this BluePick app, show you the different types of services that we use, the architecture, how they interact, and the final outcome of this composable application. Andy? All right. Just think on it. Yeah? All right. Great. Thank you, Sean. So lots of slides. Let's get into a demo. Menwell introduced you guys to the BluePick application. I'm just going to actually show you it now. Some hot body here. There we go. All right. So I'm not sure if you remember the slide, but the BluePick app consists of a Swift-based back end and a Swift-based front end, so an iOS mobile application. And that's really what I'm going to show you guys right now. And like Sean said, we'll get into the architecture and how we actually deploy those services in a little bit. So I'm going to go ahead and fire this app up. Get that out of the way here. All right. So here's BluePick. BluePick's really, it's a photo sharing application that we've decorated with. Just like Sean said, we take that simple application and you want to make it more featureful. You want to make the user experience better. So it's a photo sharing application that does a little more. And I'll show you what. Here's the app. It's just a stream of photos right now. But what I can do is I can go ahead and I think it's a little off against some reverb there. I need to adjust the disc. I think my resolution is a little high because I can't see the bottom of this. Can you swing it? No. See the bottom here? Sorry about this. No, it takes one size. There isn't a button. You can scale. Yeah, I just need to adjust it. Sorry, guys. Display. Scaled. You can scale the simulator. Oh, you can? Yeah. I don't know how to do that. Is that on the simulator? All right. Scale. There we are. Lower. Lower. There we go. There's my buttons. OK. All right. So I'm going to simulate taking a photo with the emulator. And there's some sample photos here. So I'll grab one. And let's go ahead. This one looks nice. Let's give it a title here. Spell that right. There we are. OK. Let's post that photo. All right. So what it's going to do is it's going to upload it to our back end. And there's going to be some processing that gets done in the back. While that's happening, I'm going to flip over. I'll show you the front end. All right, I'm sorry. I'm going to show you the web front end for our application. So here it is. We have some kind of mobile login client access. So it does support logging in Facebook. I'm just going to do anonymous login for now. And you should be able to see our photo. Network's a little slow. But it is there. If I click on our photo here, you can see that's the title I just added. And off the bat, you can see we have a little extra things. There's actually some geographical information associated with this photo. And we're going to get into that, what those services are. But it's actually taking, I don't know if that's right here, the temperature. But we're simulating getting the temperature associated with a geographic location and then mapping that to the image. And that's going to be handled in the back end. We didn't actually put that in. All I gave it was a title. Let me just refresh the mobile app here. OK. And I can see on my photo the same kind of temperature reading here. But even more so, we have these tags that were generated. So we're actually using, and I'll get into this when we get to the architecture. But we're actually using Watson, the Alchemy Vision API. And what that does is it takes the photo, does some image recognition, and generates those tags for us and applies that to our photo. So you can see those are being populated right there. That's in a nutshell what the application is doing. I'm going to flip back to some slides. We're going to get back to some demos. So bear with me. All right. Let's hop back here. Great. All right. So you've seen this slide before. And really, as I said, and Manuel had said, these yellow dots, these signify our Swift-based application. So we have a back end in Apple Swift and an iOS app in Apple Swift. I showed you the web app. You can see on the left there in the pink. And then the rest of these services. So the kind of flow that I just demoed, so we took a picture of the iOS app. And then we went and uploaded that. So that goes and that hits. Let me see if I can turn this on here. All right. So we took a picture in our iOS app. I just showed you the web app, the web front end for our Ketura back end here, as Manuel mentioned. Ketura is a Swift-based web framework. So when Ketura gets the picture, it's going to go ahead and dump that into our object storage. So we get a photo, toss it over there. And the title that we associate with that photo, that's going to get dumped in as metadata into our cloud and storage here. So we have two storage services that are supporting the application. And then the interesting stuff happens. So those tags and the weather data that I showed you that got generated, those are happening on OpenWisk. I'm not sure who else is familiar with OpenWisk. It's a serverless platform, serverless computing platform. But on OpenWisk, as I mentioned, we have the Watson Vision API that's doing our image recognition. And we also have the Insights for Weather service. And that's where we're getting our weather data that's associated with the geographic information of the photo, the geotag, if you will. So we take that photo. It gets pushed through our back end, stored in object storage, metadata is in cloud end. And then as soon as that happens, OpenWisk is event driven. So what we're going to do is once that photo gets uploaded, OpenWisk is going to go ahead and kick off these jobs. So Alchemy Vision, like I just said, it grabs that photo out of the object storage, does some image processing. It's going to get those tags, and it's going to dump those back into cloud end. Associated VM metadata with our object in the object storage. Same thing with the Insights for Weather, the Weather Data Company. So that's going to take the geotag, like I mentioned. Same thing. Dump that right back into cloud end. So now we've taken that simple application of taking a photo, uploading it, that simple action. And we've enhanced the experience very simply. And what I'm going to transition into next is how our platform really facilitates that and makes that simple. So what Sean was covering earlier is this concept of infrastructure foundations. And really, in the context of BluePic, everything that has color up here would be categorized as infrastructure foundations. So all these services that we just went through, the role they play, that would be BluePic's infrastructure foundation. Now I'm done boring you with the slides. I'm going to hop into some more demos. I do have some recorded demos because I wasn't sure about the network. But if we have time at the end, I can do some more live stuff. So let's hop into the first one. Really what we're going to get into now, once I get that, I don't need this stuff. Demo one, perfect. Let me just minimize this stuff. We'll leave that there. So infrastructure foundations. Now we want to go into, as Sean said, the platform should really make that easy to do. It should make it one click provisioning. I shouldn't have to deal with the intricacies of binding those services to my applications. I shouldn't have to deal with the technical details of managing those services. They should be there. Once I provision them, they should be there for my app to consume. As you can see here, I have a set of services that's not the full set of services, if you remember the whole list from our architecture slide. We're missing the Watson Alchemy API and the WeatherData services. What we're going to do is we're going to go ahead and provision those. Just show you how easy it can be to do this. So we're going to hop over to the service catalog. And as Sean mentioned, this is ever-growing. We take more and more technologies and we want to enable them on the platform for a developer to consume. So we're going to go find the Alchemy API. And right now, we want to bind that to that application. So we're going to select our blue pic. And that's it. Got the blue pic. We do need to name it specifically just because of how the app is implemented. There's a configuration. It looks for a specific name. So we've got to give the service the right name. You can see from the catalog it gives you a little highlight of what features are available, some of the pricing plans. The free doesn't work if you routinely do it. So it had to do with the standard. So we're going to go ahead and provision that. I didn't mean to say it doesn't work. It doesn't like you to do it again. It wants you to delay it. So what it's telling me now is it wants me to restage my application. And what that's going to do is it's going to handle binding, that binding that happens. It's going to take care of that and redeploy the application, restage it. I chose not to do that at the moment because I'm going to provision a couple of services. All right, great. So now we can see here our Alchemy API has been provisioned. Perfect. We have one more to go. So let's go back to our catalog. We're going to find that weather data service. I was going really slow when I recorded these. Just to note that these services are being deployed separate from the application. So the services, the instances are being generated. And what happens is, again, this whole concept of late binding or dynamic binding and linking happens at deployment time. So that's why the message comes up as restage your app. Because at the time when a new service comes on board, you want to make sure that the application consumes that new service. So the restage takes place so that it can now talk to this new instance. That's a really good point. There's nothing saying that you have to have your application running here in order to consume these services. They can just as easily be consumed externally. You'll just have to handle the actual binding of the app to the service. All right. Once again, the weather service, we're going to go ahead and bind that to our BluePick app. Give it the right name. I'm going to go ahead, make sure we got the right pricing plan, and go ahead and create that. All right. So with a few clicks, we've got our services ready. That's the whole set of services that our BluePick needs, and that's the Infrastructure Foundation. It wants me to restage again. I opted not to. So we've got our full set of services, and now we're going to get into, we're going to fire up our application because it's stopped right now. It wouldn't run very well without the services that it needed. Those services represent one of the circles on the architecture chart. Right. Yeah. Each one of those boxes that we just saw in that view, what's going on here? Play. They correspond to the architecture diagram. The second one we showed where it had just the colors of the infrastructure services, they map one to one to those. All right. So like I said, we're going to go ahead. I stopped touching that. We're going to start our application up. And what Sean also mentioned, and what we're going to get into next that you really should come to expect out of a platform, is these kind of common features or tools that should be available to you and that are common across. When I say common, I mean I would hazard a guess most if not all applications are concerned with at least logging if not monitoring as well. So what we're going to dive into now are some of the logging and monitoring features that are available for our BluePick app. This is all default. Yeah. Again, I didn't do any provisioning in terms of logging or monitoring. Those are automatically there. Yeah. So we're going to get into that. So as Sean had said, in terms of logs, we want them centralized. We don't want to have to go to multiple locations, go tail-flogs over here and have multiple terminals. They should just all be in one spot. They should be formatted and searchable. So they not only look nice, but we can actually do things with them. They're not just a bulk of data. As you can see here, Cloud Foundry is the actual platform that BlueMix is built on. And what we're showing you here, what I'm showing you here, is we can filter where the source that those logs are coming from. So I showed you the Cloud Foundry logs. The DEA is actually the service that runs the application. And what this is showing you is that if you have multiple instances and you wanted to specify a single instance, you have that option too. And later on, actually, I'm going to get into some more logging and monitoring options that you have that are also integrated. So that was kind of a simplistic view of the logging that's available. There's actually a more customizable dashboard. If you're familiar with Elk and the Kibana dashboard, that we actually have that integrated as well. So if you want to have a little more flexibility, you're able to do that as well. Now I'm getting into kind of the baked in, the batteries included monitoring that's available. In terms of monitoring, you can only go so far in terms of the batteries included model. So what this is going to get into is, oh, sorry. So what that was doing is my application, when I hit start, it's doing that restaging. I opted not to restage at the time. So it's restaging that app, and that's why it needs to be started at the moment. So now I'm going to get into some of the baseline monitoring that's available. And really, those consist of two categories. Those are availability, as I just skipped a whole part of the, sorry about that. Sorry about this. I skipped a whole section here. All right, let's play from there. So this is going to show you availability. Our application, in terms of availability, you want that deployed in multi-region. And that's really what this graph is showing you. So the backend is actually provisioned. You can see here in three separate spots. It's showing you that it's down right now, and that's because it's currently restaging the application. So it's not actually up right now. I can get in, and when I get to more of a live demo, I'll show you that it actually is running. It has to be because of the iOS demo I showed you earlier. So some of the out-of-box testing that is available is response time. So this is just going to provide you with some kind of simplistic metrics in terms of how quickly the base route of your app is responding. And you can see we've got the activity log. The app's been started and stopped. And here, this is a graph that's showing you the response time. So there's three different colors here. I hope that's yellow, blue, and green. Those correspond, you can see down here, Amsterdam, Melbourne, and San Jose. So those correspond to the three different locations on the map that you saw up top that our application's deployed. And because this is just deployed, there's not a whole slew of data at the moment. But it's already gathering metrics for you. So you can see the instance that's deployed in Melbourne. It's responding with a 1.6 second response time. So response time is one. And then availability. That's the other batteries included monitoring that we have. And again, there's not a whole lot of data at the moment with this demo, this recorded demo. But this is going to show you the uptime of your application. All right, that's the end of demo one. I have another recorded demo that we can get into. 10 minutes left. All right, great. So I'll just go through this one and then we'll open up for questions. So as I mentioned, I showed you the simplified view of what monitoring and logging that are available. Now I'm getting into more of the customizable features that we have. This is a little bit different of a URL. So it's logmet.ng.bloomix.net. But it's still going to get the consolidated metrics and logs. And it's going to show you the same kind of data that I was just showing you in the other view, but in a more customizable way. So for those of you who are familiar with Kibana, here's our Kibana. And these are the logs that we were just seeing. You can see updated app. Apps now listening. So those are application logs. And really what you have here, you have the ability to customize your log view. In the other view you didn't, you could at least select the source at the platform layer, as well as the instance number. And here we have much more flexibility. I can add things like the application name that is coming from the organization name and the space name, where the apps actually deployed. And there's a whole other set of tagging and different kind of metadata about those logs that you have to control to customize how you want to view here. So here I'm adding the organization name, the space name, and it's pretty quick, right? And then there you go. So if I had a few different applications that would be a little more useful, this is just to demo that capability. But you can kind of see it if it's a water hose of logs, I want that ability to kind of customize what I'm looking at to make sense of all that bulk data. I'm going to kill this recorded demo. I want to show you guys that this is actually running. Let me get the right window up here. All right, great. So this is the web front end we showed you earlier. And here I am in a web browser hitting Bluemix right now. This is the same thing that we've been looking at in our recorded demos. I'm just going to go into show you a little bit more. We have a little bit more data now that the app's been running for a little while, and we've been interacting with it. So in the recorded demo, I kind of had some red here. And that was because the app was currently staging. So it had a little downtime. But now we're back up at 100% availability. I didn't define any more complex tests to perform, but that test is now passing at least. So if we drill down into that, you're going to see that we have actually some more data down in the response time graph once it loads it in here. There we go. So lots of pretty colors. So there's a lot more data for us to look at and do things with. Apart from that, I think that's kind of the end of this. So that is the infrastructure foundations in terms of the 12-factor app. What you're going to hear in the next session, Dan's going to cover some of the options for running these microservices, kind of some trade-offs in terms of how they're get deployed and run, and some of the options that you have. I think we've got about five minutes. If there's any questions, could you please just take them to the microphone? All right, well, thanks for joining us. In about five minutes, we're going to have some refreshments. I think he said we're going to start the beverage service. The beer's coming. Thank you. Please stay for the next couple of sessions. I think we're going to have a little bit of a break, and then we'll be resuming soon. Thank you.