Choosing an Azure datacenter for your service

When building a web-based service that will be used by people all around the world you also have to think about network latencies that are imposed by geographical distances. Your service itself may be very fast, but it won't matter if users on the other side of the globe will experience it with a delay of 1 second.

With Microsoft Azure, the cloud provider that we also use for all of our own services, you can choose from datacenters at different locations to run your service, thus optimizing network distance for your target audience. That is, of course, if you only want to run your service in just one datacenter and not in multiple ones to be able to reach more geographical regions on fast lines. We'll deal with the one-datacenter case in this blog post, since running a web-based service in multiple locations is neither technically simple, neither cheap, but optimizing the user experience for the intended target audience is something even the smallest applications are ought to do. So let's see how we can decide which datacenter to choose!

The methodology described here is the same we used to decide where to deploy our Orchard SaaS, DotNest.

Where are my users located?

First, you have to determine where your (intended) target audience is mostly located, since foremost you want users of your target audience to have the best user experience.

If your service is already running in some form, or you know that your target audience is the same as one of your other service's than you can consult your web analytics to get some exact anwers. This is of course not available if your service is totally new and you don't yet have experience of this sort; then it depends on your business plan to make a guess that's sufficiently educated.

For DotNest we decided that our primary audience is in West Europe and North America. This actually is quite lucky match: since there are a lot of high-speed network cables laid out under the Atlantic Ocean between the two continents (as you can see from e.g. this slightly out-of-date picture) it's actually possible to find a location that will be able to serve both sides of the big pond equally well.

Gathering the tools

OK, now we know where our users are located. But how are we going to determine which datacenter is best suited for them? We'll make some measurements!

Firstly we need to set up endpoints in all of the datacenters so we can use them to measure latency. For this we'll use Azure Web Sites: we won't deploy anything to the websites, the default page that a blank website returns will be enough, since we don't want to measure server performance but only network latency as much as possible. The websites will be just free ones, as the performance of a blank website, in our experience, doesn't differ from or vary significantly more than one on a paid tier, so it doesn't affect latency measurements.

At the time when our measurements were made less datacenters were available on Azure, so we've only made test websites for those DCs, namely the following:

You can use these endpoints for your own tests if you wish of course.

Since websites can go idle, especially the ones on the free tier, it's best if you warm them up by opening them before making any measurements.

Seondly we also need some tool to measure latency of the various endpoints from different locations. For this we've used Alertra's Spot Check tool (see the textbox on the top of the page) that can measure response times from a variety of locations. (Another interesting tool to check the latency from your current locations to all Azure datacenters is Azure Speed Test.)

Evaluating the results

So we've set up all the test sites and have the right tool to measure response times. The next step is get the numbers clear and see which location performs best.

For this purpose we've created a simple spreadsheet that you can use to evaluate the results. As you cen see we've made measurements to all of the websites with Alertra's tool and put them into a table. Then we calculated the average response times for our intended target audience's locations, namely London, Chicago, Los Angeles and Washington DC in the P column. By simply changing the function that calculates the values in that row you can see the numbers for your target audience too.

As one can see from the spreadsheet East US came out as the winner with North Central US being a close second. East US was faster than North Central US in the majority of cases and also a bit faster on average too.

While the proportion of these numbers may be accurate, take the concrete values with a grain of salt. In our experience the actual response times are much better than the ones measured by Alertra's tool. For example from Hungary, where we're located, we can get a response from DotNest within 150ms at worst for cached pages, what is much faster even than what Alertra's tool measured from London (about 500ms)

For DotNest we've gone with the East US datacenter, and so far it seems like a good decision. We've got numerous feedbacks form our users that the service is very fast.

So where are you going to put your application?

zoltan.lehoczky Azure Latency

Other recent posts

Rebuilding DotNest.com: Orchard Core, Tailwind 4, and a more maintainable workflow
DotNest is Lombiq’s managed Orchard Core hosting platform where users can create and run Orchard Core sites without handling infrastructure, updates, or maintenance themselves. We recently rebuilt the site to give DotNest a clearer presentation and a more modern user experience. By looking behind the scenes of the DotNest site rebuild, you’ll see how a website redesign can become a broader modernization project: improving how landing pages are structured, introducing Tailwind 4 into an Orchard Core front-end workflow, simplifying asset handling, and using AI-assisted tools in a practical way while keeping developers in control. Why the rebuild mattered The previous site served its purpose, but it no longer matched what we envisioned for DotNest. Beyond a more modern design, we needed clearer messaging, and a content management structure that would be easier to maintain as the site evolved. This was especially important because DotNest is more than a marketing website. It also reflects how we approach building maintainable Orchard Core platforms. If the site itself is hard to update, every future improvement becomes slower and more expensive than it should be. So we treated the rebuild as more than a visual refresh. It became a chance to rethink the site’s structure, front-end workflow, and development process in a way we can reuse on future Orchard Core projects. Building landing pages around reusable sections One of the main changes was how landing pages are structured in Orchard Core. Previously, the DotNest pages used simple Liquid widgets for page sections. This was quick and flexible while most changes were made directly by developers, but it also meant that the page structure was less explicit and harder to evolve consistently over time. Around the same time, the Orchard Core community was also moving toward more reusable “Blocks”-style page structures, which aligned closely with the direction we already wanted to take for DotNest. The rebuild became a good opportunity to apply a similar pattern in practice. For the new site, each landing page section now has its own content type, and the sections are composed on the landing page through Orchard Core’s BagPart. This keeps the flexibility of section-based pages while giving each section a clearer structure and purpose. The result is a landing page system that is easier to understand, easier to extend, and less dependent on ad-hoc template changes. At the same time, the reusable section-based approach gives content editors flexibility within clear guardrails, making it much harder to accidentally break layouts or page structure. For a marketing site that will keep evolving, that maintainability matters as much as the initial design. Modernizing the front-end workflow The rebuild was also the point where we introduced Tailwind 4 into our internal front-end workflow for Orchard Core projects. Previously, we used a BEM-style approach with custom CSS files. While this worked well for years, it also created more manual structure and coordination as the site evolved. With Tailwind 4, we could build UI components faster, keep styling closer to the markup, and work more consistently with our design system. As part of the rebuild, we removed the old Node.js-based asset pipeline and integrated Tailwind directly into the .NET build workflow. That led to Lombiq Tailwind Targets, our open-source MSBuild integration for Tailwind CSS. With Lombiq Tailwind Targets, Tailwind compilation runs as part of the .NET build process, making the front-end workflow feel like a natural part of the Orchard Core application instead of a separate toolchain to maintain. This also aligned with a broader direction we had already started exploring at Lombiq: simplifying front-end tooling and moving away from Node.js-based workflows where they add unnecessary maintenance overhead. We wrote earlier about this approach in Step away from that Node.js. Using AI where it helps, with developers still in control AI-assisted tools became part of the rebuild mainly in the UI and front-end workflow. We used Magic Patterns to explore UI directions and generate Tailwind-based starting points from our design system. Since the generated code was not always aligned with Tailwind 4 or the final Orchard Core implementation, we still reviewed and refactored it before integrating it into the site. To support this workflow, we also created two open-source repositories: Tailwind Agent Skills and Orchard Core Agent Skills. These agent skill collections give AI tools more project-specific context around Tailwind 4, Orchard Core theming, content modeling, shapes, and recipes, making the output far more useful than generic prompting alone. The goal was not to automate development away, but to make AI-assisted work more practical and reviewable for real Orchard Core projects. AI helped speed up repetitive and exploratory tasks, while developers still made the architectural and implementation decisions needed to keep the final result maintainable. What we gained from the project One of the biggest takeaways was how much easier Orchard Core landing pages become to manage once reusable sections and clearer content structures are introduced. The previous setup had gradually accumulated friction over time, while the new approach already feels easier to extend and work with. The rebuild was also our first larger Tailwind 4 project, and it significantly changed how quickly we can build and adjust UI components. That experience directly led to Lombiq Tailwind Targets and helped shape how we want to handle front-end workflows in future Orchard Core projects. We also learned a lot about practical AI-assisted development. Working on a real-world project made it much clearer where AI tools actually help and where developer oversight still matters. That experience ultimately led to the Tailwind Agent Skills and Orchard Core Agent Skills repositories. Most importantly, we validated different development approaches for future Orchard Core websites. If you’re planning an Orchard Core website, a redesign, or a modernization project, reach out to us. We’re always happy to help teams build Orchard Core solutions that remain easy to evolve as requirements grow over time.

Your analytics isn’t broken. It’s incomplete.

Web analytics is the foundation of modern marketing decisions. But today, a growing portion of user behavior simply doesn’t show up in your reports.

Ad blockers, browser extensions, and privacy tools can strip tracking parameters or block analytics scripts entirely. The result is incomplete campaign data, misleading attribution, and decisions based on partial visibility.

For marketing and product teams, this is not just a technical inconvenience. It is a business risk. Campaign performance becomes harder to evaluate, budgets are harder to justify, and growth decisions rely on guesswork instead of evidence.

Bringing Orchard Core into the classroom at Óbuda University
Since 2013, we’ve been working with Óbuda University on a hands-on way to teach web development. What began as a course built around Orchard CMS later evolved into an Orchard Core-based subject, giving students a chance to learn by building something that could actually work in the real world, not just completing classroom exercises.We asked our colleague Gábor Domonkos, who has led the collaboration for years, to walk us through how the course started, how it works today, and what students usually take away from it.– How did this collaboration start?At first, the university had a Hungarian, non-developer course focused on Orchard CMS and DotNest, Lombiq’s hosted Orchard platform. Students built sites through the admin UI, which was a good introduction to content management. But once Orchard Core arrived, we saw a chance to create something more ambitious: a developer-focused subject where students could also write code and go beyond the basics.– What changed with Orchard Core?Orchard Core made the course much more flexible. Students can now learn not just how to use a CMS, but how to extend it, customize it, and build on top of it. That meant more room for customization and coding. It also gives them a much more realistic picture of what it means to develop with a modern CMS on ASP.NET Core.– How is the course structured?The semester is built around a few milestones. Early on, students choose their project topic and define the basic idea. Midway through the semester, they should already have a working site with real content. By the end, the project should be close to final, both in structure and content.The later stages are mostly about making sure students stay on track. If they need help, they can share a short update so we can spot problems early and steer them in the right direction. Some students also choose to demo their project before the official deadline.– What do students usually build? Any favorites?That depends on which version of the course they take. In the non-developer version, students often build sites with forms, search, taxonomies, and content workflows. In the developer-focused version, they go further and build custom modules, themes, and more advanced functionality.One project that stands out was a volunteer platform. Organizations could publish volunteer opportunities, and users could browse, apply, and track their enrollments. It was a nice example of how Orchard Core can support a real, practical use case without adding unnecessary complexity.– Has this led to anything beyond the course?Yes, some students later became our colleagues at Lombiq. By the time they finish the course, they already know the basics of Orchard Core and have built something real with it. More importantly, they have seen what it’s like to work with a real open-source ecosystem, not just with a classroom demo.– Where should someone start if they want to learn Orchard Core today?If someone wants to learn Orchard Core today, Lombiq has a few good starting points. Dojo Course 3 is a full video course on YouTube that walks through Orchard Core for both users and developers. We also maintain the Lombiq Training Demo for Orchard Core on GitHub, which is a functional module with heavily commented code to help developers understand how Orchard Core works in practice. And beyond that, Orchard Dojo regularly publishes tutorials, tips, and other learning resources for the Orchard community. For us, that is the best proof that the collaboration works. Students gain practical experience, the university gets a more hands-on subject, and the industry gets people who are better prepared for real projects. We believe more universities could benefit from this kind of collaboration, whether with Orchard Core or other open-source technologies. And if you are exploring something similar, we are always happy to share what has worked for us so far.

Event management backend for one of the largest retailers
Avastec, a UK company, approached us to continue the development of their existing Orchard Core-based headless backend utilized by the event management site of one of the world's largest retailers. It was already in use with a publicly accessible Node.js-based frontend. The end client urgently wanted some new features, with follow-up tasks to optimize the system's performance, and keep the app up-to-date while maintaining the integrity of the user interface. Our initial task involved the transformation of data migrations from the simpler recipe-based paradigm to a more structured code-based approach. This transition aimed to enhance the traceability of modifications the development team applied. Simultaneously, a suite of UI tests was integrated into the workflow to uphold continuous code quality assurance. Leveraging the flexibility of Orchard Core's migration API, we executed this pivotal migration process without it negatively affecting users. Since then, we've delivered a lot to meet various user requirements, including event ticketing, integrating with a GDPR compliance API, and launching the site for another brand of the end client. One particularly interesting task was the implementation of QR code-based entry management, which we also supplemented with UI tests using the Lombiq UI Testing Toolbox. We've also implemented a feature to let the app use a fake video feed during tests, what we also demoed during the weekly Orchard Core podcast. From our other open-source projects, we also utilized Lombiq Helpful Extensions, as well as Lombiq Hosting - Azure Application Insights, since the app is hosted in Azure. This is what Steve Taylor, CTO and Founder of Avastec says about our joint work: Working with this team has been a genuinely positive experience from day one. They quickly understood the complexities of our existing Orchard Core setup and delivered improvements without disrupting a live, high-traffic platform. Their ability to balance rapid feature delivery with long-term maintainability and performance has been particularly valuable. The introduction of structured migrations, robust UI testing, and innovative solutions like QR-based entry management significantly elevated the quality of the system. They’ve consistently demonstrated technical expertise, reliability, and a proactive mindset, making them a trusted partner in the ongoing evolution of our platform. Thanks to Orchard Core, UI testing, and innovative feature implementations, we effectively addressed Avastec’s challenges and delivered a significantly improved event management backend. It continues to serve the end client, with us working on improvements to this day. Do you want to launch and event management platform on Orchard Core? We have actually built several more too, get in touch with us!