APIs, Microservices, and Containers

Learn more about APIs, Microservices, and Containers

Jennifer from GT Software:

Hey, everyone. This is Jennifer from GT Software and I wanted to share this clip with you a clip where we ask Don Spoerke—what are the differences between APIs, microservices and containers?

Don Spoerke from GT Software: 

Thank you, Jennifer.

The textbook definition of an API or application programming interface is a set of clearly defined methods of communication between various components. What we’re talking about is having things talk to each other. Well, how do you make that happen when each interaction could have different dimensions and parameters? The best that you could hope for is perhaps to standardize it.

Now, some APIs can be very low level, even down to the operating system. Things like allocating storage or opening a socket or checking permissions may be common functions, but the APIs that I have the most experience with are the higher-level, functional APIs ranging from getting the current temperature from the Weather Channel to tracking a package with one of the many delivery services or getting customer data from a CICS application.

The important thing to remember is, is they typically are presented in a standard way like an HTTP interface to a specific endpoint. Now since the ’60s we used point-to-point APIs to connect things, but they’re expensive to create and maintain and were highly specific to what you’re connecting. Now, we attempted to correct the problems with the first generation APIs by trying to make them more reusable, but unfortunately they were only reusable for limited purposes and were still highly dependent on the resources in the organization to maintain.

But with the introduction of SOA, notably SOAP, XML, and now REST, a whole new era in application integration opened up. Finally, we had a common standard and interface for connecting applications. It wasn’t long after the introduction of SOA and SOAP that GT software got into the mainframe API game. We realized very early on that having the mainframe be a full participant in the API evolution would provide countless benefits to our customers and prospects. Today, driven by the Internet of Things and the need to expose more information at a faster pace, APIs have become the new gold standard for application exposure and integration.

Microservices are a specialization of an implementation approach for service-oriented architecture used to build flexible, independent, deployable software systems. They’re really the first realization of SOA and are becoming more popular for building continuously deployed systems; in other words, a variant of SOA that constructs an application as a collection of loosely coupled services. In a microservice architecture, services are fine-grained, and the protocols are lightweight, perhaps something like atomic services and REST.

Let’s look at some of the characteristics of microservices to get a better understanding. First, it’s a design architecture that separates parts of an application. If we think about a banking system, that might mean splitting the deposit of a check, the clearing of a check, and checking the balance of your checking account into separate pieces of business logic. These microservices have the characteristics of a functional program, so not only are you getting to the end point, but the microservice may also have some logic associated with it. Because the focus is to distance ourselves from monolithic applications, the microservice has a well-defined scope and does only one thing.

Remember, we can think of these microservices as building blocks for building another application. So, checking an account balance would be a proper scope of functionality for a microservice, and because they’re fine-grained, some say we’ve finally done SOA right. But to add to the confusion, microservices are as much an architectural style as an implementation. What that means is, that besides the logic of the microservice, it may have its own database or file system, even its own operating environment.

APIs expose functions of an application as more readily accessible service interfaces. Microservices are a means to deploy an API. Microservices rely on APIs as the means to communicate with each other internally. Microservices provide more flexibility in developing an application, but a collection of APIs makes the creation of microservices easier. It may be clearer if they were just called “micro-components” instead of microservices because the bottom line is there is a time and place for both in an organization.

So, what about containers? I think one of the best definitions I’ve seen for containers comes from Amazon. Containers provide a standard way to package your application’s code, configuration, and dependencies into a single object. Containers share an operating system installed on the server and run as an isolated process, ensuring quick, reliable, consistent deployments regardless of your environment. In this context, what we’re talking about is that no container can directly access or affect another container. The challenge with this approach is that multiple servers would need to be configured to run multiple microservices, which causes a great negative effect on each other, or perhaps results in increased overhead. So, to offset these negative effects, each microservice is implemented as a set of containers managed by cluster software like Kubernetes.

So, it circles all back to APIs. In its most basic form, every microservice exposes an API.

To view the full webinar: Modern Application Development and the Mainframe