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.
As you can see from Fig. 78,
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
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.
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
names in the upper-right corner of each microservice panel.
Back on the Resource Graph page in the orchestrator, click on the link
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.
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
(remembering that the suffix on your node name will differ) and click on the
settings icon (the gear) as shown in Fig. 82.
Change the cost to 10, as shown in Fig. 83.
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.
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.
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
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.
Back in the Getaway application running in your browser, note
places-gw is now serviced from Azure because the corresponding
node in GCP went off-line.
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
azr1, all data started
You then revoked the token authorizing
weather data started coming from
Then you simulated node failure by stopping the policy agent running
gcp1 so places data started coming from
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
You will run a script that changes this to
The more-specific URL tells the DNS resolver to give priority to servers
running in Azure when they act as responders in the
Back in your terminal window on the fabric manager, ensure you are
~ubuntu home directory by typing
Now go back into the Ansible application directory by typing
]$ cd application
Your command-line prompt should now look similar to
Execute the playbook that adds the
azr1 prefix to the URL for
aws2-w02-protof (the VM that runs the getaway-service microservice) by
]$ 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.
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.
places-gw have a single
service endpoint each: the GCP endpoints are gone and only the Azure endpoints
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.