How to manage feature flags in ASP.NET Core apps with Azure?
No matter how simple or complex an application is, choosing the right configuration provider right at the start will mak...
Today I will demonstrate how you can approach resource consistency. We’ll see how your governance model and mechanisms can directly support the business outcomes of your organization.
This post has originally been published on Jun 06, 2019. It has since been updated for better readability.
Last time we focused on risk control and cost management as some of the aspects of the governance model. Just as a reminder: in our process, we need to focus on the following five key areas:
This time, I will describe a case study showing how you can take care of the two latter aspects – resource consistency and deployment. You’ll see how we do it at Predica for our internal and project resources. I will also demonstrate how we approach business requirements, from defining the goal to deployment.
Your IT structure and cloud model can directly support your business goals
Actually, it probably is like that at the moment. But you need to think about it and deliberately apply it. Again, let’s start with a scenario.
In our cloud, we host internal resources like applications, databases, data warehouses, and dashboards. We are a data-driven organization, and we put a lot of effort into our operational infrastructure and applications.
As in many such cases, it consists of a lot of moving parts. To name just one simple example – our time management system comprises:
As you can imagine, keeping up with all these inconsistent resources might be a bit of a challenge. Also, we have new business requirements coming in all the time, which require changes to our environment.
Development and deployment of changes are the two elements which are always hard to manage at any organization. For us, it’s no different.
There is one key element you need to address to make sure you won’t suffer from deployment burnouts, and that you won’t have to fight resource fires in Azure – deployment automation!
In our case, internal IT operations (which formed along the way within the organization) use Azure ARM templates and Azure DevOps to manage resources and deployments.
Azure DevOps is our primary tool for gathering user stories based on business requirements, managing our team’s backlog, keeping our code base, and deploying our resources. We came a long way from using on-prem VSTS to Azure DevOps with automated deployment pipelines. We also migrated all code repositories to Git in the meantime.
Let’s track how we define our business requirements, map them to work items in Azure DevOps, and finally develop and deploy them through automated pipelines to cloud resources.
We use the OKR methodology to manage our organization’s objectives. I talked about it in one of our vlog episodes which you can check out below.
How to work with the Objectives and Key Results system?
Every quarter, we set Objectives for each department. Then we add Key Results, and consequently a way to measure our goals – and that’s how we get OKRs. All actions taken within Predica Practices and other departments are aligned with them.
Why is it important? Because IT doesn’t exist next to the business, it is not a service provider for industry; it works together with the rest of the organization to deliver the objectives.
It means that even our development and resource management must be aligned with business goals.
In our case, OKRs are defined in 7Geese (the app we use to manage our objectives) and are public and visible to everyone. Here is an example of how one such OKR is defined (its ID is 369516, we will get back to it and explain why this is important).
Objectives (OKRs) defined at the company level are translated into Epics and Features in Azure DevOps. For each OKR which requires some work to be done in our environment, our IT department aligns the backlog respectively.
We have an Epic in Azure DevOps where we manage our work related to OKRs. It is done very quickly with tags. A Feature in Azure DevOps is tagged with the ID of the OKR to which it refers. Now we are getting back to our OKR with ID 369516, which translates to this Feature: “Each Project runs according to Predica Methodology.”
Our IT department breaks it down to a Feature at the User Story level, which translates into development and deployments in our environment. Each User Story is tagged with its relevant business and technology area.
Here you can see that this particular Feature breaks down to several tasks, where one of them is related to the development of our timesheet Tabular model.
We have another Feature, also derived from our OKRs, which is a requirement for our internal tools to be managed through a CI/CD pipeline. There you also have a User Story for our Tabular.
If you go back to our first article in the series, you will know that all our actions should be driven by business objectives and goals set by the organization.
This is what we achieve with our OKR approach and translating business goals into Azure DevOps items.
Our business objective is to have all our projects ran according to our methodology. It posits using CI/CD tools for resource deployment to avoid manual implementation and resource inconsistency.
Note: to address the need for resource consistency across all your Azure deployments, you can use the following tools:
We use those tools, and primarily Azure DevOps, to make sure that our resources are deployed in an efficient and consistent way, to meet our business objective.
Simple but powerful!
To make it practical, let’s get back to our OKR related to the Tabular model. The model is built on Azure stack. It serves as our main data source for our analytical tools and self-service Power BI dashboards. Additionally, it combines several data sources, including our timesheets and financial data.
According to our framework, we don’t want to risk that anything goes sideways during deployment, or that someone will change it manually.
Thus, based on the business objectives set above, we have translated our OKR directly to an Azure DevOps task and configuration of our deployment pipeline for the Tabular model.
Here is a high-level diagram of our deployment model for this particular piece of our operations.
As you can see, we maintain a full flow through Dev and Test environments with the build and final deployment into the production environment.
All of it is done in an automated way to comply with our cloud governance model in terms of automation and resource consistency.
From the Azure DevOps perspective, our business stakeholders can monitor the current status of these deployments with dashboards and reports.
Overall, the project status for our internal IT operations looks like this:
And here are the particular build and deployment pipelines for specific resources:
As you can see, cloud governance sets directions and rules for how we operate our cloud environment. It is fully aligned with our business goals, as we derive our rules from business policies and objectives set at the company level.
This doesn’t mean that it’s just a static document with lots of theory and guidelines. Rather, it is a real-life implementation with practical usage, where your objectives and rules set the direction on where to head with technology and how to apply it.
Based on this approach, we can implement different solutions and tools. In our case, we bet on Azure DevOps as a standard way of doing things, although it’s not the only purpose we use it for. You can read more about it in another series, starting with this article.
Read similar articles