API Safety for IBM i Infrastructure, Operations, and Architecture
IBM i API Management from the Systems and Operations Perspective: Monitoring, Logging, Security, Performance, Troubleshooting, User Satisfaction, and more!
APIs are everywhere today, and the IBM i is no exception. Manual processes are being automated, new revenue channels are opening, data and functions are being integrated across all enterprise platforms, user experiences are being totally overhauled with open-source and low code options, and organizations are directly connecting with their customers and suppliers.
API enablement comes with risk! How do you ensure that you are not exposing your critical systems to attacks? How do you monitor API performance to ensure your applications are responding quickly? How do you respond quickly to errors and troubleshoot problems?
Whether you are already taking advantage of the power of APIs or just starting to look into how they might help your organization, securing, managing and monitoring them must be central to your strategy.
In this webinar, we will cover the best practices that will ensure your APIs are the most secure, the fastest performing, easiest to maintain, and of course logged and auditable.
Setting up and maintaining comprehensive API Security
Implementing Zero Trust policies to ensure your APIs are safe and secure
Proactively monitoring API access to optimize performance and response time
Setting up high speed infrastructure to handle high API call volumes
Managing APIs to maximize reliability
Tracking and troubleshooting API projects
All right, well, welcome, everybody, to this webinar on API infrastructure operations and architecture. And I’m going to start out talking pretty basically about APIs and how they’re being used in the IBM i environment and what the impact is that APIs are having on computing in general, because they are really transforming the whole technology landscape. They’re changing the way business is being done. So I’m going to talk a little bit about that. And then we’ll get in and talk specifically about different use cases in the IBM i world, so different ways people are using APIs. And then we’ll talk about security for APIs, because APIs have become the most popular vector for attacks on systems. And we’ll talk a little bit about API management and monitoring, and then a little bit about managing the development and deployment of APIs. So this webinar is going to focus more on operations and infrastructure on APIs rather than development of APIs, which, if you want more about that, we actually have a couple of webinars that focus on that.
So let’s get in and talk a little bit about the trends in APIs and what’s happening with APIs right now. So I traced the evolution and the popularity of APIs back to this memo that came out from Jeff Bezos over at Amazon. And he put this out. This memo came out in 2002. And what he said was he said, from this time forward, all teams will henceforth expose their data and functionality through services interfaces, meaning you cannot build any functionality for Amazon if you do not provide it with an API interface for people to talk to it. And then down here, number six, it says anyone who doesn’t do it will be fired. And thank you, have a nice day. So it really became a founding principle of Amazon and how they developed their applications. And a lot of people point to this as really the idea, the concept that made Amazon such an agile organization. They were able to move from marketplace to marketplace and to business to business because they were able to repurpose the code that they built just by simply rearranging the modules that they were using. And they’ve continued that to this day. If you want to do business with Amazon or use Amazon as a business channel, they provide literally thousands of APIs for interacting with their systems to allow you to automate the process of doing business with Amazon. So APIs have really become universal connectors between applications, between companies, between organizations to allow people to share data and to share functions machine to machine in real time. So we can do business very, very fast. If you think about when you go to Amazon and buy something, there are literally dozens of APIs being executed every time you do something. So when you look for an item and you see a list of items, Amazon is actually pulling the data about those items from their partner’s system. So they’re pulling in that data via APIs. When you go to get a price, they do an API call to their business partners to get price quotes. You want to schedule your shipment, they do API calls out to the shipping providers to get information about shipment costs. So there are constant API calls being made. If you place an order, that goes to the vendor to make sure that they reserve that item so they don’t sell the same item twice. So there’s the constant communication going back and forth via these APIs. And you can do the same thing in your IBM i environment. So you can use a few things for APIs, you can use all kinds of things for APIs. They can be the central switching station basically of all access to and from your IBM i. And companies are very, very rapidly adopting this. So APIs are becoming part of companies’ digital transformation efforts. So if you see here in this survey, it said that 65% of enterprise leaders strongly agree that APIs are part of their digital transformation strategy, 32% somewhat agree. So 97% of the people who responded to the survey said that APIs are an important part of their digital transformation strategy. Only a couple of percent actually didn’t think that they were important. And these are some of the reasons that they gave for why they’re important. So 49% said, we want to make the experience, the user experience better. And this is really important because all kinds of studies show that if people aren’t having a good experience through your website or through your API interface, they’ll leave and go somewhere else. They want to accelerate innovation. You can take advantage of emerging technology very quickly via APIs. In fact, if you’re interested in using some kind of technology, pretty likely that if you go and do a search on Google, you’ll find that there are APIs to access that technology. They want better collaboration among their internal teams. So they want to be able to share functions among the different teams. They don’t want to have a Windows group and a Unix group and an IBM i group and have them not talk to each other. They want to be able to make sure that everybody is collaborating and working together. And then they can also use third parties. So if they want to work with an Amazon or they want to work with a Shopify or they want to work with Magento or one of these outside organizations, they can work together and develop applications that talk to each other. And the developers, it makes it much easier for developers to do their work. Using APIs, they can access things like open source modules and add those to the applications. And I’ll talk a little bit more about that in just a couple of minutes.And what we’re also seeing is rapid growth in creating APIs between organizations. So if you look over here at this chart, you know, 74% of API communications were kind of on the Jeff Bezos line, that they’re internal kind of communications of the original idea that all of our applications will talk to each other. But more and more, the fastest-growing set of APIs are APIs that allow the companies to talk to their business partners and their customers, to make functions available so that there can be machine-to-machine communication across organizations, and then also to take advantage of these third parties that are creating APIs for performing different kinds of functions. And I’ll talk about some of those use cases as well.
Let’s talk a little bit about the architecture of setting up an API environment. So basically, what you want to do with an API is wrap your existing application. So one of the things APIs allow you to do is they allow you to take advantage of all the new technology and do all the new things without having to rewrite that core application code. And it’s really something that is highly risky and very scary to do. And why do it? You’ve got these applications that work really well for your business. They’re tailored for how your business operates. If what you need is to take advantage of new technology, APIs give you a way to say, I can continue to take advantage of this great application that I have running and yet still get all the advantages of the modern environment. And so that’s part of what we try to do with Eradani Connect, or Eradani Connect product is actually a wrapper that wraps around all of your native IBM codes, your RPG code, CL code, COBOL code, DB2 applications. It wraps around them to create that layer of APIs so that you can call in and run those functions. So you can cut from the outside. You can go in and run an RPG program, the CL command, a group of COBOL programs. You can access the DB2 database, the logical files, physical files, stored procedures, tables, views. So you can access all of that from the outside. And from your RPG, COBOL, DB2 applications, you can call out to the API. So if you want to call out to Amazon, you can call out directly from your RPG programs through Eradani Connect. So it’s designed to be that kind of layer that wraps around your IBM i applications. And what we’ve done is try to make that extremely, extremely fast. If you’re going to start going down this road of building APIs and putting in an API infrastructure, it’s really, really important that they’re very responsive. You don’t want users sitting on a screen waiting for six or seven seconds for the screen to come back. You want to be able to have that API call be very, very fast and very responsive. And you may be handling very large volumes of API calls. We had a trucking company that was getting a million rate requests a day. So they had a high volume of calls coming in. We have other customers whose call volume is in the tens or hundreds of millions a day. So you can end up with very, very high volumes of calls as people realize they can talk to your application machine to machine. So you want to plan for what kind of performance do you need? What kind of speed are you going to need out of your APIs? Do you need to handle 10 million calls a day? So maybe I need to handle 120 to 150 calls a second. What is the volume you’re expecting so you can ensure that you have an API connector that can handle the volume that you’re looking for? And then you also want to look at how much load is that going to put on your IBM i back end? Maybe there’s some processing you can push into the API layer so it’s not putting as much of a load on your IBM i. And so this is just some benchmarking we did with Eradani Connect where we could handle with a single server without any optimization about 120 to 150 calls a second. But we can tune that and we can actually horizontally scale to many more than that. And with our new Kafka link, we’ve actually benchmarked this at 12,000 calls a second. Now Kafka is a system designed to provide you with the ability to handle very, very high volumes of API calls. So if you need that really where you’re getting the billions of calls, you can handle that with the Kafka link and it will handle the really, really high volumes of calls. And then when deciding how to set up your architect, you want to say, OK, so where should my APIs live? Should they be right on the IBM i? If they’re right on the IBM i, you get the advantage that they have access to your IBM i resources directly. So that’s going to make them very, very fast as you operate through that API server. So that’s a choice. It does mean, though, that you’re now connecting your IBM i to the outside world. So the outside world is coming into your IBM i and accessing the API layer directly there on the IBM i. So you could instead choose to say, no, you know what, I’d rather have my API layer be external to the IBM i. So I could say, I’m going to put my API servers on Windows machines or Unix machines or Linux machines. And maybe I’m going to have those machines running outside the firewall or in the DMZ or maybe up in the cloud so that I can have a layer where, first, I’m going to check all those APIs that are coming in before I actually go in and get access to the IBM i. And you can configure the IBM i to only accept connections from those API servers. So you can have that extra layer of protection where the IBM i is being protected by the systems that are filtering out any potential bad requests before they ever get to your IBM i. So something to think about is, how do you want to actually structure your environment? You could even have those API servers running up in the Amazon cloud or the IBM cloud if you want to do that. The advantage of having them running on Windows and Linux servers is you can scale them up. So the purple boxes here represent instances of an API server. If you’re running on the IBM i, you actually can do the same thing. You could scale up and have multiple API servers. But unless you’re actually expanding the size of the IBM i, you’re not really getting any additional processing power. Whereas if you’re doing it by putting it on a bunch of external servers, you can add servers and add servers where you’re actually getting additional processing power every time you do that. So again, these are some things to think about as you’re implementing your API strategies. What is the volume I’m going to expect? What are my security requirements? How do I want to make sure that I set this up for success? When you’re implementing APIs, one of the things that we’ve gotten from listening to IBM about this is your successful API strategy means using the right tools for the job as you create this API environment.
OK, so we’ve talked a little bit about setting up your API architecture, some of the tools to use. Let’s talk a little bit about security and securing those APIs. So one of the reasons you really want to think about this, by 2022, this year, APIs will become the most frequent attack vector, according to Gartner. API attacks are way up. 91% of enterprises have had an API security incident. So you can see that this stuff is happening a lot. And one of the things that’s very scary about it is some of those attacks, not just API attacks, but attacks on infrastructure, are coming from inside. So even if you’ve protected your system from the outside, if you’ve got somebody running a Windows machine, or a Mac, or something, or a machine on your network that’s been compromised, somebody clicked on a bad link, now the hacker can get to your system from inside using that user’s valid credentials. And so another thing APIs can do is creating an API layer around your system can actually help protect you even from insider attacks. And I’ll talk about that in just a second. There’s just some statistics about the number of attacks that have been occurring. And these are some of the reasons why people think they have the API issues. One is they’re not logging. They’re not keeping track of who’s accessing their APIs, what kind of volume they’re getting, and where they’re coming from. They’re not authenticating properly. Misconfiguration. So the API is giving people access to things they shouldn’t have access to. So a lot of times, we see IBM i users who basically open an ODBC connection to the database, and now that user has basically access to the entire database.
OK, so a little bit about security and securing the environment. Let’s talk about managing and monitoring the APIs. So you want to be able to make sure that you’re keeping track of. Remember, one of the security issues was inadequate managing and monitoring the APIs. So you want to be able to make sure that you know what API calls are coming in, how they’re being routed, who is the person that’s calling in. I want to be able to make sure I understand what data they’re sending me and what data I’m giving them back. So all that information, you want to make sure and you want to be able to do that whether somebody is calling into your IBM i to access one of your resources or you’re calling from the IBM i out to something else. You want to make sure that you’re monitoring all of those calls and you’re making sure that they’re all being done in accordance with whatever policies you set up. And not all APIs are a simple call and response, right? Not all APIs are I’m going to send you some data, I’m going to get some data back. They can have many, many steps, and so it becomes difficult to debug if there’s a problem. It becomes difficult to understand what’s happening. This is just a sample of a customer of ours that had a very complex API workflow where they wanted to give their customers the ability to look at their orders and then find out exactly where their order was at any moment in time. So first, from a mobile device, they would go in and say, you know, I’m customer X, show me my orders, so that would get authenticated in the API layer. Then they’d go to the IBM i, it would extract the list of their orders, send them back their orders. Then they would select from their orders the order they were interested in, so it would go back to the IBM i, get more data about that order and details about the order. Then they’d hit the track shipment button, which would then go back to the IBM i, which would then send a message out to their freight provider to find out where the truck was, and then it would generate a map and send back a map to the end user. So there are a bunch of steps in making that API work, and so you want to make sure that you’re tracking everything that happens, and that’s one of the things that Eradani Connect does. So Eradani Connect actually does all that authentication. It does all the routing. It does all the data transformations from place to place, so from JSON to RPG data structures and back. So it does all those transformations for you, and it ensures that all the communications are secure. So in that particular case, we had a bunch of different API types in one use case. So the modernization case, the integration of internal systems, the integration with outside systems to public APIs, using modern language. We had integrated open-source components, so lots and lots of things going on inside that one API use case, and we were able to implement that and create the whole thing, the user interface and all the other code and all the API connections in just a couple of months. So a little bit about the actual monitoring. So I talked about this. You can throttle API communication. So if you’re suddenly getting overwhelmed with APIs, you can slow down the API calls, and you can slow them down by user, by IP address. You can shut somebody off completely if you want to, and you can do that in both directions. We have customers that use APIs that they get charged for, and so they want to make sure that their users aren’t making too much use of those APIs. So they’ll limit how many API calls can go out from their system. And so with Eradani Connect, we give you the ability to limit those API calls by the endpoint, the API endpoint, by the application it’s accessing, by groups of endpoints, by IP address, by the user, so we can protect you from the different kinds of things that could overwhelm your system. And it also gives you the ability to monetize your API. So you could actually be in the position of saying, we’re going to provide an API to our system, but we’re going to charge people for it. So you can actually track that and charge people based on their API usage. And then you can also have the system go out and do health checks to say, is my API running? The last thing you really want is to find out that your API is broken when somebody calls you and says, hey, your API is broken. So you want to be able to get that notification proactively. So you can have the API management system actually going out and hitting your APIs and saying, are you up and running? Are you performing properly? So you don’t have to wait to get that kind of response. And so let’s take a look at actual monitoring here.
And another one, when you have competing third-party APIs, different APIs that do the same thing like geocoding, how can you compare APIs to identify which API is more accurate, really that’s accurate, or provides more accurate data? Great. So if I’m understanding, let me just bring up another window here real quick. So I’ve got this up and running here. What I’m doing here is signing on to Eradani Connect. So one of the things we do in Eradani Connect is we allow you to create what we call applications. Applications are basically business area functions that you create. You can create as many of these as you want. You can call them whatever you want. And they’re really used for organizing your APIs. So you can have all your JD Edwards APIs in one place, all your warehousing APIs in one place, transportation APIs, payroll app, whatever you want. You can create whatever you want for these organizational structures. And then you can go in and you can see what’s the list of APIs that are actually associated with this. So now you can actually have us, if we’re generating APIs for you, you can actually have us put those APIs, those generated APIs, into a Git repository. If you do that, it becomes very, very easy to compare versions of APIs or different APIs to each other. So you can actually compare them and see what’s different about them. So if you want to see, gee, how are we handling the API call in this version versus how are we handling it in this other version, you can actually see what’s different and decide which one is the most appropriate. So you have a way of organizing the APIs. And then with Git integration, you can then actually see the differences between the APIs.
Fantastic. We do have one more, if we have time for it. Yeah, go ahead.mPerfect. Can API development be performed in the cloud, like with Azure or AWS? Sure. Yeah. And in fact, that’s one of the options for implementing, if you’re implementing Eradani Connect. And here, let me just bring up another slide here. Here we go. So we actually have a bunch of customers that are doing things this way, where they actually have their API servers running up in the cloud. So they’re running their API servers in IBM Cloud, in the AWS Cloud, the Azure Cloud. So you can deploy your APIs there. Now, typically, you would develop your API on your development machine. So you’re going to develop the API there, but then you can have it deployed and running wherever it is you want it to run. Now, you could remotely access a development box in AWS, or Azure, or IBM, and then develop it there if you wanted to. So it’s kind of up to you, but you can have those API servers running wherever you want them to run. Fantastic. Thank you so much, Dan. That was the last question, unless we have any more. We’ll input in the Q&A box. I don’t see any coming through.
So thank you so much for everyone joining us today. It was a great presentation, Dan. Thank you. We will, again, send you a recording of this webinar to your email address that you gave us. If you have any questions, please do let us know. I appreciate it. Have a great day. Thanks, Dan. Anything else from you? Nope. Just thank you, everybody, for attending. And if you have additional questions, please feel free to send it to me. My email address is just firstname.lastname@example.org. And thanks for coming.