DEV Community: Cloud with Chris

Tales from the Real World - Architecting the Transformation

Chris Reddington — Sun, 12 Sep 2021 12:34:31 +0000

This post was originally published on Fri, Sep 10, 2021 at cloudwithchris.com.

Most organizations engaged in transformation today are moving from left to right in digitally-driven maturity models. The objectives are well known: increase agility, boost productivity, and provide seamless digital experiences for consumers.

Architects play a pivotal role as the curators of this transformation. In this session, Asanka will share his experience on how architects can contribute and introduce a framework to follow on refactoring enterprises.

Shift Left and Increase your Code Quality with Azure DevOps Branch Policies

Chris Reddington — Sun, 12 Sep 2021 12:31:39 +0000

This post was originally published on Thu, Sep 9, 2021 at cloudwithchris.com.

What are Branch Policies?

This post is similar to another I recently wrote on using Branch Protection Rules in GitHub. Instead of focusing on GitHub, we'll be looking at how you can use Branch Policies in Azure DevOps (specifically, Azure Repos). If you're using Azure Repos, but not using Branch Policies - I'd encourage you to start using them! I hope this post helps you learn how!

In the world of DevOps, there is a term known as Shift Left. This term effectively means 'find and prevent issues early'. There are several studies that have shown that the most effective way to prevent issues is to find them early in the software delivery lifecycle. This is because the more issues you find early, the more likely it is that they will be identifiable, and therefore fixed.

Let me play devil's advocate for a moment. What happens if you have no barriers to push your code into the main line of development? If there are no quality checks, then you could be pushing code to your production codebase that isn't up to scratch. If you have no automated tests, or code review process, then you don't have the ability to identify and fix issues early. This means you're going to have to wait until the end of the software delivery cycle to find the first issue, which is a waste of time and money. Wouldn't it be better if you could find the first issue as soon as possible?

This is where Branch Policies come in. Branch Policies are used to enforce workflows for one or more branches in your Git repository hosted on Azure Repos. These rules are enforced by the service and can be configured by anyone who has permissions as per the repository security configuration.

Tip: To control who which users or groups can Edit Branch Policies, in addition to other repository-level actions, navigate to your Azure DevOps Project Settings. Under the Project Settings, you will see a section for Repos, and an item called Repositories. You can specify permissions across all repositories within the project, or a specific repository. This can be achieved by specifying Azure DevOps Groups or individual users, and then selecting the appropriate permissions for them. You can find an example in the screenshot below.

In essence, before you commit to a certain branch (or a set of branches), you need to fulfil a set of conditions. If you don't, then you won't be able to commit to that branch. These conditions include:

You need to have a minimum number of reviewers that have approved your change, before code can be merged.
You need to have work items associated with your change, before code can be merged. This allows for traceability, so you know what changes are associated with each change to the codebase.
All active comments (i.e. discussions, rather than code comments) must be resolved before a Pull Request can be merged.
Restricting changes to be merged in a specific way (This could be its own entire blog post, so we'll gloss over this one for the purposes of this post.)
Trigger a build automatically when a Pull Request is triggered. This enables you to run builds, automatic tests, and other automated processes to automatically verify whether some changes may have broken the codebase.
Ensure a successful status check from External Services (Perhaps some external code scanner that you have a dependency upon?) before a Pull Request can be merged.
Automatically include code reviewers on a Pull Request if certain areas of code have changed. This is a nice alternative for the CODEOWNERS concept if you are familiar with it from GitHub.

Tip: Branch policies can be configured from the Branches page under Azure Repos. You can action these by hitting the ellipses (three dots) on the branch that you would like to protect. In the screenshot below, you can see that the main branch has been protected as it has a small icon (which looks a little like a medal), next to the branch name.

So, in summary - you need to have a set of conditions that you can fulfil before you can commit to a branch. If you don't, then you won't be able to commit to that branch.

Setting up Branch Policies

In Azure DevOps, Navigate to the branches section of Azure Repos in your Azure DevOps project.
Make sure that you have the appropriate repository selected at the very top of the page. (You can house several Git repositories within the same Azure DevOps project, so it's important to ensure you're working in the appropriate context!)

Hover over the appropriate branch, and select the ellipsis (three dots) on the right hand side. Select the Branch Policies option.

You will see a list of settings, some of which will have subsettings within them This is the list of branch policies that you can configure for the branch that you wish to protect. There is no save button on this form, as the options are saved automatically.

Configure the rules as appropriate for your branch. I typically configure some variation of the following: Require a minimum number of reviewers, Check for linked work items, Check for comment resolution and Build validation.

Tip: There is some great detail in the Azure Docs about each of the Branch policies that you can configure. Rather than re-writing the same detail here, I encourage you to dive in and take a look over there!

Navigate back to the branches page under Azure Repos. If you did not previously have a Branch Policy configured, you should now notice a small icon (which looks a little like a medal) next to the branch name.

As an example, I made some changes to my master branch protection policy. I now have the Require a minimum number of reviewers set to 1, and allow requestors to approve their own changes enabled. Consider this a warning - this configuration means that I can review my own PRs and approve them, somewhat defeating the point of a Pull Request workflow. However, given it's just myself that works on the project - It makes some sense here. I have set Check for linked work items to on, and Check for comment resolution to on as well.

Tip: You aren't limited to applying branch policies to individual repositories. You can navigate to the Project Settings, and navigate to the Repositories option underneath the Repos section. Click on the policies tab, and you will see a section for Branch Policies. Here, it says that you can "Protect important branch namespaces across all repositories in this project"

Now, we'll want to check whether our Branch Policies are working! After navigating to my readme.md, and wanting to make a dummy change - You will notice that I am prevented from committing the change to the main branch.

Instead, we can use the same User Interface to commit the change in a new branch and raise a Pull Request. Pull Requests can also be raised under the Azure Repos section, by clicking on the Pull Requests item.

After creating a Pull Request with the default settings, you can see that I have been taken to the Pull Request page to review the changes. Based on the settings that I had configured, even if I approve the Pull Request, I will not be able to merge the changes. This is because I have not linked a work item to the changes, and therefore have not met the conditions to merge.

At this stage, I have now proceeded to link a work item with the Pull Request. You can see that the Pull Request now just requires 1 reviewer to approve.

Finally, after approving the Pull Request, I can now merge the changes.

Summary

There we go! Throughout this blog post, we have begun our journey of shifting left. We are no longer allowing any code to be directly committed to our production codebase. Instead, we are enforcing a set of rules so that a consistent workflow is maintained. That workflow may include peer reviews, build validation, ensuring work items are linked and more! This is only one part of the journey in shifting left. Azure Pipelines are incredibly powerful, and could be used to automate your builds, tests and more when using build validation. Why not create an Azure Pipelines that is triggered when a Pull Request is created or updated? I hope that you can see how this wider story may continue. But, of course - that's for another day!

Are Branch Policies something that you are already using? Perhaps in Azure DevOps, GitHub, or with another tool? I'd love to hear how you're using them, and some of the practices that you may have picked up along the way. Drop me a message over on Twitter, @reddobowen. In the meantime, I hope this has been useful! Thanks for reading, and bye for now.

Migrating to the Cloud

Chris Reddington — Sun, 12 Sep 2021 12:17:22 +0000

This post was originally published on Wed, Sep 8, 2021 at cloudwithchris.com.

In this episode, Chris is joined by Susanne Tedrick. Susanne is an Azure Infrastructure Specialist for Microsoft and the award-winning author of "Women of Color in Tech". They will discuss the basic technical and business considerations to be made when migrating applications and workloads to the cloud, based on the Cloud Adoption Framework.

Fix for .bashrc not executing on startup in Ubuntu on Windows Subsystem for Linux

Chris Reddington — Sun, 12 Sep 2021 12:14:32 +0000

This post was originally published on Mon, Sep 6, 2021 at cloudwithchris.com.

In case you haven't heard, I'm planning to do some livestreams in the near future which are focused on live development / building in the cloud. I'm working on a few ideas, but if you have any suggestions - please throw them my way! To prepare for this, I've recently spent some time making sure my local development environment is in order. Windows Terminal and Windows Subsystem for Linux (WSL) are a couple of the key tools in my local development environment. Windows Subsystem for Linux is the focus for this post.

Windows Terminal is an awesome tool. I've written another blog post on how it can make you productive with Azure. If you aren't familiar with it, or want some productivity tips - I definitely recommend checking out the post!

For my local development, I typically use Ubuntu in Windows Subsystem for Linux. From my university days, the computer terminals were all Linux-based (I think a flavour of Debian?), and I used a Macbook Pro throughout my time at university as well. I've built up a bit of a natural preference for the Linux command-line over that time, so it now comes more naturally to me. Hence why Windows Subsystem for Linux, Windows Terminal and Ubuntu are my go-to local command-line tools.

As you'll have guest from the title of this post, I've been having some issues with my Ubuntu environment. Nothing significant, but several papercuts that kept getting in the way of my productivity. I'll talk about other issues that I've been working on fixing in separate blog posts.

My goal was to have a consistent usability experience configured across the PowerShell and Ubuntu environments, considering tools such as ohmyposh.

Tip: If you haven't heard of ohmyposh, then it's worth looking into. Scott Hanselman has done a brilliant write-up on how you can get this setup in your environment.

I was following one of his posts, but couldn't seem to get the prompt working successfully. Scott's guidance and posts are awesome. I've followed the same post before, so I know that it works. There had to be something else going on in my environment. I made the changes to my ~\.bashrc file as suggested throughout several blog posts and docs, but nothing seemed to reflect the modifications to ~\.bashrc when a new shell was created. There was no pretty prompt, and my aliases were not working.

My next troubleshooting step is likely the one that most of you would try next. Clearly, there was something in my ~\.bashrc preventing the full file from executing. It must be failing to execute mid-way through. Let's figure out how far the script is able to execute and debug from there.

The troubleshooting step? It's of course the highly-advanced (sarcasm intended!) use of echo statements throughout the script to identify at what stage the script is failing.

I shut down the WSL environment by using wsl.exe --shutdown and reopened a new Linux Tab in the Windows Terminal to ensure this was a fresh instance. I was surprised to find that none of my new echo statements were being invoked. This led me to the conclusion that ~\.bashrc wasn't being executed.

I had to test the theory. To achieve this I executed the command source ~\.bashrc in the Ubuntu tab that had already been opened.

Tip: The source command reads and executes the commands within a file, so would certainly load the ~\.bashrc file, and set the desired configurations.

Because of its nature,you make sure that you're only using the source command on a file where you trust the contents!

The series of echo statements printed into the terminal immediately. I was also greeted by a new, prettier looking prompt - ohmyposh! My theory held true. The ~\.bashrc file wasn't being executed when a new Linux Tab was created in Windows Terminal. This was also the case when directly opening Ubuntu in WSL.

This led onto the next line of investigation. Why was it not executing on start up? As it turns out, there's a fairly simple explanation. The summary on the man pages for bash gives us a clearer understanding of the potential problem (quoted below).

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.

So, how is ~/.bashrc being executed in the first place? After looking in my home directory, I could see that I have a file called ~/.profile. This file includes the following code snippet, which loads the ~/.bashrc file if it exists.

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
        . "$HOME/.bashrc"
    fi
fi

As a next step, I investigated the other files available in the home directory. I noticed that a ~/.bash_profile file exists (which would have taken precedence over the other files). At some point, I must have followed a set of instructions to install some software and mistakenly created a .bash_profile file instead of putting it into the ~/.bashrc file, as there was only one line (which was also present in my ~/.bashrc file).

I then removed the ~/.bash_profile file and used the wsl.exe --shutdown command to shutdown the WSL environment, so that I can determine whether this fixed the execution problem by launching a fresh environment. Guess what? It was the problem! After removing the superfluous ~/.bash_profile file, the ~/.bashrc file executed without any problems - The echo statements, ohmyposh, and all of the aliases that I had expected to be configured.

So what's the morale of the story here? Be careful when you're following instructions! Adding a file here or there can seem trivial, but might have some side-effects based upon the wider system. Map the instructions back to your own environment, and what makes sense (i.e. Whenever I made the change previously - rather than creating a ~/.bash_profile and adding the contents, I should have just added them to the ~/.bashrc file).

Now, I have an environment that has all of my aliases, ohmyposh and wider configuration preferences set up correctly. It's a small tweak, but has a big impact on my own productivity.

I hope that you've found this post useful. Have you had your own challenges getting your local Linux Environment setup? Let me know over on Twitter, @reddobowen, perhaps we can share some tips!

In the meantime, thanks for reading this post. Stay tuned for some additional tips in the near future - bye for now!

Tales from the Real World - Leveraging Azure as a Telco provider

Chris Reddington — Sat, 04 Sep 2021 07:05:19 +0000

This post was originally published on Fri, Sep 3, 2021 at cloudwithchris.com.

In this session Chris is joined by Ivo who will explain how Telco providers are leveraging Azure to offer services to their customers. He will explain how they transform and what the future will be. He will also cover the benefits and struggles that they faced on the way.

CGN7 - Cloud Gaming Notes Episode 7 - Game Streaming and Cloud-Powered Gaming

Chris Reddington — Sat, 04 Sep 2021 07:00:11 +0000

This post was originally published on Wed, Sep 1, 2021 at cloudwithchris.com.

In this session, Chris is once again joined by Lee Williams. Chris and Lee talk through industry trends around Game Streaming (i.e. streaming games to your device, rather than livestreaming what you're playing to others), and the opportunities this brings to game creators and consumers.

Shift Left and Increase your Code Quality with GitHub Branch Protection Rules

Chris Reddington — Mon, 30 Aug 2021 17:01:20 +0000

What are Branch Protection Rules?

If you're using GitHub as your source control provider, then I'd encourage you to using Branch Protection Rules if you're not already doing so! In this blog post, we'll cover what Branch Protection Rules are and how they can increase your code quality.

This is where Branch Protection Rules come in. GitHub Branch Protection Rules are used to enforce workflows for one or more branches in your Git repository hosted on GitHub. These rules are enforced by GitHub and can be configured by the organization or individual repository owner.

You need to have a certain number of approvals from the approvers list.
You need to have status checks to pass before you can commit.
All conversations on code must be resolved before a Pull Request can be merged.
Commits must be signed.
Require a linear history (i.e. commits can't be pushed out of order. This could be caused by merging a feature branch based on an old version of master, for example). There is a good write-up on linear vs non-linear history here.
Ensure that all restrictions also apply to administrators.
Restrict which people, teams or apps can push to any branches which match the convention you've set.

So, in summary - you need to have a set of conditions that you can fulfil before you can commit to a branch. If you don't, then you won't be able to commit to that branch.

Setting up Branch Protection Rules

Navigate to a GitHub Repository that you own. For example, I am the organization owner of CloudWithChris, so will navigate to my cloudwithchris.com repository.
Click on the Settings tab.

Click on the Branches tab.

Click on the Add Rule button.

You will now see a form to create a new Branch Protection Rule. The first thing you need to do is complete a Branch name pattern. This pattern is used to match branches in your repository. For example, if you have a branch called master, then you would enter master in the pattern field. If you had several branches that start with preview, e.g. preview/mynewfeature or preview/myothernewfeature, then you would enter preview/* in the pattern field.

Configure the rules as appropriate for your branch. I typically configure some variation of the following: Require pull request reviews before merging, Require status checks to pass before merging, Require conversation resolution before merging, Require signed commits and Require all restrictions to apply to administrators.

Tip: Here are some extra insights when setting these rules -

Require pull request reviews before merging - You will need to specify the needed number of reviews to allow the Pull Request to be merged. This ensures that you have had a minimum number of peer reviews. Careful not to set this too high, as otherwise you'll be waiting on others to review your Pull Request. And potentially continually reviewing other people's requests!

Require status checks to pass before merging - If you have setup status checks on your repository, then you can configure the Branch Protection Rule to require that specific status checks pass before the Pull Request can be merged. Great for additional external validation if you depend on external services for verifying your code quality.

Require conversation resolution before merging* - If there is an ongoing discussion on code around implementation details, you may not want the Pull Request to be merged until the discussion is resolved. This is a good way to ensure that you don't accidentally merge a Pull Request that has not been fully resolved.

Require signed commits - This enforces that all commits on the branch must be signed. This may be required under certain Software Licenses, or if you wish to prove that someone committing is indeed who they say they are. You can find extra detail on commit signature verification on the GitHub docs, or a walkthrough that I put together on setting this up for your own commits.

Require all restrictions to apply to administrators - This helps you ensure that Administrators are not 'above the law', and have to follow the same rules as any other contributor (i.e. not able to override).

Click on the Save changes button.

You should now see that an additional rule has been added to your Branch Protection Rules list. Repeat this as many times as you need to, so that you can set up the workflow that best suits your branching strategy.

As an example, I made some changes to my master branch protection policy. I now have the Require pull request reviews before merging set to 1 (which means I just need one review on the PR), and Require signed commits set to true. I also have the Require all restrictions to apply to administrators set to true.

After navigating to my readme.md, and wanting to make a dummy change - You will notice that I am prevented from making the change.

Tip: A word of warning. If you're working on a pet project where it's mainly yourself contributing (e.g. Cloud With Chris). If you enable the require pull requests before merging, and apply restrictions to all administrators, then you will have to wait for someone else to review your Pull Request. There is no ability for a Pull Request author to approve their own changes. If you disable the Require all restrictions to apply to administrators, then you will be able to merge the pull request (though this would be true for any other administrators of your repository as well).

Summary

There we go! Throughout this blog post, we have begun our journey of shifting left. We are no longer allowing any code to be directly committed to our production codebase. Instead, we are enforcing a set of rules so that a consistent workflow is maintained. That workflow may include peer reviews, status checks, and other validation. This is only one part of the journey in shifting left. GitHub Actions is incredibly powerful, and could be used to automate your builds, tests and more. Why not create a GitHub Action that triggers on a Pull Request to a target branch? I hope that you can see how this wider story may continue. But, of course - that's for another day!

Are Branch Protection Rules something that you are already using? Perhaps in GitHub, or with another tool? I'd love to hear how you're using them, and some of the practices that you may have picked up along the way. Drop me a message over on Twitter, @reddobowen. In the meantime, I hope this has been useful! Thanks for reading, and bye for now.

Getting into DevRel

Chris Reddington — Fri, 27 Aug 2021 14:34:39 +0000

This post was originally published on Fri, Aug 27, 2021 at cloudwithchris.com.

In this session, Chris is joined by Martin Woodward - Director of Developer Relations at GitHub to talk about building communities, building experience talking and leading communities and then of Developer Relations, what it means and how to get into that role as your job.

Why you should care about Azure Front Door Standard and Premium

Chris Reddington — Fri, 27 Aug 2021 09:25:34 +0000

This post was originally published on Thu, Aug 26, 2021 at cloudwithchris.com.

Azure Front Door - It's an Azure Service that has been generally available for quite some time. It went Generally Available (GA) in April of 2019 after being in Public Preview since September 2018. It's had several updates since, including a slew of Web Application Firewall enhancements, Rules Engine support and much more. But did you know Microsoft released the Azure Front Door Standard and Premium SKUs in preview in Februrary of 2021? So, what are they? How do they compare to the aforementioned Azure Front Door offering? And when would you want to think about using Azure Front Door compared with Azure CDN? We'll be covering all of those points in this post.

What is Azure Front Door?

Let's first set the scene, making sure we're all on the same page. What even is Azure Front Door? If you haven't deployed it for your own solution, it's quite likely that you've used it as a consumer. There is a great case study on how LinkedIn uses Azure Front Door as part of their own infrastructure stack. Not a LinkedIn user? Well, the original Azure Front Door general availability blog post notes that Office 365, Xbox Live, MSN and Azure DevOps had all adopted Azure Front Door. So, like I mentioned - if you haven't already deployed it - it's quite likely you've already used it!

Azure Front Door is a global service, which is typically used as an entry point for web applications. It's well-suited for this task, as it operates at Layer 7 (HTTP/HTTPS-based) of the networking stack. However, calling it a load balancer would be underselling it. Azure Front Door uses the Microsoft Global Edge network to accept traffic from end-users. You can associate a Web Application Firewall (WAF) with it, to protect your applications from potential threats.

Note: There are different types of Load Balancing options. For example, Azure Load Balancer operates at Layer 4. Azure Traffic Manager is a DNS based load balancer. The difference between these is where they operate in the networking stack. Layer 4 is the transport layer, whereas Layer 7 is the application layer.

Therefore, the decisions that can be made at Layer 4 are typically based around the TCP and UDP protocols. There is no context or option to make decisions based upon information at the application level (e.g. Path based filtering, etc.). Layer 7 load balancing allows you to make load balancing decisions based upon some information/context from the application. Think about aspects like Request Headers, Request Paths, etc. A good comparison would be Azure Load Balancer (Layer 4) vs Azure Application Gateway (Layer 7).

You can find some additional information on Layer 4 vs Layer 7 load balancing on the NGINX Website.

How do Azure Front Door Classic, Standard and Premium compare?

Azure Front Door Standard and Premium went into preview in February 2021. The explanation of Azure Front Door in the previous section is true for Azure Front Door (Classic), as well as Azure Front Door Standard and Premium.

However, Azure Front Door Standard and Premium has additional enhancements. Depending on the type of traffic - You can either accelerate traffic by using Dynamic Site Acceleration (DSA) to the appropriate source, or serve up cached contents through it's Content Delivery Network functionality. In the Standard and Premium SKUs, Azure Front Door combines the capabilities of Azure Front Door, Azure CDN and Azure Web Application Firewall (WAF).

Both Azure Front Door Standard and Premium contain several common features, including -

Custom Domains
SSL Offload
Caching
Compression
Global load balancing
Layer 7 routing
URL rewrite
Enhanced Metrics and diagnostics
Traffic report

Azure Front Door premium contains the following features, in addition to the previous list -

Private Origin (Private Link)
Web Application Firewall (WAF) support
Bot Protection
Security Report

Note: Private Origin (Private Link) support is a big deal in my opinion. Before Azure Front Door Standard/Premium, I've seen a few scenarios where an organisation wants to build an Architecture of Azure Front Door in front of Azure API Management. The only way to achieve this at the time was by restricting traffic inbound, based upon Request Headers sent from Azure Front Door.

With Azure Private Origin (Private link), you can still route traffic to your backend origins, even if they are only accessible privately.

Why would you care about this pattern? So that you can guarantee traffic is not being bypassed to your backend services, and is being routed through Azure Front Door. Perhaps you have adopted some rules in your WAF that you wish to process before traffic reaches your application. Having a private backend, while having a public entry point at the edge allows you to achieve this.

It's worth mentioning that (at time of writing), Azure Front Door Standard and Premium are in a preview state. Azure Front Door (Classic) is Generally Available. However, the docs call out many reasons to use Azure Front Door Standard or Premium. It's important to note that it's not recommended for production workloads until it exists a preview state.

There is a difference in the pricing models between Azure Front Door (Classic) and Azure Front Door Standard / Premium. Azure Front Door classic had a more involved pricing structure, based upon outbound data transfers, routing rules, inbound data transfers and frontend hosts. The WAF capability was an additional cost if enabled, with custom rules / managed rulesets also having an additional price per unit.

In contrast, Azure Front Door Standard / Premium's pricing model is simplified. There is a base fee for either the Standard or Premium SKU. On top of that, there are charges based upon outbound data transfers (i.e. data going out of Front Door POPs to the client), inbound data transfers from POPs to origin and requests incoming from client to Front Door POPs.

Note: It's important to note that Azure Front Door Premium includes Web Application Firewall (WAF) at no additional cost. This is an additional cost in Azure Front Door (Classic). Of course, the finer details of the pricing model can change over time. For the latest and greatest, please review the Azure Pricing Page.

Azure Front Door vs Azure CDN

Based on the previous section, you've likely noticed that Azure Front Door (Standard/Premium) and Azure CDN now share some common functionality around caching, and the rules engine.

If you've previously used Azure Front Door (Classic), then you may have previously had an architecture that used both Azure Front Door as well as Azure CDN. However, even Azure Front Door (Classic) had caching capabilities built-in as per the Azure Docs.

You'll notice that the adjustments for Azure Front Door Standard and Premium, make this feel like a much more integrated experience, as it is part of the setup process of your new Azure Front Door Resource (as explained in the blog post announcing Azure Front Door Standard and Premium). The idea behind this new Azure Front Door experience is a single unified platform to accelerate static and dynamic content acceleration. All that, with the combined functionality of Web Application Firewall (as explained in the opening of this post).

Note: What is the difference between Static Content/Site Acceleration and Dynamic Content/Site Acceleration?

Think of Static Content/Site Acceleration as caching the files closer to your end-users. So, a typical CDN scenario. This is how the Cloud With Chris website, as well as Cloud With Chris Podcast MP3 files are delivered to you. They are hosted in a central location (e.g. Azure Static Web App or Azure Storage Account), and are cached at Points of Presence on the Microsoft Edge closer to you.

But what about Dynamic Site Acceleration? The fact that it's dynamic means that we can't cache the content, as it's likely going to change over time. That strategy may not work here. Fundamentally, the internet is an unreliable place. Routes become unavailable, transient issues can impact our path. Dynamic Site Acceleration uses route optimization techniques to choose the most optimal path to the origin, so that users can be sent via the fastest and most reliable route possible.

Dynamic Site Acceleration can often use additional TCP optimizations to ensure the traffic is routed efficiently and effectively. For example, eliminating TCP slow start, leveraging persistent connections and tuning TCP packet parameters are just some typical examples (these are general examples to illustrate the point, and not specific to Azure Front Door).

How does Azure Front Door work?

As a service, your usage of Azure Front Door is primarily around configuration (i.e. setting up your endpoint name, your origin details and additional configuration around caching, compression and WAF options).

From a scalability perspective, the service deals with this transparently.You won't see any sliders to specify the minimum, maximum or desired number of instances. You don't need to specify autoscale rules or similar. The service will scale automatically for you.

Now, I've hinted a few times that Azure Front Door is a global service. This means that Azure Front Door's edge nodes (sometimes known as points of presence) are global in nature. This point is worth thinking about in some further detail.

One of the configuration options that you have in Azure Front Door is adjust the health probes used from the edge nodes to your origin.

Why is this important? As Azure Front Door is global, it's going to have many of these edge environments all across the globe. That means that each of those edge environments will be sending a health probe at some point. If you're particularly aggressive with your probe timeout settings (e.g. every few seconds), then this will cause a significant increase in the requests to your backend origin.

Note: This is particularly important to consider if your origin wasn't designed for scale, and you may need to consider the additional load from these probes.

Alternatively, if you are using a serverless tier (based on pay-per-execution), then your health probe configuration will have a tangible impact on your costs.

Summary

In summary, Azure Front Door Standard / Premium are some welcome evolutions on the Azure Front Door (Classic) offering. It has a new pricing model which is simpler to understand, and contains some notable feature updates (e.g. Private Origin Support (Private Link)). Azure Front Door Standard is content-delivery optimised as opposed to premium which is security optimised.

Azure Front Door can bring value if you have a distributed set of users that you want to serve content to. The content can either be dynamic (and leverage the Dynamic Site Acceleration capabilities of Azure Front Door) or static (and leveraging the caching capabilities of Azure Front Door). Don't forget, the premium SKU is security optimized and has Web Application Firewall (WAF) capabilities built-in. A great addition to the entry point for your Web Application!

If you want to learn more about Azure Front Door, I recommend that you take a look at the Introduction to Azure Front Door Microsoft Learn Module, as well as the Azure Documentation. Be aware that there is a separate documentation hub for Azure Front Door (Classic) and Azure Front Door (Standard/Premium).

Are you already using Azure Front Door? Are you using Classic, Standard or Premium? Perhaps you're considering using Azure Front Door after scanning through this post? I'd love to hear more over on Twitter, @reddobowen. If there's anything that you'd like me to explore in a hands-on blog post, please let me know! I'm already considering a blog post which compares Azure Front Door (Classic) with Azure API Management to Azure Front Door (Premium) with Azure API Management, and the private link capabilities (which I hinted a little further up in the article). Thanks for reading, and bye for now!

Why closed captions in your public speaking may make a difference

Chris Reddington — Fri, 27 Aug 2021 09:23:51 +0000

This post was originally published on Wed, Aug 25, 2021 at cloudwithchris.com.

People with hearing impairments are often overlooked, yet they are actually in greater numbers most people believe. In this talk, I’ll give insight to those people. I know this of my own experience since I am deaf user with Cochlear Implants which gives me a hearing back, but it is not a full hearing as you might hope for. I also can give some insights for other people who are less impaired because I’ve am a co-founder of two national associations in Switzerland.

43 - A Decentralized Reference Architecture for Cloud-native Applications

Chris Reddington — Fri, 20 Aug 2021 21:46:18 +0000

This post was originally published on Fri, Aug 20, 2021 at cloudwithchris.com.

The number of microservices running in enterprises increases daily. As a result, service composition, governance, security, and observability are becoming a challenge to implement and incorporate. A "cell-based" architecture is an approach that can be applied to current or desired development and technologies to address these issues. This technology-neutral approach helps cloud-native dev teams become more efficient, act in a more self-organized manner, and speed overall release times.

In this talk, Asanka will introduce the "cell-based" reference architecture, which is decentralized, API-centric, cloud-native and microservices friendly. He will explain the role of APIs in the cell-based approach, as well as examine how real applications are built as cells. Asanka will explore the metrics and approaches that can be used to measure the effectiveness of the architecture and explore how organizations can implement the cell approach.

Discussing the Cloud with Chris Integration Platform

Chris Reddington — Fri, 20 Aug 2021 21:43:56 +0000

This post was originally published on Thu, Aug 19, 2021 at cloudwithchris.com.

In this session, Chris is joined by Karl Cooke, Blogger at https://irishtechie.com. Chris and Karl talk all about the CloudWithChris.com integration platform, and the numerous automation/integration activities that Chris has in place to save time and focus on building content!