In this blog post we are going to be showing you can configure Azure Application Insights to send your logs, exceptions and performance metrics from a .NET 6 API.

Installation
Start by installing the Microsoft.ApplicationInsights.AspNetCore nugget package.

Now in your startup class you will need to configure some options for the telemetry collection.
You can use the AddApplicationInsightsTelemetry extension method on the IServiceCollection and pass your options as so:

public class Startup
{
    public virtual void ConfigureServices(IServiceCollection services)
    {
        services.AddApplicationInsightsTelemetry(GetApplicationInsightsServiceOptions());    
    }

    private static ApplicationInsightsServiceOptions GetApplicationInsightsServiceOptions()
    {
        return new ApplicationInsightsServiceOptions
        {
            AddAutoCollectedMetricExtractor = false,
            EnableEventCounterCollectionModule = false,
            EnableDiagnosticsTelemetryModule = false,
            EnablePerformanceCounterCollectionModule = true,
            EnableDependencyTrackingTelemetryModule = true,
            EnableRequestTrackingTelemetryModule = false,
            ConnectionString = Configuration[ConfigurationConstants.ApplicationInsightsConnectionString],
        };
    }
}

This is where we define the types of telemetry we want to collect.
The documention of the options are here: https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core?tabs=netcorenew#use-applicationinsightsserviceoptions
We are also getting the connection string of the application insights resource from our appsettings.

Telemetry modules
Now if we want to go further, we can even specify what metrics to collect for each module.
For instance, let’s say we want to indicate which performance metrics to collect. Then you can do the following:

        services.ConfigureTelemetryModule<PerformanceCollectorModule>((module, applicationInsightsServiceOptions) =>
        {
            module.DefaultCounters.Add(new PerformanceCounterCollectionRequest(@"\Process(??APP_WIN32_PROC??)\Private Bytes", @"\Process(??APP_WIN32_PROC??)\Private Bytes"));
            module.DefaultCounters.Add(new PerformanceCounterCollectionRequest(@"\Process(??APP_WIN32_PROC??)\% Processor Time", @"\Process(??APP_WIN32_PROC??)\% Processor Time"));
        });

You can view the documentation on configuring telemetry modules here: https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core?tabs=netcorenew#configure-or-remove-default-telemetrymodules

Extensibility
To add or remove properties from collected telemetry (before it gets sent to Azure) you can create classes that implement the ITelemetryInitializer class from the Azure Application Insights SDK (https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core?tabs=netcorenew#add-telemetryinitializers).

A classic example for a telemetry initializer is a correlation id initializer. You would get a correlation id from your http request and pass it to all telemetry so that you can have a nice trace of everything that went through your system:

public class CorrelationIdInitializer : ITelemetryInitializer
{
    private readonly IHttpContextAccessor _httpContextAccessor;
    private const string CorrelationIdProperty = "CorrelationId";

    public CorrelationIdInitializer(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    public void Initialize(ITelemetry telemetry)
    {
        ISupportProperties telemetryProperties = (ISupportProperties)telemetry;

        // This is just an extension method where you would extract the correlation id from the request headers according to your header name.
        string correlationId = _httpContextAccessor.HttpContext.GetCorrelationId();

        if (!string.IsNullOrWhiteSpace(correlationId) && !telemetryProperties.Properties.ContainsKey(CorrelationIdProperty))
        {
            telemetryProperties.Properties.Add(CorrelationIdProperty, correlationId);
        }
    }

To register the telemetry initializer, simply register the class and its respective interface (always ITelemetryInitializer) on your service collection: services.AddSingleton<ITelemetryInitializer, CorrelationIdInitializer>();

Filtering
Additionally, you also have the ability to filter out telemetry from being collected. This is a great feature that allows you to focus only storing what you really care about and will save you a LOT of costs.
Do keep in mind that filtering out telemetry does mean that you won’t be able to query it and therefore can make your tracing a bit difficult.
This is all related to telemetry processors (https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core?tabs=netcorenew#add-telemetry-processors).

Imagine you have thousands of fast dependencies (see the list of automatically tracked dependencies https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-dependencies#automatically-tracked-dependencies) that are being stored by your system but you come to a conclusion that they only make it hard to monitor your system and you don’t really need them.
Filtering them out is the way to go OR you could consider sampling instead https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core?tabs=netcorenew#sampling.
Lets create a processor that filters out successful dependencies that had a duration under 500 milliseconds:

public class FastDependencyProcessor : ITelemetryProcessor
{
    private ITelemetryProcessor Next { get; set; }

    public FastDependencyProcessor(ITelemetryProcessor next)
    {
        Next = next;
    }

    public void Process(ITelemetry item)
    {
        if (!ShouldFilterTelemetry(item))
        {
            Next.Process(item);
        }
    }

    public bool ShouldFilterTelemetry(ITelemetry item)
    {
        bool shouldFilterTelemetry = false;

        DependencyTelemetry dependency = item as DependencyTelemetry;

        if (dependency != null
            && dependency.Duration.TotalMilliseconds < 500
            && dependency.Success.HasValue && dependency.Success.Value)
        {
            shouldFilterTelemetry = true;
        }

        return shouldFilterTelemetry;
    }
}

After creating the class, you have to register the telemetry processor as part of your service collection like so:
services.AddApplicationInsightsTelemetryProcessor<FastDependencyProcessor>();

Keep in mind that if your telemetry processors will be executed in the order in which you’ve called them in your register process.

Final notes

– Azure Application Insights is a great tool that gives you visibility on how your application is doing.
You can use the SDK to collect most telemetry automatically or you could even instrument specific scenarios manually by making use of the TelemetryClient instance (https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core?tabs=netcorenew#how-can-i-track-telemetry-thats-not-automatically-collected).
– It is important to monitor your costs as it is easy to end up storing everything and not only what you need. So start by defining what you need to collect and what metrics will be relevant for you.
Then you can filter out the irrelevant data and from there on you could even create alerts from the data you collect, using Azure Monitor.
If you are trying out Application Insights on a test environment, you can even set a daily cap of X GB so that you control your spending. Simply navigate to the Azure Application Insights resource through the Azure Portal and click “Usage and estimated Costs” on the sidebar:

– From what I’ve seen so far, the collection of dependencies/exceptions can represent the majority of costs as you may have a lot of dependencies flowing through your system and because exceptions are a type of telemetry that occupies a lot of space. Filtering out irrelevant dependencies will definitely help.
As for exceptions, you may consider using the Result pattern instead of using exceptions for the normal control flow of your code. This also has the advantage of decreasing the impact on performance lead by exceptions to your application since you reduce the amount of exceptions thrown.

The post Configuring Azure Application Insights on a .NET 6 API appeared first on Blog IT.

Introduction

An Azure SQL Server failover group is a group of databases that can be automatically or manually failed over from a primary server to a secondary server in a different Azure region in case of a disaster in the primary server. Failover groups provide high availability and disaster recovery for Azure SQL Server databases.

The process described in this post is composed by two main steps:

• Provisioning the database
• Adding the database to the failover group

Provisioning the database

The first step is to create the database. This step is composed by the following actions:

• Get the tenant information
• Create the database

Tenant information class:

Code to create database programatically:

Adding the database to the failover group

The second step adds the newly created database to the failover group. This step is composed by the following actions:

• Get the failover group where we want to add the database
• Re-add the existing databases to the failover group – necessary since when we get the failover group the list of databases of the group is empty and, without this step, the failover group would only have the new database
• Add the new database to the failover group

Other Articles

To learn why your business should migrate to SharePoint Online and Office 365, click here and here.

If you want to learn how to develop SPFx solutions, click here.

If you want to learn how you can rename a modern SharePoint site, click here.

If you want to learn how to save time time scheduling your meetings, click here.

If you want to learn how to enable Microsoft Teams Attendance List Download, click here.

If you want to learn how to create a dynamic org-wide team in Microsoft Teams with all active employees, click here.

If you want to modernize your SharePoint classic root site to a modern SharePoint site, click here.

If you are a SharePoint administrator or a SharePoint developer who wants to learn more about how to install a SharePoint 2019 farm in an automated way using PowerShell, I invite you to click here and here.

If you learn how to greatly speed up your SharePoint farm update process to ensure your SharePoint farm keeps updated and you stay one step closer to start your move to the cloud, click here.

If you prefer to use the traditional method to update your farm and want to learn all the steps and precautions necessary to successfully keep your SharePoint farm updated, click here.

If you want to learn how to upgrade a SharePoint 2013 farm to SharePoint 2019, click here and here.

If SharePoint 2019 is still not an option, you can learn more about how to install a SharePoint 2016 farm in an automated way using PowerShell, click here and here.

If you want to learn how to upgrade a SharePoint 2010 farm to SharePoint 2016, click here and here.

If you are new to SharePoint and Office 365 and want to learn all about it, take a look at these learning resources.

If you are work in a large organization who is using Office 365 or thinking to move to Office 365 and is considering between a single or multiple Office 365 tenants, I invite you to read this article.

If you want to know all about the latest SharePoint and Office 365 announcements from Ignite and some more recent announcements, including Microsoft Search, What’s New to Build a Modern Intranet with SharePoint in Office 365, Deeper Integration between Microsoft Teams and SharePoint and the latest news on SharePoint development, click here.

If your organization is still not ready to go all in to SharePoint Online and Office 365, a hybrid scenario may be the best choice. SharePoint 2019 RTM was recently announced and if you to learn all about SharePoint 2019 and all its features, click here.

Happy Coding!

The post Provision a database programmatically in Azure SQL database with a failover group appeared first on Blog IT.

The pipelines bring to us the opportunity to create automatic tasks to execute development operations, like deploys, migrations, tests, etc. Focused in the deploy routine, some applications need other operations to ensure the stability between the application and other resources, like the database.

During the development process, the developers usually customize and improve the application database in the development environment scope, and it can be made easily by using frameworks that contains routines to create source files that have the responsability to keep the history of changes and are used to update the database for determinated version. These files are known as migrations. 

In this post, we will see how to apply migrations for the databases that are located in different environments (staging, production, etc.), using the Code-First entity concept, and the Entity Framework Core.

Migrations

To generate database migrations, we can execute the “Add-Migraton <name>” command from the Entity Framework. This command will generate some source files that will contain the code to apply the migration to the database. To execute these migration files, you just need to execute the “Update-Database” command. But, Microsoft recommends to create a SQL file individually, and suggest to execute this file direct to the database, without need to execute an intermediary software (C# + EF) to access the database. To do this, we will have to follow the steps below:

• 1. Create a Pipeline in Azure Devops;
• 2. Install dotnet-ef-tool;
• 3. Generate SQL script;
• 4. Execute SQL script to the database;
• 5. Script File as a Pipeline Artifact.

NOTE: We don’t need to worry about which migration need to be applyed to the database. The dotnet-ef-tool command will generate a script cantaining the needed logic. Check the third step for more details.

1. Create a Pipeline in Azure Devops

We will create a common deployment pipeline in Azure Devops for ASP.NET Core backend applications. Check the end of the post to see the full result of the pipeline.

2. Install dotnet-ef-tool

To execute tool commands of Entity Framework, we have to install a package named dotnet-ef-tool. This needs to be available into the pipeline’s context to be used for the SQL script generation. To install this tool by a pipeline task, we can use the task below:

- task: DotNetCoreCLI@2
  displayName: 'Install EF tool'
  inputs:
    command: 'custom'
    custom: 'tool'
    arguments: 'install --global dotnet-ef'

3. Generate SQL script

To generate the SQL script containing the logic to apply migrations, we will use the dotnet-ef-tool. By default, the command does not generate the logic to check which migration should be applied, so we have to enable this behavior using the parameter: –idempotent. By using this behavior, we don’t need to worry about the migrations that will be applyed to the database since the generated script already has it. Below, you can see the task that could be used to generate the script file:

- task: DotNetCoreCLI@2
  displayName: 'Generate SQL Script'
  inputs:
    command: 'custom'
    custom: 'ef'
    arguments: 'migrations script --idempotent --project $(Build.SourcesDirectory)\Data.csproj --output $(System.ArtifactsDirectory)/script.sql'

NOTE: We don’t need to stablish any database connection for the script generation, since we are following the Code First concept for entity creation, so, the command will just look at the entities source code of the project to generate the SQL file. If we don’t use the –idempotent argument, the script will generate the SQL without the conditional logic to determinate which migration should be applied, causing an error if the database already exists.

4. Execute SQL script to the database

Now, with the SQL script available, we just need to execute this file to the database. In this post, we will use a common Azure Database as an example, so for this case, we can use the following task to accomplish this requirement:

- task: SqlAzureDacpacDeployment@1
  displayName: 'Update Database'
  inputs:
    azureSubscription: '<Service Connection Identifier>'
    AuthenticationType: 'connectionString' # You can use other method to authenticate to the database if you want
    ConnectionString: '<Database Connection String>'
    deployType: 'SqlTask'
    SqlFile: '$(System.ArtifactsDirectory)/script.sql'

5. Script File as a Pipeline Artifact

Well done. The last task will only be used to make the file available to be accessed by the pipeline runner user. To do this, you can use the task below to add the generated script.sql file to the file bundle (artifacts). To check the artifacts, just access the artifacts option from the pipeline details after the job’s execution.

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifacts'
  inputs:
    PathtoPublish: '$(System.ArtifactsDirectory)/script.sql'
    ArtifactName: '$(artifactName)'
    publishLocation: 'Container'

Conclusion

In this post, we could learn an easy way to apply the database migrations to the remote environment by using automation (pipelines) to accomplish it. This method is simple, and does not have any database validation before script execution. So, if you have an active and sensitive environment, be sure that the needed validations are considered before the database update, to ensure that the database will not be update wrongly.

Pipeline Result

trigger:
- none

pool:
  vmImage: windows-latest

variables:
  solution: '**/*.sln'
  buildPlatform: 'AnyCPU'
  buildConfiguration: 'Release'
  artifactName: 'artifacts'
  environment: 'Development'

- task: NuGetToolInstaller@1
  displayName: 'NuGet Installation'

- task: NuGetCommand@2
  displayName: 'NuGet Restore'
  inputs:
    restoreSolution: '$(solution)'

- task: VSBuild@1
  displayName: 'Build Project'
  inputs:
    solution: 'backend/WebAPI'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: PublishSymbols@2
  displayName: 'Publish Symbols'
  inputs:
    SearchPattern: '**/bin/**/*.pdb'
    SymbolServerType: 'FileShare'
    CompressSymbols: false

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifacts'
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'artifacts'
    publishLocation: 'Container'

- task: DownloadBuildArtifacts@0
  displayName: 'Build Artifacts'
  inputs:
    buildType: 'current'
    downloadType: 'single'
    artifactName: '$(artifactName)'
    downloadPath: '$(System.ArtifactsDirectory)'

- task: DotNetCoreCLI@2
  displayName: 'Install EF tool'
  inputs:
    command: 'custom'
    custom: 'tool'
    arguments: 'install --global dotnet-ef'

- task: DotNetCoreCLI@2
  displayName: 'Generate SQL Script'
  inputs:
    command: 'custom'
    custom: 'ef'
    arguments: 'migrations script --idempotent --project $(Build.SourcesDirectory)\Data.csproj --output $(System.ArtifactsDirectory)/script.sql'

- task: SqlAzureDacpacDeployment@1
  displayName: 'Update Database'
  inputs:
    azureSubscription: '<Service Connection Identifier>'
    AuthenticationType: 'connectionString'
    ConnectionString: '<Connection String>'
    deployType: 'SqlTask'
    SqlFile: '$(System.ArtifactsDirectory)/script.sql'

- task: AzureRmWebAppDeployment@4
  displayName: 'Deploy Application'
  inputs:
    ConnectionType: 'AzureRM'
    azureSubscription: '<Service Connection Identifier>'
    appType: 'webApp'
    WebAppName: 'armazemlegalapi'
    deployToSlotOrASE: true
    ResourceGroupName: '<Resource Group Identifier>'
    SlotName: 'production'
    packageForLinux: '$(System.ArtifactsDirectory)/Project.zip'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifacts'
  inputs:
    PathtoPublish: '$(System.ArtifactsDirectory)/script.sql'
    ArtifactName: '$(artifactName)'
    publishLocation: 'Container'

References

• Microsoft Managing Schemas Article

The post Entity Framework – Update Database using Azure Pipelines appeared first on Blog IT.

Create IT as an Internet connection of 100mbps Down/20mbps Up. Azure was capping at a 150mbps symmetrical connection.

TeamViewer VPN, Azure Site-to-Site and Point-to-Site connections were capped at 10mpbs.

Azure plans

In Azure, the most economical plans were chosen, considering our requirements. Some plans were free, some were cheaper than the others, but having VPN capabilities and all configurations supported, we chose the cheaper plans that were available with all these needed features supported.

Browsers

We used Chrome, Firefox and Edge. This was to eliminate browser differences. Not showing any differences in total execution times, we kept using Chrome as a default testing browser.

LAN Connection

Lan wise, our internal network is based on a 1gbps Local Area Network.

On-Premises Service Host

The On-Premises Service was hosted on a machine running Windows 10 Retail with latest updates installed and IIS Express. All code was made with Visual Studio 2017 Enterprise. The relevant host hardware specifications are:

1. Intel® Core™ i7-6700HQ CPU @ 2.6GHz
2. 32GB of RAM DDR4 @ 3400MHz
3. NVMe M.2 PCI-e 240GB SSD

Testing Hours

All tests were executed on working hours, 9am to 18pm, GMT.

The Writer

I’m a consultant @ Create It, a Portuguese company. If you read this, make sure I know about it! ? Hugs and kisses! This was an absolute pleasure to make ?

The post Latency test between Azure and On-Premises – Specifications appeared first on Blog IT.

Note: 5MB results must be multiplied by 10 (value x 10)

Here are the results. All of them. Don’t forget to multiply 5MB results by 10!

With the graph below, we can check how message sizes influence latency. After doing some math, these are the results:

As we can confirm, latency follows an exponential growing rate, which means, the bigger the message, even greater will be latency. We can confirm that, for each scenario, this applies.

But what does it tell me? This tells you that you need to be careful if you’re planning on sending big messages between two points. This exponential growing rate applies to all scenarios!

All values listed and noted, so we gave tests a score. This score is calculated by adding all three results (10kb, 100kb and 5mb) and dividing all by three. This will give us average execution time. For your best understanding, below is an exponential graph. This climbs faster and faster to infinity, being the horizontal axle message sizes, and the vertical one latency:

Now for the results!

As we can check, Test #2 (Local On-Premises LAN) was the winner here, latency wise. This was expected. Although this is the fastest, it’s the riskiest and NOT RECOMMENDED! It’s true that latency is reduced, but with only ~53ms difference between Azure Site-to-Site on a 100Kb message, is it worth to have a full infrastructure depending on your maintenance? And the networking gear it requires? What about having someone responsible for the room 24/7? How about costs? Think about it! Think about savings when migrating your business to Cloud!

Second place goes to HTTP without VPN (Exposed services). Not a Cloud solution, and a risky one too! If you like hackers messing with your vital business services and trying to break in from all over the world 24/7, go right ahead!

Regarding fast and safe Cloud solutions, which is the main reason of reading this document after all, the winner was Test #4 (Azure Site-to-Site VPN), getting third place on the board, by a difference of 8 points! This managed to be the safest, more efficient and with 99.9% uptime method of expanding your office or network, and have a low-latency data exchange. This is the optimal and safer solution. No hackers, no maintenance, no worries!

Consult us to migrate your business! You’re at the doorstep to your future!

For full test specifications, read here!

The post Latency test between Azure and On-Premises – Conclusions appeared first on Blog IT.

First step is to configure an Hybrid Connection in Function Apps network configuration. Then, you can run Hybrid Connection Manager (assuming you’ve downloaded it from Azure), to manage your connection.

After saving which connection you want to use, you can always confirm connection status in this window:

But wait, I see Service Bus referenced in that print screen! What’s that?

Service Bus is a technology of asynchronously sending and receiving messages from multiple publishers to multiple subscribers. This is, as you’ve probably guessed, a publish/subscribe mechanism.

This is an example of a publish/subscribe architecture. The image should be self-explanatory. A sender sends a message, and all subscribers have filters to only process the messages that they subscribe to.

Why didn’t you test this method?

Well, before you call me anything, you got to understand why.

Architecture!

This concept relies on checking the bus for new messages from time to time, with a 10 second interval for instance. Each 10 second, your program/service, or whatever you want to call it, will check the bus for new messages and retrieves them. This generates a “waiting game”, that’s why it’s called an asynchronous process. It’s not designed to be fast, but to be reliable and to connect multiple services into one giant message box.

Example:

A highway. A highway in USA connects multiple states together, and you can choose where to leave it. You can choose a city in a certain state, or a totally different city in another state, it just depends where you’re going to. This is the same. The service bus it’s like that highway. A publisher publishes a car. Each message (car) has a topic (destination), and every subscriber (city/state) retrieves a message (car) depending on their topic (destination).

This is the main reason that latency doesn’t apply here. It’s a very robust and clean way of integrating services with applications, but latency isn’t a concern here. It’s just not made to be fast. It’s made to be simple.

Conclusions and summary next post!

The post Latency test between Azure and On-Premises – Part Seven appeared first on Blog IT.

This function calls our  REST Web Service (On-Premises) via Point-to-Site VPN connection to Azure. This can be called on-demand via URL, via Run button on the image, or via Logic Apps.

Important note:
In this scenario, the client makes one single HTTP request, instead of 10 requests as previous scenarios.

This is a Logic App (Designer View). We start by a Recurrence Action, which is a timer set to run each 30 second. When recurrence action is fired, this logic app starts by calling “HttpTriggerCSharp1”, which is the function app showed previously. When this function app is finished, the logic app sends an e-mail to my Create account reporting total execution time.

Finally, this is the e-mail that is sent by our logic app. We can see that total execution time reported by the function app is 63ms. Read on for full results!

Test #6 10kb message

Called by a Logic App trigger, the client makes a HTTP request to our On-Prem Service, receiving a 10kb message, the same as before.

We can see that total execution time was 59ms. This is measured by calling the function app via Run button. We’ll be doing this due to being easier to obtain results. This same result is reported by mail if the function is called by Logic Apps. Execution time oscillated between 47ms and 70ms, being the median value ~59ms. Not bad, and slightly faster than TeamViewer VPN, but slower than direct HTTP request without VPN.

Regarding this same result and comparing it to Site-to-Site VPN, we can see that this method took more ~15ms to execute. This can have a very important influence if you are choosing between PTS and Site-to-Site for your business. Also, Site-to-Site has a more constant flow, while this test was more irregular (had more peaks).

Rest assured that this method works, if you can trade a slight latency increase over cost.

Test #6 100kb message

Now for 100kb message, we’ll repeat the same steps to obtain the results.

As we can verify, the test took 78ms to execute. It peaked 97ms and drops to 68ms. Overall, it took more ~8ms to execute than Site-to-Site but was ~22ms faster than TeamViewer. Regarding direct HTTP request without any VPN, this was slower ~17ms. That’s quite a punch there. Let’s try 5Mb.

Test#6 5mb message

Now to the ultimate 5MB test. No more words needed here.

We can see that this is a deal breaker here. The latency here is way over any other test we did. 3.8s! This may happen due to several reasons, the main ones being:

1. Function App performance not meeting our requirements,
2. The way that Azure connects PTS VPN to Function Apps,
3. Consuming a large data might be doing some memory swaps server-side.

Overall test discussion

Well, this is very surprising. Function Apps is clearly not the way for a large message. The processing is inefficient, therefore takes way too much time. PTS connection to a VM in Azure was faster by more than one second, and surprisingly cheaper!

This solution may still be in Preview, or may have bugs, or maybe it just wasn’t made for this type of usage. Regarding complexity, is clearly simpler to use than a VM, it’s serverless and scalable. You can get rid of VM and make your functions directly accessible via any web browser on any platform.

For exposing your logic in a cleaner, faster way, this is what you need. For data crunching or analytics, it’s also the cleanest way, but if you’re planning to use it to make HTTP requests to your on-prem services, you should consider other options, unless execution time isn’t on the equation.

Read the next post here about relays and service bus!

The post Latency test between Azure and On-Premises – Part Six appeared first on Blog IT.

Will this be faster that Azure Site-to-Site?

Test #5 10kb message

10Kb is our base message. PTS didn’t show any issues regarding this one.

Execution time is practically the same as before (on Site-to-Site scenario), with the same message size. 1% is not noticeable on a large batch execution. Let’s see for 100KB. If results change more drastically, then we can analyze and find a reason for this.

Test #5 100kb message

We didn’t see a big difference before. Will 100kb be the game changer?

Actually, it is! It’s ~10ms faster than before! Site-to-Site is beginning to lose to PTS.

Probable causes are:

1. Router delays due to packet queues (Site-to-Site)
2. Router processing power limitations of encrypting packets (and routing them)
3. General hardware limitations

 We start to see some differences now. ~10ms is a noticable improvement. How fast will 5MB be?

Test #5 5mb message

The ultimate test on PTS.

Well, PTS it’s not for large messages. It’s inefficient and takes a lot of time! You should only use this for a one-time-only scenario, like accessing a VM or downloading some files from Azure. Processing large messages with PTS is not recommended, as execution times increased ~1 second in average.

 Overall test discussion

This is an awkward situation. 100KB is faster than Site-to-Site, but 5MB it’s not. While processing small to medium messages you should be fine. Not recommended for production as it showed to have some unusual peaks, so latency may be compromised.

Go to next test!

The post Latency test between Azure and On-Premises – Part Five appeared first on Blog IT.

Consider it as an extended office, with VMs and Azure Functions running outside your premises, as if they were there right next to you! It’s the future.

We’ll be using the same messages, as well the same service-client logic (Via HTTP GET). Instead of using TeamViewer VPN or exposing our service, we’ll use a secure VPN connection to a gateway, that has one VM that’s running the client app associated to it.

We’ll start by doing 10kb, following 100kb and 5MB. Again, this is the most common scenario nowadays!

Test #4 10kb message

Running 10kb of data through Azure VPN Site-to-Site is surely a piece of cake.

It took ~44ms to execute! It’s roughly the same as 263bits through TeamViewer VPN! Using the same 10kb, this test scenario has a reduced execution time of~20ms! Now that’s an improvement. A secure, tight VPN to Azure, site-to-site, with reduced latency! That’s quite a hit in P2P (Peer-to-Peer) VPN connections!

Test #4 100kb message

Well, after seeing a ~20ms drop with a 10kb message, will execution times drop with a message that’s 10 times bigger?

Remember how TeamViewer VPN managed ~100ms on this test? If that’s quick, this is blazing fast! Less ~30ms than P2P VPN solution. Azure Site-to-Site connection is proving to be better than TeamViewer, and only ~9ms slower than HTTP without VPN. Let’s go for 5MB.

Test #4 5MB message

Let’s go through the ultimate test. Can we saturate the Azure VPN connection with this?

Well, that’s astonishing. For a message this size, execution time it’s greater by ~150ms only! Guess that’s the price to pay for a secure tunnel. Direct HTTP execution times are smaller, but considering risk over latency, this is a great and optimal candidate.

Overall test discussion

Well, this did prove me wrong. Initially, I had the idea that TeamViewers’ P2P VPN connection was born to be faster, but it’s not! Azure Site-to-Site is faster, safer, scalable and available to multiple devices, both on Azure and on-premises. Personally, I think this solution is optimal for enterprise integration, as is your business logic needs. For a fast and secure connection to Cloud computing, this is an excellent candidate. It has 99.9% uptime, which is great for 24/7 intensive data crunching or message exchanging.

Proceed to test #5 here!

The post Latency test between Azure and On-Premises – Part Four appeared first on Blog IT.

We’ll be exposing the REST Service (on-premises), and connecting the client application via HTTP (Azure), transmitting the same messages as previous tests.

Starting at 10kb, then 100kb and 5Mb. 10kb, only a fifth (1/5) of an average HTML file. For instance, Google main page size is 392.8 kB in total.

Exposed services. The hackers’ paradise and snoopers’ ocean. A security risk for sure. VPN protects you from all that. It’s a secure tunnel to anywhere.

Test #3 10kb message

After changing port forwarding configurations in our on-prem router, we’re able to expose our REST web service, listening on port 65443 (a random port was chosen). This will be for testing purposes only and will be removed immediately after all testing’s done (for security reasons).

Results are in! It took almost the same time as before (with TeamViewer VPN)! This is amazing, because the VPN we used added no delay whatsoever, at least for this message size! Execution times peaked at ~55ms.

Test #3 100kb message

Now for 100kb of text. Will HTTP be faster than HTTP over VPN?

WOW! Less ~40ms each! TeamViewer VPN is losing ground now! This took ~60ms each for 100kb of data. This is almost half the time that VPN took! How about 5MB of data?

Test #3 5MB message

The ultimate 5MB of text over HTTP. No explaining needed here… Image speaks by itself.

Wait, didn’t TeamViewer VPN take ~1600ms each to execute? This is very surprising, as we start to notice serious delay due to VPN! ~1.2 seconds each is what HTTP takes to execute a request and a 5MB response. If you do the math, for each 10 messages, you save ~4 seconds! That’s a lot!

 Overall test discussion

Well this is a no brainer. TeamViewer VPN didn’t stand a chance here. For 10kb of data, the results are nearly the same. Neither VPN or HTTP (no VPN) struggled with 10kb, but 100kb and 5MB came with a lot of differences. No VPN proved to be faster in larger messages, but VPN provides a safer, encrypted transmission. I call this your decision: Speed over Security. Exposed services are a serious risk, but VPN is a bit slower. In execution time, HTTP without VPN is clearly a winner here.

 Test#4 on the next post!

The post Latency test between Azure and On-Premises – Part Three appeared first on Blog IT.