Application Policy

Requirements

Your application service graph defines the required communicative relationships between the application microservices. The service graph for Getaway is shown in Fig. 69.

Fig. 69 Getaway Application Service Graph

Service Interconnection Fabric allows the application developer to set policy based on the relationships between the nodes in the service graph. To do this, Bayware introduces two new concepts: services and contracts.

Service Graph

Nodes & Edges

The nodes in the service graph map to SIF services. Edges between nodes in the service graph map to SIF contracts. One service may communicate with another service only through a contract. The contract defines the policy that allows the services to communicate.

Contracts in the Service Interconnection Fabric

A contract, which defines policy that allows one service to communicate with another service, may be used by more than two services within a service graph. It may describe, for instance, policy for point-to-multipoint communication and not simply point-to-point communcation. A contract is essentially a waypoint on the path between services that describes the policy that allows those services to communicate.

A contract has pre-defined roles: you can think of these as being an endpoint of an edge eminating from the contract waypoint. In its simplest form, a role might be client or server. So the policy inherently embedded within the contract might allow, simply, that the client can initiate communication with the server, but not the other way around.

Services in the Service Interconnection Fabric

A developer’s application microservice maps to an SIF service (the node in the application’s service graph). When creating an SIF service on the orchestrator, the developer may assign a role from a contract to the service. This assignment defines how the service may communicate.

The developer permits a service in a container or on a VM to communicate with other services by creating a service token on the SIF orchestrator and then installing that service token directly on the VM or via a container orchestration platform such as Kubernetes. That token authenticates the service and authorizes the communication defined by the contract role assigned to that service.

Essentially, defining the policy for your application, then, only requires you to define the service graph: the microservices (SIF services) and how they communicate (SIF contracts).

Fabric Manager Tool: bwctl-api

In Application Infrastructure you were introduced to the bwctl command-line tool that allows you to interact with public cloud providers to create virtual private clouds and virtual machines. In this section, you will use another fabric manager command-line tool, bwctl-api, that allows you to interact directly with the SFI orchestrator. Actions that can be performed by clicking around on the GUI can also be performed by scripting them through bwctl-api.

First, you will use bwctl-api to generate Getaway’s service graph (contracts and services) and, second, you will use bwctl-api to generate service tokens that authorize Getaway’s microservices to operate on the SIF infrastructure.

Generating the Service Graph

Before we begin, let’s confirm that there are, indeed, no contracts and services pre-installed on the orchestrator. Back on the orchestrator GUI open in your browser, click on the Services button in the sidebar navigation menu. It should look similar to Fig. 70.

Fig. 70 No Services Installed

You may click on the Contracts button in the sidebar navigation menu to confirm that there are no contracts, as well.

Just as you used a YAML description of infrastructure components with bwctl in the last section, here you will use a YAML description of Getaway’s service graph with bwctl-api.

Back in the terminal window that has an SSH session open on your FM node, take a look at the service graph’s YAML description located in the ~ubuntu home directory. Recall that you can do this using Linux cat command

]$ cat getaway-app.yml

As you navigate through the text (scrolling up, if required), notice that the YAML spells out requirements for generating a domain (getaway-app), four contracts (frontend, weather-api, places-api, and news-api), and five services (http-proxy, getaway-svc, weather-gw, places-gw, and news-gw). If you look carefully, you’ll see that contracts and services are defined within a given domain and that services are assigned a particular role within a contract. In fact, the getaway-svc service, given its place in Getaway’s service graph, takes on four contract roles.

Now back at the Linux prompt, execute the batch file by typing

]$ bwctl-api create batch getaway-app.yml

This should complete pretty quickly. Once it does, return to the orchestrator GUI in your browser and reload it. You can do this in most web browsers by clicking the reload button in the address bar or by typing ⌘+R on a Mac keyboard or CTRL+F5 on a Windows keyboard.

If your orchestrator browser window is still showing the Services or Contracts page, it should now be populated.

With services and contracts populated, you can now see the service graph. In the navigation menu, click on Domains under Admin. You should now see a domain called getaway-app. Click it.

On the Domain page for getaway-app, click the View Graph button at the bottom. Voilà! There is the service graph for Getaway with all its contracts and services depicted (see Fig. 71).

Fig. 71 Getaway Service Graph on the Orchestrator

Generating the Service Tokens

Getting back to a (somewhat) more physical world, although the policy is now in place to allow the microservices to communicate (http-proxy can request data from getaway-svc; getaway-svc can request data from the three back-end services, weather-gw, places-gw, and news-gw), they have not yet been authorized to communicate within a workload i.e., a container or a virtual machine.

That’s where tokens come in. For a service in a given domain, you can ask the orchestrator to generate a token that can be used to authorize the service to operate. Once you have the token, you, as the devOps engineer, can use it in whichever workload you choose. You will see this in the next section, Application Microservices, when you install the tokens. For now, you simply generate the tokens.

As with all things related to the orchestrator, you could generate service tokens using the orchestrator GUI or using the bwctl-api tool. Here you will use the latter.

A YAML file in the ~ubuntu home directory describes the service token request. You can explore it by using cat

]$ cat getaway-tokens.yml

Notice that the YAML description requests multiple tokens for the three back-end services, weather-gw, places-gw, and news-gw. Each of these services runs both in GCP and in Azure. By creating a unique token for each running service instance, you can control authorization independently in each cloud. This will come in handy later on when you delete a token for news-gw in one cloud and see that the same microservice operating in the other cloud automatically takes over.

Now execute the command to get the tokens from the orchestrator. Here you will redirect Linux stdout to a file where the tokens will be saved.

]$ bwctl-api create batch getaway-tokens.yml > tokens.yml

This should be quick. Once it has completed, use cat to explore the file containing the service tokens returned by the orchestrator

]$ cat tokens.yml

The orchestrator has returned a YAML sequence of eight tokens, each associated with a particular service within a given domain in a given cloud, as prescribed by the requesting YAML file. You will use these in the next section to create service endpoints that get Getaway’s microservices up and running and communicating with each other.

Summary

In this section you learned about the relationship between an application’s service graph and SIF services and contracts to inject policy between microservices. Services map to service graph nodes; contracts map to service graph edges. You created the service graph for Getaway and then asked the orchestrator to generate tokens that you will use in the next section to create service endpoints. All this was done using your fabric manager’s command-line tool, bwctl-api, that allows orchestrator GUI operations to be scripted through its API.

Next up: You will install service tokens that authorize Getaway’s microservices to operate over the service interconnection fabric.