It all sounds important...but also a little confusing. Like, why are there so many moving parts? And what do they actually do?

In this guide, we’re going to break it all down – step by step – using real examples and simple language.

You’ll learn:

• What load balancers are (and why apps even need them)

• How apps were deployed before load balancers existed (hint: everything lived on one lonely server)

• How Azure Virtual Machines work – and how they let you scale up your apps

• What Virtual Machine Scale Sets are, and how they help handle sudden traffic spikes

• The differences between Azure Load Balancer and Azure Application Gateway, and when to use each

By the end, you won’t just understand what these tools do – you’ll know when and why to use them in real-world scenarios.

Whether you’re a curious beginner, a hands-on builder, or someone just trying to wrap their head around Azure’s ecosystem, this guide is for you.

Ready to untangle the cloud spaghetti? Let’s go! 🍝🚀

📚 Table of Contents

1. 🧊 What Are Load Balancers?

2. 🖥️ How Applications Were Deployed Before Load Balancers

3. ⚙️ Azure Virtual Machines (VMs) – The Building Blocks

4. 📈 The Need for Scaling – Vertical vs Horizontal

5. 🔁 Azure Virtual Machine Scale Sets (VMSS) – Scaling Made Simple

6. 📦 Azure Load Balancer – Spreading the Traffic

7. 🍴 Azure Application Gateway – Smart Routing for Modern Apps

8. 🔍 Azure Load Balancer vs Azure Application Gateway

9. 🧭 Use Cases: When to Use Each One

10. ✅ Conclusion

11. Study Further 📚

12. About the Author 👨‍💻

🧊 What Are Load Balancers?

Imagine you're running a small restaurant with just one chef in the kitchen. Everything goes smoothly when you have a few customers – each order is prepared one after the other, and everyone leaves satisfied.

But what happens when 50 people walk in all at once?

🍽️ One chef can’t handle that many orders at the same time.
⏳ People start waiting longer.
😤 Some customers leave.
💥 The chef gets overwhelmed – and eventually burns out.

This is what can happen to a server (the computer running your app) when too many users try to access it at the same time.

So, What Does a Load Balancer Do?

A load balancer is like a smart restaurant manager. But instead of food orders, it handles user requests – the things people do when they open your app, click buttons, or load data.

Let’s say you now have three chefs (servers) instead of one. The load balancer’s job is to:

• 👀 Watch for incoming orders (user requests)

• 🧠 Decide which chef (server) is available or least busy

• 🍽️ Send that request to the right one

• 🔁 Repeat this over and over, making sure things stay fast and smooth

So in simple terms, a load balancer takes all the incoming traffic to your app and distributes it across multiple servers so no single server gets overloaded – cool, right? 🙂

Why Were Load Balancers Introduced?

Back in the early days, many applications were hosted on just one machine – called a Single Server Deployment.

That was okay when you had a small number of users. But once things started to grow – more users, more actions, more data – single servers became a bottleneck:

• They could only handle a limited number of requests.

• If they went down, your entire app would stop working.

• Scaling (adding more power) was expensive and manual.

💡 Enter load balancers – designed to solve this by making it possible to:

• Spread traffic across multiple servers (so no one server crashes under pressure),

• Replace or restart servers without downtime,

• Add or remove servers as needed, depending on how busy your app is (this is called scaling).

A Simple Use-Case Scenario

Let’s say you're building an online store — your own mini Amazon. At first, you host your app on one Azure Virtual Machine. Things are great. But one day, you run a huge promo and suddenly…thousands of people flood in to browse, shop, and check out.

Your single VM starts lagging.

Orders fail. People complain. Your dream app? Crashing fast. 💥

So what do you do?

You spin up two more VMs to help out – but now you’ve got another problem: How do you divide the traffic between the three?

This is where the load balancer steps in. It:

• Looks at every incoming user request

• Figures out which VM is available and least busy

• Sends the request there

• Keeps rotating requests in real-time

And the result?
✅ No single VM gets overwhelmed
✅ Your app stays fast and responsive
✅ Users are happy (and buying stuff again!)

🖥️ How Applications Were Deployed Before Load Balancers

Before cloud tools like load balancers came along, the typical way to run an application was pretty simple: You’d deploy the entire app on a single server, like running a small business from one tiny shop.

First Things First: What’s a Server?

Think of a server as a special computer that’s always connected to the internet. Its job is to “serve” your app to people when they visit your website, open your app, or use your service.

In cloud platforms like Azure, we usually call these Virtual Machines (VMs) – basically, software-powered servers you can spin up with a few clicks.

Monoliths vs Microservices

Now, applications come in different “shapes.” The two most common are:

• Monoliths: Everything is bundled together into one big app. All the code – from user login to shopping cart to checkout – lives in a single unit.

• Microservices: The app is broken into smaller, independent apps (services). Each service does one job – like login, payments, orders – and runs separately.

How Were These Apps Deployed?

Whether it was a monolith or a bunch of microservices, they were all usually deployed on a single server (VM).

For monoliths, you just ran the entire app directly on the server. For microservices: you'd run each service in a separate space on that same server, using containers.

Wait — What’s a Container?

A container is like a mini-computer inside a computer. It has everything an app needs to run – code, tools, settings – and it keeps each app isolated from the others.

Why use containers?

• You can run multiple services on the same server without their underlying software (software needed for each app to run) interfering with each other.

• It’s faster and more efficient than installing everything directly on the server.

• They make moving apps between environments (for example, test → production) super smooth (no more “But, it works on my machine…”).

Popular tools like Docker make working with containers easy.

Connecting It All Together: Domains, Subdomains, and Reverse Proxies

When your app lives on a server, you want people to be able to reach it. That’s where domain names come in.

• Your server has a public IP address – a set of numbers like 102.80.1.23, that gives it a unique identifier on the public internet

• But instead of asking users to type numbers, you link that IP to a domain name, like mycoolapp.com

If your app has microservices, you might even assign subdomains like:

• api.mycoolapp.com for the backend

• dashboard.mycoolapp.com for the user interface

• payments.mycoolapp.com for payments

To manage all this, you’d use a reverse proxy (like Nginx or Apache). It listens on the main domain and subdomains, and forwards traffic to the right app or service.

Example:

• Someone visits dashboard.mycoolapp.com

• The reverse proxy checks the domain and forwards the request to the correct container running the dashboard service

And to help with all of this setup – from deploying containers to configuring reverse proxies – there are developer-friendly tools like Coolify. Coolify is an open-source platform that makes it super easy for developers and DevOps teams to:

• Deploy apps in containers

• Set up domains and subdomains

• Configure reverse proxies – all from a clean dashboard, no complex terminal commands needed

All this was set up on ONE SERVER/VM. But here’s the catch: when that one server got overloaded or went down…💥 everything stopped.

That’s why we needed a better way. And that's where scaling and load balancing came in – to keep apps running smoothly, no matter the traffic.

⚙️ Azure Virtual Machines (VMs) – The Building Blocks

When it comes to running apps in the cloud, Virtual Machines (VMs) are the basic building blocks – kind of like renting an apartment in a giant digital skyscraper.

You don’t need to buy the whole building (aka physical servers), you just rent the space you need, when you need it.

What Exactly Is a Virtual Machine?

A Virtual Machine is a software-based computer that runs inside a real, physical computer (a server) – hosted in a data center, like those run by Microsoft Azure.

It looks and behaves like a normal computer:

• It has an operating system (Windows, Linux)

• You can install apps

• It has memory (RAM), storage (disks), and CPU

But the best part? You don’t need to worry about the hardware. Azure takes care of that behind the scenes – all you do is say:

“Hey Azure, give me a Linux VM with 4GB RAM and 2 CPUs.”

And boom 💥 — it spins up in minutes.

Why Use a VM?

Let’s say you’ve built a web app – it’s just a simple blog. You want to deploy it and make it accessible to the world.

Here's what you can do with a VM:

• Set it up with your favorite OS (for example, Ubuntu)

• Install web servers like Nginx or Apache

• Deploy your app

• Bind it to your domain name

• Let the world visit your blog at myawesomeblog.com

It’s your own personal environment – no sharing, full control.

📈 The Need for Scaling – Vertical vs Horizontal

Imagine your app is growing. At first, it’s just a few users. Then a few hundred. Then thousands are logging in, placing orders, chatting, uploading photos – all at once 😮

Suddenly, your server (VM) is under pressure. It’s like trying to pour a flood through a straw.

So, What Do You Do When One Server Isn’t Enough?

This is where scaling comes in – the art of upgrading your app’s infrastructure to keep up with traffic.

There are two main ways to scale:

🧱 Option 1: Vertical Scaling (aka Scaling Up)

You take your existing VM and give it more power:

• Add more CPUs 🧠

• Increase RAM 🧵

• Add faster disks ⚡

Think of it like upgrading from a regular car to a sports car. It’s the same vehicle, just faster and stronger.

Pros:

• Simple to do

• No major changes to your app setup

Cons:

• There’s a limit to how much you can upgrade

• Still a single point of failure: if the VM crashes, everything goes down 😬

🧩 Option 2: Horizontal Scaling (aka Scaling Out)

Instead of boosting one server, you add more servers – multiple VMs running copies of your app.

Now:

• Users can be distributed across all these VMs

• If one goes down, others keep serving traffic

• You can dynamically add or remove VMs based on traffic

It’s like opening more checkout counters in a busy supermarket 🛒

Pros:

• The load is evenly distributed. For example, if one server previously handled 100% of the traffic, adding two more servers would result in the traffic being split into approximately 33% to 34% for each server.

• Improves both performance and reliability

• You can scale based on real-time demand, that is traffic inflow

Cons:

• Needs something to split traffic between VMs – Load Balancers

• More expensive. You end up paying the original amount for 1 VM (for example $30) for the number of VMs you provide – if you provide 3 VMs at $30 each, you end up paying $90 at the end of the month

Quick Real-World Example

Let’s say you’ve launched an e-commerce site for sneakers 👟 Traffic spikes during a big sale? Your vertical scaling (bigger VM) might choke.

But with horizontal scaling:

• You spin up 5 VMs across different regions

• Traffic is shared between them

• If one VM slows down, others handle the load

So, remember 👇🏾

🔁 Azure Virtual Machine Scale Sets (VMSS) – Scaling Made Simple

Okay – so we’ve talked about horizontal scaling: adding multiple VMs to handle growing traffic. Sounds great, right?

But here’s the thing: manually spinning up and configuring 5, 10, or 100 VMs... every time your app gets busy? Yeah, that’s not fun 🙃

Enter: Virtual Machine Scale Sets (VMSS)

VMSS is Azure’s way of automating horizontal scaling. Instead of creating each VM one by one, you define a template, and Azure takes care of the rest:

• How many VMs to start with

• How to configure them (OS, apps, settings) ⚙️

• When to add or remove VMs based on traffic 📈📉

A Simple Analogy 🧃

Think of VMSS like a juice dispenser at a party:

• At first, it pours into 2 cups (VMs)

• If 10 guests show up? It starts filling 5 cups

• Party slows down? Back to 2 cups again

You never have to refill manually – the dispenser adjusts on its own. 🎉

How It Works (Without the Jargon 😌)

1. You set the rules: “If CPU usage goes above 70%, add 2 more VMs.”

2. Azure watches traffic and adjusts the number of VMs automatically.

3. All VMs are identical – like clones, all running the same app setup.

4. It works with Azure Load Balancer to spread traffic across all these VMs smoothly.

Real-Life Example: Food Delivery App 🍕📱

You’ve built an app where users order food. During lunch and dinner, traffic explodes.

💡 With VMSS:

• You start with 3 VMs in the morning

• At 12PM, Azure sees high CPU usage, so it spins up 5 more VMs

• At 3PM, traffic drops, so Azure removes the extra VMs

You only pay for what you use. And users get a smooth experience – no delays, no crashes 👌🏾

📦 Azure Load Balancer – Spreading the Traffic

By now, you know that your app can live on multiple Virtual Machines (VMs), and that you can scale them easily using Virtual Machine Scale Sets (VMSS).

But here's the big question: when users start accessing your app – hundreds, even thousands at once – how do you make sure that all that traffic is fairly and efficiently distributed across those VMs?

You don’t want one VM to be overwhelmed while others are just chilling. You need a middleman – something smart enough to balance the load.

That’s where Azure Load Balancer steps in. It’s Azure’s way of saying, “Don’t worry, I got this” when traffic starts rolling in.

🏢 So, What Is Azure Load Balancer?

Azure Load Balancer is a traffic director. It takes incoming traffic from the internet (or even internal sources within your network) and intelligently spreads it across multiple backend machines – usually VMs.

It's like having a well-trained receptionist who routes every customer to the next available agent, so no one waits too long and no one gets overwhelmed 😃.

And the best part? This entire process happens in the background – fast, silent, and seamless. Users visiting your app have no idea a traffic manager is working behind the scenes. They just see a fast, responsive experience.

🌐 The Frontend IP – Your App’s Public Face

Every Azure Load Balancer is tied to a Frontend IP, which is basically the public IP address of your application – the one users connect to when they open www.yourapp.com.

This IP acts as the entry point. All user traffic comes through it first. But the Load Balancer doesn’t actually run your app. Instead, it accepts the traffic and forwards it to one of the VMs in the backend pool (we’ll get to that shortly).

You can configure this Frontend IP to be either public (accessible over the internet) or private (used for internal traffic within your cloud network – say, between microservices or internal tools).

🗂️ Backend Pool – Where the Magic Happens

Behind every Azure Load Balancer is a backend pool – a group of VMs (or VM Scale Set instances) where your actual app is running. These are the real workers, doing all the heavy lifting.

When traffic hits the Frontend IP, the Load Balancer takes that request and hands it off to one of the VMs in the backend pool.

But it doesn’t just randomly pick one. It checks a few things first – like whether the VM is healthy, whether it's already busy, and what rules you’ve set.

Each VM in the pool typically runs the same app or service. This means any of them can handle any incoming request, which is what makes load balancing possible in the first place.

🩺 Health Probes – Keeping Tabs on the VMs

Now, how does the Load Balancer know which VM is healthy or not? This is where health probes come in. Think of them as regular check-ups.

You configure the Load Balancer to periodically "ping" each VM – maybe by hitting a specific URL (like /health) or a certain port (like 80 for HTTP). If a VM doesn’t respond correctly, Azure marks it as unhealthy and temporarily removes it from the rotation.

This ensures users never get routed to a broken or unresponsive instance of your app. And once the VM becomes healthy again, it's automatically added back to the pool.

⚖️ Load Balancing Rules – Who Gets What?

Next, we have Load Balancing Rules. These are the instructions that tell Azure Load Balancer exactly how to behave.

You can define rules like:

• “Forward all HTTP (port 80) traffic to backend pool VMs on port 80”

• “Forward HTTPS (port 443) traffic to VMs on port 443”

• “Only route traffic to healthy VMs”

These rules make Azure Load Balancer highly customizable. You get to decide how traffic flows, which protocols to support, and how to handle backend ports. It's like customizing the rules of a relay race – who gets the baton and when.

👟 Real-World Example: Sneaker Sale Rush

Imagine you're running an online sneaker store at www.sneakerblast.com. You’re launching a flash sale, and thousands of users are hitting your website all at once.

Thanks to your Azure Load Balancer, here’s what happens:

1. All those users land on your Frontend IP, the public face of your site.

2. The Load Balancer accepts the traffic and checks the health probes of all VMs in the backend pool.

3. Based on its rules, it forwards each user to a healthy, available VM.

4. One VM might serve a user in Lagos, another in Nairobi, another in Accra – all seamlessly.

If one VM crashes or lags? The Load Balancer detects it instantly and stops routing traffic to it until it’s back online.

That’s smooth traffic management without any manual effort.

🍴 Azure Application Gateway – Smart Routing for Modern Apps

So far, we’ve seen how Azure Load Balancer helps you split traffic across multiple VMs running a single service – like a monolithic app or a web frontend.

Let’s say you have a web application deployed on a VM. It listens on port 80, and you’ve scaled it into 3 instances. The Azure Load Balancer takes requests from the internet and spreads them across all 3 instances of the same service. Easy, right?

You can even link the Load Balancer’s public IP address to your domain – like mydomain.com – so users can visit your site normally.

🧠 But What If You Have Multiple Services?

Now imagine you’ve gone beyond just one app. You’re building something more modern, like a set of microservices.

You now have:

• A payment service listening on port 5000

• An authentication service on port 6000

• A purchase service on port 7000

All deployed across the same VMs (or Virtual Machine Scale Set), just on different ports.

Here’s the problem: an Azure Load Balancer is designed to route traffic to one backend pool – basically one service – on one port. If you tie it to mydomain.com, it can only send traffic to one of your microservices. 😬

So… what do you do?

You might think: “Let me just create a separate Load Balancer for each service!” 🤕

But that means:

• You’ll have to pay for multiple load balancers

• You’ll end up managing 3–5 public IP addresses

• You might even need to buy multiple domains like mypayment.com, myauth.com, and so on to route users properly

Yikes. That’s impractical, messy, and expensive 😖💸

🎉 Enter Azure Application Gateway

Azure Application Gateway solves this problem beautifully. It’s designed to route traffic intelligently – not just to one service, but to multiple services using just one gateway.

It works like this:

1. You create one public-facing frontend IP (like 52.160.100.5)

2. You link that IP address to your main domain, for example mydomain.com

3. Then, you define multiple backend pools – one for each service:

   • Payment service (port 5000)

   • Auth service (port 6000)

   • Purchase service (port 7000)

4. Next, you set up routing rules that decide how to forward each request.

✨ Two Ways to Route with Application Gateway

You can configure smart routing based on:

• URL paths:

  • mydomain.com/payment → Payment service

  • mydomain.com/auth → Auth service

• Subdomains (host headers):

  • payment.mydomain.com → Payment service

  • auth.mydomain.com → Auth service

This way, all your services share one public IP and one domain – super clean, super efficient 🙌🏾

🤓 Real-Life Scenario (Let’s Break It Down)

Let’s say you’re building a startup platform that has three key microservices:

• Payment service that handles transactions

• Authentication service that handles login and user identity

• Purchase service that manages product ordering

Each service is containerized and deployed on the same VM (or across several VMs using a VM Scale Set). But – and this is key – they all listen on different ports inside the VMs:

• Payment → port 3000

• Auth → port 6000

• Purchase → port 7000

Now, without a smart routing solution, you’d be stuck trying to expose just one of these services using a standard Azure Load Balancer. But you need all three to be accessible from the internet – and you don’t want to pay for or manage 3 different Load Balancers 😅

So, what do you do?

🧠 Using Azure Application Gateway to Route Traffic Intelligently

Here's how you can fix this using one Application Gateway:

1. Deploy your microservices inside each VM:

   • Each service runs on a specific port

   • All VMs in your scale set are identical (they contain all three services)

2. Create backend pools in Application Gateway:

   • A backend pool for the payment service (pointing to port 3000 on all VMs)

   • One for the auth service (port 6000)

   • Another for the purchase service (port 7000)

3. Create routing rules:

   • Option A (Path-based routing):

     • Requests to mydomain.com/payment → go to the payment backend pool

     • Requests to mydomain.com/auth → go to the auth backend pool

     • Requests to mydomain.com/purchase → go to the purchase backend pool

   • Option B (Subdomain-based routing):

     • payment.mydomain.com → payment service

     • auth.mydomain.com → auth service

     • purchase.mydomain.com → purchase service

You just tell the Application Gateway: “Hey, if a request comes in for this URL or subdomain, send it to this port on these VMs.” And it does just that – consistently and intelligently 🔁

📦 So, What’s Really Happening?

Imagine a user visits mydomain.com/auth. Here’s what goes on behind the scenes:

1. The DNS translates mydomain.com to your Application Gateway’s public IP

2. The Gateway receives the request

3. It checks your routing rules

4. It sees that /auth should go to the backend pool for port 6000

5. It forwards the request to one of the VMs running the auth service

6. The response goes back to the user – fast and seamless ✨

This happens in milliseconds, for every request. And because the Application Gateway is aware of multiple ports and services, it can handle routing logic that a regular Load Balancer just can’t do.

🔍 Azure Load Balancer vs Azure Application Gateway

By now, you've seen how both tools help route traffic in Azure – but they solve different problems.

Let’s break down how they compare, and when you should use one over the other 👇🏾

🛣️ 1. Routing Logic

Azure Load Balancer
It simply distributes incoming traffic evenly across a pool of VMs. It doesn’t care what the request is – it just balances the load.

Imagine a delivery guy who doesn't ask questions – he just drops each package at the next available house.

That’s what Azure Load Balancer does: it sends traffic to one of your servers without looking inside the request.

Azure Application Gateway
This is the smart one. It looks at what’s inside each request (like the URL path or domain) and makes intelligent decisions.

Just like a smarter delivery guy who looks at the address and decides where to go: "Oh! This one is for the payment office, not the main office."

That’s what Application Gateway does: it reads the request (like the URL or domain name) and sends it to the right place according to the routing rules.

🌐 2. Protocols Handled

Load Balancer
Works at the transport layer (Layer 4 in the OSI model). It deals with TCP/UDP traffic – raw network traffic, like HTTP, video streaming, games, and so on.

Application Gateway
Works at the application layer (Layer 7). It handles web traffic only – like websites and apps (HTTP/HTTPS) – and it can actually read what's being asked, like:

• “Go to /login”

• “Go to payment.mydomain.com”.

TL;DR: Load Balancer just pushes packets. App Gateway actually reads your web requests.

🔁 3. Use Case Scenarios

🔐 4. SSL Termination & Security Features

Load Balancer doesn’t handle security stuff. You’ll need to secure each server yourself (for example, set up HTTPS on each one).

Application Gateway can secure everything in one place – you upload your SSL certificate once and it takes care of HTTPS for all services.

It can also protect you from hackers and bad traffic with something called WAF (Web Application Firewall), which protects your app from threats like SQL injection, XSS, and so on (you need to set this up manually).

💰 5. Pricing and Complexity

Load Balancer is cheaper and easier to set up. Great when you don’t need anything fancy.

Application Gateway costs more, but gives you more control and less headache when working with complex apps and microservices.

Trying to use Load Balancer for multiple services? You’ll need to create one Load Balancer per service, which becomes costly and impractical.

🧠 Summary Table

🧭 Use Cases: When to Use Each One

There’s no one-size-fits-all when it comes to hosting apps in the cloud. The right setup depends on what you’re building, how much traffic you expect, and how complex your app is.

Let’s walk through 4 different use-case scenarios, starting from the most basic setup all the way to a fully auto-scaled and smartly routed architecture.

1️⃣ Single VM Instance – For Small Projects or Internal Tools

Use this when:
You're just getting started. You’ve built a small app – maybe a portfolio, a blog, or a side project – and you want to make it live, OR You’re a startup that just launched.

How it works:
You spin up one Azure VM, install your app on it, and open the port it listens on (for example, port 80 for a web server). You can then attach a public IP to the VM and bind it to a custom domain like myawesomeapp.com.

Real-life examples:

• A developer hosting a portfolio website or blog

• A startup testing a new product with only a few users

• An internal company tool for a small team

Pros:

• Super simple setup

• Low cost

• Full control of your environment

Cons:

• If the VM goes down, your app goes down

• No auto-scaling – performance may drop with traffic spikes (the only way to adapt to increased CPU/memory usage due to traffic inflow is via manually scaling the VM vertically)

• You manually maintain and monitor everything

2️⃣ Manual Horizontal Scaling – For Apps With Medium, Predictable Traffic

Use this when:
Your app is growing – maybe you have a few thousand users now, and performance matters. You want more than one server so your app doesn’t crash during busy hours.

How it works:
You manually create 2 or 3 Azure VMs with the same app setup. You then add a Load Balancer in front to split traffic evenly across them.

Real-life examples:

• A business with a customer portal

• A school website that handles regular logins, lecture video streaming, and so on during class hours

• An app that gets traffic mostly during the day (predictable load)

Pros:

• Better performance and availability

• Load is shared across multiple VMs

• You can scale manually when needed

Cons:

• You must manually add or remove VMs – which takes effort

• Still need to monitor performance manually

• No built-in automation or auto-healing

3️⃣ Auto-Scaling with VM Scale Sets + Azure Load Balancer – For Apps With Spiky or Unpredictable Traffic

Use this when:
You’re building something more serious – traffic comes in waves (for example, a fitness/coach booking app), and you don’t want to sit around scaling VMs all day. You want Azure to automatically scale your infrastructure for you.

How it works:
You set up a Virtual Machine Scale Set (VMSS) that can automatically create more VMs when needed (like during high traffic), and remove them when things are calm — saving money. A Load Balancer distributes traffic across all those VMs.

Real-life examples:

• A media platform where people upload videos or photos

• A shopping site that gets surges during promotions, for example Black Fridays

• A booking platform with peak traffic in evenings/weekends

Pros:

• Automatic scaling – saves time and money

• High availability: VMs can be replaced if one fails

• Easy to grow as your user base grows

Cons:

• Works best if your app is monolithic (one big service)

• No support for routing traffic to specific services – just spreads traffic across VMs

• Load Balancer can’t look at URL paths or subdomains

4️⃣ VM Scale Set + Azure Application Gateway – For Microservices or Complex Web Apps

Use this when:
You have a modern, multi-service app – maybe built with microservices. Each service (like payments, authentication, search, and so on) lives on a different port or even in a container.

You want to route traffic smartly – like /login goes to the auth service, /pay to payments, and /search to the search service – all on the same domain.

How it works:
You still use a VM Scale Set for auto-scaling, but instead of a basic Load Balancer, you add an Application Gateway. It can inspect each request and send it to the right service based on things like:

• URL path (for example, /payments, /orders)

• Subdomain (for example, payments.mydomain.com, auth.mydomain.com)

Real-life examples:

• A full-blown SaaS product with multiple services

• An e-commerce site with checkout, account, orders, and admin dashboards

• A business migrating from a monolith to a microservices setup

Pros:

• Smart routing based on path or subdomain

• Everything runs under one public IP and one domain

• Secure HTTPS handling + optional Web Application Firewall (WAF)

• Auto-scaling and high availability

Cons:

• More complex setup

• Slightly higher cost due to Application Gateway

• Needs planning around port numbers and backend pools

🧠 Quick Summary Table

✅ Conclusion

By now, you’ve gone from simply hearing the words “load balancer” or “scale set” to understanding exactly how they work, when to use them, and what problems they solve. Whether you’re just launching a small app or scaling up a high-traffic service, Azure gives you flexible, powerful tools to grow with confidence.

We started from the very beginning – a single virtual machine. It’s simple and great for small apps, but it quickly becomes a bottleneck as traffic grows.

That’s where scaling comes in. We explored:

• 🧱 Vertical scaling – Upgrading the same VM (quick fix, but limited)

• 🧩 Horizontal scaling – Adding more VMs to handle traffic better

Then we introduced Azure Virtual Machine Scale Sets (VMSS) – which bring auto-scaling to life. No more manual intervention – Azure can scale your servers up and down based on demand.

But where things really get smart is with load balancers:

• 📦 Azure Load Balancer helps spread traffic across your VMs — great for single-service apps

• 🍴 Azure Application Gateway takes it further by routing requests based on URL paths or subdomains — perfect for multi-service or microservice apps

🎯 TL;DR – What Should You Use?

• Single VM: For side projects, portfolios, or internal tools

• Manual scaling + Load Balancer: For medium apps with predictable load

• VMSS + Load Balancer: For monolithic apps with auto-scaling needs

• VMSS + Application Gateway: Also includes auto-scaling but for microservices or smart routing needs

💡 Final Thoughts

Cloud apps grow – fast. And with growth comes complexity. But with the right Azure setup, you can stay one step ahead of your traffic, serve users better, and keep costs under control.

Remember: you don’t need to start big. Start small, understand your app's traffic patterns, and scale only when you need to. Tools like Azure VM Scale Sets, Load Balancer, and Application Gateway give you the control and power to build scalable, modern applications without over-engineering.

Thanks for sticking with me through this deep dive. I hope this made things clearer, simpler, and maybe even a little fun 😊

Study Further 📚

If you would like to learn more about Azure Virtual Machines, Scale Sets, Load Balancer, and Application Gateway, you can check out the courses below:

• Microsoft Azure Fundamentals AZ-900 Exam Prep Specialization — Microsoft, Coursera

• Azure Virtual Machine Tutorial | Creating A Virtual Machine In Azure | Azure Training | Simplilearn — YouTube

• Virtual machine scale sets — YouTube

• Azure Load Balancer | Azure Load Balancer Tutorial | All About Load Balancer | Edureka — YouTube

• Azure Application Gateway Deep dive | Step by step explained — YouTube

About the Author 👨‍💻

Hi, I’m Prince! I’m a DevOps engineer and Cloud architect passionate about building, deploying, and managing scalable applications and sharing knowledge with the tech community.

If you enjoyed this article, you can learn more about me by exploring more of my blogs and projects on my LinkedIn profile. You can find my LinkedIn articles here. You can also visit my website to read more of my articles as well. Let’s connect and grow together! 😊

I hope you're doing well. Whether you're a seasoned coder, a curious learner, or just someone browsing through, welcome to my little corner of the internet.

In this tutorial, we’ll dive into how you can deploy a web service on Microsoft Azure app service. It’s a topic I’ve been excited to explore, and I hope you’ll find it insightful and helpful. So grab a coffee, sit back, and let’s get started.

Prerequisites

• Basic understanding of RESTful web services

• Programming knowledge

• Docker basics

• Docker Hub account

• Command Line Interface (CLI) skills

What we’ll cover:

• Key Terminologies

• How to Install Docker and Docker Compose

• How to Create a Simple Get Client Info Web Service

• How to Build the App’s Docker Image

• How to Run the App in the Container

• How to Create an Azure Resource Group on Azure Portal.

• How to Deploy to Azure App Service

• Conclusion

Before we actually get started, I’d like to go over some key terminologies that I'll be using throughout this tutorial. Understanding these terms will make it easier to follow along and get the most out of what we're discussing. Let’s dive in!

Key Terminologies

1. Docker

Docker is an open-source platform that simplifies application development, shipping, and deployment by using containers. With Docker, there are three key things you can do:

• build once and run anywhere

• keep environment consistent, and

• easily scale your application with container orchestration tools like Kubernetes.

2. Docker Hub

Docker Hub is a cloud-based repository where developers can store, share, and manage Docker images. You can think of it as the GitHub for Docker images 😉.

3. Docker Image

A Docker image is a lightweight, standalone, and executable package that includes everything needed to run a piece of software. You can also think of it as a blueprint for creating and running a container.

Once built, an image is immutable, meaning it cannot change after creation. Instead, you create a new version when updates are needed. This means that you’ll need to rebuild if you update the code that’s being run in the container.

4. Container

A container is a running instance of a Docker image. It provides an isolated environment where an application runs with all its dependencies, without interfering with the host system or other containers.

Wait, what?! 😕 Well, simply put, a container is like a tiny virtual machine that runs the built Docker image. But unlike traditional VMs, it has no init process (PID 1), meaning it always runs on a host system rather than being fully independent. By now, you should be getting the idea: no image, no container. A container depends on an image to exist. You have to cook before you serve, right? 🍽️

5. Azure Resource Group

An Azure resource group refers to a store or folder containing all related resources for an application you want to deploy to production using MS Azure Cloud. For example, if I want to deploy an eCommerce web app with MS Azure, I could create a resource group called EcommWebAppRG. I’d use this to create all the resources I needed for the web app to go live and be accessible – like VMs, DBs, caches, and other services.

Alrighty, now that all the terms are out of the way, lets get started with the tutorial so you can learn how to deploy a web service on Azure App Service.

Since we are deploying an app, let’s start by creating simple REST API app. I’ll be using Golang for the API development, but you can use any programming language/framework of your choice. If you’d like to follow along with the app for this tutorial, I’ve provided the source code here.

How to Install Docker and Docker Compose

To install Docker and Docker compose on your PC, for Mac and Windows you’ll need to download Docker desktop for your Operating System here.

For Linux, you can run the following command:

sudo apt update # update apt registry
sudo apt install docker.io # for docker engine
sudo apt install docker-compose-plugin

After downloading the Docker desktop for your application, open your terminal and enter the following command to verify that Docker and Docker Compose have been successfully installed on your machine:

docker-compose -v # this should show the version of docker compose cli you have on your PC

My Docker Compose version is:

Docker Compose version v2.31.0-desktop.2

docker -v

You should see something similar if Docker has successfully been installed on your machine:

Docker version 27.4.0, build bde2b89

How to Create a Simple Get Client Info Web Service

Alright, I’ll use this handy tool called sparky_generate to generate the app code template. sparky_generate is a command line tool used to generate boilerplate code for backend development using various backend languages and frameworks.

Use this command to install and setup the tool on your Mac or Linux machine. If you are on Windows, you can use WSL.

wget https://raw.githubusercontent.com/Ayobami6/sparky_generate/refs/heads/main/install.sh

chmod 711 install.sh
./install.sh # run the install command like so

sparky # run the sparky command like so

You should see something similar to the below. Select whatever framework you want to use for your backend service.

I will select Go, because I’m using Go for this tutorial. You should have your project template ready once you’ve selected your framework. I won’t go through how to code the web service since it’s out of scope for this tutorial. The goal here is to deploy on Azure using Azure App Service.

How to Build the App’s Docker Image

To build the Docker image for our app, we first need to create a Docker file that will include all the steps needed to build the image.

touch Dockerfile

We will be using a multistage Docker build to reduce the size of our Docker image. We need something as light as possible.

The multistage Docker build helps reduce size because we use different stages for different concerns. This helps ensure that only what’s needed runs the application in the final stage. For example, we might need certain artifacts to build the application, but we don’t need them to run the application. This is why we have the builder and runner stages in the Docker file below.

Our first stage (build) is concerned with building and bundling the application. The second stage (runner) is just used to run the executable we built in the first stage. So basically all files, modules, and so on used in the build process will be discarded in the runner since they’ve already served their purposes.

# using the first stage as build
FROM golang:1.23-alpine AS build # using alpine base image to reduce size

# install git on the machine
RUN apk add --no-cache git

# setting the current work directory on the vm to be /app
WORKDIR /app

# Copying all go dependency files to the working directory
COPY go.mod go.sum ./

# Install go dependencies
RUN go mod download

# copy all remaining files to the working directory
COPY . .
# build the execuatable

# build the go program
RUN go build -o api cmd/main.go

# stage 2 AKA the runner
FROM alpine:3.18

RUN  apk add --no-cache ca-certificates

# copy the go executable to the working directory
COPY --from=build /app/api .

# expose the service running port
EXPOSE 6080

This Dockerfile outlines all the steps for building a Docker image for our app. Lets go through all these steps line by line. Because we are using a multistage build here, our stages are build and runner.

• The first stage build starts from the first FROM golang:1.23-alpine AS build. It initializes a stage with all the steps in the stage. It states that the base image to be used for all the steps in this stage should use a pre-existing golang:1.23 image using an Alpine Linux distro to run all the steps in the stage.

• Next, we have RUN, which is used to run the command apk add git, followed by setting the working directory to the /app folder.

• Then we have the COPY command that copies all the Go dependencies that will run the Go program.

• Following that is RUN go mod download which is used to install all the dependencies.

• We then have the command COPY . . to copy all the files to the working directory /app of the image

• Then the last step in the build stage, RUN go build -o api cmd/main.go, builds the app code main.go to an executable API. The second stage “runner“ uses an alpine:3.18 base image, and also uses the RUN directive to add ca-certificates to the Alpine base image. The COPY is used here to copy just the built executable file from the builder image to the runner image.

• We then expose port 6080 so our built container can accept an HTTP connection from port 6080.

Now, let’s write our docker-compose.yml file to define and run our containerized service::

services:

  client_info_app:
    build: 
      context: .
      dockerfile: Dockerfile
    container_name: info_app

    ports:
      - "6080:6080"

    command: "./api"

Understanding the YAML Structure

YAML follows a key-value structure similar to a dictionary or hashmap. In our file, the top-level key is services, which acts as the parent key. Within services, we define individual service configurations.

In this case, we have a single service named client_info_app, which contains the necessary properties for Docker to build and run it.

• build: This specifies how to build the Docker image for the service. The context: . tells Docker to look for the Dockerfile in the same directory as the docker-compose.yml file.

• container_name: This assigns a custom name (info_app) to the running container, making it easier to reference.

• ports: Defines the port mappings between the host and the container. The - before "6080:6080" indicates that multiple mappings could be listed. Here, port 6080 on the host is mapped to port 6080 inside the container.

• command: Specifies the command to execute inside the container once it starts. In this case, it runs ./api.

This structure allows us to define and configure multiple services within the services key if needed, but for now, we are only defining client_info_app.

How to Run the App in the Container

You can use this command to start the container:

docker-compose up client_info_app

The above command will first build the image if it doesn’t exist. Then it runs it, because remember: no image, no container.

If all looks good, you should have something similar to this, depending on your application framework:

You should also verify that your Docker image has been built as well. To do that, run the following:

docker images

Voilà! You now have your Docker image built and ready for deployment on Azure App Service.

Let’s go on to the Azure Portal to deploy the app.

Note: if you don’t have an active Azure Subscription, that’s fine – you can still follow along. If you want to get a trial account, you can get one here.

How to Create an Azure Resource Group on Azure Portal.

As a reminder, an Azure resource group refers to a store or folder containing all related resources for an application you want to deploy to production using MS Azure Cloud. Now let’s go about creating one.

When you login to the Azure portal, you should see some like this, the dashboard:

Search for Resource group using the search bar:

Click on Create to create a new resource group:

Give your resource group a name and select a region for it. Here I will use the default East US 2, but you can use any you want. Then click on Review + create.

You should see something like the above after creating the resource group.

How to Deploy to Azure App Service

Ok now that we’ve created the resource group, let’s go ahead and create the Azure App Service. To do this, navigate back to the dashboard and click on Create a resource.

You can search for Web App if you don’t see it in the list there. Then click on the Create Web App option:

Here, select the resource group you created earlier, give the app a name, then select Container for the Publish option.

Before you click on Create, go back to your dev workspace (VS Code or whatever IDE you are using) to push your Docker image to Docker Hub so you can add it there before proceeding to the next steps.

But why do you need to push to Docker Hub? Well, first of all, for accessibility – so we can easily share it with others or have other services access it (which is what we need here).

Remember how I compared Docker Hub with Github earlier? Docker Hub helps you host your Docker image on the internet and make it available for others or for various services on the internet to access if you make it public. Otherwise it’s limited to only authorized services.

To push the Docker image to Docker Hub, you first need to tag the Docker image with your Docker Hub username. Go to Docker Docker Hub to register and get your username if you don’t have one.

Run the following:

docker tag client_info_webservice-client_info_app:latest ayobami6/client_info_webservice-client_info_app:latest
# this adds the latest tag to your docker image

This shows that you successfully tagged your image with the latest tag.

Before you actually push the image to Docker Hub, go ahead and login to it with the Docker CLI.

docker login # this will prompt for browser authetication, for the prompt and login your account with your usernam and password

Push the image to Docker Hub like this:

docker push ayobami6/client_info_webservice-client_info_app:latest

You should see something like the below once you enter the push command on Docker Hub.

Alright, now that you have the Docker image on Docker Hub, you can go ahead and deploy it using Microsoft Azure App Service.

Click on the container on the top menu bar to configure the container settings.

Here, select Other container registries.

Select public, because your pushed image is public (meaning it’s publicly accessible over the internet).

Add your Docker image and tag. You can get this when you run the command docker images.

λ MACs-MacBook-Pro ~ → docker images
REPOSITORY                                        TAG         IMAGE ID       CREATED         SIZE
ayobami6/client_info_webservice-client_info_app   latest      a14f2a5b3bd4   2 weeks ago     30.8MB
postgres                                          13-alpine   236985828131   4 weeks ago     383MB
glint_pm_frontend-nextjs                          latest      424233ceaa4b   4 weeks ago     1.72GB
flask_app-flask_app                               latest      ff6ecfc4ba5a   5 weeks ago     203MB
nginx                                             latest      124b44bfc9cc   7 weeks ago     279MB
encoredotdev/postgres                             15          58b55b0e1fc7   10 months ago   878MB
λ MACs-MacBook-Pro ~ →

Copy the repository name and tag – in my case I have ayobami6/client_info_webservice-client_info_app and tag latest → ayobami6/client_info_webservice-client_info_app:latest.

Then add your startup command. If you are not using Go for the development like I am, your startup command will be different – so just use the command you added to your Docker compose command key, like so command: "./api". Copy just the value (mine is ./api) don’t add the double quotes, and add it to the startup command.

This start up command is the command that will start the application from the container and get the container running.

Click on review and create to create the service.

Once the deployment is complete you’ll be redirected here:

Congratulations! You’ve successfully deployed your web service to Azure App Service. You can visit your app using the default domain from the overview. Mine is here.

Conclusion

Deploying a RESTful web service on Microsoft Azure App Service is a powerful way to leverage cloud technology for scalable and efficient application hosting.

Understanding key terms like Docker, Docker Hub, and Azure Resource Groups will help you streamline the deployment process.

This guide walked you through creating a simple web service, building a Docker image, and deploying it on Azure. By following these steps, you can confidently deploy your applications, ensuring they are accessible and performant.

Thank you for following along, and I hope this tutorial has been insightful and helpful in your cloud deployment journey. If you found it useful, feel free to share it with others who might benefit from it. Happy coding and deploying!

Stay tuned for more insightful content, and let's continue learning and growing together. Cheers to building smarter, more efficient solutions with Azure.

You're not alone in this. I’ve faced this exact issue, and I was able to solve it with the help of a spare VM. So the only thing you'll need is a spare PC somewhere that you can access.

Here, I'm using Azure, but the process should be fairly simple for other cloud providers as well. Even if you have a homelab with your old PC or something that you can SSH into, the only thing you'll have to change is the commands that deal with Azure. Everything else should work just fine.

And the best part? We will be doing everything inside a Docker container. So if you ever want to remove all the AI models, just remove the container, and you're all set. Even your VM is not going to install anything locally, pure Docker! 👌

In this article, I will show you how to host local LLMs with Ollama in a Docker container on an Azure Virtual Machine.

What you will learn: 👀

• How to use Ollama to run multiple LLMs on a single machine.

• How to set up ollama and ollama-webui containers with docker-compose.

• How to create a VM on Azure and configure everything using the Azure CLI.

• How to restrict Azure VM access to your public IP using Azure CLI.

By the end of the article, you will have a fully functional Azure VM capable of running all your chosen AI models (dependent on its specs, of course).

Table of Contents

• How to Set Up the Environment

• How to Set Up the Azure Virtual Machine

  • Create a Resource Group

  • Create the Virtual Machine

  • Get the Virtual Machine Public IP

  • Configure the VM Network to Allow Access Only from the User's IP

• How to Set Up the VM for Running AI Models

  • Set Up the Virtual Machine

  • Set Up Docker Compose

  • Deploy the Containers

  • Run the LLMs Locally Inside the Docker Container

• Wrapping Up

How to Set Up the Environment

💁 You will mostly be writing Bash, so make sure that you know some basics of shell scripting before moving forward.

Create a folder to keep all your source code for the project:

mkdir run-local-ai-models-docker-azure \
    && cd run-local-ai-models-docker-azure
mkdir azure scripts

Here, the azure directory will hold all the scripts required to work with the Azure VM, and the scripts directory will hold everything needed to set up the VM to run the LLMs.

Create a new .env file in the root of the project with the following environment variables. Make sure you change the size, name, location and the models as you like.

RESOURCE_GROUP="ollama-vm-rg"
LOCATION="eastus"
VM_NAME="ollama-vm"
VM_SIZE="Standard_D2s_v3"
USERNAME="<your-username>"

# This will be used as a backup when we can't fetch the IP
# from the 'api.ipify.org'
IP_ADDRESS="<your-ip-address>"

# Change it to whatever models you like.
OLLAMA_DEFAULT_MODEL="qwen2.5-coder:3b"

# Make sure to use "," when separating multiple models.
OLLAMA_ADDITIONAL_MODELS="deepseek-r1:1.5b,tinyllama:1.1b"

WEBUI_PORT=3000
OLLAMA_PORT=11434

And finally, you need to have Azure CLI installed. Follow the installation instructions shown here to install it locally on your machine.

Once, you have it installed, authenticate the CLI with your Azure account using the following command:

az login

Once you are logged in, the setup is complete, and you can start coding the project. 🎉

How to Set Up the Azure Virtual Machine

In this section, I'll show you how to set up your Azure VM using the Azure CLI az. You'll do everything from making a separate resource group to setting up the network to only allow access from your IP address, and finally, creating the VM.

When creating a new file for this section, make sure you do it in the azure directory.

Create a Resource Group

First, begin by creating a new resource group for your Virtual Machine. But what’s a resource group? Basically, a resource group is like a container that holds related resources, such as the VM, storage, NSGs and all. It helps organize these resources quickly, making it easier to deploy, update, and delete them all at once. In short, just think of it as a way to group related stuff together.

Create a new file called create-resource-group.sh and add the following lines of code:

#!/usr/bin/env bash
set -e

SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
PROJECT_ROOT="$(dirname "$SCRIPT_DIR")"

source "$PROJECT_ROOT/.env"

echo "Creating resource group '$RESOURCE_GROUP' in location '$LOCATION'..."
az group create --name $RESOURCE_GROUP --location $LOCATION

echo "Resource group created successfully."

Notice the set -e command. By adding this, its telling the script to stop if any step causes an error. Without this, the script would keep running even if a step fails, which would lead to errors. Remember this command, as it is in all the scripts you’ll write.

Next, it sources the .env file to access the environment variables. After that, it runs the az command to create a resource group with the given name and location.

Now, run the following command:

bash create-resource-group.sh

To check if it worked, go to your Azure account and look under the Resource groups section for your new resource group.

If you see your resource group on the list, you’re good to go.

Create the Virtual Machine

Now that the resource group is created, you can now move forward to creating the virtual machine itself. This script is also going to be fairly similar to the earlier one.

Create a new file called create-vm.sh and add the following lines of code:

#!/usr/bin/env bash
set -e

SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
PROJECT_ROOT="$(dirname "$SCRIPT_DIR")"

source "$PROJECT_ROOT/.env"

VM_EXISTS=$(az vm show --resource-group $RESOURCE_GROUP --name $VM_NAME --query "name" -o tsv 2>/dev/null || echo "")

if [ -n "$VM_EXISTS" ]; then
    echo "VM '$VM_NAME' already exists in resource group '$RESOURCE_GROUP'."
    echo "Please choose a different VM name or use the existing VM."
    exit 1
fi

echo "Creating VM '$VM_NAME'..."
az vm create \
  --resource-group $RESOURCE_GROUP \
  --name $VM_NAME \
  --image Ubuntu2204 \
  --admin-username $USERNAME \
  --generate-ssh-keys \
  --size $VM_SIZE \
  --public-ip-sku Standard

# The above command generates the ssh key as "id_rsa", if you already
# have a key called id_rsa in the ~/.ssh directory, make sure to name it to something else
ssh-add ~/.ssh/id_rsa

echo "VM created successfully."

First, it checks if a VM with the same name is already in the resource group. If it isn't, then it creates a new VM there, providing details like size, image, username, and asking it to generate an SSH key which it will use to log in to the VM.

I chose Ubuntu because, in another section where you’ll set up Docker, I’ve used Debian steps. If you want to use a different distro, make sure to update that script, too.

Now, run the following command:

bash create-vm.sh

After running the command, under the VM section, you should see your newly created VM.

There you have it, the VM is up and running. You could manually go into the VM and set it up, but I will show you how to automate all of these steps as well, because we are devs, remember? 😉

Get the Virtual Machine Public IP

So, now that you have the VM created perfectly, it’s time to fetch the public IP of the VM so you can then use SSH to login.

Create a new file called get-vm-details.sh and add the following lines of code:

#!/usr/bin/env bash
set -e

SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
PROJECT_ROOT="$(dirname "$SCRIPT_DIR")"

source "$PROJECT_ROOT/.env"

echo "Getting VM details..."

PUBLIC_IP=$(az vm show --resource-group $RESOURCE_GROUP --name $VM_NAME --show-details --query publicIps -o tsv)

if [ -z "$PUBLIC_IP" ]; then
    echo "Error: Could not retrieve public IP for VM '$VM_NAME'"
    exit 1
fi

echo "VM Public IP: $PUBLIC_IP"
echo "Ollama API endpoint: http://$PUBLIC_IP:$OLLAMA_PORT"
echo "Web UI: http://$PUBLIC_IP:$WEBUI_PORT"

echo "PUBLIC_IP=$PUBLIC_IP" > "$PROJECT_ROOT/.vm_details.env"

echo "VM details retrieved successfully."

All it is doing is sourcing the .env and then using the az command to fetch the public IP of the VM and store it in a separate file called .vm_details.env. This way, in other scripts, it doesn't need to fetch the public IP repeatedly and can simply source the file to access it.

Now, run the following command:

bash get-vm-details.sh

Configure the VM Network to Allow Access Only from the User's IP

Now that you have the VM working, there's a slight security issue with it. If you check your VM network settings, you'll see that there is no IP restriction. This means anyone can easily try to SSH into your VM.

Allowing access from any source IP address is definitely not a good idea. You need to configure this to allow access only from your public IP, and also need to configure the port for ollama and ollama-webui.

Create a new file called configure-network.sh and add the following lines of code:

#!/usr/bin/env bash
set -e

SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
PROJECT_ROOT="$(dirname "$SCRIPT_DIR")"

source "$PROJECT_ROOT/.env"

echo "Configuring network security..."

# Get current public IP address with fallback to .env one.
echo "Retrieving current public IP address..."
IP_ADDRESS_CURRENT=$(curl -s https://api.ipify.org || echo "")
if [ -z "$IP_ADDRESS_CURRENT" ]; then
    echo "Warning: Could not retrieve IP from api.ipify.org, falling back to .env value"
    IP_ADDRESS_CURRENT=$IP_ADDRESS
fi

echo "Using IP address: $IP_ADDRESS_CURRENT"

NSG_NAME=$(az network nsg list --resource-group $RESOURCE_GROUP --query "[?contains(name, '${VM_NAME}')].name" -o tsv)
if [ -z "$NSG_NAME" ]; then
    echo "Error: Could not find NSG for VM '$VM_NAME'"
    exit 1
fi

create_or_update_nsg_rule() {
    local RULE_NAME=$1
    local PORT=$2
    local PRIORITY=$3

    RULE_EXISTS=$(az network nsg rule list --resource-group $RESOURCE_GROUP --nsg-name $NSG_NAME --query "[?name=='$RULE_NAME'].name" -o tsv)

    if [ -z "$RULE_EXISTS" ]; then
        echo "Creating new rule: $RULE_NAME for port $PORT..."
        az network nsg rule create --resource-group $RESOURCE_GROUP --nsg-name $NSG_NAME \
            --name "$RULE_NAME" \
            --protocol tcp --direction inbound --priority $PRIORITY \
            --source-address-prefix $IP_ADDRESS_CURRENT --source-port-range "*" \
            --destination-address-prefix "*" --destination-port-range $PORT \
            --access allow
    else
        echo "Updating existing rule: $RULE_NAME with new IP address..."
        az network nsg rule update --resource-group $RESOURCE_GROUP --nsg-name $NSG_NAME \
            --name "$RULE_NAME" \
            --source-address-prefix $IP_ADDRESS_CURRENT
    fi
}

# Check if 'default-allow-ssh' exists
SSH_RULE_EXISTS=$(az network nsg rule list --resource-group $RESOURCE_GROUP --nsg-name $NSG_NAME --query "[?name=='default-allow-ssh'].name" -o tsv)
if [ -n "$SSH_RULE_EXISTS" ]; then
    echo "Updating existing SSH rule (default-allow-ssh) with restricted IP..."
    az network nsg rule update --resource-group $RESOURCE_GROUP --nsg-name $NSG_NAME \
        --name "default-allow-ssh" \
        --source-address-prefix $IP_ADDRESS_CURRENT
else
    # If no default SSH rule, create our own with a different priority
    create_or_update_nsg_rule "SSH_Restricted" 22 1010
fi

# Configure rules for Ollama and Web UI
echo "Opening ports for Ollama API and Web UI (restricted to your IP)..."

create_or_update_nsg_rule "Port_${OLLAMA_PORT}_Restricted" $OLLAMA_PORT 1001
create_or_update_nsg_rule "Port_${WEBUI_PORT}_Restricted" $WEBUI_PORT 1002

echo "Network security configured successfully."
echo "Note: If your IP address changes, you'll need to run this script again to update the rules."

Don't be scared by this script. It might seem complex, but it's actually pretty straightforward. The first thing it does is try to get the user's IP address. It first attempts to fetch the user's IP from a service called api.ipify.org (because public IPs can change frequently), which returns your current public IP. If there's an error, it falls back to using the IP address stored in the .env file.

Next, it tries to get the VM's NSG (Network Security Group) because it's needed when creating a new NSG rule. If there’s an error, there's no point in continuing with the script, so it exits with an error status.

There's also a function called create_or_update_nsg_rule, which is used to create a new NSG rule if it doesn't exist. If it does exist, it simply updates it to allow access only from the user's IP address.

Finally, it creates or updates the SSH rule depending on whether it exists. It also sets up the rules for ollama and ollama-webui so you can access the exposed port on your local machine to test the models with ollama-webui.

Now, run the following command:

bash configure-network.sh

After running this command, you can view the changed network settings. There should be two new rules for port 11434 and 3000, and most importantly, you should see that the source IP is limited to your public IP.

Every configuration on the Azure side is now complete. All you need to do next is write a few more scripts to set up running AI models on your configured VM. ✌️

How to Set Up the VM for Running AI Models

Now that all the configuration on the Azure side is complete, in this section, I will show you how you can configure everything on the VM side, from installing Docker to setting up containers, and deploying those containers in the Azure VM you just created.

When creating a new file for this section, ensure you do it in the scripts directory, except for the docker-compose.yaml file.

Set Up the Virtual Machine

Okay, so now that you have a VM up and running with some network settings configured, let’s set this thing up to install and set up Docker and start the service.

Create a new file called setup-vm.sh and add the following lines of code:

#!/usr/bin/env bash
set -e

SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
PROJECT_ROOT="$(dirname "$SCRIPT_DIR")"

source "$PROJECT_ROOT/.env"
source "$PROJECT_ROOT/.vm_details.env"

echo "Setting up VM with Docker and dependencies..."

ssh $USERNAME@$PUBLIC_IP << 'EOF'
  # Install Docker Engine
  echo "Installing Docker..."

  # From Docker documentation for debian based distros
  # Add Docker's official GPG key:
  sudo apt-get update
  sudo apt-get install ca-certificates curl
  sudo install -m 0755 -d /etc/apt/keyrings
  sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
  sudo chmod a+r /etc/apt/keyrings/docker.asc

  echo \
    "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
    $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
    sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
  sudo apt-get update

  sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
  # End of docker debian installation instructions

  sudo usermod -aG docker $USER

  sudo apt-get install -y docker-compose

  sudo systemctl start docker.service

  sudo docker volume create ollama_data

  # Here we will place our docker-compose.yaml file
  mkdir -p ~/ollama-project
EOF

echo "VM setup completed successfully."

And as I said earlier, in this example, I’m using Ubuntu, so I’m following Debian instructions to install Docker. If you are using a different distro, make sure to change the docker setup commands. Then it simply creates a Docker volume because you will want to persist the container state and not lose it every single time.

Now, run the following command:

bash setup-vm.sh

If everything goes well, you should have the Docker engine installed on your machine. You can verify it with the following command:

ssh <YOUR_VM_USERNAME>@<YOUR_VM_PUBLIC_IP> << 'EOF'
    docker --version
EOF

Set Up Docker Compose

Create a new file called docker-compose.yaml at the root of the project – not inside the scripts directory this time – and add the following lines of code:

version: "3.9"
services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ~/ollama_data:/root/.ollama
    environment:
      - OLLAMA_HOST=0.0.0.0
    restart: unless-stopped

  ollama-webui:
    image: ghcr.io/ollama-webui/ollama-webui:main
    container_name: ollama-webui
    ports:
      - "${WEBUI_PORT:-3000}:8080"
    environment:
      - OLLAMA_API_BASE_URL=http://ollama:11434/api
    depends_on:
      - ollama
    restart: unless-stopped

The Docker Compose file should be fairly straightforward to understand. It sets up two services, or rather two containers: ollama and ollama-webui. You need to expose the container port so that you can access it in the VM, whose port is already exposed during the VM network configuration, allowing you to access it on your local machine. Finally, it specifies the Docker volumes and a few environment variables, and that's it.

For the ollama-webui container, it’s necessary for the ollama service to be up and running first, so it depends on the ollama container. After all, what's the point of starting the UI if the service itself is not running, right?

Deploy the Containers

Now that Docker is installed on the VM, it's time to copy the docker-compose.yaml file into the VM and start the containers.

Create a new file called deploy-containers.sh and add the following lines of code:

#!/usr/bin/env bash
set -e

SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
PROJECT_ROOT="$(dirname "$SCRIPT_DIR")"

source "$PROJECT_ROOT/.env"
source "$PROJECT_ROOT/.vm_details.env"

echo "Deploying Docker containers to the VM..."

scp "$PROJECT_ROOT/docker-compose.yaml" $USERNAME@$PUBLIC_IP:~/ollama-project/

ssh $USERNAME@$PUBLIC_IP << 'EOF'
  cd ~/ollama-project
  export WEBUI_PORT=3000
  sudo docker-compose up -d
  echo "Docker containers started successfully."
EOF

echo "Deployment completed successfully."
echo "Web UI available at: http://$PUBLIC_IP:$WEBUI_PORT"

It’s pretty simple here as well. First, it copies the docker-compose file into the ~/ollama-project directory and then spins up the container in detached mode.

Now, the moment of truth. Run the following command, and if everything goes well, you should have two Docker containers running in your VM.

bash deploy-containers.sh

To see if it worked, run the following command to ssh into the VM and execute the docker ps command.

ssh <YOUR_VM_USERNAME>@<YOUR_VM_PUBLIC_IP> << 'EOF'
    docker ps
EOF

Along with some SSH output, you should see something like this, and if both containers' statuses say Up, you're all good.

By now, you should be able to visit this URL (http://<VM_PUBLIC_IP>:3000) to view the Web UI running. But there are no AI models to chat with, so let's fix that.

Run the LLMs Locally Inside the Docker Container

You’re almost there. All that is left is to install some models in Ollama. To install any model, all you need to do is ollama run <MODEL_NAME>. So, let’s do that inside a script that runs that command inside a Docker container, because remember you have Ollama running in a Docker container.

💡 GOOD TO KNOW: You can run any command inside a Docker container from outside using docker exec <CONTAINER_NAME> <COMMAND>. This is perfect for our situation because there's no need to be inside the Docker container. You just need to run one command, and that's all.

Create a new file called run-models.sh and add the following lines of code:

#!/usr/bin/env bash
set -e

SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
PROJECT_ROOT="$(dirname "$SCRIPT_DIR")"

source "$PROJECT_ROOT/.env"
source "$PROJECT_ROOT/.vm_details.env"

if [ -n "$OLLAMA_DEFAULT_MODEL" ]; then
  echo "Running default model $OLLAMA_DEFAULT_MODEL..."
  ssh $USERNAME@$PUBLIC_IP << EOF
    sudo docker exec ollama ollama run $OLLAMA_DEFAULT_MODEL
EOF
  echo "Default model $OLLAMA_DEFAULT_MODEL run successfully."
fi

if [ -n "$OLLAMA_ADDITIONAL_MODELS" ]; then
  echo "additional models $OLLAMA_ADDITIONAL_MODELS..."
  IFS=',' read -ra MODELS <<< "$OLLAMA_ADDITIONAL_MODELS"

  for MODEL in "${MODELS[@]}"; do
    # trim whitespace
    MODEL=$(echo "$MODEL" | xargs)
    echo "Running additional model $MODEL..."
    ssh $USERNAME@$PUBLIC_IP << EOF
      sudo docker exec ollama ollama run $MODEL
EOF
    echo "Additional model $MODEL run successfully."
  done
fi

echo "All models have been processed successfully."

All this script does is first check if the default model is set up in the env with OLLAMA_DEFAULT_MODEL. If it is, the script runs it and also runs any other models separated by commas in the OLLAMA_ADDITIONAL_MODELS env variable.

Now, run the following command:

bash run-models.sh

If everything goes well and you see the final echo message, then hurray! 🎉 You’ve successfully set up running LLMs inside a Docker container in an Azure VM.

Go ahead and refresh the Web UI, and you should see all your LLMs appearing in the list of available models. Choose any one you like and start chatting! 🔥

Wrapping Up

That is it for this one. I hope you enjoyed it and, better yet, understood everything we did together. I build such stuff every other week and document them with blogs. Feel free to check out some of my previous tutorials on DEV and freeCodeCamp.

You can find the complete source code here.

And hey, if you agree with the response from the above qwen2.5-coder model, here are my socials 😉:

• GitHub: github.com/shricodev

• Portfolio: techwithshrijal.com

• LinkedIn: linkedin.com/in/iamshrijal

This course offers an in-depth exploration of Azure AI services, Azure AI Search, and Azure OpenAI, equipping you with the knowledge and skills needed to excel as a Microsoft Azure AI engineer. Andrew Brown of ExamPro developed this course.

Course Overview

The course is structured to guide you through the essential components of the Azure AI Engineer Associate Certification. It begins with an introduction and an exam guide breakdown, setting the stage for a deep dive into the technical and practical aspects of Azure AI.

Here are the key sections of the course:

1. Setup: Learn how to set up your development environment and get acquainted with OpenAI Studio and AI Studio.

2. Gen AI Primer: Understand the differences between AI and Generative AI, foundational models, large language models, and the intricacies of transformer architecture, tokenization, embeddings, and attention mechanisms.

3. ML and AI Concepts: Explore supervised and unsupervised learning, neural networks, deep learning, and the tools like Jupyter Notebooks that facilitate AI development.

4. Responsible AI: Learn about the principles of responsible AI, including fairness, reliability, privacy, inclusiveness, transparency, and accountability. Learn about the Responsible AI Standard V2 and how to apply these guidelines in real-world scenarios.

5. Azure AI Services: Gain hands-on experience with Azure AI Services, including setup, diagnostic logging, and the differences between Azure AI Services and Azure AI Studio. Explore Azure OpenAI Service models, deployment types, and prompt engineering.

6. Azure AI Search: Discover the capabilities of Azure AI Search, including RAG, document cracking, HNSW, and semantic ranking.

7. Text Analytics and Computer Vision: Learn about natural language processing, sentiment analysis, PII extraction, and the capabilities of Azure AI Vision Studio.

8. Custom Vision and Document Intelligence: Understand custom vision project types, features, and object detection, as well as Azure AI Document Intelligence and form recognition.

9. Speech API and AI Video Indexer: Explore the Speech API and AI Video Indexer to enhance your AI solutions with audio and video processing capabilities.

10. Content Safety and Language Understanding: Implement content moderation solutions and explore language understanding with LUIS and QnA Maker.

11. Face Service and Cleanup: Learn about the Face Service and how to effectively clean up your AI projects.

Certification Overview

As a Microsoft Azure AI engineer, you will be responsible for building, managing, and deploying AI solutions that leverage Azure AI. This role involves participating in all phases of AI solutions development, from requirements definition and design to deployment, integration, and maintenance. You will work closely with solution architects, data scientists, data engineers, and other specialists to build secure, end-to-end AI solutions.

The skills measured in the certification include planning and managing an Azure AI solution, implementing content moderation, computer vision, natural language processing, knowledge mining, document intelligence, and generative AI solutions.

Get Started

To start your journey towards becoming an Azure AI Engineer Associate, watch the full course on the freeCodeCamp.org YouTube channel (14-hour watch).

We'll also deploy the application on Azure App Service and make it production-ready by setting up features like autoscaling and multiple environments.

You'll learn how Neon Postgres can make your development and deployment processes easier along the way.

Here's what we'll cover:

• Setting up a Neon Postgres database and exploring its features
• Building a CRUD application using Spring Boot and deploying the application on Azure App Service
• Why Neon is a good fit for infrastructure that auto-scales
• Database branching in Neon Postgres and how it can ease the development workflow

Prerequisites

• Working knowledge of Java, Maven, and Spring Boot
• Basics of SQL databases
• Understanding of serverless and cloud services
• Familiarity with testing and deployment processes

Table of Contents

• What is Neon Postgres?
• How to Set Up the Database
  • Create the Database
• How to Build the Spring Boot CRUD App
  • Create an Entity Class
  • Create a Repository
  • Create a REST Controller
  • Configure the Database
• How to Deploy on Azure App Service
  • Create a New Web App
  • Deploy the Application
  • Access the Application
• How to Set Up Autoscaling
  • Autoscaling in Azure
  • Autoscaling in Neon
• How to Configure Database Branches in Neon
• Summary

What is Neon Postgres?

Neon is a fully managed serverless Postgres database platform. It offers features such as high availability, automatic backups, and scaling options to handle varying traffic levels.

Neon is designed to be cost-efficient and developer-friendly, and it focuses on providing a seamless experience for developers.

In addition to the standard Postgres features, it provides capabilities like database branching, allowing you to create Git-like branches of the database for different purposes.

How to Set Up the Database

To begin with, let's explore how you can set up a Neon database for your application.

Firstly, you'll need to create an account on the Neon website. It doesn't require a credit card to sign up, and you're automatically set up with the free tier to get started.

Here's a pricing and features comparison of Neon plans:

Neon pricing plans

In the free tier, we get 0.5 GB of storage with basic computing which is enough for playing around with the database and building small applications.

Create the Database

Once you've signed up, you can access the dashboard and create a new project.

Star by filling in the project name, region, and Postgres version options. In addition to this, we can choose two additional options:

• compute size – You can choose a min and max compute size for the database. This is useful for autoscaling the database based on the load.
• suspend time – You can set a time after which the database will be suspended if not being used. This is useful for saving costs when the database is not being used.

Creating a database project in Neon

Once you submit the form, Neon will create the database and provide the connection details.

Neon Dashboard

As you can see, the database was set up in 3.3 seconds (compared to hours of installing and setting up your own infrastructure). You can choose multiple ways to connect to the database. For this tutorial, select Java as your programming language and get the JDBC connection string.

How to Build the Spring Boot CRUD App

Next, let's set up our CRUD application. We'll use Spring Boot, as it provides easy bootstrapping and configuration for building web applications.

We can use the Spring Initializr to generate a new Spring Boot project with the necessary dependencies:

• Spring Web – for building web applications
• Spring Data JPA – for working with databases using JPA
• PostGres Driver – for connecting to the Postgres database

Creating a Spring Boot project using Spring Initializer

You can generate, download, and import the project into your favorite IDE.

Create an Entity Class

Let's create an entity class to represent the data in the application. First, create a User class:

@Entity(name = "users")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private String email;

    // Constructors, Getters and Setters
}

The entity name users is the name of the table you want to use in your database.

Create a Repository

Next, create a repository interface to interact with the database. You'll extend the JpaRepository interface provided by Spring Data JPA:

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
}

You need to annotate the interface with @Repository to mark it as a Spring bean. The JpaRepository interface provides methods for CRUD operations like save, findAll, findById, delete, and so on, so you don't need to write the queries manually.

You'll provide your entity class User and the type of the primary key Long as type arguments to the JpaRepository interface.

Create a REST Controller

Finally, create a REST controller to handle the CRUD operations. You'll inject the UserRepository into the controller and implement the necessary endpoints:

@RestController
@RequestMapping("/users")
public class UserController {
    private final UserRepository userRepository;

    public UserController(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @GetMapping
    public List<User> getUsers() {
        return userRepository.findAll();
    }

    @PostMapping
    public User createUser(@RequestBody User user) {
        return userRepository.save(user);
    }

    @PutMapping("/{id}")
    public User updateUser(@PathVariable Long id, @RequestBody User user) {
        user.setId(id);
        return userRepository.save(user);
    }

    @DeleteMapping("/{id}")
    public void deleteUser(@PathVariable Long id) {
        userRepository.deleteById(id);
    }
}

Here are a few things to note:

• You're using the @RestController annotation to mark the class as a controller that handles REST requests.
• The @RequestMapping annotation specifies the base URL for the endpoints.
• You're injecting the UserRepository into the controller using constructor injection.
• Finally, you're implementing your API endpoints for CRUD operations using the @GetMapping, @PostMapping, @PutMapping, and @DeleteMapping annotations.

Configure the Database

To connect your Spring Boot application to the Neon Postgres database, you need to configure the database URL, username, and password in the application.properties file:

spring.datasource.url=jdbc:postgresql://<db-url>/<db-name>?sslmode=require
spring.datasource.username=<username>
spring.datasource.password=<password>
spring.jpa.hibernate.ddl-auto=update

Here, you configured the database URL, username, and password provided by Neon when you created the database. The spring.jpa.hibernate.ddl-auto=update property tells Spring Boot to automatically create the necessary tables or columns based on the entity classes when the application starts.

How to Deploy on Azure App Service

Now that your Spring Boot application is ready, it's time to deploy it on Azure App Service.

Create a New Web App

To deploy your Spring Boot application on Azure App Service, you'll first create a new Web App. You can do this through the Azure portal by following these steps:

• Log in to the Azure portal.
• Click on the Create a resource button.
• Search for Web App and select the Create option.
• Fill in the necessary details like resource group, app name, runtime stack, and region.
• Click the Review + create button.

Creating a Web App in Azure

Deploy the Application

The Web App takes a couple of minutes to create. Once done, you can deploy your Spring Boot application to Azure App Service.

One of the easiest ways to deploy is to package your Spring Boot application as a JAR file and deploy it to Azure App Service using the Azure CLI.

To do this, run the below commands:

mvn package
az webapp deploy --src-path neon-demo-0.0.1-SNAPSHOT.jar --resource-group learn-ba1a439c-71ca-4cab-9bb1-f5b1331bab04 --name neon-app

Here, you're packaging your Spring Boot application using Maven and deploying the JAR file to Azure App Service using the Azure CLI. You've provided the path to the JAR file, the resource group, and the app name you previously configured.

Access the Application

Once the deployment is complete, you can access your Spring Boot application on Azure App Service by navigating to the URL of the Web App. Your app is available at neon-app.azurewebsites.net

Let's use _curl _to test the endpoints.

Create a User

curl -X POST -d '{"name":"John Doe","email":"john@gmail.com"}' https://neon-app.azurewebsites.net/users

Here you provide user data in JSON format to create a new user.

Get Users

You can also can test that the user was created by fetching all users:

curl -X GET https://neon-app.azurewebsites.net/users

How to Set Up Autoscaling

A production application may experience varying levels of traffic, and it's important to scale the application dynamically based on the load.

Let's explore how you can autoscale your application when needed.

Autoscaling in Azure

Azure App Service provides autoscaling options that let you automatically adjust the number of instances as needed.

You can configure autoscaling rules in the Azure portal by following these steps:

• Navigate to the Web App in the Azure portal.
• Click the Scale out (App Service Plan) option from the left menu.
• Configure the autoscaling rules – you can choose predefined rules like traffic or create custom rules based on metrics like CPU usage, memory usage, or custom metrics.
• Save.

Azure will automatically scale the application based on the configured rules.

Autoscaling in Neon

Since your application is automatically scaled based on the load, you'll want to ensure that the database can handle the increased traffic.

Neon provides autoscaling options to scale the database dynamically based on the load. You can configure autoscaling rules in the Neon dashboard to ensure the database can handle the increased load.

Follow the below steps to configure autoscaling in Neon:

1. Navigate to the Neon dashboard and select the database. Then select the branch to configure autoscaling.

Selecting a branch from Neon project dashboard

2. Click on the Edit button next to the Compute section. Configure the autoscaling rules based on metrics like CPU usage, memory usage, or custom metrics.

Branch details view in Neon

3. Configure the min-max compute size and Save. Neon will automatically scale the database based on the configured rules when needed.

Setting up autoscaling for compute

Ensuring that both the application and the database can scale dynamically based on the load will help you handle varying levels of traffic efficiently.

How to Configure Database Branches in Neon

In a typical development workflow, multiple databases may be used for different purposes like development, testing, and production.

Neon Postgres provides database branching to create multiple branches for different purposes. Each branch is an instance of the database that you can use independently.

This Git-like feature helps set up a copy of the database for different environments like development, staging, and production. It also helps preserve data for different versions of the application.

Let's explore how you can create and manage branches in Neon Postgres:

• Navigate to the Neon dashboard and select the database.
• In the Branches section, click on the View All button.
• You can create a new branch from an existing one by clicking on the Create Branch button. You'll need to provide the branch name and what data to copy from the parent branch.

Create branch option

• You can either copy all the data or copy until a point in time or a specific record. This is useful for multiple purposes like restoring data, creating a new environment, or testing new features.

Creating a new branch

• Neon will create a new branch of the database that can be used independently. You can find the URL, username, and password for the new branch in the dashboard. And this happens in real time without any downtime and delays.

Branch-specific connection details

Now you can use your dev branch for local development and testing, and the main branch for production. This helps in keeping the data separate and ensures that changes in one branch do not affect the other branches.

Summary

In this article, we built a CRUD application using Spring Boot, Neon Postgres, and Azure App Service.

We explored how to set up the Neon Postgres database, build a basic CRUD application using Spring Boot, deploy the application on Azure App Service, and configure autoscaling for the application and the database.

We also learned about how the database branching feature in Neon Postgres helps you create branches of the database for different environments and purposes.

Modern-day computing services also provide a wide range of features which make web apps easier to use and more efficient. So it's important for developers to have a basic understanding of how the cloud works.

This article is a beginner's guide to deploying backend applications to the cloud. We'll use the Azure platform as our cloud infrastructure and Node.js/Express for the backend web application. Before we go on, here are a few requirements:

• Basic understanding of cloud computing (you can check out this article to learn more about that).
• Knowledge of JavaScript.
• VS Code.

With that, let's get started.

Introduction to Azure

Azure is a cloud computing platform developed by Microsoft that acts as a server for deploying and hosting web applications, databases, file storage, and so on.

Compared to other cloud computing services, it is quite beginner-friendly and has an actively growing user base. Let’s explore the Azure portal.

How to Set Up Azure Account

Signing up on the Azure platform is the first step to hosting your application. First, navigate to the website and complete the signup process.

Azure sign in page

After signing up, you'll have access to the management console of the Azure application where all our activities can be carried out.

Before we go on, here are some of the services we'll be getting familiar with on this platform.

• Azure Resource groups
• Azure app services
• Storage accounts
• SQL databases
• Virtual networks

Azure services

Congratulations on successfully creating your Azure account.

Deployment Options on Azure

As a cloud computing platform, Azure boasts of its wide versatility. Depending on your skill level or preference, you can deploy web applications to Azure via the following options:

• Azure CLI
• Azure Virtual machines
• Azure Functions
• Azure Kubernetes Service
• Azure Storage.
• Azure DevOps
• Azure portal service

We'll utilize the Azure portal service for this tutorial and use its VS Code integration to deploy a simple Node.js application to the Azure cloud.

How to Set Up the Backend Application

We'll create our web application using Node.js via the command line and Visual Studio Code.

Firstly, navigate to the folder where your app will be created and initialize a Node project by executing npm init

Next, initialize the app by installing the Express framework. This can be done via npm i express.

Go on and paste the sample code for this tutorial:

const express = require("express");
const app = express();

app.use(express.json());

app.get("/", (req, res) => {
    res.send("Hello, World");
});

app.listen(process.env.PORT || 5000, () => {
    console.log("Server is running on port " + (process.env.PORT || 5000));
});

The code above outputs Hello World whenever it is executed.

Application Deployment

The backend code we wrote in the preceding paragraph will be deployed to Azure via the use of Azure’s VS Code extension.

VS Code homepage

Navigate to the Extensions tab, search for Azure App Services and install the extension. On successful installation, an Azure widget will appear on your taskbar where you can sign in to the Azure cloud.

Extensions marketplace

Subsequently, we'll be creating a cloud-based web application in which our Node.js code will later be deployed.

On the Azure resources tab, clicking the plus icon will display a drop-down menu where various development options can be seen. We'll be clicking on the Azure app services option.

Azure drop down menu

After clicking that, a prompt will pop up asking for a unique name for the cloud application. In my case, I went with newApp777.

creating a web application

However, you can use any other name you so wish. Subsequently, you will need to select the backend language of your choice. Any version of Node.js will be compatible with our application.

web stacks available

Also, the F1 service option will be used for this tutorial. However, you can pick anyone you so desire.

Various Azure tiers

On successful completion, your application will be created on the Azure portal.

Now to the crux of the matter. Let's install our Node.js code on this web application.

We'll click on the code folder which provides us with options to automatically deploy our code to an Azure web app service.

Deployment dropdown menu

As soon as this is done, the list of the cloud servers on your Azure account will be shown. You can then select the new app we just created.

app deployment

Your backend code should then be deployed on the NewApp cloud server we created. On successful completion, you'll receive a success message with a link to your cloud application.

command prompt interface

Congratulations, you have successfully hosted your first web application. Navigate here to see the hosted application.

The application webpage

Additional Information

So far, we have covered the basics of deploying an application via the use of VS code extensions on Azure portal services. As you progress in the field of cloud computing, other interesting fields can also be explored such as:

• App monitoring with Azure Monitor.
• Azure app networking essentials.
• Azure MySQL database integration.
• Node JS serverless functions deployment.

You can also interact with me on my blog and check out my other articles here. Till next time, keep on coding!

In this course, Kerollos Magdy, a Microsoft software engineer, takes you step-by-step through different methods to deploy web applications. The course starts with free options and then explain how to deploy using Microsoft Azure. Regardless of the programming language or framework you use, you should be able to deploy using the same steps.

The first part of the course introduces you to deploying applications using free and sometimes open source options. In the second section, you'll get a detailed walkthrough on deploying applications using Microsoft Azure, a powerful cloud service provider. Azure’s comprehensive suite of tools and services makes it a popular choice for developers, and this course will show you how to leverage its full potential.

Kerollos brings his expertise and passion for open-source technologies to this course, making complex concepts accessible and understandable. He uses various examples to illustrate the deployment process, demonstrating how to deploy both backend and frontend applications. You'll learn about setting up a PostgreSQL database, deploying backend services, and ensuring your frontend is properly integrated.

The course also covers other services like Render, MongoDB Atlas, and Koyeb, providing you with a broad understanding of different deployment environments. Render is particularly highlighted for its ability to deploy both backend and frontend applications seamlessly. You’ll follow along as Kerollos sets up a Render account, creates a PostgreSQL database, and deploys an application using Node.js and Prisma.

By the end of this course, you'll have the knowledge to choose the most suitable deployment solution for your projects. Whether you're working on a hobby project or a professional application, these skills are invaluable. The course ensures you’re well-equipped to handle deployment tasks confidently and efficiently.

Watch the full course on the freeCodeCamp.org YouTube channel (1-hour watch).

In this article, I will guide you through building a regression model that predicts automobile prices using Azure Machine Learning’s Low-Code/No-Code tools.

Regression is a supervised machine learning technique used for predicting numerical values. To understand regression better, you can read my previous article here.

Prerequisites

To fully understand and follow the steps in this tutorial, you need the following:

1. An Azure account: You must have an active Azure account.

2. An Azure subscription: An active Azure subscription is required.

If you don’t have an Azure account yet, you can sign up for Azure for Students, the GitHub Student Developer Pack, or an Azure Free Trial. These options provide various benefits and free credits to get you started.

Now let's get into building our model. Follow the steps below to begin! Make sure you read till the end to learn the entire process.

Table of Contents

• How to Set Up Your Azure Machine Learning Workspace

• How to Set Up Compute Resources in Azure Machine Learning Studio

• How to Create Your Machine Learning Pipeline

• How to Build the Model

• How to Evaluate the Model

• How to Deploy the Model

• Cleaning Up

• Conclusion

How to Set Up Your Azure Machine Learning Workspace

To start working with Azure Machine Learning, you first need to create a workspace. A workspace is a centralized place to manage all the resources and experiments in your machine learning projects.

Step 1: Create a Resource Group

Start by signing in to the Azure Portal. Click the Create a resource button (the plus icon) on the left-hand navigation bar.

In the search bar, type “Machine Learning” and select Azure Machine Learning from the list.

Navigating to the Azure Home page and clicking the plus icon to create a new resource for the machine learning project

Step 2: Create a New Azure Machine Learning Resource

Now click Create to begin setting up your workspace. You will need to fill in the necessary details:

• Subscription: Select your Azure subscription.

• Resource Group: Either select an existing resource group or create a new one by clicking Create new and providing a name.

• Workspace Name: Provide a unique name for your workspace.

• Region: Choose a region that is closest to your location to reduce latency.

• Container Registry: Choose Create new unless you have an existing container registry you want to use.

Browsing the Azure Marketplace for machine learning services to find the appropriate tool for building and deploying models.

Step 3: Review and Create

Fill in the form with all the required info. Make sure you provide a unique Name and select a region. Then create your new container registry.

Review your settings to ensure everything is correct. Then click Review + create to validate your configuration. Once the validation is complete, click Create to deploy your workspace. This process may take a few minutes.

Setting up a new machine learning workspace in Azure with essential configuration details.

Step 4: Deployment

After the deployment is complete, click the Go to resource button to navigate to your new workspace.

In the workspace overview, click Launch studio to open the Azure Machine Learning Studio, where you will perform all your machine learning tasks.

Resource deployment complete in Microsoft Azure Machine Learning Services.

How to Set Up Compute Resources in Azure Machine Learning Studio

Once your workspace deployment is complete, you need to set up the compute resources required to run your machine learning experiments. Follow the steps below to do this.

Step 1: Access the Workspace

After the deployment is complete, click the Go to resource button. In the workspace overview, click Launch studio to open the Azure Machine Learning Studio.

Step 2: Create a Compute Instance

In the Azure Machine Learning Studio, navigate to the left-hand menu and click on Compute. Select the Compute instances tab, then click + New to create a new compute instance.

Fill in the required details:

• Virtual machine size: Select Standard_DS11_v2 for a balance of performance at minimal cost.

• Compute name: Enter a unique name for your compute instance.

Then click Create set up the compute instance. This process might take a few minutes.

Configuring compute instances in Azure Machine Learning to ensure the required computational power for training machine learning models.

Step 3: Create a Compute Cluster

In addition to a compute instance, you will need a compute cluster for scalable training. Still under the Compute section, select the Compute clusters tab and click + New.

Fill in the details:

• Cluster name: Enter a unique name for your compute cluster.

• Virtual machine size: Choose Standard_DS11_v2.

• Minimum number of nodes: Set to 0 to save costs when not in use.

• Maximum number of nodes: Set to 2 for this tutorial.

Then click Create to set up the compute cluster. Wait for the cluster to be in a running state before proceeding.

Overview of compute clusters in Azure Machine Learning

How to Create Your Machine Learning Pipeline

In this section, we will create a machine learning pipeline using Azure Machine Learning Designer. Pipelines help streamline the process of preparing data, training models, and deploying them.

Step 1: Navigate to the Designer

In the Azure Machine Learning Studio, go to the left navigation bar and click on Designer. Then click + New pipeline to start creating a new pipeline.

Interface showing the creation of a new pipeline.

Step 2: Add Your Data

You have the option to use external data or prebuilt sample datasets. For this tutorial, we’ll use a prebuilt sample dataset.

To use prebuilt sample data, click on the Components tab. Use the search bar or manually scroll to find the Automobile price data dataset. Drag and drop the dataset onto the canvas in the Designer.

Interface showing the addition of Automobile price data set.

Step 3: Explore the Data

Once the dataset is on the canvas, click on it to view its details. Navigate to the Visualizations tab to explore data distribution and statistical summaries. Click the Output+logs tab and then Preview data to inspect the first few rows of the dataset. This will help you understand the data's structure and identify any potential issues.

Visualization of dataset

Step 4: Prepare the Data

To specify the variables we want to work with, we need to filter out unnecessary columns.

From the Data Transformation section, drag and drop the Select Columns in Dataset module onto the canvas below the dataset. Connect the output node of the dataset to the input node of the Select Columns in Dataset module.

Open the module’s settings, select the columns you want to include in your model, and exclude irrelevant columns such as normalized-losses. (We are removing this column because it has high percentage of missing data). Click Save and close to apply the changes.

Interface for selecting columns in the dataset.

Next, you will need to clean any missing data. This helps us handle missing values to improve the model's accuracy.

To do this, drag and drop the Clean Missing Data module onto the canvas, below the Select Columns in Dataset module. Connect the nodes and configure the settings to remove rows with missing values. Save and close the settings.

Interface for cleaning columns in the dataset.

Step 5: Normalize the Data

To ensure the model performs well, we need to normalize the data. To do this, from the Data Transformation section, drag and drop the Normalize Data module onto the canvas. Connect the output of the Clean Missing Data module to the input of the Normalize Data module.

You'll want to configure the module to use the MinMax scaling method and select the columns to normalize, you can type them out manually by separating each column with a comma. Then save and close the settings.

Interface for normalizing columns in the dataset.

Step 6: Finalize the Pipeline Setup

Once all transformations are in place, review the pipeline to ensure all steps are correctly configured. Click Submit to run the pipeline. You can monitor the pipeline’s progress in the Jobs section.

NOTE: Each time you set up a module and you click submit, view the details of the pipeline job to keep track of your flows.

Monitoring pipeline through the link

How to Build the Model

This is the fun step where we start building our machine learning model by preparing the dataset for training and applying the appropriate algorithms.

Step 1: Split the Dataset

Drag and drop the Split Data module onto the canvas. Then connect the output of the Normalize Data module to the input of the Split Data module.

In the settings panel of the Split Data module:

• Set the Fraction of rows in the first output dataset to 0.7. This means 70% of the data will be used for training the model.

• Set the Randomized seed to any number to ensure reproducibility. For this tutorial, use 123.

Step 2: Train the Model

Now it's time to add the Train Model block. Drag and drop the Train Model module onto the canvas. Connect the first output of the Split Data module (the 70% training data) to the input of the Train Model module.

Click on the Train Model module to configure its settings. In the Edit column section, select the target variable, which in this case is price. Save and close the settings.

Next, you'll add the Training Algorithm. From the Machine Learning Algorithms section, drag and drop the Linear Regression module onto the canvas. Connect the output of the Linear Regression module to the right input of the Train Model module.

Interface showing connection of modules in pipeline

Step 3: Evaluate the Model:

Drag and drop the Score Model module onto the canvas. Connect the second output of the Split Data module (the 30% testing data) to the left input of the Score Model module. Connect the output of the Train Model module to the right input of the Score Model module.  This will apply the trained model to the testing data to evaluate its performance.

Next, drag and drop the Evaluate Model module onto the canvas. Connect the output of the Score Model module to the input of the Evaluate Model module. This will provide various evaluation metrics to assess the model’s accuracy.

Interface showing connection of modules in pipeline

Step 4: Review and Submit

Double-check all connections and settings in your pipeline. Then click Submit to run the model training and evaluation pipeline. You can monitor the job’s progress in the Jobs section, where you can view logs and outputs.

How to Evaluate the Model

After training our model, it’s important to evaluate its performance to ensure it’s making accurate predictions. We will use the Score Model and Evaluate Model modules for this purpose.

Step 1: Evaluate the Model’s Performance

Drag and drop the Evaluate Model module onto the canvas. Connect the output of the Score Model module to the input of the Evaluate Model module.

The Evaluate Model module will generate various evaluation metrics, such as Mean Absolute Error (MAE), Root Mean Squared Error (RMSE), and R-squared (R²), which are critical for assessing the accuracy and performance of the regression model.

Explore the Evaluation Metrics:

Once the pipeline execution is complete, click on the Evaluate Model module to explore the detailed metrics.

Here are some key metrics to focus on:

• Mean Absolute Error (MAE): Measures the average magnitude of errors in predictions, without considering their direction. Lower values indicate better accuracy.

• Root Mean Squared Error (RMSE): Similar to MAE but gives more weight to larger errors. Lower values are better.

• R-squared (R²): Indicates how well the model’s predictions match the actual data. Values closer to 1 signify a better fit.

Visualization of data output from the regression model.

We just built and evaluated our model. Yayy!

How to Deploy the Model

Now that we have trained and evaluated our regression model, it’s time to deploy it for real-time inference using Azure Machine Learning. Follow these steps to deploy the model and create an inference pipeline.

Step 1: Create the Inference Pipeline

Navigate to the Designer section in Azure Machine Learning Studio and create a new pipeline for deployment. Select Real-time inference to set up the deployment pipeline automatically.

Step 2: Configure the Pipeline

After selecting Real-time inference, the pipeline will be initialized with default components. You can modify the pipeline by adding necessary components.

We have to make some changes like adding Enter data manually, Execute python script modules. Also, in the select column in dataset block, edit and remove the price column. Remove connection between Score model and web service.

• Enter Data Manually: Drag and drop this block onto the canvas. This component allows manual input of data for prediction. Copy and paste the data below into the data field.

symboling,fuel-type,aspiration,num-of-doors,body-style,drive-wheels,engine-location,wheel-base,length,width,height,curb-weight,engine-type,num-of-cylinders,engine-size,fuel-system,bore,stroke,compression-ratio,horsepower,peak-rpm,city-mpg,highway-mpg,make 3,gas,std,two,convertible,rwd,front,88.6,168.8,64.1,48.8,2548,dohc,four,130,mpfi,3.47,2.68,9,111,5000,21,27,alfa-romero giulia 3,gas,std,two,convertible,rwd,front,88.6,168.8,64.1,48.8,2548,dohc,four,130,mpfi,3.47,2.68,9,111,5000,21,27,alfa-romero stelvio 1,gas,std,two,hatchback,rwd,front,94.5,171.2,65.5,52.4,2823,ohcv,six,152,mpfi,2.68,3.47,9,154,5000,19,26,alfa-romero Quadrifoglio 2,gas,std,four,sedan,fwd,front,99.8,176.6,66.2,54.3,2337,ohc,four,109,mpfi,3.19,3.4,10,102,5500,24,30,audi 100 ls 2,gas,std,four,sedan,4wd,front,99.4,176.6,66.4,54.3,2824,ohc,five,136,mpfi,3.19,3.4,8,115,5500,18,22,audi 100ls 2,gas,std,two,sedan,fwd,front,99.8,177.3,66.3,53.1,2507,ohc,five,136,mpfi,3.19,3.4,8.5,110,5500,19,25,audi fox 1,gas,std,four,sedan,fwd,front,105.8,192.7,71.4,55.7,2844,ohc,five,136,mpfi,3.19,3.4,8.5,110,5500,19,25,audi 100ls 1,gas,std,four,wagon,fwd,front,105.8,192.7,71.4,55.7,2954,ohc,five,136,mpfi,3.19,3.4,8.5,110,5500,19,25,audi 5000 1,gas,turbo,four,sedan,fwd,front,105.8,192.7,71.4,55.9,3086,ohc,five,131,mpfi,3.13,3.4,8.3,140,5500,17,20,audi 4000

• Execute Python Script: Replace the code in this block with:

import pandas as pd def azureml_main(dataframe1=None, dataframe2=None): scored_results = dataframe1[["Scored Labels"]] scored_results.rename(columns={"Scored Labels": "predicted price"}, inplace=True)
return scored_results

• Select Columns in Dataset: Edit and remove the price column to ensure it’s not included in the input data for predictions.

• Remove Connection: Disconnect the Score Model module from the web service output to ensure only the Execute Python Script block connects to it.

See the images below for a visual representation of how the connections are configured.

Interface of modules connection in pipeline

Step 3: Submit and Deploy the Model

Submit the flow and wait for all processes to complete successfully (green check mark). Once your deployment is successful, you can explore the output to verify everything is functioning as expected.

You can now deploy the model as a real-time web service for predictions.

Configuration settings for setting up new pipeline

Once all the processes are successfully completed in Azure Machine Learning Studio, you are ready to explore the output and deploy your trained model as a real-time web service.

Here’s how you can proceed:

1. Review Pipeline Execution: Ensure that all the steps in your pipeline have completed with a green check mark indicating success.

2. View Outputs and Visualizations: Navigate through the different components of your pipeline to inspect outputs and visualizations generated during data transformation, model training, and evaluation stages. This helps in understanding how each step has contributed to the overall model performance.

3. Check Evaluation Metrics: Examine the evaluation scores generated by the Score Model block to assess the performance of your trained regression model. Common evaluation metrics include Mean Squared Error (MSE), R-squared (R2), and Root Mean Squared Error (RMSE). These metrics provide insights into how well your model predicts automobile prices based on the input features.

Visualization of data output from model evaluation.

Put the following checks in place before starting the deployment:

Prepare for Deployment

First, ensure that the Execute Python Script block is correctly configured to transform input data and produce predicted prices.

You'll also want to verify that the pipeline is set up to handle real-time inference for deploying the model.

Submit the Pipeline

Click on the submit button to initiate the deployment process. Wait for Azure Machine Learning to complete the deployment and verify that all components have been successfully deployed.

Deploy as Web Service

Once deployment is confirmed successful, you can deploy the model as a real-time web service. This web service will be hosted on Azure and can be accessed via API endpoints, allowing applications to send data and receive predictions in real-time.

Testing the Web Service:

Use the Enter Data Manually block to manually input test data or use external systems to send requests to the deployed web service endpoint. You can verify that the web service responds with predicted prices based on the input features.

Monitor and Manage:

Monitor the performance of your deployed web service using Azure Machine Learning monitoring tools. You can manage the deployment by scaling resources as needed or updating the model with new data or improved versions.

Deploying your regression model as a real-time web service enables you to use its predictive capabilities in various applications without the need for direct human intervention. It ensures that your model can continuously provide accurate predictions based on real-time data inputs.

Interface showing predicted price

Clean Up

The web service you created is hosted in an Azure Container Instance. If you don’t intend to experiment with it further, you should delete the endpoint to avoid accruing unnecessary Azure usage.

Deleting your compute ensures your subscription won’t be charged for compute resources. You will, however, be charged a small amount for data storage as long as the Azure Machine Learning workspace exists in your subscription.

If you have finished exploring Azure Machine Learning, you can delete the Azure Machine Learning workspace and associated resources.

To delete your workspace:

1. In the Azure portal, in the Resource groups page, open the resource group you specified when creating your Azure Machine Learning workspace.

2. Click Delete resource group, type the resource group name to confirm you want to delete it, and select Delete.

Conclusion

Congratulations! You have successfully created and deployed a regression model using Azure Machine Learning Designer without writing a single line of code.

In this tutorial, you have learned how to clean and preprocess data, build and train a machine learning model, evaluate its performance, and deploy it as a web service. This low-code/no-code approach in Azure Machine Learning Designer makes it accessible for everyone to use the power of machine learning.

Remember to clean up your resources to avoid unnecessary charges. With these skills, you can now experiment with other datasets and machine learning problems. Azure's possibilities are endless, and Azure Machine Learning provides a robust platform for your data science projects.

Till next time, cheers :)

I will be showing you both ways of doing it – through the GUI and with the CLI.

I assume you already have built a project and optionally pushed it to GitHub or any other alternative, like GitLab or Bitbucket.

It's time to go live with your project and showcase it to the world. 💪

Whether it is your first time working with Azure or you are already a champ, feel free to follow along.

What is CI/CD?

Before we dive into Azure Static Web App, let me give you a brief overview of what CI/CD is.

Imagine you're building your cool new web app. Now, to make sure it's always up-to-date and running, you need something called Continuous Integration/Continuous Deployment (CI/CD).

Here's how it works:

• Continuous Integration (CI) is the process of automatically building and testing your code whenever you make changes and ensuring it is working as you expect.
• Continuous Deployment (CD) is the process of automatically deploying your tested code to production.

You might have already came across CI/CD if you've ever hosted your project on Vercel, Netlify, or any other site hosting platform, and noticed that once you push your local changes to your remote repository, those changes are reflected on the original hosted site in just a few minutes. Magic, huh? This is all possible with the help of CI/CD.

In short, CI/CD ensures that your project is tested and deployed whenever you push new commits to the repository hosting your project.

How to Push your Project to GitHub

In this step, I will use GitHub as an example. If your project is already pushed to GitHub, feel free to skip this step. Otherwise, follow the steps shown below.

Log in to GitHub CLI

Did you know you can create a GitHub repository right from your command line?

Let's get started. Firstly, make sure you have GitHub CLI installed. For installation instructions, follow the steps shown here.

To authenticate your GitHub CLI to your account, run the below command:

gh auth login

Follow the steps displayed in your terminal to authenticate with GitHub. Once done, you can proceed to the next step.

Create a repository

Once you're logged in, you can run the below command to start an interactive repository creation mode:

gh repo create

Or, directly specify flags to it like so:

gh repo create <repository_name> --public --license mit --description <repository_description>

Running, this command will create a repository with all the specified options in your GitHub account.

Push your changes

Now, that you have already authenticated yourself and have created a repository in your GitHub account, it's time to push your local changes to the remote repository.

Run the following commands to push your local changes to the remote:

git branch -M main
git remote add origin https://github.com/<username>/<repository_name>.git
git push -u origin main

Note that if you have SSH authentication set up, you need to make sure you change the origin URL to follow SSH protocol.

That concludes the initial preparation. Now, let's proceed with creating the Azure Static Web App. 🚀

Host your project with Azure SWA CLI

In this section, you'll learn how to host your static project, whether it built with Next.js, React, or any other static site, using Azure SWA CLI.

First, you need to install the @azure/static-web-apps-cli package as a dev dependency.

If using pnpm as a package manager, run the below command. The command might vary based on different package managers.

pnpm install -g @azure/static-web-apps-cli

Now, build your project with the appropriate build command:

pnpm run build

It's time to deploy the application with the build folder. Run the below command to deploy it to Azure SWA:

swa deploy <build_location> --env production

If your application uses an API, then you need to pass the api folder location as a flag to the above command. So, your final command would be:

swa deploy <build_location> --api-location <api_folder_location> --env production

Deploying the project with Azure Static Web App CLI.

That is it. Your site is deployed to Azure Static Web App through CLI. 🎉 You can view it in the shown URL.

There are further configuration which can be specified. For additional configuration, follow this link.

How to Host your project with Azure Portal GUI

In this section, we will create another brand new Azure SWA through the Azure portal.

Head over to the Azure portal at https://portal.azure.com and search for the Azure Static Web App.

Azure portal search results for Static Web App.

Hit "Create" and you should be asked with a bunch of extra configurations.

Creating a new Azure Static Web App.

Setting up the configurations for the Azure Static Web App.

For the Resource Group, create one and name it whatever you want. Also, give your web application a name.

If your project is hosted on GitHub, choose GitHub as the option and choose the repository from the dropdown menu. For the branch, select 'main' if you created the project from scratch with default settings.

If you are using any other alternatives, then select the one which satisfies your criteria.

Leave everything else as default and click on "Review + create" and wait till it is done hosting your project to Azure SWA.

In the Overview section of the app, you should see URL for your built project. Here is the overview of mine:

Azure Static Web App dashboard overview.

Visit the URL and you should have your site ready. 🥳

Deployed project hero section.

Wrapping Up

By now, you should have a general idea of how to host any static web app in Azure Static Web Apps.

While we could cover additional topics like adding a custom domain to our site, this may not apply to most of you, so I'm not including the steps in this article. To learn more, visit this link.

So, that is it for this article. Thank you so much for reading! See you next time. 🫡

Now that you've had a sneak peek at my portfolio in the image above, why not get in touch? 😉 Feel free to connect with me here:

• GitHub: https://github.com/shricodev
• LinkedIn: https://linkedin.com/in/iamshrijal
• Twitter: https://twitter.com/shricodev

We just posted a course on the freeCodeCamp.org YouTube channel that will help you pass the Azure DevOps Engineer Expert Certification (AZ-400). This comprehensive course, developed by Andrew Brown from ExamPro, provides in-depth coverage of all the essential skills and knowledge areas required for the AZ-400 certification. This course includes real-world scenarios and practical examples to help you apply what you learn.

Here are the key topics you will learn in this course:

• Develop an Instrumentation Strategy: Learn how to design and implement logging, telemetry, and monitoring.

• Develop a Site Reliability Engineering (SRE) Strategy: Manage alerting, perform failure analysis, and implement health checks.

• Develop a Security and Compliance Plan: Implement secure DevOps processes and manage security and compliance.

• Implement a Continuous Integration (CI) Process: Master the build strategy, manage code quality, and security policies.

• Implement a Continuous Delivery (CD) and Release Management Strategy: Design a release strategy and set up a release management workflow.

• Implement Dependency Management: Manage code dependencies and artifact repositories.

• Implement Application Infrastructure: Learn to design and implement infrastructure as code and manage Azure Kubernetes Service (AKS) and other Azure services.

• Implement Continuous Feedback: Manage feedback from users and stakeholders effectively.

The AZ-400 exam typically lasts 150 minutes and includes multiple-choice questions, drag-and-drop tasks, case studies, and more. A passing score is generally around 700 out of 1000.

Whether you’re an experienced DevOps professional or just starting, this course is designed to equip you with the skills and knowledge needed to pass the AZ-400 certification and advance your career. Watch the full course on the freeCodeCamp.org YouTube channel (8-hour watch).

The Azure AI Fundamentals Certification is for those seeking a Machine Learning role such as AI Engineer or Data Scientist.

The certification has recently been updated for 2024 and I've released an updated course to teach you how to pass the exam.

In the last decade companies have been collecting vast amount of data surrounding their service and product offerings.

The successful companies of the 2010s were data-driven companies who knew how to collect, transform, store and analyze their vast amount of data.

The successful companies of the 2020s will be ml-driven who how know how to leverage deep learning and create AI product and service offerings.

Overview of the Azure AI Fundamentals

The Azure AI Fundamentals covers the following:

• Azure Cognitive Services
• AI Concepts
• Knowledge Mining
• Responsible AI
• Basics of ML pipelines and MLOps
• Classical ML models
• AutoML and Azure ML Studio

How do you get the Azure AI Fundamentals certification?

You can get the certification by paying the exam fee and sitting for the exam at a test center partnered with Microsoft Azure.

Microsoft Azure is partnered with Pearson Vue and PSI Online who have a network of test centers around the world. They provide both in-person and online exams. If you have the opportunity, I recommend that you take the exam in-person.

Microsoft has a portal page on Pearsue Vue where you can register and book your exam.

That exam fee is $99 USD.

Can I simply watch the videos and pass the exam?

For a fundamental certification like the AI-900 you can pass by just watching the video content without exploring hands-on with the Azure services on your own

Azure has a much higher frequency of updates than other cloud service providers. Sometimes there are new updates every month to a certification however, the AI-900 is not hands-on focused, so study courses are less prone to becoming stale.

• The exam has 40 to 60 questions with a timeline of 60 minutes.
• The exam contains many different question types.
• A passing grade is around 70%.

The Free Azure AI Fundamentals Video Course

Just like my other cloud certification courses published on freeCodeCamp, this course will remain free forever.

The course contains study strategies, lectures, follow-alongs, and cheatsheets, and it's designed to be a complete end-to-end course.

Head on over to freeCodeCamp's YouTube channel to start working through the full 4-hour course.

But you'll need to have a way to back up your data, as it's crucial to ensuring the functionality of the production site and the stability of everyday workflows. So creating Azure SQL backups can help you and your team avoid data loss emergencies and have the shortest possible downtime while maintaining control over the infrastructure.

Another reason to have a current Azure database backup is Microsoft’s policy. Microsoft uses the shared responsibility model, which makes the user responsible for data integrity and recovery while Microsoft only ensures the availability of its services. Microsoft directly recommends using third-party solutions to create database backups.

In case you run a local SQL Server, you'll need to prepare for the possibility of hardware failures that may result in data loss and downtime. An SQL database on Azure helps mitigate that risk, although it's still prone to human errors or cloud-specific threats like malware.

These and other threats make enabling Azure SQL database backups necessary for any organization using Microsoft’s service to manage and process data.

In this tutorial, you'll learn about backing up Azure databases and restoring your data on demand with native instruments provided by Microsoft, including methods like:

• Built-in Azure database backup functionality
• Cloud archiving
• Secondary database and table management
• Linked server
• Stretch Database

Why Backup Your SQL Azure Database?

Although I covered this briefly in the intro, there are many reasons to back up your SQL Azure database data.

Disaster Recovery

Data centers can be damaged or destroyed by planned cyberattacks, random malware infiltration (check out this article to discover more on ransomware protection), and natural disasters like floods or hurricanes, among others. Backups can be used to swiftly recover data and restore operations after various disaster cases.

Data Loss Prevention

Data corruption, hardware failure, and accidental or malicious deletion lead to data loss and can threaten an organization. Backup workflows set up to run regularly mean you can quickly recover the data that was lost or corrupted.

Compliance and Regulations

Compliance requirements and legislative regulations can be severe regardless of your organization’s industry. Mostly, laws require you to keep up with security and perform regular backups for compliance.

Testing and Development

You can use backups to create Azure database copies for development, troubleshooting, or testing. Thus, you can fix, develop, or improve your organization’s workflows without involving the production environment.

How to Back Up Your Azure SQL Database

Backing up your Azure SQL database can be challenging if you go through the process without preparation. So that's why I wrote this guide – to help you be prepared. Here's what we'll cover in the following sections:

• Requirements for SQL Azure database backup
• How to configure database backups in Azure with native tools
• Cloud archiving
• Backup verification and data restoration

SQL Azure Database Backup Requirements

Before backing up your SQL Azure databases, you need to create and configure Azure storage. Before you do that, you'll need to go through the following steps:

First, open the Azure management portal and find Create a Resource.

Then, go to Storage > Storage account. Provide the information, including the location and names of a storage account and resource group according to your preferences. After you enter the information, hit Next.

Storage account config

Then go to the advanced section for additional settings. The optimal choice is to set _"_Secure transfer required" as Enabled and "Allow access" from All networks. For more resilience in case of human error, you can set "Blob soft delete" as Enabled. With that setting, you can quickly correct accidental deletions in the storage account.

After that, specify the tags you need to simplify navigating through your infrastructure.

Azure backup storage tags

Check the settings once more. If everything is configured correctly, hit Create. Your new storage account is now created.

Once the storage volume is created, it's time to configure a backup data storage container.

Go to the storage account, find Containers, then hit the + Container tab there. After that, specify a name for the new container and switch Public access level to Private (no anonymous access).

Container Azure storage account

You can then use the container as a backup storage (.bak files will be stored there in that case).

Azure Database Backup Configuration

Now, everything is set up for you to back up your SQL Azure database. Do the following to create a database backup:

First, go to SQL Management Studio, and establish a connection with the SQL server. After that, right-click the database that should be backed up. The context menu appears, so go to Tasks there. Then hit Back Up….

SQL server tasks backup

Then find the Destination tab, and set Back up to line to URL there. After that, hit New container.

Next, sign in to Azure. Pick the container you created before. Provide your credentials, then hit OK.

You’ll see a message asking you to sign in to Azure subscription. Then, choose the container and hit OK.

Now, you'll see the configured backup destination URL listed. To start the workflow to back up your Azure data, hit OK once again.

When your SQL Azure database backup is completed, the message shows up: "The backup of database ‘your database name’ completed successfully."

The backup file in the target container should now be visible from the Azure portal.

Keep in mind that, when uploading backups to any cloud storage, you may face issues if your network connection is not fast enough.

In case that’s true for you, you can reorganize your backup workflows: send backup data to a physical storage drive first, and then send another copy to the cloud. Thus, you can prevent operational challenges that might appear due to network bandwidth deficiency.

Cloud Archiving for Azure Database Backups

Databases tend to grow in volume as the organization grows. This means that the storage space required to fit the data and that data's backup increases significantly. Also, the original data volume prolongs the duration of full backup workflows, posing another challenge.

Of course, the first way to get more storage space is to revise your data regularly and erase records that are irrelevant, outdated, or unnecessary otherwise. Still, it's sometimes difficult to determine if data will be or become unnecessary or irrelevant, especially when dealing with issues of compliance.

To keep your organization compliant in any case, data archiving can help you solve two problems at once: you can ensure data accessibility on one hand, and save storage space on the other hand.

To archive your SQL database in the cloud, you should first save that database copy to an Azure blob container. Then, to move a newly created blob to the archive tier in the Azure portal, do the following:

1. Go to the required container where the SQL database is stored.
2. Choose the blob that you need to move.
3. Hit Change tier.

Azure blob container change tier

4. In the Access tier dropdown menu, choose Archive.

Azure blob change tier

5. Hit Save.

Additionally, the Archive storage tier is the most affordable one in Azure, meaning that you can reduce your database data TCO with it.

Secondary Database and Table Management

There exist several workflows that can help you set up Azure database backup archiving for your organization. When you need the data to stay in the initial database, for instance, creating a separate table and moving that data there can be your choice. However, the filegroup of that table should stay apart from the main database and be moved to a separate disk whenever possible.

Most probably, you’ll want to let users access the data you send to a separate table. To make that happen, you can create a view merging the relevant tables and redirect the requests to that view, not to the original table. Doing things that way, you can keep the data accessible while dealing with maintenance faster.

SQL Server Linking

If you can’t move the data to another database for internal reasons such as special Azure backup policies, you can consider maintaining your primary database accordingly.

Here, the outcome is likely to be that of the previous case, but you need to link the SQL servers or configure apps so they can send direct requests to your second server.

The downside here is that your SQL database, which was supposed to be a backup one, becomes a production database and gains appropriate importance for an organization.

There are two ways to create linked servers via SQL Server Management Studio (SSMS):

• sp_addlinkedserver (Transact-SQL) system stored procedure that creates a linked server
• SSMS GUI

After you've ensured that you have appropriate access rights on both server instances you need to link, the network is configured appropriately to access them, and SSMS is installed, you'll need to go through the following steps:

First, open SSMS.

Microsoft SSMS

Connect to the instance where you need to establish a linked server. Then find Object Explorer > Server Objects, then right-click Linked Servers.

Pick New Linked Server from the dropdown:

New linked server SSMS

Then configure the server properties, including name, server type, provider and product name:

Linked server configuration SSMS

Then you'll just need to complete the security configuration, set up the server options, and complete connection testing.

Original Data Deletion

When you don’t need 24/7 data availability but need the data stored due to internal policies or compliance requirements, you can choose what's probably the simplest solution to increase storage space efficiency. Just back up the data that can stay unavailable and then delete the originals from the main database. Accessing any records you may need will still be possible via the backup.

Stretch Database

Aiming to make data management of organizations’ databases simpler, Microsoft implemented a Stretch Database feature in SQL Server 2016. With this feature, you can get an SQL backup to Azure after you send the data from the hosted database to an Azure SQL database. The method enables you to increase overall infrastructure cost-efficiency by simplifying backup workflows.

To enable this workflow in your environment, develop the policy specifying the data on a hosted server to send to Azure. You don’t need to introduce any changes in applications that use the production database: SQL Server can independently get the records from the Azure SQL Database.

Azure Database Backups Verification and Restoration

During an SQL Azure database backup, you can choose to create such backups WITH CHECKSUMS or without them. When the workflow is complete, I recommend you use the following command: RESTORE VERIFYONLY. This command enables you to check the recoverability of backup files.

To access the data, you can restore records from a backup to a different database. With Azure Automation scripts on backups, you can accelerate the restoration process, thus minimizing downtime and increasing the overall resilience of your Azure infrastructure.

You need to follow only a few steps to restore an Azure SQL database to a required recovery point from a backup. Still, keep in mind that your subscription can define the available retention period which can vary from 7 to 35 days. A native tool for backup restoration to SQL servers is Server Management Studio.

To Conclude

The critical nature of Azure SQL database data makes Azure SQL backups obligatory for any organization that uses this Microsoft solution. In this guide, we reviewed the process of creating SQL Azure database backup using native Microsoft tools.

These tools provide data backup, backup verification, and recovery functionality along with some automation.

You can also implement a specialized all-in-one data protection solution, such as NAKIVO, the company where I work. It can help you make your data backup workflows more efficient.

We just posted a full exam-prep course on the freeCodeCamp.org YouTube channel for the AZ-900 exam. Andrew Brown from ExamPro developed this course.

Microsoft Azure is a cloud service provider. A cloud service provider (CSPs) is a technology company that offers multiple cloud services. Azure has listed over 600 cloud service offerings, from computing to storage to databases to machine learning.

Azure is the second most popular cloud platform behind Amazon Web Services (AWS). Still, many long-lived or large tech companies are embracing both cloud platforms. This may be because Azure is able to compete on cost, niche cloud-offerings, easy integration, and developers' familiarity with Microsoft software.

The Azure Foundations Certification

The Azure Foundations certification is the entry-level cloud certification for Microsoft Azure. It is commonly referred to by its course code, the AZ-900.

The exam covers the following domains:

• Cloud Concepts
• Azure Core Services
• Security, Privacy, Compliance and Trust
• Pricing and Support

The average study time – even for people who are new to cloud development – is only one week of study.

There is also some knowledge transfer if you have already earned the AWS Cloud Certified Practitioner (AWS's entry-level certification). But don't expect to pass the AZ-900 without studying.

Microsoft and Azure previously had Certifications that were service specific, but they have changed to role based Certifications (certifications based on job title).

How do you get the certification?

You obtain certification by paying the exam fee, and sitting the exam at a test center partnered with Microsoft Azure.

Microsoft Azure is partnered with Pearson Vue, a network of test centers around the world. Pearson Vue allows you to sit the exam in person or online. To sit the exam online, you need to ensure you have a quiet, clutter-free room and a working web-camera.

Microsoft has a portal page on Pearsue Vue where you register and book your exam.

Can I simply watch the course and pass the exam?

For the entry-level certification, yes, it is possible to pass by just watching videos if you already have a technical background.

For more difficult certification levels starting at the Associate level, it is necessary to use paid practice exams by third-party providers.

The exam has 40 to 60 questions with a timeline of 1 hour.

A passing grade is around 70%.

Watch the full course on the freeCodeCamp.org YouTube channel (8-hour watch).

The Azure Solutions Architect Expert Certification exam measures your ability to accomplish the following technical tasks: design identity, governance, and monitoring solutions; design data storage solutions; design business continuity solutions; and design infrastructure solutions.

We just published a 10-hour course on the freeCodeCamp.org YouTube channel that will prepare you to pass this certification exam. This course is your key to mastering the essentials of Microsoft Azure.

Andrew Brown of ExamPro created this course. He has created a ton of popular exam prep courses that have helped thousands of people get industry certification.

This course is not just a series of lectures; it's a journey through the vast landscape of Azure architecture. The course covers all the topics you need to learn to pass the AZ-305 exam. Here are the topics in the course:

☁️ Introduction: Begin your journey with a detailed breakdown of the exam guide, offering insights into what to expect and how to navigate through the course effectively. Explore the Sandbox feature, an essential tool for practical learning.

☁️ Identity Solutions: Delve into the world of Microsoft Entra ID, understanding its recent name change, applications, and compare AD vs. AAD. This section thoroughly covers Tenant, Users, Groups, and aspects of Access Rights, along with Single Sign-On and Conditional Access.

☁️ Role-based Access Control: Discover the various Azure roles and their functionalities. Learn about Access Controls, Classic Administrators, Azure RBAC, and the nuances of Azure Policies vs. Azure Roles RBAC.

☁️ Azure Policies: A dedicated section to understand Azure Policy Scope and the anatomy of Azure Policy Definition Files, alongside configuring these policies for optimal cloud governance.

☁️ Azure Resource Manager & ARM Templates: These sections are vital for understanding resource management and deployment in Azure. Learn about Azure Management Groups, Subscriptions, Resource Tags, and more. ARM Templates will guide you through resource, parameter, and function management in Azure.

☁️ Monitoring Solutions: Gain expertise in Azure Monitor, its data stores, logs, and analytics. This module includes detailed lessons on Azure Sentinel and Application Insights.

☁️ Identity Management Best Practices: A crucial part of the course focusing on principles like the least privilege and Privileged Identity Management, ensuring a strong foundation in identity security.

☁️ Azure Key Vault & Integration with On-premises Solutions: Understand the mechanics and pricing of Azure Key Vault and learn about integrating Azure solutions with on-premise infrastructures.

☁️ Comprehensive Coverage on Azure Services: The course extends into detailed explorations of Azure SQL Database, Azure Synapse Analytics, Azure Data Factory, Azure Databricks, Azure Data Lake, Cosmos DB, and Azure Cache for Redis. Each of these sections is meticulously designed to provide you with a deep understanding of Azure's data services.

☁️ Specialized Azure Modules: Learn about Azure's specialized services like Azure Virtual Machines, Azure App Service, Azure Container Instances, Azure Functions, and Azure Front Door, along with Azure CDN and Azure Service Bus. These modules offer a deep dive into specific Azure services, enhancing your architectural skills.

☁️ Migration and Connectivity Solutions: Equip yourself with knowledge on Azure Cloud Adoption Framework, Azure Migrate, and connectivity solutions like VNets and Subnets.

☁️ Network Security and Load Balancing: Understand how to optimize network security through Azure Firewall and Network Security Groups, and master load balancing and routing solutions.

Whether you're aiming to pass the AZ 305 certification or seeking to enhance your Azure expertise, this course is your comprehensive guide to success.

Watch the full course on the freeCodeCamp.org YouTube channel (10-hour watch).

But when a system's container count rises, controlling and coordinating them becomes more difficult. Fortunately, Kubernetes is a powerful container orchestration solution.

This tutorial teaches you how to leverage Azure Kubernetes Service (AKS) for container orchestration in the Azure cloud environment.

Key Terminologies

Before diving into the guide, let's define some essential terminologies:

1. Containerization: The process of packaging your application code with all the files and libraries together into a single container to ensure consistency and portability across different environments.
2. Kubernetes: An open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications.
3. Azure Kubernetes Service (AKS): A managed Kubernetes service provided by Microsoft Azure that simplifies the deployment and management of Kubernetes clusters in the Azure cloud environment.
4. Pod: The smallest deployable unit in Kubernetes, representing one or more containers running together on a node.
5. Deployment: A Kubernetes resource that defines how many replicas of a Pod should be running and the template for creating them.
6. Node: A virtual or physical machine in a Kubernetes cluster on which containers are deployed.
7. kubectl: The command-line tool used to interact with Kubernetes clusters.

How to Use Azure Kubernetes Service (AKS)

Create an Azure Resource Group

Let’s start by logging into the Azure portal, then clicking on "Create a resource" and searching for "Resource group.". Click on "Resource group" and then "Create."

Resource group

After that, let’s fill in the required information, such as the resource group name and region then click "Review + create" and then "Create" to create the resource group.

Popup for the created resource group

Create an AKS Cluster

In the Azure portal, click on "Create" and search for "Azure Kubernetes Service."Let’s now click on "Azure Kubernetes Service" and then "Create."

Creating an AKS

Fill in the required information, such as the AKS cluster name, resource group (use the one created in Step 1), and region.

Cluster Details

First, let’s choose our plan and the resource that we created earlier:

Plan and resource group

Ensure that the Preset configuration is Standard ($$). For more details on preset configurations, see the cluster configuration preset in the Azure portal. Enter a Kubernetes cluster name, such as AKScluster.

Select a Region for the AKS cluster, and leave the default value selected for the Kubernetes version.

Cluster details

Leave the default values as they are in the "primary node pool":

Primary node pool

In the next parts, leave the default options and then select Next: Review + create:

When we go to the Review + Create tab, Azure validates the parameters we've selected. If the validation is successful, we may establish the AKS cluster by clicking create. If validation fails, it informs which parameters must be changed.

Validation passed demo

The AKS cluster is created in a matter of minutes. When our deployment is finished, we may access our resource by either choosing Go to resource, or Selecting the AKS resource from the AKS cluster resource group.

Configure kubectl

After the AKS cluster is successfully created, we should click on "Go to resource."

In the AKS cluster overview page, click on "Connect" and then "Open in Cloud Shell."

The Azure Cloud Shell will open at the bottom of the portal. If prompted, choose "Bash" as the shell type. Then "Create storage".

Azure Cloud Shell

Run the following command in the Cloud Shell to configure kubectl to connect to our AKS cluster:

az aks get-credentials --resource-group <your_resource_group_name> --name <your_aks_cluster_name>

In our case, our resource group name is Tutorial and AKS our cluster is AKScluster:

az aks get-credentials --resource-group Tutorial --name AKScluster

This will output the following:

Merged "AKScluster" as current context in /home/valentine/.kube/config

To verify the connection to our cluster, use kubectl get to return a list of the cluster nodes as shown below:

NAME                               STATUS    ROLES   AGE   VERSION
aks-agentpool-22140002-vmss000000   Ready    agent   16m   v1.25.6

Deploy and Manage the Application

Now that kubectl is configured to connect to our AKS cluster, we can deploy and manage applications on it.

Create a Kubernetes deployment manifest file in the Cloud Shell. To do so let’s open the nano text editor and create the "nginx-deployment.yaml" file. Use the following command to do that:

nano nginx-deployment.yaml

The nano editor will open, and we can start typing the content of the deployment manifest. For deploying a simple NGINX web server, use the following YAML content:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

After copying and pasting our code above, we will press Ctrl + X to exit nano. This will prompt us to save the changes. Let’s press Y to confirm, and when asked to save the file, press Enter to save the file with the default name (nginx-deployment.yaml).

Now we have created the nginx-deployment.yaml file, which contains the YAML specification for deploying a simple NGINX web server with three replicas.

Let’s deploy the NGINX application to our AKS cluster using the following command:

kubectl apply -f nginx-deployment.yaml

This will be the output:

Output showing our application as been deployed

Scale the Application

We can easily scale our deployed application based on demand.

To scale the NGINX deployment to five replicas, let’s use the following command:

kubectl scale deployment nginx-deployment --replicas=5

Test the application

Let’s now check the status of our deployment by using the following command:

kubectl get deployment nginx-deployment --watch

The above command will show the status of the deployment, including the number of desired replicas, the number of available replicas, and the current state of the deployment as shown below:

NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment          3/3     3            3           13m

Deployment as a service

To expose the deployment as a service and access it externally, we'll need to create a Kubernetes service manifest and apply it using kubectl apply -f service-manifest.yaml.

For example, we can create a service manifest file named nginx-service.yaml and add the following content:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

Let’s save the file, and then apply it using the following command:

kubectl apply -f nginx-service.yaml

This will create a Kubernetes service named nginx-servicethat maps to the pods deployed by the nginx-deployment based on the app: nginx label selector. The service will be accessible externally through a LoadBalancer, and we can check its status using:

kubectl get service nginx-service --watch

We should be able to access our NGINX web server using the provided IP address.

NAME           TYPE       CLUSTER-IP    EXTERNAL-IP    PORT(S)        AGE
nginx-service LoadBalancer 10.0.61.228   20.87.237.92   80:32415/TCP   93s

Let’s visit the external IP:

Output

Congratulations! We have successfully deployed a web application to our AKS cluster, exposed it to the internet, and managed its scaling effortlessly using Azure Kubernetes Service.

Monitor the Cluster

AKS integrates seamlessly with Azure Monitor, allowing us to monitor the performance and health of our Kubernetes cluster and applications.

In the Azure portal, navigate to your AKS cluster and click on "Monitoring." There, you can explore the various monitoring options, such as cluster health, performance, and diagnostics.

Conclusion

In this tutorial, we took advantage of Azure's free trial to learn the ins and outs of AKS. We also used the Azure site to establish our own AKS cluster, with the opportunity to adjust parameters as needed. Cloud Shell was also utilized without installing anything on the PC.

You can check out my personal blog here. Happy learning.