Create Virtual Applications

CloudAware Virtual Applications may be created to distinguish:

• Department, Team, Site, Project within your enterprise

• Customers, if you're an MSP

• Purchasers, if you're a reseller, etc

Creating an application also makes sense in such cases when, for example, 1) there are AWS, Azure and Physical servers in your Cloudaware environment and you need to provide access to view AWS data only, or 2) only 1 AWS instance should be available for the application user, etc. Note that the sooner you create the virtual application, the better since billing and cost data is not retrospective - it may be collected and shown in the app only starting the day when the application was created.

Key Features

• Multi-cloud and non-cloud support

• Cascades give you ability to attach object hierarchies by attaching single object

• Inventory automation using auto-attachment rules

• Ability to attach objects that are not taggable or exceed the tag limit.

Prerequisites

Think of the assets that should be attached to the virtual application you will be working on. You may create a list view showing running AWS instances, for example. Consider the logic that can be used for attaching assets in question to different tiers of the virtual application.

Application Creation

1.  Log in to your Cloudaware account. Locate the section CLOUDAWARE in Navigator → Applications. 

2. Click New CloudAware Application.

3. Give the virtual application a proper name. Click Create. If everything is fine, you will see a success message. 

4. Click Go To Application Settings to create tiers.

5. Click Add Tier(1). Give the tier a meaningful name(2). Click Add Tier(3) to save.

6. Locate the resources in question on a list view, e.g. Running Instances. Check the boxes and click Attach To The Application.

7. You will be offered to select the appropriate application and a tier. Review the objects that will be attached and click Attach.

You can continue OR if it is preferable, you can detach them clicking Detach Objects.

Cascades

Consistency is one of the main challenges you face when you try to be organized. Once of the best practices is to follow relationships between objects and use these relationships to get consistent and auto-updatable inventory.

Cloudaware virtual applications support cascades. This means that once a resource is attached to the application, all related objects will be cascadingly attached as well. For example, once you attach an AWS EC2 Instance, all related EBS Volumes or Network Interfaces will also be attached.

1. When choosing what object to attach, check if there is another object above it that can cascadingly attach it. For example, it's better to attach an ELB than its instances, it's better to attach a Beanstalk Application than a Beanstalk Environment and it’s always better to attach URLs.

1. Try to minimize manual attachments. When you manually attach something, there is a logic for choosing an objects behind it. It's much better to implement that logic in an auto-attachment process, because Cloudaware will keep track of new objects that comply with your logic. If you need to attach something by hand, try to attach only truly static resources.

Auto-Attachment Processes

Cascades are good but they only work for big services with lots of interconnected objects. What would you do with all objects that have no relationships with each other? The answer is to implement the process that will monitor your assets and automatically validate them against defined rules and choose the application accordingly. These are auto-attachment rules.

Cloudaware application auto-attachment rules are are based on Salesforce Workflow Rule functionality. A workflow rule is like an IF/THEN statement. IF part of the statement is called criteria, THEN part of the statement is called actions. The simplest of workflows will check for a specific values on an object and then update the 'Application Tier Client Name' field on it with a specific value. The value should be set to the applications tier's name.

Note that 'Application Tier Client Name' consists of 2 parts: Application name and Application Tier name for example: AWS - Production (see the example below).

Application Attachment Workflow:

1. From your Cloudaware account open a main menu under your username.

2. Go to Setup → Workflow & Approvals → Workflow Rules → New Rule.

3. Select the object to which this workflow rule applies. e.g. AWS EC2 Instance. Click Next.

4. Add Rule Name (1), set Evaluation Criteria(2) and Rule Criteria(3) to trigger your workflow rule. Add Filter Logic if necessary.

Click Save & Next.

4. Add Workflow Action → New Field Update.

5. Give this workflow acton a name. Select AWS EC2 Instance: Application Tier Client Name as a field to update.

6. Select a radio button Use a formula to set the new value. Enter the formula "Application Name" & " - " & "Application Tier Name". Click Save.

7. Review the workflow rule details. Click Done.

6. Click Activate to activate your workflow.

Attachment Logic Examples

• if Name starts with prod set Tier Name to "The Application - The Tier"

• if tag:Customer equals CustomerA set Tier Name to "The Customer App - The Tier"

• if tag:Application is not empty and tag:Tier is not empty set Tier Name to tag:Application+" - "+tag:Tier

You can create even more complicated auto-attachment rules combining workflow rules with formula fields or even updating them via API from external system. Almost any complicated object classification logic is possible using workflows and formulas.

Object Re-attachment After Application Tier Client Name Change

If Application Tier Client Name is changed, objects will be re-attached in 1 hour. However, there may be a delay in jobs if a customer didn't log in for some time.