Forem: Yemisi Oyesainu

Team Process Customization with Azure Boards

Yemisi Oyesainu — Tue, 02 Jan 2024 17:08:25 +0000

As part of my various blogs on Agile Planning and Portfolio management, I would like to delve into customizing Team process with Azure Boards here.
In Azure DevOps, there are two types of processes. One is read only while the other is inherited processes. The Read only processes are core system processes which can not be customized. They are Scrum, Agile and CMMI. Inherited processes are created based on core system processes but they can be customized. Several team projects can reference a single customized process such that any updates or changes made to such process will also be updated on all the team projects that referenced the process. Both new and existing projects can reference a newly created inherited process.

The following steps will demonstrate how to create an inherited process from Scrum (a core system process) and customize it.

(1)Log in to Azure DevOps and click on the Azure DevOps logo. This will lead to the account root page.
Click on Organization settings

(2)On the Organization settings menu, under Boards, click on Process.
On All processes pane, by the right side of Scrum, click on the ellipsis, and from the ellipsis dropdown menu, select Create inherited process

Under the Process name (required) textbox, type Customized Scrum and click on Create process

(3)On the All processes pane, click on Customized Scrum entry

Select Product Backlog Item

Next, on the Product Backlog Item pane, select New Field

A panel for Add a field to Product Backlog Item will come up. Under Definition, in the Name textbox for Create a field, type EShop Ticket ID

Click Layout on the Add a field to Product Backlog Item panel, in the Label textbox, type Ticket ID,
on the Group textbox, type EShopOnWeb,
then click Add field

(4)Return back to the All processes pane, and select Scrum

The current project, EShopOnWeb, is using Scrum but now we want to change the project process to Customized Scrum.
On the Scrum pane, select the Projects tab and on the row having EShopOnWeb, click on the ellipsis and select Change process from the dropdown

In the Select a target process dropdown menu on the Change the project process pane, select Customized Scrum and click on Save as shown in the image below

.
Then click Close when the change is complete

(5)Return back to the account root page by clicking on the Azure DevOps logo and select the EShopOnWeb project

On the page that come up, on the left side vertical pane, under Boards select Work items and click on the first backlog item

There it is! The Ticket ID that we defined earlier

Hope this is helpful and easy to understand. Please give your feedbacks in the comment section below.

How to Customize Kanban Boards using Azure Boards

Yemisi Oyesainu — Tue, 02 Jan 2024 16:50:39 +0000

Generally, Kanban Board is a visual tool used for project management and optimizing workflows. It is usually designed in a way that teams are able to visualize their tasks, limit work in progress, and maximize efficiency. Kanban board is an effective tool in agile methodologies. Azure boards can be used to customize Kanban board to match the way a Software development team plan to work to ensure a successful delivery.

Basically, Kanban boards consist of the following components:

(a) Visual signals: At a glance, members of the team can assess the workflow and ascertain what has been done, any adjustment to be made, and next steps to be taken.

(b) Columns: Each column on the board represents a stage in the workflow such as To Do, In Progress, and Done. These are arranged from left to right to show how the work is progressing.

(c) Cards: These are used to represent work items on the board. They contain details about the tasks such as its status, priority and others.

(d) Limiting Work In Progress: This is an essential principle in using Kanban board. Number of tasks allowed in each column should be limited to avoid overloading so that the work can flow smoothly.

In this blog we will have a glimpse of how to customize Kanban board with Azure boards. This article is a continuation of the concepts I demonstrated in an article, Using Azure Boards to manage Sprints and Capacity

Come on, let's set out!

Step 1
Log in to Azure DevOps portal, in the list of Boards items, select Boards. On the Boards tab, click on the cogwheel icon for Configure board setting

Step 2
On the Settings panel, select the Tag color tab, then click on +Tag color
In the Tag textbox, type data and leave the default color in place. In this case the color is yellow.

Step 3
Next on the Settings panel of the Configure board settings, select the Annotations tab

As you can see here, the Annotation is enabled. This will make the child work items of that type easily accessible by clicking the visualization on each card.

Step 4
Select the Tests tab on the Settings panel. This will enable you to configure how tests appear and behave on the card
Now, click on Save and close to save the Styling rule.

Step 5
On the Board tab of the EShop-Web panel, open the work item representing the As a customer, I want to view new tutorials backlog item.

At the top of the panel, by the right side of the 0 comments entry, click Add tag and in the textbox type data and press the enter key
Click the Add tag again and enter ux in the textbox and press the enter key
Then, click on Save and close

The two tags data and ux are now showing on the card with data having color yellow as specified in Step 2 above

Step 6
Back on the Boards panel, click on the Configure Board setting cogwheel icon by the right side of the funnel icon
Select the Columns tab, click + Column
Under the Column name label, in the Name textbox, type QA Approved
In the WIP limit textbox, type 1. The figure 1 here signifies that its only one work item that should be in this stage at any point in time.

Step 7
On the Settings panel, click on the Column tab again. In front of QA Approved created earlier, there is an ellipsis, click on it and hold your cursor on it to move it twice to the right so that it will now be in the middle of Committed and Done. Then click Save and close

To make the QA Approved column visible on the Kanban board view, refresh the Boards portal

Step 8
Drag the work item, As a customer, I want to see tutorials I recently viewed from the Committed stage to the QA Approved stage

Drag the work item, As a customer, I want to view new tutorials from the Approved stage to the QA Approved stage

There is a signal on the panel showing figure 2 in red indicating that this stage has exceeded its limit. So we have to move the item, As a customer, I want to see tutorials I recently viewed
back to the Committed stage

Step 9
Go back to the Boards panel and click on the Configure board settings cogwheel icon by the right side of the funnel icon
On the Settings panel, select the Columns tab and go to the QA Approved tab. Here, we want to turn on split column. This will address the issue of when work gets moved into a column and when it actually starts. It will show the actual status of work in progress.

Scroll down to the bottom of the QA Approved panel, you will see the Definition of done textbox, type Passes all tests. This is a qualification that will apply to any work that is actually done.
On the Settings panel, click Save and close

As seen in the image below, the split consists of two columns, Doing and Done.

Also, the image below shows how the Definition of done appears on the Board panel

Step 10
Adding Swimlanes to your Kanban board enables you to visualize the status of work that supports different service-level classes.
Click on the Configure boards settings cogwheel icon and on the Settings panel, select the Swimlanes tab
Next, click on + Swimlane
In the Name textbox under the Swimlane Name label, type Expedite.
Now click Save and close

Step 11
Go back to the Board tab of the Boards panel, drag the work item on Committed stage and drop it on QA Approved|Doing stage of the Expedite Swimlane. This will make the work item have priority when the QA bandwidth becomes available

That is it! We have customized a Kanban Board. If you find this helpful kindly drop your feedback in the Comments section

Using Azure Boards to Manage Sprints and Capacity

Yemisi Oyesainu — Tue, 02 Jan 2024 16:23:35 +0000

What are Sprints?

Literally speaking, Sprint means the duration or time spent running as fast as one could to cover a short distance either in a race or probably when one is in a hurry to catch up with a train or bus. Today, Software developers are typically sprinting to stay ahead of the rapid demand of the Tech industry. This calls for proper and efficient planning and this is where Agile methodologies such as managing Sprints and Capacity comes in.

Explaining what Sprints means in Agile planning can not be done in isolation of an idea of what Scrum is. Developers use Scrum as a framework for tackling complex tasks (projects) by breaking them into smaller bits that can be completed in increments. These 'smaller bits' are Sprints which are fixed length duration of about four(4) weeks (or less sometimes) having specific start and end dates. This duration is consistently maintained throughout the development process and a new Sprint start immediately the preceding one has been successfully completed. The number of Sprints in a software development project depends basically on how complex the project is. During a Sprint, the development team work on planned specific task which is known as User Story.

User stories describe the definite requirements of the development project. It captures the functionality, who the end user is, and what value or benefit the user derives from that functionality of the software. They are essential part of Product backlog taking into considerations the inputs from the Scrum team and other stakeholders. They are used to estimate the efforts required for the development process because they eventually become the basis for the task that the team will work on during the Sprint. Also, during Sprints, the team works on creating new features based on the User stories.
The Scrum team is made up of the Scrum master, the Product owner and the Developers. It is the responsibility of the Scrum master to make sure that the Scrum team is effective in discharging their responsibilities while the Product owner manages the product backlog and ensure that it is easily understood.

What is Capacity?
Capacity refers to the quantity of work that a development team can perform within a given timeframe during a Sprint. This usually depends on the past ability of the team, availability of the team members, their skillsets and unexpected bugs. Having a good knowledge of the teams' capabilities will enable them and the Product owner to choose the User stories it can reasonably accomplish from the Product backlog.

Managing Sprints and Capacity is an integral part of Agile planning and Portfolio management. This is the responsibility of the Scrum team. A Sprint usually has a cycle. A Sprint cycle consists of the following steps: sprint planning, daily scrum, sprint review, and sprint retrospective .
At Sprint Planning meeting, the stakeholders and the development team determines the goals of the Sprint by defining the tasks to be worked on during the iteration.
At the beginning of each day during the Sprint, the Scrum master have a Daily Scrum, which is a stand-up meeting with all the team members in respect of their activities and progress so far.
Sprint review session is an exhibition of the work accomplished during the entire Sprint to the stakeholders and other team members. This review will afford them the opportunity to make any necessary corrections before Production.
Sprint retrospective happens at the end of each Sprints when developers exchange ideas and learn from any mistake made in order to fashion out ways to address such in the next Sprint.

In a few quick steps, I will demonstrate how this will be done using Azure Boards. Lets go! (Note that this blog is a follow up to my article on Managing Work items with Azure Boards

Step 1
Log in to the Azure DevOps portal and on the vertical navigation pane, click on Boards and select Sprints

Step 2
On the Taskboard tab, in the toolbar, select the View options symbol by the left side of the funnel icon.
From the dropdown menu, select the Work details entry and select Sprint 2 as filter.

In the image above, Sprint 2 has two tasks in the To do stage and none of these have been assigned. The numbers 5 and 3 showing in front of Unassigned represent the estimated quantity of work remaining to be done.

Step 3
On the To Do Column, I will click on the Unassigned entry in front of the Task Item Add page for most recent tutorials, and from the list of user accounts, I will select my account to assign the task to myself.

Step 4
Next, I will select the Capacity tab
And on the Capacity tab view, click on + Add user and select my user account. Set the Activity field to Development and, in the textbox of Capacity per day , type 1.

Lets see how to set time for vacation. Vacations are added to Capacity view.
Next to the entry representing my user account ( this will be your user account when you are taking this Lab), is the Day off column, click on the 0 entry. This will bring up the space to set days off.

For this Lab, I will set my vacation to 4 days off using the calendar and click OK

Go back to the Capacity tab and click Save

Step 5
On the Sprint view, select Taskboard tab again

A basic advantage of the Boards is the opportunity to easily make useful updates to crucial data. It is advisable to make a routine revision of the Remaining Work estimate to align with the anticipated time for each task. For example, after checking the work involved in Add page for most recent tutorials task, you may discover that the time required is more than initially expected.

Step 6
In the square box representing the Add page for most recent tutorials on the Taskboard tab, to match the total capacity of hours for this Sprint, set the total number of hours to 14

The image above shows that the Development and your personal capacities is automatically expanded from 5hours(previously) to 14hours and 'colour bars' remains green for both of them i.e Development capacity and your capacity. However, the overall Team capacity is exceeded because of the extra 3hours required for Optimize data query for most recent tutorials task, the number of hours is now 17. That's why the 'colour bar' for the Team turned red

Note that there are two basic ways to resolve this kind of capacity issues:

(i) move the task to future iteration by opening the task here and
edit it within the panel providing access to the task details.
(ii) move the task to future iteration by going through the Backlog view which provides an in-line menu option to move it.

But as for this Lab we are not moving the task yet

Step 7
Select the View option icon by the left side of the funnel icon. From the dropdown menu, select the Assigned To= entry.

The view shown in the image above will enable you to view the progress of tasks by person instead of by backlog item.

Step 8
Next, click the Configure team settings cogwheel icon by the right side of the funnel icon.
Select the Styles tab, then click + Styling rule
Under the Rule Name label, in the Name textbox, type Development
In the Card color dropdown menu select the green rectangle

Any card that meets the rule criteria that will be set in Step 9 below will be set to green.

Step 9
To set the rule criteria, go to the Rule criteria section, under Field dropdown menu, select Activity,
in the Operator dropdown menu, select =,
in the Value dropdown menu, select Development.

In the next three steps, we will navigate other parts of the Team Settings panel.

Step 10
On the Settings panel, select the Backlog tab. In the image below you can see that Epic is not selected by default but you can decide to change this

Step 11
On the Settings panel, select the Working days tab. Here, you can specify the working days that the team will follow. This also applies to the calculations of capacities and burndown

Step 12
On the Settings panel, select the Working with bugs tab. In this view, you have the options of specifying how you want the bugs to appear on the Boards

Now to save the Styling rule, click on Save and close

This blog has explained and demonstrated what Sprints and capacity are and how they are managed with Azure Boards.

Hope you find this interesting to follow through. Try it out yourself and don't forget to let us know how you feel about the article in the comment section below.

Managing Work items with Azure Boards

Yemisi Oyesainu — Tue, 02 Jan 2024 15:44:39 +0000

For agile planning and portfolio management, Azure Boards is an effective tool to manage work items.

What are work items in Software development project? They are used to track the features and requirements of your project, code bugs and risks that may be associated with the project. As demonstrated in my article on Agile Planning and Portfolio management, while creating the project, EShopOnWeb, Scrum was selected as the Work item process. This will determine the work item types available on which each work item will be based. In this blog, I will demonstrate how to manage work item available for tracking information under the Scrum process. However, there are other options of work item process that you can select from. These are Agile process, Basic process and CMMI process. Work items plays an essential role in accomplishing the overall project because work items are individual tasks that made up the entire project. They can be used to describe work to be done, impediments to be released, test definitions or other key items.

Let's get to work now! There is a pre-requisite for this Lab on managing work items, that we will do first. That is, a preconfigured Parts Unlimited team project. (NB: It is a requirement for some Azure DevOps Lab).

Configuring Parts Unlimited Teams Project

Step 1
We will use Azure DevOps Demo Generator to automate the
creation of a new Azure DevOps project within my account that
is prepopulated with content like work items, repos etc. To do
this, I will open this link on my browser
https://azuredevopsdemogenerator.azurewebsites.net/ and sign in
using the Microsoft account associated with my Azure DevOps
subscription

Step 2
I will accept the permission request for accessing my subscription.

Step 3
Click on the dropdown on the right side of Select organisation to select on your Azure DevOps organisation and type Parts Unlimited as the name of the project.

Step 4
Click on Choose Template as shown in the image above. Select Parts Unlimited. Next, click on Select Template

Step 5
Click on Create Project

Yeah! We are ready to move on to the main Lab to demonstrate how to manage work items with Azure Boards

Managing Work items
To demonstrate this, we will use work items to set up the plan to extend the Parts Unlimited site, project created above, with a product training section.

Step 1
Log in to your Azure DevOps portal and on the vertical navigational pane, click on Boards and select Work items.
Next, click on + New Work Item and select Epic

Step 2
In the Title box, type Product Training and click on Unassigned entry and from the dropdown menu select your user account to assign the new work item to yourself.

Step 3
By the side of Area entry, Click on EShopOnWeb entry as shown in the image below

From the dropdown menu, select EShop-Web. The Area will be set to EShopOnWeb\EShop-Web.

Step 4

By the side of Iteration entry, Click on EShopOnWeb entry

From the dropdown menu, select Sprint 2. The Iteration will be set to EShopOnWeb\Sprint 2. Then click on Save but do not close the page

Step 5
In the Related work section, click on + Add link. Then select New item from the dropdown menu.

Now, click on the Link type and from the dropdown list, select Child; next on the dropdown list of Work item type select Feature; in the Title textbox, type Training Dashboard and click OK

Step 6
On the New Feature Training Dashboard, click on Save and Close

Step 7
On the Azure DevOps navigation pane in the Boards menu, click on Boards, then EShop-Web boards as shown below

In the upper right corner of the page, click on Backlog items and from the dropdown menu select Features

Step 8
Hover the cursor on the rectangle representing the Training Dashboard feature. This will reveal the ellipsis symbol (...) in its upper right corner, click on it and from the dropdown menu, select Add Product Backlog item

Step 9
In the textbox of the new product backlog item, type As a customer, I want to view tutorials and press the Enter key to save the entry. This will create a new product backlog item (PBI) Work item that is a child of the feature and shares its area and iteration

Repeat the same step to add these two product backlog items:
As a customer, I want to see tutorials I recently viewed
As a customer, I want to request new tutorials

Step 10
In the upper right corner of the Boards panel, select the Features entry and from the dropdown menu, select Backlog items

Step 11
On the Board tab of the EShop-WEB panel, I will drag the first work item: As a customer, I want to view new tutorials from the New stage and drop it under the Approved stage

Step 12
On the rectangle representing the first work item that I moved to the Approved stage, I will hover the cursor to reveal a down facing caret symbol and click on it to expand the work item card. Then click on Unassigned and assign the PBI to myself.

Step 13
I will drag the second work item, As a customer, I want to see tutorials I recently viewed from the New stage and drop it on the Committed stage.
I will drag the third work item, As a customer, I want to request new tutorials from the New stage and drop it on the Done stage.

Step 14
On the Board tab of the EShop-WEB pane, at the top of the pane, click on Backlog to display the tabular form.

Step 15
Still on the Backlog tab of the EShop-WEB pane, in the upper left corner of the pane, click the second plus sign from the top, the one next to the first work item. This will display the NEW TASK panel.
In the Enter title textbox, type Add page for most recent tutorials.
In the Remaining Work textbox, type 5
In the Activity dropdown menu, select Development
Then click on Save & Close

Step 16
We will repeat Step 15 above to add another task.
Click on the plus sign from the top
On the NEW TASK panel, in the Enter Title textbox type Optimize data query for most recent tutorials
In the Remaining Work textbox, type 3
In the Activity dropdown menu, select Design
Then click on Save & Close

Waoh! In this task we have been able to have a walkthrough on how to manage work items with a popular agile tool, Azure Boards. Simple, not so?

Tell us what you feel about this piece in the comment section below

Azure Boards: An effective tool for Agile Planning and Portfolio Management

Yemisi Oyesainu — Tue, 02 Jan 2024 15:27:37 +0000

For some years now, Agile project management have come to stay as an effective way of planning and collaborating on different types of projects. Particularly of interest is its application to Software Development life cycle. It has helped teams to streamline and plan their activities in such a way that achieving best results is not as tedious as what it used to be. One of the popular tools used extensively by Developers is Azure Boards. It has helped in effortlessly navigating the complexities of project planning with ease. But before we dive much into Azure Boards and demonstrate how it can be used, lets briefly explain what Agile Planning and Portfolio Management means.

What is Agile Planning?

It is a style for Project management used for Software development projects. It is an incremental iterative approach that is very flexible and makes continuous improvement for software applications possible. Most times these improvements are necessitated by Customer's or User's feedbacks.

With agile planning, Software engineers are able to understand and estimate the time it will take to perform each task and complete the entire project. The team will break down the entire project activities into different 'portions' known as Sprints. Processes created from Sprints usually becomes repeatable processes that can be used throughout an application or product life cycle.

What is Portfolio Management?
Creating a Portfolio in the management of software projects is a usual norm as this sets out project-related activities, responsibilities and tasks. Therefore, a portfolio is a selection of projects grouped together to be centrally managed and controlled in accordance with the organization's set goals and objectives. This allows for strategically planning project execution with agile principles. The risks and returns on investment of each projects are considered and this will help the members of the Project Portfolio Management(PPM) to make effective decisions.

As mentioned at the outset, this blog will deal with one of the tools used by Software developers for Agile planning and Portfolio management - Azure Boards.

Azure Boards
Azure Boards is a web-based service provided by Microsoft to plan, track and collaborate on software development process. It supports agile planning and methodologies like Scrum and Kanban. It is a platform that can be customized for the management of work items and effective team collaborations. The hubs on Azure Board include Work items, Boards, Backlogs, Sprints, Queries, Delivery Plans and Analytics views. (For more on Azure Boards click here).
This blog and four other blogs to follow on my page will demonstrate (with well-annotated images) to use Azure Boards in the following ways to perform some agile planning and portfolio management tasks:

Manage teams, areas, and iterations
Manage work items
Manage Sprints and Capacity
Customize Kanban Boards
Customize Team process

Managing Teams, Areas and Iterations with Azure Boards
For this lab and the other four stated above which will be covered in subsequent articles, you will need to set up an Azure DevOps Organization. To do this, take the following simple steps

i. Log in to your account on Azure portal

ii. Search for Azure DevOps Organization on the Search bar and click on it

iii. Next, you will have this page. Then click on My Azure DevOps Organization

iv. Input your details and click on Continue

v. Click on Create new Organization and then Continue

Yes!! We are ready to take the first step in this lab on how to manage teams, areas nd iterations

Step 1 -Create and configure team project.
We will create a new Azure DevOps project with a repository based on the eShopOnWeb. Lets have a walkthrough
(a) Open your Azure DevOps Organization on a browser (Please be sure you are using a browser that supports Azure DevOps such as Microsoft Edge)
Click on New Project

(b) We will give this project the name eShopOnWeb and select the Visibility option to be Private

(c) Click on Advanced and select Scrum under Work Item Process.Git is already the default Version Control. Now Click on Create

We are now ready for the main task of this Lab

Step 2 - Create a new team and configure its area and iterations
(a) Ensure that your Browser displays your Azure DevOps organization with the eShopOnWeb project generated in Step 1(c) showing like this :https://dev.azure.com/youraccontname/eShopOnWeb

(b) Click on Project settings and select Teams under the General section

(c) Next, click on New Team. However, there is a default team, EShopOnWeb Team, already for this project but we need to create a new one

(d) Name the new team EShop-Web, leave other settings at default and click on Create

(e) On the list of teams, Click on the newly created EShop-Web team to have a view of its details

(f) To define the schedule and scope of the team, click on Iterations and Area Paths link at the top of the EShop-Web page.

(g) On the Boards pane, click on Iterations and then at the bottom of the page on the left hand side, click on + Select iteration(s)

(h) On the window that comes up for Iterations, select EShopOnWeb/Sprint 1 and click on Save and Close

(i) To set the dates for the Sprint 1, select Sprint 1 and click on the ellipsis (...) that is in front of Sprint 1 on the Iterations' page. On the dropdown menu, click on Edit

(j) I will state three(3) full work weeks for each Sprint. In this Lab, the first Sprint starts from 18th December 2023 and ends on 5th January 2024

(k) Repeat Steps 2(g) to 2(j) to add Sprint 2 and Sprint 3.

Note that the first day of Sprint 2 is the next working day after the end of Sprint 1. Sprint 1 ends on Friday 5th January 2024 and Sprint 2 starts on Monday 8th January 2024. Each of Sprint 2 and Sprint 3 also lasts for 3 working weeks.

(l) Now we will configure the Area path. On the Project Settings / Boards / Team Configuration pane, click on Areas. You will notice that there is a default area named after the team name

(m) Click on the ellipsis by the left side of default area as shown in the image below. From the dropdown menu select Include sub areas

Please note that by default, all teams is set to exclude sub-area paths. With that, the team will not be able to view work items from sub areas but only the work items associated with their specific area path. However, if the Management team decide to change the default setting and include the sub areas as we did in this Lab, for example, the EShopOnWeb team will gain visibility into all work items from all sub areas under its hierarchy.

As noted above, my subsequent blogpost will address managing work items, sprints and capacity, customizing Kanban Boards, and customizing team process.

I hope you find this blog helpful. Kindly drop your feedbacks in the comments section.

Ensuring Resilience: Safeguarding Azure Key Vault and Storages from Disasters

Yemisi Oyesainu — Wed, 02 Aug 2023 18:55:03 +0000

Planning for disaster recovery is an essential norm in cloud environment. It cannot be taken lightly because of its importance in guaranteeing high availability and integrity of services and applications deployed in the cloud. This is fundamental to continuity of any business entity. Disaster Recovery (DR) is organization's resilience in promptly recovering access and functionality of its infrastructure after a disruptive event, which may be as a result of natural disaster or resulting from human actions or errors.

Come on and let's explore some best practices for disaster recovery on Key Vault and Storage accounts. For a clearer and concise discussion we will look into these as it applies in Microsoft Azure Architecture. It is believed that the basic knowledge of a Cloud Service Provider (CSP) Infrastructure can assist in understanding the same scenario in other CSPs’ infrastructure.

First, we will highlight what the objectives of Disaster recovery are in cloud environment, an overview of what key vault and storages are as cloud solutions and what are the potential risk that can impact on the high availability of key vault and storages, and will be presented. And more importantly, we will look into steps for designing a DR plan for the two solutions and how this applies to them individually.

Objectives of Disaster Recovery
A Disaster recovery plan aims at accomplishing the followings:

To ensure business continuity: With DR, organisations will be able to minimize the impact of a disaster on business operations and ensure that critical functions can continue or resume as quickly as possible after a disaster.
To minimize downtime: The downtime that immediately follows a disruption will be minimize or non-existent depending on the effectiveness of the Disaster recovery plan. This limits financial losses and at the same time customers’ confidence level is maintained.
To restore data: Essential data and applications will be recovered and restored to their functional state after a disaster to resume normal operations.
To preserve data integrity: The integrity and accuracy of recovered data will be maintained to avoid potential errors or inconsistencies that could impact business processes.
To identify and mitigate risks: Potential risks and vulnerabilities will be assessed to enhance preparedness and reduce the likelihood of future disasters or minimize their impact.
To protect assets and resources: Hardware, software, equipment, and facilities, will be protected from excessive damage or loss during a disaster.
To ensure compliance to Regulatory requirements: Disaster recovery plans seek to adhere to laws relating to data privacy, security, and business continuity.
To enhance organizational resilience: Planning for an effective disaster recovery promotes a culture of resilience within the organization, whereby members are encouraged to be adaptable and flexible to face unforeseen challenges.

Key Vault
Key Vault is a cloud service for securely storing and accessing secrets. These secrets include API keys, passwords, certificates, or cryptographic keys. Access to these are securely controlled by the Key vault. A detailed documentation on how to implement key vault in azure can be accessed on my earlier blogpost. Considering that these secrets kept in the Vault are very sensitive, a good disaster recovery plan for this service is very crucial.

Storages
Storages plays a vital role in any Cloud or on premise Infrastructure. Deployed resources needed to be kept in a secured manner that will make accessibility possible when needed. In cloud computing, Storage is the capability of storing and managing data, files, and other resources in storage services provided by a cloud service provider. Cloud storage allows users and organizations to access, upload, download, and modify their data without the need for managing a physical infrastructure.

In Azure, Storage services offers high availability, scalability, durability, and security for a variety of data objects in the cloud and this can be accessed globally. Types of Storage services in Azure include Azure Blob Storage, Azure Files, and Azure Queue Storage, Azure Table and Azure Managed Disk. The user-interface tools for interacting with Azure Storage is the Azure portal and Azure Storage Explorer. A descriptive article on how to create a Storage account with Blob Storage Container can be found in my earlier blog Creating a Storage Account with Azure Blob Storage Container

Potential Risks on Key Vault and Storages
Risks and threats that Key Vault and storage systems may encounter are enumerated below:

Natural disaster – On this list are fire outbreak, hurricanes, flood, earthquakes, tsunami, tornado, wildfire etc.
Cyber attacks
Human errors: Here, let’s talk about each of the resources one at a time

(a) Risk of human error on key Vault

(i) Unauthorized Access to sensitive keys, secrets, and
certificates may occur if proper access controls and
permissions are not set up
(ii) Compromising the encryption keys when they are not
adequately protected. This may lead to the exposure of
encrypted data.
(iii) Malicious or negligent actions by authorized users with
access to the Key Vault could lead to data breaches or
misuse of sensitive information.
(iv) Not rotating the encryption keys regularly can increase
the risk of prolonged exposure of sensitive data
(v) Insecure management of secrets, such as passwords or API
keys
(vi) When key vault is not designed with redundancy or backup
mechanisms it can become a single point of failure for
applications

(b) Risk of human error on Storages

(i) Misconfiguring Publicly Accessible Containers/Blobs can give way to unauthorized access to sensitive data
(ii) Weak access controls and authentication mechanisms for Storages
(iii) Accidental deletion or corruption of data without proper backups can lead to irreversible data loss.
(iv) Users with access to storage accounts might intentionally or unintentionally compromise data security.
(v) Failure to use encryption for data at rest or in transit increases the risk of data exposure if the storage resources are compromised.
(vi) If SAS (Share Access Signatures) tokens are not securely managed and expire too late, attackers might abuse them to gain unauthorized access to storage resources.
(vii) Misconfiguration of Cross-Origin Resource Sharing (CORS) might lead to unauthorized cross-origin requests, potentially exposing sensitive data.

Designing a Disaster Recovery (DR) Plan for Key Vault and Storage

In designing a DR plan, the following has to be considered:
a) Assessing the risks by identifying and evaluating this potential impact
b) Essential metrics such as the Recovery Point Objective (RPO) and Recovery Time Objective (RTO) has to be defined
c) Choose the disaster recovery strategy

Implementing Disaster Recovery for Azure Key Vault

The two main ways of implementing DR plans for Key Vault are
(i) Backup and Restore
(ii) Multi region Replication

(i) Backup and Restore
Presently, Azure Key Vault (AKV) doesn't provide a way to back up an entire key vault in a single operation but the contents of the key vault can be backed up individually. Azure Key Vault has multiple layers of redundancy which ensures that keys and secrets remain available to your application.

When there is disaster, Key Vault maintains availability by automatically failing over requests to a paired region without any intervention from a user. This is because the keys and the secrets together with other contents in the key vault are replicated within the region and to a secondary region at least 150 miles away. But the replication must be within the same geography to maintain high durability of Key Vault contents. If individual keys, secrets or certificates in the Key vault fails, alternate components within the region automatically take over the request to make sure that there's no downtime.
However, note that exception to paired regions is single region geo like Brazil South, Qatar Central. In single region geo, Zone Redundant Storage (ZRS) is used to replicate data three times within the single location/region.

If an entire region becomes unavailable (which is very rare), what happens? Requests are automatically directed (failed over) to a secondary region. When the primary region is available again, requests are routed back to the primary region. Again, this does not apply in single region geo.

To restore backed up contents of a Key Vault, it can only be restored in the same geography due to cryptographic boundary. For example, East US and West US belong to the same geography - United States. The regions can be different, but they need to belong to the same geography and the same Subscription.

You can configure soft-delete and purge protection features on your key vault to protect your secrets against accidental or malicious deletion of your secrets. This allows recovery of the deleted vaults and deleted contents of the key vault known as soft-delete. It is important to note that Key Vault does not support the ability to backup more than 500 past versions of a key, secret, or certificate object.

(ii) Multi region replication
Azure Key Vault is a multi-tenant service that uses a pool of Hardware Security Modules (HSMs).Multi region replication is the extension of a managed HSM pool from primary region to secondary region that enhances the availability of critical cryptographic keys if one region become unavailable. After configurations, both regions are active, and replication takes place automatically. The closest available region to the application receives and fulfills the request, thereby maximizing read throughput and latency. The picture below explains how this works.

When multi-region replication is enabled on a managed HSM in the primary region, a second managed HSM pool, with three load-balanced HSM partitions, is created in the secondary region. When requests are issued to the Traffic Manager global DNS endpoint the closest available region receives and fulfills the request. For the list of Azure regions where you can replicate HSM pool from as the primary region, click on this link.

Implementing Disaster Recovery for Azure Storages

Storage account is used to manage the services that comprise Azure Storage. Storage accounts is used to deploy storage resources such as blob containers, file shares, tables, and queues. To plan disaster recovery for Azure storage, the Cloud concept of Redundancy comes into play.
Redundancy is the process of duplicating copies of data, systems and other resources so that if there is any disruptive events or actions, you have immediate and secure access to backed-up copies. In Azure Storage Redundancy, redundancy setting for Storage accounts are broadly divided into two categories:

(i) Redundancy in the Primary region
(ii) Redundancy in the Secondary Region

Redundancy in the Primary Region
Storage resources in a Storage account is usually replicated three times in the primary region. For the purpose of Disaster Recovery plan within a zone, Zone Redundancy Storage (ZRS) is recommended.

Primary Region
ZRS

The diagram above depicts how Zone Redundancy Storage is structure in three availability zones.

Zone-redundant storage (ZRS) have the features listed below:
(a) It copies data synchronously across three Azure availability zones in the primary region.
(b) It offers durability for storage resources of at least 99.9999999999% (12 9's) over a given year.
(c) If a zone becomes unavailable you can still access the data for both read and write operations
(d) ZRS in the primary region is recommended for
(i) Scenarios that require high availability.
(ii) Restricting replication of data to a particular country or
region to meet data governance requirements.
(iii) Azure Files workloads.
(e) It provides excellent performance, low latency, and resiliency for your data if it becomes temporarily unavailable within a zone.
f) ZRS is supported for Standard storage accounts, Premium block blob accounts and Premium file share accounts

Point (e) above shows that Zone Redundant Storage is only effective for any disruptive event that occur within a zone. For regional disaster recovery, Geo Zone Redundant Storage (GZRS) is recommended. GZRS make use of ZRS in the primary region and geo-replicates data to a secondary region.

Redundancy in a Secondary Region
Replicating data to a secondary region is ideal to achieve high availability and durability especially in a scenario of a complete regional outage or a disaster in which the primary region irrecoverable. There are two options for copying your data to a secondary region:
(a)Geo Redundant Storage (GRS)

The picture above shows how data is replicated from a Primary region to a Secondary region. The features of GRS are stated below
i. It copies data synchronously three times within a single physical location in the primary region using LRS, and then copy it asynchronously to a single physical location in a secondary region

ii. Data written to the secondary location is also replicated within that location using LRS.
iii. Primary region and secondary region are usually hundreds of miles away apart
iv. It offers durability for storage resources of at least 99.99999999999999% over a given year

(b) Geo-Zone-Redundant Storage(GZRS)

The picture depicts geo replication in Geo Zone Redundant Storage.
How does it work?
i. It combines the high availability provided by redundancy across availability zones with protection from regional outages provided by geo-replication.
ii. In a GZRS storage account, data is copied across three availability zones in the primary region
iii. Data is also replicated to a secondary geographic region for protection from regional disasters.
iv. For Storage solutions, it is used to achieve maximum consistency, durability, availability, excellent performance, and resilience for disaster recovery.
v. It provide at least 99.99999999999999% durability of objects over a given year.
vi. It is only Standard General-purpose v2 storage accounts that support GZRS
vii. Enabling read access to the secondary region will make data to be always available to be read from the endpoint as well as from the primary endpoint

Testing and Monitoring Disaster Recovery procedures
Testing

Backup Testing: Conducting regular tests for the backup and restore process is important to ensure that data can be successfully restored from the GZRS storage. To do this, a test environment can be created where data can be restored to verifying its integrity after a disruptive event
Failover Testing: Test the failover process to a secondary region to simulate a disaster scenario. Ensure that the application can continue to function seamlessly using the data from the secondary region in the event of a disaster
Testing Data Consistency: In a multi-region setup, you need to ensure that the data in both regions is consistent. Regularly test data consistency checks to ensure there are no discrepancies between the data in the primary and secondary regions.
Load Testing: Conduct load testing after failover to ensure that the secondary region can handle the increased traffic and workload.

Monitoring

Monitor data replication continuously between the primary and secondary regions. Azure Monitor can be used to track the status of GZRS replication and get alerts if any issues arise.
Set up health probes and heartbeats to check the availability and responsiveness of your application and storage services in both regions.
Implement Application Performance Monitoring (APM) tools to monitor the application's performance during normal operation and after failover.
Configure alerts to notify relevant members of Disaster recovery team in case of a disaster recovery event. These alerts can be set up to trigger when specific conditions are met, such as data unavailability or replication delays.
Use automation scripts to regularly test the disaster recovery procedures and monitor the infrastructure's health. This can help identify issues before they degenerate.
Conduct regular incident response drills to test how your team responds to disaster recovery scenarios

Steps for Creating a Disaster Recovery Team

Select members who are experts in cloud security, storage technologies, key management, and disaster recovery. This should staff from IT, security, operations, and any other relevant departments.
All team members must have a comprehensive knowledge of the key vault and storage services provided by your cloud provider to ensure effective disaster recovery planning.
Conduct a thorough risk assessment specific to key vaults and storage services. Identify potential threats, vulnerabilities, and risks that could impact the availability or security of your data.
Define your recovery objectives using the metrics: Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for key vaults and storage.
Develop Disaster Recovery Plan outlining step-by-step procedures for data backup, replications, recovery, and restoration as described above.
Establish clear communication and coordination channels among the DR team members and with other relevant stakeholders. Each member must have full documentation of their roles and responsibilities during and after a disaster
Training on key vault and storage services' disaster recovery features and best practices together with awareness of any updates thereof should not be neglected

Conclusion
It is very important to pay attention to disaster recovery procedures on key vault and storages because these two services are very crucial and fundamental in cloud environment. This article has discussed extensively overview of key vault and storages and potential risks that may interfere with their availability.

How to implement disaster recovery procedures such as backup and restore, together with multiregion replication were explained. Testing and monitoring Disaster recovery plan basically by the disaster recovery team was also highlighted.

In all, regularly reviewing and updating the disaster recovery plan as your cloud environment and business needs evolve will ensure high availability and resilience of key vault and storages as well as other cloud resources.

Trust this is useful. Please let us have your feedbacks

Disaster Recovery on Kubernetes and Container Registry

Yemisi Oyesainu — Fri, 28 Jul 2023 16:51:52 +0000

Disaster Recovery (DR)
Disaster recovery is an integral cloud benefit. It is an essential advantage of adopting cloud architectures for business solutions. It is the ability to recover data, applications and IT infrastructures after a disaster or a disruptive occurrence. This occurrence may be natural or man-made. They include flood, hurricanes, earthquakes, hardware failures, cyber-attacks, non-compliance with best practices etc. Disaster recovery in cloud environment is accomplished with various tools, services and architectural builds which ensures resiliency and high availability.
Strategies employed for disaster recovery in on-premise environment differs greatly from what obtains in containerized environment. Granted, this is costlier than DR in containerized environment because backups for systems and data has to be kept safe in a physical data center (usually offsite). Investments in the maintenance and physically securing such infrastructure can be mind-blowing.

Kubernetes and Container Registry
Before diving into disaster recovery as it relates to Kubernetes and Containers Registry, let’s have a brief overview of what Kubernetes and Container Registry are.
First, Containers are lightweight packages that house the application code together with dependencies and configuration for specific application. Containers make deployment of application to any compute environment easy such that when there is higher demand for your application, it is not difficult to scale out to meet those demands by deploying additional container instances. This is depicted in the picture below

Container image is an executable code that can create a container on a computing system. It includes everything that a container needs to run. It is a snapshot of a specific application or service along with its dependencies and configurations. These images are stored and managed in Container Registry.
Container Registry is a storage location where developers can push and pull container images and share them with their teams or the broader community. There are three main types of Container Registry:
(i) Docker Hub - this is a public registry that make over 100,000 off-the-shelf images shared by software vendors, open source projects, and Docker’s community of users, accessible
(ii) Self-hosted Registries- this is managed by individual organisation when they prefer to host their container images on their own on-premises infrastructure
(iii) Third party Registry Services – these are Container Registry services provided by Cloud Service Providers. They are fully managed offerings that also give you control over how you manage your images but with no operational cost for infrastructure. These include Amazon Elastic Container Registry, Azure Container Registry and Google Container Registry.
These registries help in the containerization workflow. Containerization workflow is orchestrated such that it is easy for developers and operations teams to work with large-scale container deployments. A popular platform very useful here is Kubernetes.
Kubernetes is an open source platform for Container Orchestration. It is portable and extensible for automating deployment, scaling and management of containerized workload. It eliminates the complexity associated with management of containers. Containers are usually complex to manage because critical applications run in such environment. This necessitate the importance of having a very good and standard plan for disaster recovery in containerized environment. One that conforms to the best practices in the Industry.

Disaster Recovery on Kubernetes and Container Registry
As explained above, in today’s technology world, Kubernetes and Container Registry play a crucial role in application development and deployment workflows. Therefore, having a robust disaster recovery plan for these components is essential for the following reasons
(i) To maintain business continuity: When a disaster or any disruptive event occur, it affects the smooth running of business operations, slowing it down or stopping abruptly. But having disaster recovery plan in place will ensure business continuity
(ii) To improve system security: Disaster recovery plans limit security risks. This is because most cloud based DR solutions have built-in security features that can detect and block cyber attacks
(iii) To reduce cost of recovery: Business operations returns to normal state as early as possible after a disruption if there is an effective recovery plan. Thus, resulting in minimized loss due to the disaster
(iv) To ensure customer retention: Customers always watch out for the capabilities of an organisation to recover after a disaster. This often affect their decision to continue their business relationship with the organisation. Imagine what can happen to a commercial bank that its Data centre was destroyed by fire and was unable to render the least of its services, like checking of account balance, for about a week after the fire outbreak.

Disaster recovery on Kubernetes and Container registry refers to the strategies and practices employed to ensure the availability, resilience, and recovery of containerized applications and container images in case of disruptive events or perils.
Planning for these will basically be in three phases:
(i) Identifying the potential risks on Kubernetes and Container Registry
(ii) Preserving the applications and images before the occurrence of any disaster i.e. backup plans
(iii) Recovering the applications and images after a disaster or disruptive event i.e. recovery plans

What are the Potential Risks?
These risks can be grouped into two:
1.Risks due to natural disasters
Natural disasters are acts of nature caused by the natural forces of the Earth where great damage and, sometimes, loss of life occurs. These include earthquakes, flood, hurricanes, volcanic eruptions, landslides, wildfires etc. These can cause an outright or partial destruction of data centres and other cloud infrastructures leading to disruption in availability of cloud applications and services.

2.Risks due to man made errors of system malfunctions. These are discussed below

a.Security vulnerabilities: Cyber attackers can gain unauthorized access to containerized applications if they are not regularly updated and patched. When deploying and managing Kubernetes components in-house, the Kubernetes API server and its components as open source tools have potential risk because both external and internal users connect to it. Also, RBAC is the Kubernetes-native method of managing and controlling authorization to Kubernetes resources. In the event of a security breach, attackers can quickly get high-level access to the clusters using the cluster admin role.
b.Vulnerable container images: Container images that are not scanned for vulnerabilities before deployment are detrimental to the cluster where they run. Images from untrusted source can have critical vulnerabilities like remote code execution.
c.Security risk of Kubernetes secrets: Kubernetes secrets are useful for securing sensitive data like passwords, certificates, or tokens and using them inside containers but they may not secure the cluster data against malicious cyber attacks. This is because they are not encrypted by default. Another massive threat to secrets is that any pod and any applications running inside the pod in the same namespace can access and read them. In addition to this, any old or unused secrets can create confusion and let out vulnerable data.
d.Runtime threats: Containers are controlled by the host operating system in the runtime and these run on Worker nodes. If there are permissive policies or container images with vulnerabilities, they can permit unauthorized access into the whole cluster and this will be destructive.
e.Risk through network access: Network policies are used to manage and restrict the network access between pods, namespaces, and IP blocks. They also work with the labels on the pods. But when these labels are not used efficiently, it can lead to unauthorized access.
f.Partial monitoring and audit logging: Monitoring only the application metrics when an application is deployed to a Kubernetes cluster can predispose the whole system to unhealthy anomalies
g.Unrestricted pods and namespaces: This can give way to unwanted access to sensitive data inside your cluster.
h.Cluster and Resource misconfiguration: When online examples for Kubernetes resources are not edited using "kubectl edit" commands during configuration, the changes will be overwritten in the next deployment and you will not be able to track the modifications thus leading to unpredictable outcomes

Major Elements of Disaster Recovery on Kubernetes and Container images in the Container Registry
1.Backup and Restore
This is the process of making duplicate copies of critical data to be able to restore them when needed.

As seen in the image above, data are backed up and stored in an offsite location. This may be on physical secondary location or in private or public cloud.
Backup objectives has to be defined through metrics like the Recovery Point Objective (RPO) and Recovery Time Objective (RTO) to ensure that data is protected and minimize interruption in case of a data loss event. The RPO is the frequency at which backups are made while the RTO indicates the time it takes to restore data from backup. Organisation should strive to achieve the lowest metric in both the RPO and the RTO for the following reasons:
a)The smaller the RPO, the lesser the risk for data loss when recovering from a backup.
b)A shorter RTO indicates that the recovery process should be able to restore data more rapidly after data loss and allow for the quicker continuation of business activities
For Kubernetes, regularly backing up the Kubernetes cluster's configuration and etcd database is essential to recover the cluster's state in case of failure.
Generally, backing up in Container registry bothers on regularly backing up the container images. This is usually automated with the built in features of the registry to be sure that the most recent image versions and metadata backed up consistently. Consulting the official documentation for the specific container registry solution you are using is very essential for more detailed and up-to-date instructions on how to perform backups and ensure data integrity.

2.Data Replication

The picture shows replication strategy for Kubernetes from Data Center 1 named Active which is the Primary location to a Data Center 2 named Standby, a Secondary location.
Processes involved in Replication of data are stated below:

Running multiple replicas of critical application components across different nodes in a Kubernetes cluster ensures redundancy and high availability. If one replica fails, the others can continue to handle the workload
Geo-replication of data and applications across multiple geographically dispersed data centers or availability zones within a cloud provider's infrastructure ensures redundancy and fault tolerance.
Many container registry solutions offer built-in replication features that can copy container images to multiple locations or even across different cloud providers.

3.Disaster Recovery Plan
Outlining the steps and procedures (for various disaster scenarios) to follow in case of a disaster is very crucial to ensure proper implementation. This should include information on the followings:

backup schedules
recovery point objectives (RPOs)
recovery time objectives (RTOs)
the responsibilities of different team members during a recovery operation.

4.Multi-cluster Set up

Deploying Kubernetes clusters across multiple regions or data centers can provide geographical redundancy. If one data center experiences a disaster, applications can failover to another cluster in a different location. This ensures protection against regional outage.
Having a multi-cluster environment enables you to ensure that workloads don’t experience downtime due to a problem within a single cluster, as you can seamlessly transfer them to another cluster.

5.Load Balancers
(a)In Kubernetes clusters, a Load Balancer service does the
following:

Distributes network loads and service requests efficiently across multiple instances
Enables autoscaling in response to demand changes
Ensures High Availability by sending workloads to healthy Pods These actions mitigate the impact of potential failures and spares users the annoyance of dealing with unresponsive services and applications when a disaster occurs.

(b)For effective use of Load balancers for Disaster recovery plan
in Container Registry, the registry has to be replicated to a
secondary region. In Azure, Container Registry's has built-in
geo-replication feature that perform this task
Actions needed here are:

i. deploy load balancers to both the primary and secondary regions
ii. set up health probes or monitoring checks on the container
registry instances behind the load balancers
iii. configure disaster recovery routing to ensure traffic are
redirected to secondary region in the event of disaster

6.Monitoing and Alerting

After setting up the backup process, regularly monitor the backup logs
Implementing effective monitoring and alerting systems can help detect issues early and trigger recovery processes automatically
This make it easy to detect security breaches or performance problems

7.Regular testing of Disaster Recovery plan

Conduct periodic testing of the failover process to be sure that the disaster recovery plan will work as expected when there is need for it. It will help to identify and address any weaknesses in the recovery plan. Here are some useful steps to take:-

a)Set up a separate environment specifically dedicated to testing disaster scenarios. This should be isolated from the production environment to prevent any accidental impact on live services.

b)Create a replica of your production Kubernetes cluster and container registry in the test environment using the same versions of Kubernetes, container images, configurations, and other dependencies to ensure consistency

c)Identify the potential disaster scenarios you want to simulate such as node failures, network outages, container image registry unavailability, or entire cluster outages

d)Utilize infrastructure-as-code (IAC) tools like Terraform to automate the provisioning of the test environment. This helps ensure that the test environment is reproducible and consistent for each test run

e)Set up load balancers in the test environment as you have in the production environment.

f)Intentionally trigger disaster scenarios and test your backup and restore procedures.

g)Deploy monitoring and logging tools in the test environment to closely observe the behavior of the system during each simulated disaster

h)Analyze the results and make necessary adjustments to improve the recovery plan

i)Create scripts or automation to clean up and reset the test environment after each simulation

j)Document the results of each disaster simulation and any improvements effected

k)Repeat testing regularly

8.Security

(a)Access Control

Apply strong access controls to limit who can manage and modify resources in the Kubernetes cluster and container registry.
Use Kubernetes RBAC (Role Based Access Control) to define granular access levels based on roles, allowing only authorized users to perform specific actions.

(b)Network Security

Use Virtual LANs (VLANs) to segregate the disaster recovery environment from the production environment
Network Policies in Kubernetes can be used to control traffic flow between pods and namespaces and enforce security rules.

(c)Secure Authentication and Authorization

Use authentication mechanisms such as TLS certificates or OAuth tokens.
Integrate with an Identity Provider (IdP) for centralized user management and single sign-on (SSO).
Enforce the use of Multi-Factor Authentication (MFA) for accessing critical resources. This adds an extra layer of security, making it difficult for unauthorized users to gain access

(d)Encryption

Encrypt sensitive data at rest and in transit.
Use encryption for etcd data, Kubernetes secrets, container images, and communication channels.
Utilize TLS/SSL certificates for secure communication within the Kubernetes cluster and with the container registry.

(e)Secure Container Images

Container images must be scanned for vulnerabilities before deployment to ensure that only secure images are used in the DR environment.
Use image signing and verification to prevent unauthorized modifications.

(f)Regular Updates and Patching
Consistently update the Kubernetes cluster, container runtime,
and other components with the latest security patches.

(g)Communication with External Services

These can be secured with VPNs or encrypted channels
Communication between the DR environment and external systems must be authenticated and authorized

(h)Security of the Disaster Recovery Site

This applies to organisation maintaining on premise infrastructure
A separate site must be used for disaster recovery and you must ensure that it meets the same security standards as the primary site.
Securely transfer data between the primary and DR sites using encrypted channels such as VPN, TLS/SSL Certificates, VLAN (for Container registry) etc

9.Create Disaster recovery team
Creating a disaster recovery (DR) team for Kubernetes and the Container Registry is crucial for effectively handling and mitigating potential disasters. Note the following steps and criteria while creating the team

(a) Members of the team should consist of skilled individuals who understand the infrastructure, applications, and data involved and stakeholders like the IT managers, DevOps leads, Cloud Administrators/Engineers, application owners, and security personnel
(b) Define and assign specific roles and responsibilities of each team member based on their expertise and knowledge of Kubernetes, container orchestration, container registries, network management, and disaster recovery procedures systems involved
(c) Select individuals who are available and accessible during potential disaster scenarios
(d) Provide training and knowledge sharing sessions to the DR team to ensure that all members understand the disaster recovery plan and procedures and get familiar with the organization's infrastructure, applications, and data dependencies
(e) Set up clear communication channels such as Google meet, Microsoft Teams, for the DR team to stay connected during both normal operations and disaster scenarios.
(f) Organize regular disaster recovery drills and testing exercises for the team, to validate the effectiveness of the plan and identify any areas for improvement
(g) All procedures, configurations, and contact information in the disaster recovery documentation must be kept up-to-date. And updated documentation must be circulated among DR team members
(h) Set up alerts to notify the team about any suspicious or unauthorized activities.

Real live Scenarios of disaster recovery on Kubernetes
1.BlackRock, a global investment management firm, utilizes
Kubernetes to deploy its applications across multiple regions.
They set up a disaster recovery strategy where applications and
data are automatically replicated and failover to a secondary
Kubernetes cluster in case of a disaster in the primary region.

2.Adobe's Experience Manager (AEM), a content management solution,
uses Kubernetes for its disaster recovery strategy. They deploy
AEM in a highly available Kubernetes cluster with data
replication and automated failover across different regions or
data centers

3.Pinterest, a visual discovery and bookmarking platform, runs its
Kubernetes workloads on Amazon EKS. They have a multi-
Availability Zone EKS deployment to ensure redundancy and high
availability. In the event of a failure, their applications can
quickly recover in another Availability Zone.

Real live Scenarios of disaster recovery on Container Registry

1.Docker Hub, the official Docker image registry, employs robust
disaster recovery practices to ensure the availability of
container images for developers worldwide. They use a
combination of data replication, backups, and load balancing
across multiple regions to ensure high availability and data
redundancy. In the event of an outage in one region, users can
still access images from other available regions.

2.Microsoft Azure's Azure Container Registry (ACR) is designed for
high availability and disaster recovery. ACR replicates
container images across multiple regions, providing geographic
redundancy to ensure accessibility even during regional outages.
Additionally, ACR integrates with Azure Backup for image
registry backup and recovery.

3.Amazon Web Services (AWS) Elastic Container Registry (ECR)
offers container image storage with built-in redundancy and high
availability. ECR automatically replicates images across
multiple AWS Availability Zones within a region to ensure data
durability. Additionally, AWS provides multi-region replication
options to further enhance disaster recovery capabilities.

Conclusion
Disaster recovery on Kubernetes and container registry is a critical aspect of ensuring the high availability, resilience, and business continuity of modern cloud-native applications. Kubernetes has emerged as a dominant and popular orchestration platform for containerized workloads, offering flexibility and scalability to deploy applications across various environments. Along with it, Container registries play an essential role in securely storing and managing container images, making them an important part of the disaster recovery strategy.

This article have explored the key components of a robust disaster recovery plan for Kubernetes and Container Registry, together with strategies highlighted in view of best practices and real-life examples. We learned how to set up test environments to simulate disaster scenarios, the importance of encrypted channels for data transfer, and the significance of a well-prepared disaster recovery team.

As Cloud computing continues to evolve, organizations primary aim is to deliver seamless, reliable, and uninterrupted services to their customers. And this can be achieved by leveraging on the capabilities of Kubernetes, Container registries, and other cloud provider services while keeping on guard for potential disasters.

I hope you find this article helpful. Please leave your feedbacks in the comment section

How to Capture the Image of a Virtual Machine

Yemisi Oyesainu — Sat, 01 Jul 2023 09:59:45 +0000

Hi! I'm here again with some little tips on capturing the Image of a virtual machine. You may wonder, why do I need to do this? Well, it is a good idea to have something you can refer to or make use of in future in case you need to know something about your VM or use your virtual machine again from its fresh state it was when you created and deployed it.

More importantly, when you created an image of a virtual machine, it can be used to create multiple VMs.
In Azure, when the image of a virtual machine is captured, the virtual machine will be temporarily stopped. This to achieve consistency of the data and prevent encountering any problem while creating the image. This is crucial because capturing an image requires a point-in-time snapshot of the virtual machine's disk.

Azure Compute Gallery is an Azure service used for storing images of VMs captured. From the gallery you can share your images and you can replicate them to multiple regions.
Yes, that's the gist.

In my earlier post, Adding Data Disk to a Virtual Machine I created a virtual machine, connected to it, installed a web server role and added a data disk. You can click on the link to see how this was done.

Now let's go through some simple steps to capture the image of a virtual machine. I want to capture the image of the Virtual machine Abiksvm created in the post referred to above.

Step 1
Go to Azure Portal and click on the virtual machine to be captured

Ascertain the Status of the virtual machine that it is running

Step 2
Go back to the Azure portal home page and select Azure Compute Gallery

Click on 'Create'

I will complete the Project details and Instance details as follows:
Subscription: Azure Pass Sponsorship
Resource group: UniRg
Gallery name: Abiksgallery
Region: East US

Click on Review and Create

Click on Create

Go to Resource

The Compute Gallery for storing the VM image we want to capture has been created.

Step 3
Lets go back to the virtual machine we want to capture
Click on Capture

Select the Compute Gallery already created, Abiksgallery
And name the VM Image definition. I will name is Abiksimage

Input the Version number 0.0.1

The Default replica count is 2.I will leave it at 2.You can input any number you desired.
I will select the two regions where I want to replicate the image captured: West US 2 and UK South

Click on Review and Create

Click on Create

When you click on 'Create', the VM has to be stopped before the snapshot will be taken as seen in the picture above.

Then, the Virtual machine will also be generalised. Generalizing is a process that removes machine and user specific information from the VM. This also has to take place before the image of the VM is taken.

When the deployment is complete, that means that the image has been taken. Lets click on Go to Resource and see for ourselves.

Also, go to the Portal's home page and Click on the gallery, Abiksgallery

Viola! The image has been successfully captured and stored in the gallery.

Simple. Not so?

What is your view about this? Please leave your comments below

Load Balancer and Virtual Machine Scale set

Yemisi Oyesainu — Fri, 30 Jun 2023 18:25:38 +0000

Load balancers and Virtual Machine Scale sets are different tools or services, but both are excellent infrastructure for achieving scalability and high availability of applications in Cloud environment.

Before we embark on highlighting how the two works, let's look at what each of them really are.

Load Balancer is a networking component or service that distributes incoming network traffic across multiple backend servers, virtual machines, or other resources. As the name implies, it balances workload across these resources. It can be implemented as software or hardware appliances or as cloud-based services provided by cloud platforms.
Its main features are
(i)traffic distribution
(ii)resources health monitoring
(iii)session persistence
(iv) SSL termination

There are different types of Load balancers classified based on specific needs and requirements. They are
(i)Local/Network Load Balancer or Transport Layer Load Balancer: This operates at the network layer (Layer 4) of the OSI model distributing workload based on IP addresses and port numbers. They are often hardware appliances or software solutions specifically designed for local or on-premises network environments.
(ii)Application Load Balancer (ALB) or Application Layer Load Balancer:It runs at the application layer (Layer 7) of the OSI model making the load balancing decisions based on information within the application layer protocols, such as HTTP headers, URLs, or cookies. ALBs are commonly used for HTTP(S) traffic and provide advanced features like content-based routing, SSL termination, and session persistence.
(iii)Global Load Balancer: distributes traffic across multiple data centers or regions, allowing load balancing on a global scale. It directs requests to the nearest or least loaded data center, reducing latency and improving performance. Generally, it is used for multi-region architectures to achieve high availability and global traffic optimization. Examples of GLB architectures are DNS hosting solutions, such as Infoblox and CloudFlare; DNS service of a major public cloud providers like AWS Route53, Azure Traffic Manager.
(iv)Software Load Balancer: These are implemented in software and run on standard servers or virtual machines. They provide load balancing functionality without the need for specialized hardware appliances. Software load balancers are flexible and scalable, often used in cloud environments or virtualized infrastructures.
(v)Reverse Proxy Load Balancer: This is located between clients and backend servers, acting as a proxy for incoming requests. It receives the client requests, performs load balancing, and forwards the requests to the appropriate backend server. They are often use in handling incoming web traffic, providing SSL termination, and offering advanced caching or content delivery capabilities.
(vi)DNS Load Balancer: This distributes traffic by leveraging the DNS (Domain Name System) to resolve domain names to multiple IP addresses. It can direct clients to different IP addresses based on factors like geographic location or server health. DNS load balancing is an effective approach for balancing traffic across multiple resources or locations.

Virtual Machine Scale Set (VMSS) is a tool or service provided by cloud computing platforms, such as Microsoft Azure, that enables the management of a group of identical virtual machines as a collective unit.
Other important features and benefits of VMSS includes
(i)It makes deployment and management of multiple virtual machines easy by automatically creating, scaling, and distributing them based on predefined policies.
(ii)In VMSS, scaling rules and conditions are defined to automatically add or remove virtual machine instances based on demand. Adding more VM Instances is referred to as scaling out while reducing number of VM Instances is known as scaling in
(iii) It is used to update and maintain the virtual machines within the set, and this include rolling upgrades and fault domain support.

You can have more control over the way the scale set manages virtual machine instances by using the orchestration modes. When creating VMSS, the orchestration mode is defined and this can not be modified after the deployment of the scale set.
There are two main types of orchestration modes:

(i)Scale sets with Uniform orchestration: It is optimized for large-scale stateless workloads with identical instances.
It uses a virtual machine template to scale up to desired capacity. It also uses identical VM instances though it has some ability to manage or customize individual virtual machine instances. Individual Uniform VM instances are exposed via the Virtual Machine Scale Set VM API commands. When it is configured with less than 100 instances, it provides fault domain high availability. It supports a full range of scale set management and orchestration, including metrics-based autoscaling, instance protection, and automatic OS upgrades.

(ii)Scale sets with Flexible orchestration: This achieves high availability with identical or multiple virtual machine types. Up to 1000 VMs can be provisioned in the orchestration mode. These are spread across fault domains in a region or within an Availability Zone making scaling out easily achievable. This orchestration mode works with all sizes of virtual machines.

How does Load balancer and Virtual Machine Scale set work together?
A load balancer receives incoming network traffic from clients. It then distributes the traffic across the virtual machines within a Virtual machine scale set. The workload is evenly distributed preventing any single virtual machine from being overwhelmed.

When demand for your application increases, a VMSS can automatically scale out by adding more virtual machine instances to handle the increased load. The load balancer ensures that the incoming traffic is distributed across all the available instances, enabling horizontal scaling and providing additional capacity.

If for any reason a virtual machine within the scale set becomes unavailable or unhealthy, the load balancer will redirect the workload meant for that Virtual machine to the remaining healthy instances, ensuring uninterrupted service enhancing applications high availability.

Load balancers performs regular health checks of each virtual machine instance within a VMSS and route traffic only to the healthy instances. If a virtual machine becomes unhealthy, the load balancer can automatically stop sending traffic to it until it recovers.

As I mentioned at the outset, you can see how Load balancers and Virtual machine scale sets work together to achieve scalability, high availability, and efficient traffic distribution for applications deployed in a cloud environment.

Let's proceed to Azure Portal to create a Load balancer and Virtual Machine Scale Set

(1)Log in to Azure Portal and type Virtual machine scale sets into the search bar

Click on 'Create'

Complete the Project details and Scale sets details
My Subscription is Azure Pass Sponsorship and my Resource group is UniRg.I will name the scale sets Abbyvmss and choose East US as the Region

I will leave Orchestration at default and choose the image as Windows Server 2019 under the Instance details

Complete details of the Administrator account.
My username is Azureuser and password is Password123*

(2)To configure Load balancer, click on 'Networking'

Under 'Networking' click on Azure load balancer
Next click on create Load balancer. I will name it balancer1
Then click 'Create'

To allow traffic from the Load balancer, we have to edit the Port configuration of the Network interface

Click on the Edit button on the left side of the V-net

Click on 'Allow selected ports' under Public Inbound Port

Select HTTP(80), RDP (3389) and Click OK

(3)Go to Scaling

I will leave the Initial Instance Count at the default of 2 and Scaling Policy at Manual

(4)Click on 'Health' and enable application health monitoring

Click on Review and Create

Click on Create and allow the deployment to complete

(5)Go to Resource

The Virtual machine scale set Abbyvmss has been created with load balancer and two virtual machine instances

The two VM Instances are running.

Trust you find this useful.Please proceed to the comment section and let's have your feedback

Adding Data Disk to a Virtual Machine

Yemisi Oyesainu — Thu, 29 Jun 2023 12:09:29 +0000

Creating and deploying Virtual Machines is an essential part of Cloud Computing and as such, it has become one of the major Cloud Administrators' role. However, when Virtual machines are created newly, they only have Operating System Disk. To be able to store application data and any other data or information on the Virtual machine, data disk needs to be added.

Data disks attached to Virtual machines are managed disk. This is because they are created and managed by Cloud Service Providers(CSP). Managed Disks have several benefits compared to unmanaged disks.

First, the management of the disk is simple because you don't have to bother yourself about managing storage accounts, blob containers, or dealing with manual scaling and configuration. The CSP takes care of all these.

Second, reliability is enhanced. Managed disks provide built-in redundancy and high availability. Data are replicated within the same region, ensuring that your data remains intact even if an individual disk or underlying hardware fails. These type of disk provide a reliable and convenient solution for data recovery, ensuring that your data remains protected and recoverable in case of any unforeseen occurrence.

Thirdly, managed disks offer improved performance and low latency by leveraging on the cloud service provider's infrastructure and storage optimization techniques. There is also different disk types with varying performance characteristics, such as Standard HDD, Standard SSD, and Premium SSD, based on your workload requirements, that you can choose from.

Finally, managed disk makes scalability and platform integration easy.

Now we will set out to create a Windows Virtual machine, connect to it, install a web server on it, add a data disk and initialise it for use.
Come on and let's do these together.

Step 1
I will start by logging in to Azure Portal and select Virtual Machine

Step 2
Click on 'Create'

Complete the Project details and Instance details
I will choose to complete them as follows:

Subscription : Azure Pass Sponsorship
Resource Group: UniRg
Virtual Machine Name: Abiksvm
Region: East US
Availability option: Availability zone
Image: Windows Server 2019 Datacenter - x64 Gen 2
Leave other parameters at default

Step 3
Complete the details for Administrator account
I will choose my Username as Azureuser and password is Password123*(Note that you can choose any username and password you desire)

Under Select Inbound ports, click on 'HTTP (80)' and 'RDP (3389)'

Go to Monitoring and disable Diagnostics

Click on Review and Create

Then Click on Create and wait for the deployment to complete

Click on 'Go to Resource'

Step 4
Connect to the Virtual machine
Click on Connect

Click on 'Download RDP File'

Open the RDP File downloaded, it will bring up a dialog box for Remote Desktop Connection

Click Connect

Enter the Username and Password created under the Administrator Account in Step (3) above to log in to the Virtual machine Abiksvm and click OK

Click Yes

We have connected to the Virtual Machine

Step 5
Install a Web Server role on the Virtual Machine
Type PowerShell into the Search window of the Virtual Machine

Right click on the Windows PowerShell and then click on Run as Administrator

When the Terminal is ready, type in this command:
Install-WindowsFeature Web-Server

Then press Enter on your keyboard and wait for the Installation to complete

The Web Server role has been installed. Lets check this out.

Go back to the Overview page of the Virtual machine Abiksvm on the Azure portal and copy the IP Address of the VM

Paste the IP Address in your browser and press Enter on your keyboard

That's it! A Windows Server has been installed.

Step 6
Add Data Disk to Virtual Machine Abiksvm
On the VM, Click on 'Disks' and then, click on 'Create and attach a new disk'

Give the disk a name. I will name it datadisk and change the size to 10GB

Click on 'Save'

The Data disk has been created

Step 7
Initialise the Data disk
Go back to the VM we connected to earlier and type 'disk management' in the search window

Click on 'Create and format hard disk partitions'

Click OK

Scroll down to Disk 2 and Right click on 'New Simple Volume'

Click Next

Give the Volume label a name and click next. I will give it the same name I used on Azure Portal, datadisk

Click on Finish

The Data disk has been successfully initialised and ready for use.

Trust you find this useful. Please let's have your comments.

Organise your Resources with Tags

Yemisi Oyesainu — Tue, 27 Jun 2023 16:52:23 +0000

Classifying your resources in the cloud environment is very essential. This will enable you to identify your resources based on the setup that obtains in your organisation.

Tags are used to identify resources in the cloud. They are descriptive metadata that helps you to logically arrange your resources into a taxonomy. It consists of key-value pair. That is, a tag is a label made up of a key and an optional value.
It can be applied to Azure resources, resource groups, and subscriptions.

It helps in identifying cost of different business processes in the cloud. Organisations can use tags to identify billings associated with each departments cloud resources usage. For example, The employees' names and their departments may be used as a key-value pair:

Name of Employee Department Tag(key:value)
Gladys Procurement Gladys:Procurement
Richard Finance Richard:Finance
Catherine Sales Catherine: Sales

Other parameters can be used to create a key:value pair depending on the Company's setup and mode of operations.

Next, we will see how Resource tagging can be implemented in Microsoft Azure. The following steps will guide you

Step 1
Log in to azure Portal

Step 2
Type 'Policy' into the Search bar and click on it

Step 3
Click on 'Assignments' to Assign a Policy

Then Click on 'Assign Policy'

Click on the small box in front of Policy Definitions and wait for it to come up

Type Tag in the Search box of the Available Definitions and Select 'Require a tag and its value on Resources'
Then Click on 'Add'

Go to Parameters and give the Tag a name and the Tag value too
The name will be Company and the Value will be Eunicloud
Therefore, the Key:Value pair is Company:Eunicloud
Please note that tag values are case sensitive.

Click on 'Review and Create'

Then, Click on 'Create'

A policy assignment was created to implement resource tagging.

Step 4
Go back to Azure portal Home page and click on Storage account

Click on 'Create'

Complete the Project details and Instance details
I will select my subscription, Azure Pass Sponsorship and Resource group is UniRg

The name of my Storage account is yemmystore (this is a random name. You can give yours any name of your choice) and I will select East US for the Region

Click on 'Review'

The Validation of the Storage account failed and could not be created. This is because of the Policy that is already assigned, requires that any resource to be created should be tagged Company:Eunicloud
Therefore, we have to assign the tag to yemmystore so that it can be created

Then Click on 'Review'

Then, Click on 'Create' and wait for the deployment to complete

The Storage Account yemmystore has been created with the tag
Company:Eunicloud

Step 5
Go back to the Home page of the Azure portal and select Policy

Click on 'Assignments'

Then Click on the Assignment name 'Require a tag and its value on Resources'

Click on 'Delete Assignment'

Select Yes in the Dialog box

The Policy assignment has been successfully deleted

I hope this is useful. When next you are creating your resources, try it out. Your workload will be well organised.

Comments are welcomed.

Migration to the Cloud-Estimate Cost savings with TCO Calculator

Yemisi Oyesainu — Tue, 27 Jun 2023 11:54:08 +0000

In my earlier blog post, Manage the Cost of your Cloud Resources, I have discussed about Migration to the Cloud and its benefits.

Here, we will look at how organisations can make informed decisions by estimating the cost that will be saved when they chose to migrate their business operations from on premise to the cloud environment. A very useful tool in this instance is Total Cost of Ownership Calculator (TCO).This calculator compares the cost of using the Infrastructure for your business workloads on premise with the cost of infrastructure needed to run the same workload in the cloud.

Let's explore this with the following steps
Step 1
Type 'Total Cost of Ownership Calculator' in your browser

Click on 'Total Cost of Ownership(TCO) Calculator|Microsoft Azure'

Step 2
The first step on the Calculator is to define your workload. Here you will enter the details of your on premise workloads
(a) For Servers, Click on Add Server Workload

Under Workload 1, I wiil select Windows operating system and leave other parameters at default

Under Workload 2, I will select Web app under workload type and for operating system I will choose Linux.Other parameters will be left at default

(b) For Databases, Click on Add Database

Under Database 1 Source, I will select Microsoft SQL Server, and OS will be Windows. Others will be at default

Under Database 2 Source, I will select MySQL Server, and OS will be Linux. Others will be at default

(c)For Storage, Click on Add Storage and leave the parameters at default

(d) For Networking, I will select the Destination Region as North Europe

Step 3
Click Next

Step 4
I will leave the Assumptions at default and click on Next to view the Report which is the Comparison of on premise cost of infrastructure with Azure cost of infrastructure for the same workload

The Blue graph line indicate the On premise cost while the Green graph line shows the Azure cost for the same workload for a period of five years. There is a wide difference in the two costs. This difference is the cost saved by moving the organisation's workload to the cloud. It is indicated on the graph and this amount to $98,257 as shown on the top of the graph.

The two pie charts below shows the total on premise cost and total azure cost for the period amounting to $117,590 and $19,333 respectively

The graph also indicate the percentages of cost of each of the services used by the company while on premise and when migrated to the cloud on Azure

It is really worthwhile to migrate to the cloud. For instance, some costs that are incurred on premise are not incurred at all in the cloud i.e. Cost of building, equipping & maintaining Datacenter and Networking which are cared for by the Cloud Service Provider while other cost such as Compute services is reduced from 80% on premise to 69% in the cloud.

TCO is a very simple and easy to use tool.

Is this helpful? Please leave your feedback in the comment section.