Architecture

What is Landing Zone in Azure? How to implement it via Terraform

March 16, 2023 Architecture, Architectures, Azure, Azure Kubernetes Service(AKS), Azure Solution Architect Expert, Best Practices, Cloud Computing, Emerging Technologies, Kubernetes, Microsoft, Software/System Design, Terraform No comments

In Azure, a landing zone is a pre-configured environment that provides a baseline for hosting workloads. It helps organizations establish a secure, scalable, and well-managed environment for their applications and services. A landing zone typically includes a set of Azure resources such as networks, storage accounts, virtual machines, and security controls.

Implementing a landing zone in Azure can be a complex task, but it can be simplified by using Infrastructure as Code (IaC) tools like Terraform. Terraform allows you to define and manage infrastructure as code, making it easier to create, modify, and maintain your landing zone.

Here are the steps to implement a landing zone in Azure using Terraform:

  1. Define your landing zone architecture: Decide on the resources you need to include in your landing zone, such as virtual networks, storage accounts, and virtual machines. Create a Terraform module for each resource, and define the parameters and variables for each module.
  2. Create a Terraform configuration file: Create a main.tf file and define the Terraform modules you want to use. Use the Azure provider to specify your subscription and authentication details.
  3. Initialize your Terraform environment: Run the ‘terraform init’ command to initialize your Terraform environment and download any necessary plugins.
  4. Plan your deployment: Run the ‘terraform plan’ command to see a preview of the changes that will be made to your Azure environment.
  5. Apply your Terraform configuration: Run the ‘terraform apply’ command to deploy your landing zone resources to Azure.

By implementing a landing zone in Azure using Terraform, you can ensure that your environment is consistent, repeatable, and secure. Terraform makes it easier to manage your infrastructure as code, so you can focus on developing and deploying your applications and services.

Once the landing zone architecture is defined, it can be implemented using various automation tools such as Azure Resource Manager (ARM) templates, Azure Blueprints, or Terraform. In this blog, we will focus on implementing a landing zone using Terraform.

Terraform is a widely used infrastructure-as-code tool that allows us to define and manage our infrastructure as code. It provides a declarative language that allows us to define our desired state, and then it takes care of creating and managing resources to meet that state.

To implement a landing zone using Terraform, we can follow these steps:

  1. Define the landing zone architecture: As discussed earlier, we need to define the architecture for our landing zone. This includes defining the network topology, security controls, governance policies, and management tools.
  2. Create a Terraform project: Once the landing zone architecture is defined, we can create a Terraform project to manage the infrastructure. This involves creating Terraform configuration files that define the resources to be provisioned.
  3. Define the Terraform modules: We can define Terraform modules to create reusable components of infrastructure. These modules can be used across multiple projects to ensure consistency and standardization.
  4. Configure Terraform backend: We need to configure the Terraform backend to store the state of our infrastructure. Terraform uses this state to understand the current state of our infrastructure and to make necessary changes to achieve the desired state.
  5. Initialize and apply Terraform configuration: We can initialize the Terraform configuration by running the terraform init command. This command downloads the necessary provider plugins and sets up the backend. Once initialized, we can apply the Terraform configuration using the terraform apply command. This command creates or updates the resources to match the desired state.

By implementing a landing zone using Terraform, we can ensure that our infrastructure is consistent, compliant, and repeatable. We can easily provision new environments, applications, or services using the same architecture and governance policies. This can reduce the time and effort required to manage infrastructure and improve the reliability and security of our applications.

Implementing Azure Landing Zone using Terraform and Reference Architecture

Below I provide general guidance on the steps involved in implementing an Azure Landing Zone using Terraform and the Azure Reference Architecture.

Here are the general steps:

  1. Create an Azure Active Directory (AD) tenant and register an application in the tenant.
  2. Create a Terraform module for the initial deployment of the Azure Landing Zone. This module should include the following:
    • A virtual network with subnets and network security groups.
    • A jumpbox virtual machine for accessing the Azure environment.
    • A storage account for storing Terraform state files.
    • An Azure Key Vault for storing secrets.
    • A set of Resource Groups that organize resources for management, data, networking, and security.
    • An Azure Policy that enforces resource compliance with standards.
  3. Implement the Reference Architecture for Azure Landing Zone using Terraform modules.
  4. Create a Terraform workspace for each environment (dev, test, prod) and deploy the Landing Zone.
  5. Set up and configure additional services in the environment using Terraform modules, such as Azure Kubernetes Service (AKS), Azure SQL Database, and Azure App Service.

Conclusion

Implementing an Azure Landing Zone using Terraform can be a powerful way to manage your cloud infrastructure. By automating the deployment of foundational resources and configuring policies and governance, you can ensure consistency, security, repeatable, and compliance across all of your Azure resources. Terraform’s infrastructure as code approach also makes it easy to maintain and update your Landing Zone as your needs evolve. This can help us reduce the time and effort required to manage our infrastructure and improve the reliability and security of our applications.

Whether you’re just getting started with Azure or looking to improve your existing cloud infrastructure, implementing an Azure Landing Zone with Terraform is definitely worth considering. With the right planning, tooling, and expertise, you can create a secure, scalable, and resilient cloud environment that meets your business needs.

References

Example Code

  1. Implementing Azure Landing Zone using Terraform :

Here’s an example Terraform code snippet that creates an Azure Landing Zone with a virtual network, subnets, and a network security group:

  • Define the subscription and resource group using Terraform:
#hcl coderesource "azurerm_resource_group" "landing_zone_rg" {
  name     = "landing-zone-rg"
  location = var.location
}

resource "azurerm_virtual_network" "landing_zone_vnet" {
  name                = "landing-zone-vnet"
  address_space       = ["10.0.0.0/16"]
  location            = var.location
  resource_group_name = azurerm_resource_group.landing_zone_rg.name

  subnet {
    name           = "web-subnet"
    address_prefix = "10.0.1.0/24"
  }

  subnet {
    name           = "db-subnet"
    address_prefix = "10.0.2.0/24"
  }
}
resource "azurerm_network_security_group" "landing_zone_nsg" {
  name                = "landing-zone-nsg"
  location            = var.location
  resource_group_name = azurerm_resource_group.landing_zone_rg.name

  security_rule {
    name                       = "http"
    priority                   = 100
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "80"
    source_address_prefix      = "*"
    destination_address_prefix = "*"
  }

  security_rule {
    name                       = "ssh"
    priority                   = 200
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "22"
    source_address_prefix      = "*"
    destination_address_prefix = "*"
  }
}
resource "azurerm_network_security_group" "nsg-web" {
  name                = "nsg-web-dev"
  location            = azurerm_resource_group.resource_group.location
  resource_group_name = azurerm_resource_group.resource_group.name
}

resource "azurerm_network_security_group" "nsg-db" {
  name                = "nsg-db-dev"
  location            = azurerm_resource_group.resource_group.location
  resource_group_name = azurerm_resource_group.resource_group.name
}

resource "azurerm_subnet_network_security_group_association" "web-nsg" {
  subnet_id                 = azurerm_virtual_network.virtual_network.subnet_web.id
  network_security_group_id = azurerm_network_security_group.nsg-web.id
}

resource "azurerm_subnet_network_security_group_association" "db-nsg" {
  subnet_id                 = azurerm_virtual_network.virtual_network.subnet_db.id
  network_security_group_id = azurerm_network_security_group.nsg-db.id
}

This Terraform code creates a resource group, a virtual network, a subnet, and two additional subnet for web-frontend, db-backend , associated network security groups, and associates the subnet with the network security group. The network security group allows inbound traffic on port 22 (SSH) and port 80 (HTTP). This is just an example, and the security rules can be customized as per the organization’s security policies.

  • Create an Azure Kubernetes Service (AKS) cluster:
#hcl code
resource "azurerm_kubernetes_cluster" "aks" {
  name                = "aks-dev"
  location            = azurerm_resource_group.resource_group.location
  resource_group_name = azurerm_resource_group.resource_group.name
  dns_prefix          = "aks-dev"

  default_node_pool {
    name            = "default"
    node_count      = 1
    vm_size         = "Standard_D2s_v3"
    os_disk_size_gb = 30
  }
}

2. Implementing Azure Landing Zone using Terraform and Cloud Adoption Framework:

Cloud Adoption Framework for Azure provides a set of recommended practices for building and managing cloud-based applications. You can use Terraform to implement these best practices in your Azure environment.

Here’s an example of implementing a landing zone for a development environment using Terraform and the Cloud Adoption Framework modules:

security groups using the Azure Cloud Adoption Framework (CAF) Terraform modules:

#hcl code
provider "azurerm" {
  features {}
}

module "caf" {
  source  = "aztfmod/caf/azurerm"
  version = "5.3.0"

  naming_prefix               = "myproject"
  naming_suffix               = "dev"
  resource_group_location     = "eastus"
  resource_group_name         = "rg-networking-dev"
  diagnostics_log_analytics   = false
  diagnostics_event_hub       = false
  diagnostics_storage_account = false

  custom_tags = {
    Environment = "Dev"
  }

  # Define the virtual network
  virtual_networks = {
    my_vnet = {
      address_space = ["10.0.0.0/16"]
      dns_servers   = ["8.8.8.8", "8.8.4.4"]

      subnets = {
        frontend = {
          cidr           = "10.0.1.0/24"
          enforce_public = true
        }
        backend = {
          cidr = "10.0.2.0/24"
        }
      }

      nsgs = {
        frontend = {
          rules = [
            {
              name                       = "HTTP"
              priority                   = 100
              direction                  = "Inbound"
              access                     = "Allow"
              protocol                   = "Tcp"
              source_port_range          = "*"
              destination_port_range     = "80"
              source_address_prefix      = "*"
              destination_address_prefix = "*"
            }
          ]
        }
      }
    }
  }
}

In this example, the aztfmod/caf/azurerm module is used to create a virtual network with two subnets (frontend and backend) and a network security group (NSG) applied to the frontend subnet. The NSG has an inbound rule allowing HTTP traffic on port 80.

Note that the naming_prefix and naming_suffix variables are used to generate names for the resources created by the module. The custom_tags variable is used to apply custom tags to the resources.

This is just one example of how the Azure Cloud Adoption Framework Terraform modules can be used to create a landing zone. There are many other modules available for creating other types of resources, such as virtual machines, storage accounts, and more.

Due to the complexity and length of the example code for implementing Azure Landing Zone using Terraform and Reference Architecture, it is not possible to provide it within a blog article.

However, here are the high-level steps and an overview of the code structure:

  1. Define the variables and providers for Azure and Terraform.
  2. Create the Resource Group for the Landing Zone and networking resources.
  3. Create the Virtual Network and Subnets with the appropriate address spaces.
  4. Create the Network Security Groups and associate them with the appropriate Subnets.
  5. Create the Bastion Host for remote access to the Virtual Machines.
  6. Create the Azure Firewall to protect the Landing Zone resources.
  7. Create the Storage Account for Terraform state files.
  8. Create the Key Vault for storing secrets and keys.
  9. Create the Log Analytics Workspace for monitoring and logging.
  10. Create the Azure Policy Definitions and Assignments for enforcing governance.

The code structure follows the Cloud Adoption Framework (CAF) for Azure landing zones and is organized into the following directories:

  • variables: Contains the variables used by the Terraform code.
  • providers: Contains the provider configuration for Azure and Terraform.
  • resource-groups: Contains the code for creating the Resource Group and networking resources.
  • virtual-networks: Contains the code for creating the Virtual Network and Subnets.
  • network-security-groups: Contains the code for creating the Network Security Groups and associating them with the Subnets.
  • bastion: Contains the code for creating the Bastion Host.
  • firewall: Contains the code for creating the Azure Firewall.
  • storage-account: Contains the code for creating the Storage Account for Terraform state files.
  • key-vault: Contains the code for creating the Key Vault for secrets and keys.
  • log-analytics: Contains the code for creating the Log Analytics Workspace.
  • policy: Contains the code for creating the Azure Policy Definitions and Assignments.

Each directory contains a main.tf file with the Terraform code, as well as any necessary supporting files such as variables and modules.

Overall, implementing an Azure Landing Zone using Terraform and Reference Architecture requires a significant amount of planning and configuration. However, the end result is a well-architected, secure, and scalable environment that can serve as a foundation for your cloud-based workloads.

It’s important to note that the specific code required for this process will depend on your organization’s specific needs and requirements. Additionally, implementing an Azure Landing Zone can be a complex process and may require assistance from experienced Azure and Terraform professionals.

Azure Cosmos DB – TTL (Time to Live) – Reference Usecase

October 9, 2018 .NET, .NET Core, .NET Framework, Analytics, Architecture, Azure, Azure, Azure Cosmos DB, Azure Functions, Azure IoT Suite, Cloud Computing, Cold Path Analytics, CosmosDB, Emerging Technologies, Hot Path Analytics, Intelligent Cloud, Intelligent Edge, IoT Edge, IoT Hub, Microsoft, Realtime Analytics, Visual Studio 2017, VisualStudio, VS2017, Windows No comments

TTL capability within Azure Cosmos DB is a live saver, as it would take necessary steps to purge redudent data based on the configurations you may. 

Let us think in terms of an Industrial IoT scenario, devices can produce vast amounts of telemetry information, logs and user session information that is only useful until we operate on them and take action on them, to be specific up to finate period of time. Once that data becomes surplus, we need an application logic that purges these old records.

With the “Time to Live” or TTL, Microsoft Cosmos DB provides an ability to have your documents automatically purged from database storage after a certian period if time(which you configured)

  • This TTL by default can be set on a document collection level and later can be overridden on a per document basis.
  • Once the TTL is set, Cosmos DB service will automatically remove the documents when its lifetime is over.
  • Inorder to track TTL, Cosmos DB uses an offset field to check when it was last modified.  This field is identifiable as “_ts”, which exists in every document you create.  Basically it is a UNIX epoch timestamp. This field is updated everytime when the document is modified. [Ref: Picture1]

image

[Picture1]

Enabling TTL on Cosmos DB Collection:

You can enable TTL on a Cosmos DB collection simply by using Azure Portal –> Cosmos DB collection setting for existing or during creation of  a new collection)

TTL value needs to be set in seconds – if you need 90 days => 60 sec * 60 min * 24 hour * 90 days = 7776000 seconds

image

[Picture2]

Below is a one of the reference architecture in which Cosmos DB – TTL would be essentially useful and viable to any Iot business case:

image

[Picture3]

Hope that was helpful to get some understanding. For more references visit:  Cosmos DB Documentation

Scalability – Scale Out/In vs Scale Up/Down (Horizontal Scaling vs Vertical Scaling)

October 1, 2016 Architecture, Azure, Cloud Computing, Cloud Services, Horizontal Scaling, Performance, Reliability, Resilliancy, Scalability, Scale Down, Scale In, Scale Out, Scale Up, Software/System Design, Vertical Scaling, Virtualization No comments

When you work with Cloud Computing or normal Scalable highly available applications you would normally hear two terminologies called Scale Out and Scale Up or often called as Horizontal Scaling and Vertical Scaling.  I thought about covering basics and provide more clarity for developers and IT specialists.

What is Scalability?

Scalability is the capability of a system, network, or process to handle a growing amount of work, or its potential to be enlarged to accommodate that growth. For example, a system is considered scalable if it is capable of increasing its total output under an increased load when resources (typically hardware) are added.

A system whose performance improves after adding hardware, proportionally to the capacity added, is said to be a scalable system.

image

This will be applicable or any system such as :

  1. Commercial websites or Web application who have a larger user group and growing frequently,
  2. or An immediate need to serve a high number of users for some high profile event or campaign.
  3. or A streaming event that would need immediate  processing capabilities to serve streaming to larger set of users across certain region or  globally.
  4. or A immediate work processing or data processing that requires higher compute requirements that usual for a certain job.

Scalability can be measured in various dimensions, such as:

  • Administrative scalability: The ability for an increasing number of organizations or users to easily share a single distributed system.
  • Functional scalability: The ability to enhance the system by adding new functionality at minimal effort.
  • Geographic scalability: The ability to maintain performance, usefulness, or usability regardless of expansion from concentration in a local area to a more distributed geographic pattern.
  • Load scalability: The ability for a distributed system to easily expand and contract its resource pool to accommodate heavier or lighter loads or number of inputs. Alternatively, the ease with which a system or component can be modified, added, or removed, to accommodate changing load.
  • Generation scalability: The ability of a system to scale up by using new generations of components. Thereby, heterogeneous scalability is the ability to use the components from different vendors.

Scale-Out/In / Horizontal Scaling:

To scale horizontally (or scale out/in) means to add more nodes to (or remove nodes from) a system, such as adding a new computer to a distributed software application.

image

Pros:

  • Load is distributed to multiple servers
  • Even if one server goes down, there are servers to handle the requests or load.
  • You can add up more servers or reduce depending on the usage patterns or load.
  • Perfect for highly available web application or batch processing operations.

Cons:

  • You would need additional hardware /servers to support. This would increase increase infrastructure and maintenance costs.
  • You would need to purchase additional licenses for OS or required licensed software’s.

Scale-Up/Down/Vertical Scaling:

To scale vertically (or scale up/down) means to add resources to (or remove resources from) a single node in a system, typically involving the addition of CPUs or memory to a single computer.

image

Pros

  • Possibility to increase CPU/RAM/Storage virtually or physically.
  • Single system can serve all your data/work processing needs with additional hardware upgrade being done.
  • Minimal cost for upgrade

Cons

  • When you are physically or virtually maxed out with limit, you do not have any other options.
  • A crash could cause outages to your business processing jobs.

We discussed in detail about the both approach in Scalability, depending on the need you will have to choose right approach. Nowadays high availability of cloud computing platforms like Amazon AWS/Microsoft Azure etc., you have lots of flexible ways to Scale-Out or Scale-Up on a Cloud environment, which provides you with virtually unlimited resources, provided you are being capable to pay off accordingly.

Hope this information was helpful, please leave your comments accordingly if you find any discrepancies or you have any queries. 

Why SOA ?–Service Oriented Architecture

May 19, 2015 .NET, Architecture, FAQs, Interview Qns, KnowledgeBase, Microsoft, Service Oriented Architecture No comments

SOA starts with a simple idea – the concept of service. Services are unassociated, loosely coupled units of functionality that are self-contained. Each service implements at least one action, such as submitting an online application for an account, retrieving an online bank statement or modifying an online booking or airline ticket order.

There are multiple definitions for SOA:

The OASIS group and the Open Group have both created formal definitions.
OASIS’s Definition of Service Oriented Architecture
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
The Open Group’s Definition of Service Oriented Architecture
Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation. Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services. A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports)

The purpose of SOA is to allow users to combine together fairly large chunks of functionality to form ad hoc applications built almost entirely from existing software services. The larger the chunks, the fewer the interfaces required to implement any given set of functionality; however, very large chunks of functionality may not prove sufficiently granular for easy reuse. Each interface brings with it some amount of processing overhead, so there is a performance consideration in choosing the granularity of services.

SOA as an architecture relies on service-orientation as its fundamental design principle. If a service presents a simple interface that abstracts away its underlying complexity, then users can access independent services without knowledge of the service’s platform implementation.

Horizontal Layers of SOA

SOA-based solutions endeavour to enable business objectives while building an enterprise-quality system. SOA architecture is viewed as five horizontal layers:

  1. Consumer Interface Layer – These are GUI for end users or apps accessing apps/service interfaces.
  2. Business Process Layer – These are choreographed services representing business use-cases in terms of applications.
  3. Services – Services are consolidated together for whole-enterprise in-service inventory.
  4. Service Components – The components used to build the services, such as functional and technical libraries, technological interfaces etc.
  5. Operational Systems – This layer contains the data models, enterprise data repository, technological platforms etc.

Cross Cutting – Vertical Layers of SOA

There are four cross-cutting vertical layers, each of which are applied to and supported by each of the following horizontal layers:

  1. Integration Layer – starts with platform integration (protocols support), data integration, service integration, application integration, leading to enterprise application integration supporting B2B and B2C.
  2. Quality of Service – Security, availability, performance etc. constitute the quality of service parameters which are configured based on required SLAs, OLAs.
  3. Informational – provide business information.
  4. Governance – IT strategy is governed to each horizontal layer to achieve required operating and capability model.

Benefits:

The use of services provides major benefits:

  • In contrast to the use of large applications, which tend to be “information silos” that cannot readily exchange information with each other, the use of finer-grained software services gives freer information flow within and between enterprises. Integrating major applications is often expensive. SOA can save integration costs.
  • Organizing internal software as services makes it easier to expose its functionality externally. This leads to increased visibility that can have business value as, for example, when a logistics company makes the tracking of shipments visible to its customers, increasing customer satisfaction and reducing the costly overhead of status enquiries.
  • Business processes are often dependent on their supporting software. It can be hard to change large, monolithic programs. This can make it difficult to change the business processes to meet new requirements (arising, for example, from changes in legislation) or to take advantage of new business opportunities. A service-based software architecture is easier to change – it has greater organizational flexibility, enabling it to avoid penalties and reap commercial advantage. (This is one of the ways in which SOA can make an enterprise more “agile”.)

[Quote: TheOpenGroup.org]

Now to coming to the question “Why SOA?”, I believe mostly it is answered.

In summary  SOA helps you with:

  • Reuse and composition. This is particularly powerful for creating new business processes quickly and reliably.
  • Recomposition. The ability to alter existing business processes or other applications based on service aggregation.
  • The ability to incrementally change the system. Switching service providers, extending services, modifying service providers and consumers. All of these can be done safely, due to well-controlled coupling.
  • The ability to incrementally build the system. This is especially true of SOA-based integration.

Reference Sources: