Cross-Functional Architecture And Tools For Cloud-Based Operating Models
After you have run the “acm appliance on” and “acm appliance off” commands for the example applications, you can experiment and dig deeper.
In the normal day to day situations when a process breaks, you have access to the complete logs, segregated by step, inside the workflow that the Agile Cloud Manager creates for your uniquely modeled systems and appliances, so that you can immediately navigate to whatever needs to be adjusted in order to get the automation running again.
If the automation breaks anywhere in the process of running the above commands, follow the instructions given in the articles about how to use logging in the Agile Cloud Manager.
After you have successfully run the “appliance on” and “appliance off” sequences given above, you can expiriment with the other CLI commands, which are described at this link. In order to use the other, more granular, CLI commands, you will need to examine the configuration files from the repositories given in the value passed into the “sourceRepo” flag of the “acm setup on <flags>” commands given above. You can find these configuration files in the “acmConfig” directory, which will be created locally when you run the “acm setup on <flags>” command. You can learn the Domain Specific Language DSL at this link and you can learn the Command Line Interface CLI at this other link . As you develop confidence, you can progress to reading about how the DSL and CLI fit into Low Level Design .
Finally, make sure that everything has been destroyed in the Azure Portal and in the AWS Console before you finish with the demos.
If used properly, the Agile Cloud Manager will clean up every resource after commands are run so that you will not have orphaned resources in the cloud. But like any tool, the Agile Cloud Manager must be used properly in order to function properly.
One example is that if an “on” workflow breaks in the middle of its process for reasons caused by the underlying cloud provider or due to your variable inputs, you need to figure out which of the CLI commands must be run in order to destroy the things that were created before the workflow broke. Or you need to re-run the entire “on” command until every step in the workflow works as intended.
Another example is if you destroy the terraform backend while resources managed by that terraform backend still exist in the cloud.
The Agile Cloud Manager greatly simplifies the management of complex systems and greatly reduces the amount of code required in pipelines.
Leveraging the greatly simplified interface offered by the Agile Cloud Manager requires that you learn how to navigate through the very understandable logs, and that you learn how to select and use the various CLI commands available to perform surgery on your systems.
Pipeline design later on can embed all the CLI commands into governable operations you can utilize to control how all the different types of surgeries can be performed on your systems.
But for now, on the very first day of running the demos, if all else fails, you can manually delete any orphaned resources in the AWS Console or in the Azure Portal if time constraints prevent you from learning the Agile Cloud Manager’s CLI interface and object model well enough in order to be able to use the CLI to do any necessary cleanups if, for example, an Azure region is having an outage, or if you chose an illegal value for one of the variables in config.yaml.
To delete Azure resources from these demos, simply delete any remaining Azure Resource Groups that were created by the demos. You can do this in the Azure Portal Web GUI.
To delete AWS resources from these demos, simply delete any remaining CloudFormation stacks that were created by these demos. You can do this in the AWS Console Web GUI.