Managing an AKS cluster effectively requires a good understanding of its configuration options — particularly around node pools, scaling strategies, and upgrade paths. Let’s dive in!

Configuring Node Pools in AKS

In AKS, node pools represent a group of virtual machines (VMs) that provide the compute resources for your Kubernetes workloads. Node pools allow you to define and manage different configurations for different workloads, giving you greater flexibility to optimize performance and cost.

Types of Node Pools:

1. System Node Pools
The system node pool is required and responsible for running system-level pods, such as the core Kubernetes components (e.g., the kubelet) and monitoring agents. Typically, system node pools run critical infrastructure services, and they are automatically created when you set up an AKS cluster.

2. User Node Pools
You can create multiple user node pools to host your application workloads. These can be configured with different VM sizes, types, and scaling options based on the resource requirements of your applications.

Configuring a Node Pool:

When creating a node pool, several key configuration options are available:

• VM Size: Choose the appropriate VM size for your workloads (e.g., compute-optimized, memory-optimized, or GPU-based VMs).
• Node Count: Define the number of VMs in the node pool. You can start small and scale up based on your workload demands.
• Scaling Options: AKS allows for both manual scaling and autoscaling to dynamically adjust the number of nodes in a pool.
• Spot Nodes: For cost-sensitive, non-critical workloads, you can use Azure Spot VMs in your node pool. These are significantly cheaper but come with the caveat of being evicted when Azure needs the capacity back.
• Node Labels and Taints: You can assign labels to nodes and use taints to control the scheduling of pods, ensuring that certain workloads are allocated to specific node pools.

How to Add a Node Pool:

Using the Azure CLI, you can add a node pool to an existing AKS cluster with the following command:

az aks nodepool add \
 - resource-group <ResourceGroup> \
 - cluster-name <ClusterName> \
 - name <NodePoolName> \
 - node-count 3 \
 - node-vm-size Standard_DS3_v2

In this example, we create a new node pool named `NodePoolName` with 3 nodes of size Standard_DS3_v2.

Scaling AKS Clusters

Scaling is an essential part of managing Kubernetes workloads. It ensures that your applications can handle increases or decreases in demand without manual intervention.

Two Main Scaling Methods in AKS:
1. Manual Scaling
With manual scaling, you explicitly adjust the number of nodes in your cluster. You can scale up when demand increases or scale down to reduce costs during off-peak hours. Here’s how to scale manually using the Azure CLI:

az aks scale \
 - resource-group <ResourceGroup> \
 - name <ClusterName> \
 - nodepool-name <NodePoolName> \
 - node-count 5

This command scales the node pool to 5 nodes.

2. Cluster Autoscaler
The cluster autoscaler automatically adjusts the number of nodes in the node pool based on the resource requests of the running workloads. The autoscaler adds more nodes when the cluster is under pressure and removes nodes when there is excess capacity. To enable autoscaling in a node pool, use the following CLI command:

az aks nodepool update \
 - resource-group <ResourceGroup> \
 - cluster-name <ClusterName> \
 - name <NodePoolName> \
 - enable-cluster-autoscaler \
 - min-count 3 \
 - max-count 10

In this example, the autoscaler ensures that the node count stays between 3 and 10 nodes based on workload demands.

Managing Workloads Across Node Pools

Workload management across node pools is vital for performance optimization and cost efficiency. You can assign different workloads to specific node pools based on their resource needs or criticality. This is achieved by using node selectors, taints, and tolerations.

Node Selectors:

A node selector is used to schedule pods on a specific set of nodes. You can define labels on your nodes and match them with pod specifications to ensure that certain workloads are assigned to the right nodes. For example, if you have a node pool with GPU nodes for machine learning workloads, you can create a pod that specifies the label for GPU nodes.

Here’s an example pod configuration with a node selector:

apiVersion: v1
kind: Pod
metadata:
 name: gpu-pod
spec:
 containers:
 - name: gpu-container
 image: my-gpu-app:latest
 nodeSelector:
 kubernetes.azure.com/mode: "gpu"

Taints and Tolerations:

Taints and tolerations are mechanisms that prevent workloads from being scheduled on certain nodes unless the workloads explicitly tolerate the taint. For instance, you can taint a node pool to only accept critical system workloads while keeping it off-limits to non-essential workloads.

To taint a node pool:

az aks nodepool update \
 - resource-group <ResourceGroup> \
 - cluster-name <ClusterName> \
 - name <NodePoolName> \
 - node-taints Critical=true:NoSchedule

You can then add a toleration to your pod specification to allow it to be scheduled on these tainted nodes.

Example:

Case 1: Taint Node 1 (Blue)

Since Pods are not tolerated so none of them would be scheduled on node 1

Case 2: We add tolerance to pod D. Now only Pod D will be able to schedule on Node 1

Upgrading AKS Clusters

Keeping your AKS cluster up to date with the latest Kubernetes version is crucial for security, stability, and access to new features. Azure provides a managed upgrade process to handle this efficiently.

Upgrade Process:

1. Check Available Kubernetes Versions
   Before upgrading, you can check which Kubernetes versions are available for your AKS cluster using the following CLI command:

az aks get-upgrades - resource-group <ResourceGroup> - name <ClusterName>

This command will list the current version of your cluster and the available upgrade versions.

2. Upgrade the Cluster
Once you’ve identified the desired version, upgrading is as simple as running:

az aks upgrade \
 - resource-group <ResourceGroup> \
 - name <ClusterName> \
 - kubernetes-version <Version>

AKS ensures that the upgrade process is performed in-place with minimal downtime. The upgrade occurs node by node, draining workloads from the nodes being upgraded, and then re-scheduling them onto upgraded nodes.

Node Pool Upgrades:

You can upgrade individual node pools separately if needed. This is useful for gradually upgrading parts of the cluster to test stability. Here’s how to upgrade a node pool:

az aks nodepool upgrade \
 - resource-group <ResourceGroup> \
 - cluster-name <ClusterName> \
 - name <NodePoolName> \
 - kubernetes-version <Version>

Conclusion

Effectively configuring and managing your AKS cluster is essential for ensuring smooth and scalable operations. With node pools, scaling strategies, and upgrade processes in place, you can fine-tune your cluster’s performance and ensure that your workloads are distributed and managed efficiently.

In the next post of the Azure AKS Series, we’ll take a closer look at networking and security in AKS, exploring how to manage internal and external traffic, configure ingress controllers, and secure your cluster using network policies and Microsoft Entra ID (formerly Azure Active Directory) integration.

In this first installment of the Azure AKS Series, we’ll explore what AKS is, why it’s a popular choice for enterprises, and how you can set up your first AKS cluster.

What is Azure Kubernetes Service (AKS)?

Azure Kubernetes Service (AKS) is a managed Kubernetes service provided by Microsoft Azure that automates the operational overhead of managing Kubernetes clusters. AKS eliminates the complexity of manual setup, monitoring, and scaling by offloading much of the management to Azure, making it easier for developers and IT teams to focus on their applications instead of infrastructure.

With AKS, you can:

• Deploy and manage Kubernetes clusters without needing deep Kubernetes expertise
• Automatically scale clusters based on workload demands.
• Benefit from Azure’s security, monitoring, and integration with other Azure services like Azure DevOps, Azure Monitor, and Microsoft Entra ID (formerly Azure Active Directory).

In essence, AKS provides the power of Kubernetes, with the simplicity of a managed service, helping organizations accelerate their cloud-native journey.

Why Use Azure Kubernetes Service?

The demand for managed Kubernetes services like AKS has grown due to several reasons:

1. Simplified Cluster Management
Managing Kubernetes involves many manual processes, including node management, scaling, patching, and upgrades. With AKS, Azure handles most of these tasks for you, allowing your team to focus on the development and optimization of applications.

2. Built-In Scaling
AKS provides seamless scaling features, including the cluster autoscaler and Horizontal Pod Autoscaler (HPA), which allow your applications to dynamically respond to changes in workload demand without manual intervention.

3. Integrated Monitoring and Security
AKS comes with built-in support for Azure Monitor track resource utilization and performance, and Azure Security Center for monitoring security vulnerabilities. You can easily secure your cluster using Role-Based Access Control (RBAC) integrated with Microsoft Entra ID (formerly Azure Active Directory) for centralized authentication and security management.

4. Cost Efficiency
In AKS, you only pay for the nodes (virtual machines) running your workloads, not for the Kubernetes control plane itself, which is managed by Azure for free. This offers a significant cost advantage over self-managed Kubernetes clusters where control plane management costs are incurred.

5. Integration with Azure Ecosystem
AKS integrates seamlessly with other Azure services, such as Azure DevOps for CI/CD pipelines, Azure Load Balancer for traffic management, and Azure Container Registry for storing container images. This deep integration simplifies the lifecycle of cloud-native applications.

Benefits of Managed Kubernetes Services

Using a managed Kubernetes service like AKS offers several key benefits:

• Reduced Operational Overhead: With Azure managing the Kubernetes control plane, upgrades, and patching, the burden on your operations team is significantly reduced.
• Improved Security: Managed services provide regular security patches and compliance certifications, ensuring that your Kubernetes environment remains secure and up to date.
• Built-In High Availability: Managed Kubernetes services automatically provide high availability for the control plane, which ensures the stability and resilience of your cluster without additional configuration.
• Quick Time to Production: AKS accelerates the time it takes to move from development to production with simplified cluster creation and deployment processes.

Basic AKS Architecture Overview

Before diving into how to create an AKS cluster, let’s quickly go over the basic architecture of AKS.

1. Control Plane (Managed by Azure)
The control plane in AKS is fully managed by Azure and includes core Kubernetes components such as:
 — API server: Manages requests from users or applications.
 — Scheduler: Distributes pods across nodes based on resources.
 — Controller Manager: Manages the state of the cluster.
 — etcd: A key-value store for persisting cluster state data.

Azure handles scaling, patching, and availability of the control plane components, so you don’t need to worry about it.

2. Nodes (Your Responsibility)
The nodes are the virtual machines (VMs) that run your containerized applications. These are grouped into node pools, which can be customized for different workloads. You manage the node pools, including scaling and updating them when necessary.

3. Networking
AKS supports different networking models, such as Kubenet and Azure CNI, to handle internal and external communication for your pods and services. Ingress controllers, like NGINX or Azure Application Gateway, are often used for routing external traffic.

4. Storage
AKS integrates with Azure Disks, Azure Files, and other storage solutions to provide persistent storage for stateful applications running in your Kubernetes environment.

How to Create an AKS Cluster

Creating your first AKS cluster is straightforward using the Azure Portal, Azure CLI, or Terraform. Here, we’ll walk through the process of setting up a basic AKS cluster using the Azure Portal.

Steps to Create an AKS Cluster using Azure Portal:

1. Sign in to the Azure Portal
Navigate to the [Azure Portal](https://portal.azure.com/) and search for Kubernetes Services.

2. Create a Kubernetes Service
Click on Create to start the cluster creation process. Choose the following:
 — Subscription: Select your Azure subscription.
 — Resource Group: Create or select an existing resource group.
 — Cluster Details: Provide a name for your AKS cluster and select a region.

3. Configure Node Pools
Choose the size and number of nodes for your cluster. For testing or development, you might want to start with Standard_D2S_v3 VM size (2 vCPUs, 8GB memory). You can always scale up later.

4. Networking Configuration
Decide on a networking option (Kubenet or Azure CNI). Azure CNI is often recommended for better network integration with Azure services.

5. Enable Monitoring
Enable Azure Monitor and Log Analytics to track the health and performance of your cluster.

6. Review and Create
Review your configurations, and click Create to deploy your cluster. It might take a few minutes for the deployment to complete.

Steps to Create an AKS Cluster using Azure CLI:

az aks create --resource-group myResourceGroup --name myAKSCluster --node-count 2 --generate-ssh-keys --attach-acr $ACRNAME

Once deployed, you can connect to the cluster using the Azure CLI with:

az aks get-credentials - resource-group <ResourceGroup> - name <ClusterName>

This command retrieves the credentials and configures `kubectl` to interact with your AKS cluster.

Conclusion

Azure Kubernetes Service (AKS) provides a powerful, scalable, and cost-effective way to deploy and manage Kubernetes clusters in the cloud. Its fully managed control plane and deep integration with Azure services make it an ideal choice for enterprises looking to build, scale, and secure their cloud-native applications.

In the next post, we’ll dive deeper into AKS cluster configuration, exploring how to manage node pools, scaling options, and upgrade strategies to optimize your environment.

Stay tuned, and if you haven’t yet, follow this series to stay updated on the latest in Azure AKS!

Welcome to the Azure AKS Series, where I will take you through a comprehensive journey of mastering AKS, from the fundamentals to advanced topics. Whether you’re a beginner looking to get started with AKS or a seasoned cloud architect aiming to optimize your Kubernetes workloads, this series has something for everyone.

Why Focus on AKS?

As more businesses shift to cloud-native architectures, developers and IT professionals are increasingly turning to Kubernetes to handle complex deployment challenges. Azure Kubernetes Service (AKS) provides a managed Kubernetes environment that significantly reduces the overhead of manual configuration, management, and scaling. AKS takes care of routine tasks like health monitoring, automatic upgrades, and scaling, enabling your team to focus on building applications rather than maintaining infrastructure.

With integrated Azure services, including Azure Monitor, Microsoft Entra ID (formerly Azure Active Directory), and Azure DevOps, AKS stands out as a leading choice for enterprises seeking to deploy, manage, and scale containerized applications in the cloud.

What Will You Learn?

This series will cover the full breadth of AKS, starting with the fundamentals and gradually progressing to more advanced topics. Whether you’re just setting up your first AKS cluster or aiming to secure, scale, and optimize your Kubernetes workloads, this series is designed to help you achieve your goals.

Here’s a sneak peek of what you’ll learn:

1. The Fundamentals of AKS — We’ll start by introducing AKS, its architecture, and how to set up your first cluster. Learn how to deploy applications efficiently and integrate AKS with Azure’s powerful ecosystem.

2. Cluster Configuration & Scaling — Discover how to configure your AKS clusters with node pools, autoscaling, and upgrade strategies to ensure you maintain a highly available and performant environment.

3. Networking and Security— Explore how to manage networking in AKS, including service discovery, ingress controllers, and the all-important topic of security. Learn how to secure your cluster with Azure AD integration, network policies, and more.

4. Monitoring and Troubleshooting — Learn how to monitor your AKS cluster with Azure Monitor and Grafana, and gain the skills to troubleshoot common issues effectively.

5. DevOps with AKS— Discover how to integrate AKS into a seamless DevOps pipeline using Azure DevOps and GitHub Actions, enabling continuous integration and delivery for your applications.

6. Real-World Best Practices — Finally, we’ll wrap up with real-world best practices and case studies, showing how enterprises leverage AKS to power their applications.

Who Is This Series For?

This series is ideal for:
- Developers and DevOps engineers who are new to Kubernetes and want to learn how to run containerized applications in AKS.
- Cloud architects looking to optimize, secure, and scale Kubernetes workloads in Azure.
- IT professionals who need to understand Kubernetes infrastructure management without the overhead of manual intervention.

What’s Next?

The first article in the series will introduce you to Azure AKS, its core concepts, and how to set up your first cluster. As we move through the series, you’ll get hands-on guidance with examples and best practices to help you succeed in your Kubernetes journey.

Make sure to follow this series, as each article will build on the previous one, providing you with a comprehensive guide to mastering Kubernetes with AKS.

Stay Connected

I encourage you to engage, ask questions, and share your thoughts as we move through the series. Subscribe to my Medium channel, and feel free to share the articles with colleagues who might also be interested in learning more about Azure AKS.

Conclusion

Azure Kubernetes Service simplifies the complexity of Kubernetes management, allowing you to focus on what matters most — building great applications. Join me in this exciting journey, and let’s unlock the full potential of AKS together!

Stay tuned for the first installment, where we’ll dive into the fundamentals of AKS.

Authenticating with Microsoft Entra ID

The first step in managing access to your AKS cluster is to integrate it with Microsoft Entra ID, Microsoft’s enterprise-ready identity management solution. By integrating Entra ID, you can leverage your existing user accounts and groups to control access to your Kubernetes resources.

Defining Kubernetes RBAC

Once you’ve integrated Entra ID, you can use Kubernetes RBAC to define the permissions for your users and groups. Kubernetes RBAC consists of two main components: Roles/ClusterRoles and RoleBindings/ClusterRoleBindings.

- Roles and ClusterRoles: Define the set of permissions that can be granted to users or groups. Roles are scoped to a specific namespace, while ClusterRoles are cluster-wide.
- RoleBindings and ClusterRoleBindings: Bind Roles or ClusterRoles to users or groups, granting them the defined permissions.

By creating these RBAC resources, you can granularly control access to your Kubernetes resources, ensuring that users and groups only have the necessary permissions to perform their tasks.

Leveraging Azure RBAC

In addition to Kubernetes RBAC, you can also use Azure RBAC to manage access to your AKS resources. Azure RBAC allows you to define permissions at the Azure resource level, such as the AKS cluster itself, the Kubernetes API, and the kubeconfig file.[1][3]

This two-pronged approach, combining Kubernetes RBAC and Azure RBAC, provides a comprehensive access control solution for your AKS environment, allowing you to manage permissions at both the Kubernetes and Azure resource levels.

Practical Examples

To illustrate the concepts, let’s consider a few practical examples:

• Granting Full Access to the Finance Team: Create a Kubernetes ClusterRole with full permissions, then bind it to the “finance-team” group from Entra ID.

# Create a ClusterRole with full permissions
kubectl create clusterrole finance-team-full-access --verb=* --resource=*

# Bind the ClusterRole to the "finance-team" group
kubectl create clusterrolebinding finance-team-full-access --clusterrole=finance-team-full-access --group=finance-team

• Restricting Access to the Development Namespace: Create a Kubernetes Role with limited permissions in the “development” namespace, then bind it to the “dev-team” group from Entra ID.

# Create a Role with limited permissions in the "development" namespace
kubectl create role dev-team-access --namespace=development --verb=get,list,watch --resource=pods,deployments

# Bind the Role to the "dev-team" group
kubectl create rolebinding dev-team-access --role=dev-team-access --group=dev-team --namespace=development

• Allowing Read-Only Access to the Kubernetes Dashboard: Use Azure RBAC to grant the “AKS RBAC Reader” role to the “dashboard-viewers” group, restricting their access to the Kubernetes Dashboard.

# Assign the "AKS RBAC Reader" role to the "dashboard-viewers" group
az role assignment create --role "AKS RBAC Reader" --assignee-object-id $(az ad group show --group dashboard-viewers --query objectId -o tsv) --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ContainerService/managedClusters/<cluster-name>

By following these best practices and leveraging the power of Kubernetes RBAC and Azure RBAC, you can effectively manage access to your AKS clusters, ensuring that users and groups only have the necessary permissions to perform their tasks.

References:

1. https://learn.microsoft.com/en-us/azure/aks/manage-azure-rbac
2. https://learn.microsoft.com/en-us/azure/aks/hybrid/kubernetes-rbac-azure-ad
3. https://learn.microsoft.com/en-us/azure/aks/operator-best-practices-identity

Benefits of Amazon Redshift Serverless

Get started with analytics in seconds

Focus on obtaining insights by getting started quickly and running real-time or predictive analytics on all your data without worrying about managing data warehouse infrastructure.

Experience consistently high performance

Intelligent, proactive, and automatic scaling for dynamic workloads is enabled along dimensions like query complexity, frequency, ETL (extract, transform, and load), or dashboarding usage patterns to deliver tailored performance optimizations.

Save costs and stay on budget

Pay only for what you use on a per-second basis, and pay nothing when the data warehouse is idle. Adjust your desired price-performance targets for your workload to maintain consistent performance and stay on budget.

Use cases

Self-service analytics

Perform what-if analyses, anomaly detection, and ML-based forecasting, and get fast, actionable insights from your data.

Auto scaling for unpredictable workloads

No longer spend time determining compute capacity and encountering overspending or underserving as you run workloads with regular usage throughout the day and peaks of activity that involve complex, hard-to-predict queries.

New applications

Unsure of how to size your data warehouse when deploying a new data-driven application? Start an Amazon Redshift Serverless endpoint, and your data warehouse will be sized according to your workload requirements.

Auto scaling for variable workloads

Have applications with high variability in usage? Think of your HR, budgeting, and operational reporting applications. You no longer have to over- or under-provision capacity. Avoid overpaying, performance issues, and poor user experiences.

Multi-tenant applications

For multi-tenant applications with each tenant having specific busy and idle periods — depending on the time of day, year, promotional events, and so on — architect to use a workgroup for each tenant with a wide capacity range. Any workgroup can quickly scale up to handle periods of high activity.

Benefits of AWS Fargate

With AWS Fargate, you can focus on building applications. You manage less, choose how you pay, and improve security through isolation by design.

Manage your applications, not infrastructure

Deploy and manage your applications, not infrastructure. Remove the operational overhead to scale, patch, help secure, and manage servers.

Monitor your applications to gain metrics and insights

Monitor your applications through built-in integrations with AWS services like Amazon CloudWatch Container Insights or gather metrics and logs with third-party tools.

Improve security through isolation

Improve security through workload isolation by design. Amazon ECS tasks and Amazon EKS pods run in their own dedicated runtime environment.

Optimize for cost

Pay only for compute resources used, with no upfront expenses. Further optimize costs with Savings Plans, Fargate Spot, or AWS Graviton processors.

How it works

AWS Fargate is compatible with both Amazon Elastic Container Service (Amazon ECS) and Amazon Elastic Kubernetes Service (Amazon EKS). Select any OCI-compliant container image, define memory and compute resources, and run the container with serverless compute. With multiple CPU architectures and operating systems supported, you can enjoy the benefits across a wide variety of applications.

Use cases

Web apps, APIs, and microservices

Build and deploy your applications, APIs, and microservices architectures with the speed and immutability of containers. Remove the need to own, run, and manage the lifecycle of a compute infrastructure, so you can focus on your applications.

Modernize applications

Use AWS Fargate with Amazon ECS or Amazon EKS to more easily run and scale your containerized workloads. Migrate and run your Amazon ECS Windows containers without refactoring or rearchitecting your legacy applications.

Support AI and ML applications

Create a flexible and portable artificial intelligence (AI) and machine learning (ML) development environment. Train, test, and deploy your ML models with scalable resources that boost server capacity while avoiding overprovisioning.

Data processing

Run data processing workloads, scale up to 16 vCPU and 120 GB memory per task, and integrate with AWS Batch for serverless parallel processing.

This type of automation is especially valuable for multitenant databases, distributed databases, development and test systems, and other environments with highly variable and unpredictable workloads.

Benefits

1. Highly scalable: Scale instantly to hundreds of thousands of transactions in a fraction of a second.
2. Highly available: Power your business-critical workloads with the full breadth of Aurora features, including cloning, global database, Multi-AZ, and read replicas.
3. Cost effective: Scale out fine-grained increments to provide just the right number of database resources and pay only for capacity consumed.
4. Simple: Removes the complexity of provisioning and managing database capacity. The database will scale to match your application’s needs.
5. Transparent: Scale database capacity instantly, without disrupting incoming application requests.
6. Durable: Protects against data loss using the distributed, fault-tolerant, self-healing Aurora storage making your data durable across three Availability Zones (AZs) in a Region.

Use cases

Variable workloads

You’re running an infrequently-used application, with peaks of 30 minutes to several hours a few times each day or several times per year, such as a human resources, budgeting, or operational reporting application. You no longer have to provision to peak capacity, which would require you to pay for resources you don’t continuously use, or to average capacity, which would risk performance problems and a poor user experience.

Unpredictable workloads

You’re running workloads with database usage throughout the day, and also peaks of activity that are hard to predict. For example, a traffic site that might see a surge of activity when it starts raining. Your database will automatically scale capacity to meet the needs of the application’s peak load and scale back down when the surge of activity is over.

Enterprise database fleet management NEW

Enterprises with hundreds or thousands of applications, each backed by one or more databases, must manage resources for their entire database fleet. As application requirements fluctuate, continuously monitoring and adjusting capacity for each and every database to ensure high performance, high availability, and remaining under budget is a daunting task. With Aurora Serverless v2, database capacity is automatically adjusted based on application demand. You no longer need to manually manage thousands of databases in your database fleet. Features such as global database and Multi-AZ deployments ensure high availability and fast recovery.

Software as a service applications NEW

Software as a service (SaaS) vendors typically operate hundreds or thousands of Aurora databases, each supporting a different customer, in a single cluster to improve utilization and cost efficiency. But they still need to manage each database individually, including monitoring for and responding to colocate databases in the same cluster that may take up more shared resources than originally planned. With Aurora Serverless v2, SaaS vendors can provision Aurora database clusters for each individual customer without worrying about costs of provisioned capacity. It automatically shuts down databases when they are not in use to save costs and instantly adjusts databases capacity to meet changing application requirements.

Scaled-out databases split across multiple servers NEW

Customers with high write or read requirements often split databases across several instances to achieve higher throughput. However, customers often provision too many or too few instances, increasing cost or limiting scale. With Aurora Serverless v2, customers split databases across several Aurora instances and let the service adjust capacity instantly and automatically based on need. It seamlessly adjusts capacity for each node with no downtime or disruption, and uses only the amount of capacity needed to support applications.

Azure Policy helps to enforce organizational standards and to assess compliance at-scale. Through its compliance dashboard, it provides an aggregated view to evaluate the overall state of the environment, with the ability to drill down to the per-resource, per-policy granularity. It also helps to bring your resources to compliance through bulk remediation for existing resources and automatic remediation for new resources.

Common use cases for Azure Policy include implementing governance for resource consistency, regulatory compliance, security, cost, and management. Policy definitions for these common use cases are already available in your Azure environment as built-ins to help you get started.

Specifically, some useful governance actions you can enforce with Azure Policy include:

• Ensuring your team deploys Azure resources only to allowed regions
• Enforcing the consistent application of taxonomic tags
• Requiring resources to send diagnostic logs to a Log Analytics workspace

Azure Policy objects

Policy definition

The journey of creating and implementing a policy in Azure Policy begins with creating a policy definition. Every policy definition has conditions under which it’s enforced. And, it has a defined effect that takes place if the conditions are met.

In Azure Policy, there are several built-in policies that are available by default. For example:

• Allowed Storage Account SKUs (Deny): Determines if a storage account being deployed is within a set of SKU sizes. Its effect is to deny all storage accounts that don’t adhere to the set of defined SKU sizes.
• Allowed Resource Type (Deny): Defines the resource types that you can deploy. Its effect is to deny all resources that aren’t part of this defined list.
• Allowed Locations (Deny): Restricts the available locations for new resources. Its effect is used to enforce your geo-compliance requirements.
• Allowed Virtual Machine SKUs (Deny): Specifies a set of virtual machine SKUs that you can deploy.
• Add a tag to resources (Modify): Applies a required tag and its default value if it’s not specified by the deploy request.
• Not allowed resource types (Deny): Prevents a list of resource types from being deployed.

To implement these policy definitions (both built-in and custom definitions), you need to assign them. You can assign any of these policies through the Azure portal, PowerShell, or Azure CLI.

Initiative definition

An initiative definition is a collection of policy definitions that are tailored toward achieving a singular overarching goal. Initiative definitions simplify managing and assigning policy definitions. They simplify by grouping a set of policies as one single item.

Assignments

An assignment is a policy definition or initiative that has been assigned to a specific scope. This scope could range from a management group to an individual resource. The term scope refers to all the resources, resource groups, subscriptions, or management groups that the definition is assigned to. Assignments are inherited by all child resources. This design means that a definition applied to a resource group is also applied to resources in that resource group. However, you can exclude a subscope from the assignment.

Trigger Condition and Evaluation Workflow of Azure Policy

The Azure policy will check the request payload and compare it with the policy definition and then decide the next action. The following part will explain how the policy evaluates resources by the simplified workflow sample.

Azure Open Service Mesh is a managed service mesh implementation offered by Microsoft Azure. A service mesh is a dedicated infrastructure layer that handles service-to-service communication within a microservices architecture. It helps manage the complexity of distributed systems by providing features like traffic routing, service discovery, load balancing, and observability.

Azure Open Service Mesh is built on top of the open-source service mesh project called Open Service Mesh (OSM), which is hosted by the Cloud Native Computing Foundation (CNCF). It provides a simplified way to deploy and manage service mesh capabilities in Azure Kubernetes Service (AKS) clusters.

Some key features of Azure Open Service Mesh include:

1. Traffic management: It allows you to control and manage traffic between services, enabling features like request routing, load balancing, and traffic splitting.
2. Service discovery: It provides automatic service discovery, allowing services to locate and communicate with each other without requiring explicit configuration.
3. Secure communication: Azure Open Service Mesh secures communication between services using mutual TLS (mTLS) encryption. It ensures that only authenticated and authorized services can communicate with each other.
4. Observability and monitoring: It offers built-in monitoring and observability features, allowing you to gain insights into the performance and behavior of your services. This includes metrics, logs, and distributed tracing.
5. Integration with Azure services: Azure Open Service Mesh integrates with other Azure services, such as Azure Monitor and Azure Application Gateway, to provide enhanced monitoring, security, and traffic management capabilities.

Limitations

The OSM AKS add-on has the following limitations:

• After installation, you must enable Iptables redirection for port IP address and port range exclusion using kubectl patch. For more information, see iptables redirection.
• Any pods that need access to IMDS, Azure DNS, or the Kubernetes API server must have their IP addresses added to the global list of excluded outbound IP ranges using Global outbound IP range exclusions.
• The add-on doesn’t work on AKS clusters that are using Istio based service mesh addon for AKS.
• OSM doesn’t support Windows Server containers.

By using Azure Open Service Mesh, you can simplify the management of your microservices architecture and improve the reliability, scalability, and security of your applications running on Azure.

Azure Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable microservices and containers. Service Fabric also addresses the significant challenges in developing and managing cloud native applications.

A key differentiator of Service Fabric is its strong focus on building stateful services. You can use the Service Fabric programming model or run containerized stateful services written in any language or code. You can create Service Fabric clusters anywhere, including Windows Server and Linux on premises and other public clouds.

Service Fabric powers many Microsoft services today, including Azure SQL Database, Azure Cosmos DB, Cortana, Microsoft Power BI, Microsoft Intune, Azure Event Hubs, Azure IoT Hub, Dynamics 365, Skype for Business, and many core Azure services.

Container orchestration

Service Fabric is Microsoft’s container orchestrator for deploying and managing microservices across a cluster of machines, benefiting from the lessons learned running Microsoft services at massive scale. Service Fabric can deploy applications in seconds, at high density with hundreds or thousands of applications or containers per machine. With Service Fabric, you can mix both services in processes and services in containers in the same application.

Stateless and stateful microservices

Service Fabric provides a sophisticated, lightweight runtime that supports stateless and stateful microservices. A key differentiator of Service Fabric is its robust support for building stateful services, either with Service Fabric built-in programming models or containerized stateful services.

Application lifecycle management

Service Fabric provides support for the full application lifecycle and CI/CD of cloud applications including containers: development through deployment, daily monitoring, management, and maintenance, to eventual decommissioning. Service Fabric is integrated with CI/CD tools such as Azure Pipelines, Jenkins, and Octopus Deploy and can be used with any other popular CI/CD tool.

Any OS, any cloud

You can create clusters for Service Fabric in many environments, including Azure or on premises, on Windows Server or Linux. You can even create clusters on other public clouds. The development environment in the Service Fabric SDK is identical to the production environment, with no emulators involved. In other words, what runs on your local development cluster is what deploys to your clusters in other environments.

For Windows development, the Service Fabric .NET SDK is integrated with Visual Studio and PowerShell. For Linux development, the Service Fabric Java SDK is integrated with Eclipse, and Yeoman is used to generate templates for Java, .NET Core, and container applications.