PG needed to build the car balancing model as soon as possible to be able to do a demo to investors who were impatiently waiting to see a real world example. John and Megan had picked Megan’s car for the demo which was a Tesla X. Therefore, the first IT assets Rose decided to build were a set of PaaS IoT services that could be used to collect data from the wireless sensors attached to the Tesla.
At this stage of the development since there is no infrastructure is involved, one can easily go on the cloud portal and provision the required resources with several clicks but our goal it to build ITAC from the ground up which means that we are going to do everything based on the golden standard we have defined: everything as code. The only exception to the golden rule is setting up the subscription itself that has to be done manually. For BizSpark specifically, the person who applied for it, receives an email with instructions to set the subscription and once done she becomes the global admin. The rest of the employees are added as regular users as needed.
Megan went ahead and set up the subscription and became the global admin. She then did the following:
- Registered PG’s own domain, pseudogravity.io she already bought from GoDaddy.com
- Added herself as firstname.lastname@example.org and made her both the global admin and the subscription owner.
- Added John as email@example.com as a user.
Having the users set in Azure. She began building the ITAC for the PG. She did it by creating a free account in VSTS called pseudogravity.vistualstudio.com. Since she was the global admin of the Azure subscription, the VSTS account was automatically connected to the Azure subscription.
She then added the first project to the VSTS account which she called ITAC which would continue to hold the entire definition of PG’s IT in the years to come.
Under ITAC she built a repository called Org to contain the highest level of assets belonging to CTO. Also to control access to this repo she added the following groups and added her and the only user to all groups.
- OrgOwner: Have full access to all resources within the organization.
- OrgDEV: Can update the ARM templates.
- OrgQA: Can approve a release to QA and co-approve a release to Prod.
VSTS looked like below so far:
Next step is to set up the release pipeline which normally includes three environments DEV, QA, and Prod. Whenever the ARM templates are updated, a DEV release is automatically triggered. Deploying to QA requires approval from OrgQA to make sure they are ready to test and deploying to Prod requires approval from both OrgQA and OrgOwner – which at this point means Megan would do all of these by role playing across all.
Once Megan finished the above task, she began to actually add the ARM templates for the IoT hub which collected the data from sensors. Megan did some reverse engineering here. She went to the Azure portal first and configured an Azure IoT hub in the portal and then copied and pasted the generated template and parameters json files into a new cloud ARM project she added in Visual Studio. She decided to follow the following conventions to organize ARM projects and release definitions.
- The solution name is called Org.
- Each resource group will have a corresponding project in Org. For example all the resources built for collecting and processing balancing data from sensors will be inside a project called balancingData.
- There will be a separate release task for each resource group.
- If a resource group contains multiple resources, each resource will be added in a separate template file. A master template is created that is used in the release task and references the other resources via a URL to their VSTS repo location. (To be tested once she added more resources since at this point she only has a single resource, the IoT hub).
The figure below shows what Megan had achieved so far:
Megan felt very content that she had built the first piece of what was going to be extended to define their entire IT soon. But before she would want to go to John to break the great news she thought of adding three more things:
- Thinking about extensibility of what she had accomplished for Org to the new departments they would add to their organization in the future, she decided to do some research around how to automate building all the necessary pieces for new projects including provisioning the repository, adding all the necessary groups, and the release pipeline since all needed to follow the same pattern as Org did.
- She thought or creating a web portal that provided a hierarchical view of their entire organization. What she had in mind was a org-chart tree where she could start at the top, the org, and drill down into other departments and sub departments and view their allocated resources and the associated groups which basically presented their ITAC. She wanted to build this by extracting metadata from both Azure and VSTS.
- In order to have single point of management, she thought of creating a dashboard per department in Azure that provided resource consumption costs, status (working, alerts or potential failures), and the manager of that specific department.