Why shall I use Application Insights?

There has been a lot of noise around the latest kid – Application Insights on Visual Studio Online.

It is a fantastic solution, but I did not clearly stated anywhere is:

Why shall I use it?

I think the answer is pretty easy – everybody needs diagnostics and logging while in production. It can be expensive to setup a custom solution, which spreads among different devices, different infrastructures (cloud anyone?), different networks.

Application Insights is a great solution for that, as it provides a broad range of features aimed at addressing almost every scenario in that field.

For example, the possibility of downloading an IntelliTrace file from an exception which has been logged on a specific error is just invaluable, providing all the information I might need for fixing that specific issue.

Or talking about usage – how handy can it be a service which collects and aggregates all the information related to my usage data from my real users.

I mean, from the page pattern they follow to the device they use, it is a range of data who can be used in many ways, from diagnostics to marketing. Why losing it?

As we know, integrating it is a matter of adding some JavaScript lines, a couple of files or a bunch of lines of code depending on the platform we are targeting – this is why it is really worth integrating it in our projects: with a minimal effort we can get a giant stream of information to use as a source for a broad range of tasks, not just developer-focused ones.

Application Insights Visual Studio Add-in preview – what is that?

Brian Harry recently blogged about that, this is an add-in for adding Application Insights’ telemetry straight from Visual Studio itself.

It is helpful, because once you install it you can add AI to all your new projects OOB:

It is already tied to your Visual Studio Online account (after a login, of course). Then it is going to automatically detect what project type you created and it is going to set it up for AI in a snap.

SQL Server AlwaysOn with Team Foundation Server – a great team!

High Availability and Disaster Recovery are the first two items on the list for a TFS Administrator, as Team Foundation Server hosts a critical service for almost every company with a linked development team.

Frankly in the past delegating the HA story to someone else in the organization was a very common practice, as it is not something related to TFS – which is pretty agonostic about the SQL Server deployment topology or about the number of Application Tiers.

If you want to use SQL Server AlwaysOn in your deployment – apart from all the other technologies which can be involved (Windows Failover Clustering, SQL Server Clustering, VMs redundancy, etc.) – the only configuration needed is to create a SQL Server AlwaysOn Availability Group. You are going to get a replication between up to four different SQL Server instances so you can failover at anytime.

Given a Windows Failover Cluster and two different SQL Server instances, one on each node, you just need to do as it follows:

You launch the wizard, and you specify a name and, for now, no databases are going to be contained inside the Availability Group.

Then you can select the replica mode (synchronous or asynchronous) and you must specify a Listener, which is going to become the instance name you are going to use to configure Team Foundation Server.

Then – while configuring Team Foundation Server using the Advanced mode - you are going to need to specify the Listener and tick the box saying that it is a SQL AlwaysOn Availability Group. TFS will then configure some specific settings for it in the process.

It is extremely important to add all the databases, and each database must be backed up, otherwise you won’t be able to add them to the AG.

Eventually, do not forget it is not the only HA solution, and a good HA solution is composed by several technologies working together on a minded plan :)

Here you can find the MSDN page for the topic.