Feature Showcase

Getaway - A Complete Picture

Now that Getaway is up and running with three back-end services running redundantly in both GCP and Azure, you will walk through a few scenarios that demonstrate how the service interconnection fabric reacts to changing infrastructure conditions.

Fig. 77 Getaway Application

As you can see from Fig. 78, weather-gw, places-gw, and news-gw are each running on a workload node in a VPC called gcp1 and another VPC called azr1: the former represents Google Cloud and the latter represents Azure.

Remember, you can find your service graph by clicking on Domains in the sidebar navigation menu and then clicking on Show Graph for getaway-app.

Fig. 78 Getaway Service Graph

Going back to your Resource Graph panel (choose this from sidebar navigation menu), you should note once again how your three VPCs are interconnected via three SIF processor nodes, one in each VPC.

Fig. 79 Getaway Resource Graph

Rising Infrastructure Cost

If the cost to service your clients from one VPC becomes too expensive, you might want to switch to a different VPC. In this section you’ll simulate what happens if the cost of getting to Azure rises.

To start, notice in Fig. 80 that all backend data is currently coming from Azure. You can see the azr1- names in the upper-right corner of each microservice panel.

Fig. 80 Services From Azure

Back on the Resource Graph page in the orchestrator, click on the link between aws2-p01-protof and azr1-p01-protof i.e., the link that connects the AWS VPC to the Azure VPC. As shown in Fig. 81, you can see that the cost is set to 1.

Fig. 81 Resource Graph - Link Cost

In the overlay panel in the upper-right corner of the Resource Graph page, click on the hyperlink to the azr1- node. You should see a figure similar to Fig. 82. Under the Links section at the bottom of the page, find the row associated with aws2-p01-protof (remembering that the suffix on your node name will differ) and click on the settings icon (the gear) as shown in Fig. 82.

Fig. 82 Link Configuration

Change the cost to 10, as shown in Fig. 83.

Fig. 83 Cost 10

Return to your application open in another browser window. You’ll see that all Getaway back-end services are now coming from GCP rather than Azure because the cost of getting to Azure became too expensive.

Fig. 84 Services From GCP

Revoking Authorization

Recall that you used tokens to authorize your microservices to operate on each workload node. Let’s see what happens when you become uneasy about the security of one of your nodes and you want to de-authorize it from operating in your application.

Back in the orchestrator GUI, click on Services in the sidebar navigation menu. Then click on weather-gw.

Fig. 85 Services

Scrolling down slightly, you should see two entries under the Tokens section. (Recall that the weather-gw microservice is deployed in both Azure and GCP and that each uses a distinct token.) This should look similar to Fig. 86.

Fig. 86 weather-gw Service

Inspect each token by clicking on the hyperlinks under # of SEs as shown in Fig. 87. Note which token has been utilized in Azure and which has been utilized in GCP.

Fig. 87 Tokens

After you have finished inspecting the tokens, delete the token used to authorize the endpoint in GCP by clicking on the red x on the right as shown in Fig. 88.

Fig. 88 Delete Token

Return to your application running in your browser and refresh the window. Since you de-authorized weather-gw in GCP, it is now being serviced by Azure. (Recall that the upper right corner of each microservice window in the application indicates the node supplying the data.)

Fig. 89 Weather Service From Azure

Failing Workload

Now let’s see what happens when you’ve received one of those familiar emails from your public cloud service provider that explains that one of your VMs has become unreachable because of an underlying problem with the hardware. How does your application respond?

Bring up the Resource Graph page in the orchestrator GUI and note that all the circles are green.

Fig. 90 Resource Graph - Everything’s Green

Now, some typing. Return to your terminal window with the SSH connection to your fabric manager. Ensure you are in the ~ubuntu home directory by typing cd

]$ cd

To simulate a node failure, you will stop the policy agent running on gcp1-w02-protof. Type the following at your Linux prompt, ensuring you use your own fabric name, which is the suffix to all the node names displayed in the Resource Graph page:

]$ bwctl stop workload gcp1-w02-protof

After a little chugging, you should see a message similar to

Workloads [`gcp1-w02-protof1] stopped successfully

Return to the orchestrator Resource Graph page where you should see that one of the workload nodes has turned red, as shown in Fig. 91.

Fig. 91 gcp1-w02 Stopped

Back in the Getaway application running in your browser, note that places-gw is now serviced from Azure because the corresponding node in GCP went off-line.

Fig. 92 Places Service From Azure

Selecting Target

Let’s recap where we are at with Getaway. Recall that you started with all back-end microservice data coming from Azure, but after you bumped up the cost of the link between aws2 and azr1, all data started coming from gcp1.

You then revoked the token authorizing weather-gw in gcp1 so weather data started coming from azr1.

Then you simulated node failure by stopping the policy agent running places-gw in gcp1 so places data started coming from azr1.

With only news-gw supplying data from gcp1, suppose the application developer decides he or she wants to prioritize all data coming from Azure without regard to the cost. To do this, the client microservice calls a URL with a more specific FQDN.

Right now, the getaway-service microservice uses

http://responder.news-api.getaway-app.ib.loc:8080/

You will run a script that changes this to

http://azr1.responder.news-api.getaway-app.ib.loc:8080/

The more-specific URL tells the DNS resolver to give priority to servers running in Azure when they act as responders in the news-api contract.

Back in your terminal window on the fabric manager, ensure you are in the ~ubuntu home directory by typing

]$ cd

Now go back into the Ansible application directory by typing

]$ cd application

Your command-line prompt should now look similar to

ubuntu@jsmith-c0:~/application$

Execute the playbook that adds the azr1 prefix to the URL for news-api on aws2-w02-protof (the VM that runs the getaway-service microservice) by typing

]$ ansible-playbook update-app.yml

After the playbook completes, refresh Getaway in your browser. You should see that News is now running in azr1 as show in Fig. 93.

Fig. 93 News Service From Azure

Summary

If you find your service graph again by clicking on Domains and then Show Graph for getaway-app and then enable the Show Service Endpoints box in the upper-left corner, you’ll see how the picture has changed. weather-gw and places-gw have a single service endpoint each: the GCP endpoints are gone and only the Azure endpoints remain. The news-gw service, however, still has two endpoints since Azure was simply given user preference over GCP, rather than revoking authorization or shutting down the node as in the other cases.

Fig. 94 Service Graph Endpoints