 Hi, I'm Ed Anif from Apogee. And we're going to talk to you a little bit today about how to manage APIs within Cloud Foundry and do a quick review of what do we mean by web APIs? Where do they sit within your architecture? Why you want to manage them? And the approaches that we took to integrate within Cloud Foundry using route services. So most developers work with APIs every day. So you probably all, at a basic level, sort of understand what APIs are. They're a contract. They're the ways that the software that you write talks with various services that are either within the system or distributed APIs, web APIs. Specifically, what we typically are talking about when we talk about API management is web APIs. And typically, a web API, most of the new APIs that you deal with that are internet-accessed APIs, web APIs, things that you might be talking to from Amazon or Google or Twitter or any of the various types of internet services you connect to, have tended to all converge around being JSON-based. Typically, with some form of OAuth as the authentication mechanism and we tend to advocate that the open API standard is used for describing these APIs. But this classic form of web API has been very popular and very successful for letting application developers basically open up their applications to external developers. It's what makes mobile possible and so on. In fact, one of the biggest challenges in dealing with APIs and dealing with API projects is really trying to understand where the APIs are going to sit within that architecture, what is the purpose of these APIs, which applications are talking to each other. And what we tend to find is that there's really about four different places that APIs can sit within your architecture. Many of you who are building applications that are dealing with front-end clients, perhaps mobile, are dealing with APIs that are being exposed externally. You may be doing that for the purpose of talking to a mobile app that you yourself have built. You may be doing that to make it possible for applications that other people have written to talk to your application. You might be doing it for various forms of partner integration. Those are really what, at the top of this diagram, is being shown. A lot of people that we talk to go and say, well, we're not really doing that. We're not doing any mobile. We're not doing any partner integration. But what they're doing is a lot of integration between their applications. And this is what you tend to see described as service-oriented architecture and so on, where you've got different applications. And that's really what you're seeing here. Different types of applications are talking to each other via APIs. This tends to be where you see perhaps the older styles of APIs, soap-based APIs, various forms of XML described APIs. And then if you're building proper 12-factor apps, you're probably thinking about how you abstract out your back-end resources and treat those as services that you're talking to via APIs. And we're seeing that particularly for application developers, obviously any application developer that's building on Cloud Foundry or deploying to the cloud is building towards that mechanism, treating your back-end database or accessing it via some form of perhaps REST API rather than the way you may have done it in the old days of just talking directly via JDBC or what have you to MySQL or something. Nowadays, people are talking to their databases via APIs. And then most recently, we've seen this idea that your application itself gets exploded or decomposed into a set of component services that essentially are tied together via APIs in the form of microservices. So this ends up being kind of the challenge that a lot of people deal with is just sort of when somebody just in a very vague sort of way goes and says, APIs, we're going to build APIs, what does that mean? It can cover a lot of ground. And this is just talking about the various forms of network web-based APIs. Obviously, you've got your language APIs and so on, your system APIs that I'm not even talking about in the context of this. So with that in mind, what else do you have to sort of think about in APIs? Well, the other thing is that these APIs are all used in different ways. I talked a little bit about sort of the REST style. And I'm using REST in the technically incorrect way, which is the way that everybody uses it. I'm not actually talking about hyper-media APIs. Resource-based. That is the predominant form of APIs for new API development that we're seeing. But we're seeing that there's really sort of four styles of API usage. A lot of the data access APIs, some of you may be using things like OData. People that are either part of the Microsoft or SAP ecosystems probably spend a lot of time with that. Ecosystem APIs, these are APIs that you're making available to external developers pretty much for the most part are REST-based. They're described with Swagger or OpenAPI. Experience APIs are an interesting concept. This is where you're exposing an API really purely for the purpose of having your front-end client. And it might be a JavaScript-based client. It might be a mobile app. Being able to talk to your back-end services. Netflix coined this term of experience APIs. The really important thing you have to understand about experience APIs is that, architecturally, they're actually not really designed for reuse. They're typically not, they don't go through the same sort of documentation process and so on. Because in many cases, the person who created the API is the only person who's actually going to be using that API. And that subject that we could probably go on for hours on. Because if you've ever built an experience API, you know what I'm talking about. If you've never actually built a client-side app that uses experience APIs, then it sounds like a horrible anti-pattern. And then finally, your sort of classic integration APIs, microservices and so on. Predominantly, soap and rest, although we are seeing things like GRPC as mechanisms for microservice APIs as well. So that's kind of the landscape of the different types of APIs that you see. How does this kind of play out for typically the people who are building applications? Why are they thinking about this? Why are they going and saying, OK, I need to manage these? And why do I want to think of these in the context of all of the other things I'm thinking about when I'm building an application that's going to sit within Cloud Foundry? Well, generally, what you're trying to do when you're building your application, Cloud Foundry makes it easy for you to scale your application itself. But scaling adoption of your applications is really hard. And the way that you do that, the reason why you're deploying all of these APIs is because you basically want to go and bring your application to your users wherever they are. And so that's why you're essentially building these ecosystem APIs, why you're creating these rest APIs so that it's possible for people not to have to go and essentially send their users directly to your application. They can build whatever sort of application experience they want, and it can be connected to the APIs. And these are sort of the different types of scenarios that we tend to see from a business standpoint that are kind of driving these API projects. But when you do that, you've got a whole set of challenges around that. And this is where companies like Apigee step in. And we're not the only ones. There's a number of different vendors and options. But I'd like to be a little biased and say we think we're a pretty good option on that. But generally, the problem you're trying to solve is first getting visibility into all of the API usage. And that visibility is for operational purposes. You want to understand the health of the APIs. You want to see what the latency is for the clients that are calling these APIs. You want to go and see are these APIs erroring out because people are using the wrong versions of the APIs or are they using the wrong forms of authentication, which might indicate that either you've got a documentation problem or it could be a security issue. But you want to be able to visualize that. And generally, you want to be able to go and really think about your APIs from really a data-driven approach in terms of whether anybody's using these and make your decisions accordingly. One of the challenges that people had with the old school version of API service-oriented architecture and so on is that required everybody in your organization to be a service provider. Everybody became beholden to each other because people were reusing all of these services that were being created. And that's a good thing. But the problem is that there wasn't a lot of visibility into who was doing what. So you might decide that you wanted to go and turn off an API because you didn't think anybody was using it and chaos would ensue when you did that. So these are all the sorts of things that visibility and analytics on top of your APIs gives you, both operational analytics for being able to think about the health of your APIs but also giving you the visibility to how people are using these APIs. And for some companies, this might actually be core to their business model. We're seeing more and more companies actually using their APIs as something that they even charge for. The security considerations around APIs are also fairly complicated. It isn't as simple as sort of a binary choice of does somebody have access or not. Different types of users will have different levels of access to different types of APIs. There will be data in the API payloads that might be made available depending on what level of access that you have. There might be rate limiting that's associated with APIs. For example, if you ever built an application that used the Twitter API, the basic API that they make available to people, you can only call relatively infrequently. You have to be a business partner if there's in order to be able to call it. I don't know what it currently is, say something like 10 times a second or what have you. Many companies, when they're making these APIs available, want to basically create different levels of access. They may do that because it's a business partner. They may do it because it's a trusted application. Providing an API, being a service provider, costs you something. It might cost you your time and effort. It might be the resources that you're putting behind your servers and so on. So you want to make sure that you can control these things. And in addition to that, you can also see badly designed applications. Actually, we see this all the time with mobile apps and IoT use cases where people build something incorrectly and they basically create their own distributed denial of service attack. And so from a security standpoint, being able to enforce through policies the ability to do things like rate limiting and so on is very desirable. So obviously, these are all use cases that people tend to have not even thought about in relation to APIs. When I say security in relation to APIs, most of the time people are like, oh, you mean like an OAuth access token or my keys? And yes, at a starting point, that is part of security. But there tends to be a whole set of other policies and access control rules that you need to think about in relation to APIs that tend not to realize you need until it's too late. And then finally, this idea of the developer portal and being able to go and provide documentation, the ways for people to learn about APIs is very important. If you've ever tried to make use of an API and it was documented in an inadequate way if the documentation was not structured using the proper conventions, ideally using things like Swagger or OpenAPI to make it very easy for you to understand precisely what you need to send. And with as much detail as possible, what you're going to get back, then you're going to have an exercise in frustration. And if your experience in using Web APIs has been like mine, you'll have seen that there's some situations where it's sort of an API is just a joy to use. You had half an hour to get something done. You were able to go to the website, find the information, get the credentials you needed, actually try out within the website, make a sample call, get example code. Maybe it actually generated a curl command that you could just paste into your terminal window. And you were just able to be extremely productive. And then there's other cases where it's like, OK, this is just a nightmare. And you're really struggling to try to understand it. These are all the types of things that, ideally, you would get out of whatever you were trying to do from in terms of managing your APIs. That's part of the reason why there are companies like Apogee that do API management. And again, this isn't like a product commercial. There's a lot of other alternatives to working with Apogee, of course, but I'd like you to come and take a look at what we do. So with all that in mind, how does this tie into route services and what we've done with Cloud Foundry? Well, so in order to do this, this was kind of an interesting process for us. We really needed to figure out how to integrate into the request stream. Most of what I've talked to you about gets enforced at the runtime level through essentially a proxy, if you will. The incoming API requests pass through a gateway that applies access control checks, the OAuth token, and so on captures the analytics. So when we looked at how to do this, there were a couple of different ideas. This was a project we started about 18 months ago, and we started talking to the folks at Pivotal. And one of the things we wanted to try to do was really sort of integrate into the whole service broker mechanism for providing that same ease of use, that kind of native workflow that people like so much about working with Cloud Foundry, particularly for services via the service broker. However, most of what the service broker does is dealing with back-end services. And in the case of what we wanted to do, you could think of this as more of a front-end service. And so what Pivotal did was basically open up the CF router with this concept of route services. And so what happens within Cloud Foundry when you go in and hit the Apogee tile is that essentially we go and we bind our proxy into using the Route Service API, essentially establishes a callback in the CF router so that requests that are coming into your application, and this can be done on an application-by-application way, fully respects the multi-tenancy of CF, will then get sent to the Apogee gateway that can then go and apply our API policies and so on. So this is a mechanism you can use, the Route Service mechanism. There was a session on this yesterday, and there's a whole bunch of other uses that you can do in Route Services. You can also chain these things. You could have, in addition to, in our example here, where we're binding that Apogee proxy into the CF router, but you could have a bunch of other additional interceptors, if you will, that can get a shot at dealing with incoming traffic. But the nice thing is it's all completely dynamic. You can add it after the fact. You can make changes to it and so on at runtime. And we're going to show you a demo in a few minutes on how that works. The other thing, though, that we ended up doing was also looking at how to do this outside of the Route Services mechanism, which was essentially allowing you to go and bind in a micro gateway that sits within your application. So this is kind of our approach for microservices integration, because remember, previously I showed you sort of the different forms of APIs. Well, we've seen that most of the activity around CF users tends to either be, how do I expose these APIs externally, which is what we're seeing here. I want to talk to mobile. I want to go and have devices. I want to go and build my JavaScript frontends and so on, perhaps using Angular, React, or what have you. Or we've got these scenarios where the APIs are actually essentially microservices, and you want to be able to talk between them. So we had to take a different approach on that, because obviously you don't want to necessarily have every microservice request going back out through the CF router and back in again and what have you. So for that approach, we provided a Node.js application that you can actually deploy inside your application. There's a technique called the metabild pack that we used to make this easy to do as kind of an alternative approach. So with all that in mind, I will now hand things over to Prashant, who will actually walk you through what this looks like in practice. And then we'll take some questions afterwards. Thanks. Thank you, Ed. Turn this off so there isn't any echo. All right, so Ed spoke about the need for API management and some things that you can do with API management. Let me just show that to you in a demo. OK, good. Firstly, this is the Apigee API Management screen, where API proxies are available, and you build your API management activities and tasks on this UI. Right now, this is empty. We do not have any proxies. I'm just going to refresh the screen to prove that. Right, let's use the route services. I have the CLI, and I hope this is readable at the back. Currently, I have an app already pushed, and if I do a curl into that app, you see that there's a simple JSON response, right? So this is the running app. This is running off Cloud Foundry. In order to attach Apigee to the route, I need to create an instance of the service. So we have a service available called Apigee Edge, and you create an instance of the service in your environment, which is what I'm going to do now. Once a service is created, you bind this service instance to your route, on which you want to do API management. And that would be the next step, where I bind this created instance to my route. When I do this, what I'm doing here essentially is also pointing the route to the Apigee instance that I want to work with, which is what I showed you the moment I bound the service instance to the route. A proxy is created on Apigee, on which you can now add your API management features. On the API proxy, we have a trace facility by which you can see the requests coming in, and all the API management policies being applied on it. I'm just going to try to get the right zoom setting. And I do a curl again on this. The response is still the same. Nothing happens, but this time, you see that the request has come into, OK, I hope this is fairly visible. Oh, yeah, OK. So you can see the request coming in, and right now, there essentially is no API management being done here. Now, there are a lot of APIs that you can develop, that you expose, but how do you get other users familiar with this? You need the documentation. You need to put this out. You need to enable some sort of self-service on this. And that's where we have the developer portal that Ed mentioned. The developer portal looks like this. You could have some documentation. You could have blogs. It has a community forums and so on. And if I go into API, so as a new user, I come in. I try to take a look at all the available APIs. It's categorized. Our documentation also supports smart docs by which you can also execute the API from the documentation itself and see the request and response. So for instance, if I just fire this, I already see a response that's happening. The APIs that you expose don't need to be limited only to yourself. You can publish this using the developer portal. What's also great with the developer portal is it allows self-service. So as an end user, I can come in, register myself as a developer. For the sake of time, I will already use an existing user. So once I register, I have a user. I can now go in and so I am now registered. I can go in and I can create an app. Let's come back to this. It's spoke about security. One of the easiest ways to enable security is by doing an API key verification. So I will do that in the proxy now. I'm going to add a few policies so that we start doing this API management. We have a wide variety of policies ranging from traffic management, which includes throttling, as well as caching policies. We have security policies, or API verification, SAML assertions. We also have a lot of mediation policies. You can even write your custom code to do what you would like. I will first add an API verification to this. I will also do an adjacent to XML for those who still use XML. Maybe you might be interested in the XML response. And these are specifics of how you use it. I will not get into that. But you can also you can ensure that the policies are conditionally executed. So in this case, I'm going to say request.queryparam. It might not be too readable there, but let me read that out for you. So request.queryparam.format equals XML. So in case you're requesting for an XML format, that's the only time the conversion happens from JSON to XML and not the other times. Let's save this. I had also mentioned about Spikerist. I did a demo of the Spikerist policy yesterday. I think there's a fair bit of audience who also visited it yesterday. I mean, you can know a lot of things, but I'm just going to show you some of the key features. OK. I start the trace again. Let me make a curl back to this. And we should see it failing, right? Because we have enforced an API key verification here. How does one get the API key? That's back to the developer portal using the self-service. I can create my own app. I can add a new app. Give it a simple name. Use a callback URL. Bind it to a product. A product is something through which we expose APIs. And the moment the app is created, you are given an API key that you can use for your calls. So if I go into this, I see that we have an API key. And I can now make a call using the API key, and this should succeed, right? I showed you about the format. So I can also say format is XML, where I'm requesting this in an XML. That's a bad escaping with the curl. OK, let me check this works. What did I do? Yeah, I think I missed the ampersand, right? And this time you see that the policy is applied, where the response is given back to you in XML. So the benefit of API management is you do not need to do this in each of the applications that you're developing. This is there at a central place where you can manage the policies, manage what kind of API management you can do on your applications centrally at a single place. The great thing that is possible here also is, as you said, you want to know how people are using your API. So we also have integrated analytics with a lot of out-of-the-box reports available. We capture the metadata of the request coming in and the response. So by default, you get information such as the proxy performance, latency figures, response times, and so on. So you see that over the time that we have been making calls, it's already capturing information. We do not sniff into the data coming in. We are conscious of that, so you just get the information about the request and response. If you do want to pick business-specific information, we have a policy for that as well, where you can read the request, the payload, and extract business-critical information for you, push that into the analytics, and then you can use custom reports where you build dashboards around the information that you are interested in, right? Custom reports also has drill-down features. So yeah, it takes a while. I mean, the demo has been just five minutes long, so it takes a while for the data to get ingested, digested, and aggregated, and shown up here. So you don't see that, but you could build your custom reports, you could have drill-downs, look at more information about the whole traffic, and as I said, if you wanted to precate APIs, you can get that information from this and see who's using your APIs, what are the services being most used, and what not. Well, that brings me to the end of my demo. I believe we have run out of time as well. Like I said, we have a lot more features. Do visit us at the booth. We are happy to show you more features that we have. You can reach out to us, and yeah, probably we can take some questions by the side or offline. Yeah.