How to Leverage ARM Templates in Azure for Intelligent Deployment

We previously showed in a blog post, The AppD Approach: Deployment Options for .NET Microservices Agent, how the advanced portability and refinement of AppDynamics’ new .NET Microservices Agent delivers great value to our customers who monitor .NET Core applications. Let’s dig further into how to deploy this agent following Infrastructure as Code (IaC) practices.

Azure Resource Manager (ARM) templates are an exciting framework for IaC. They allow you to create an entire environment from a simple template, with all the resources needed for your applications.

The ability to include the AppDynamics Site Extension as part of your ARM template deployment, however, introduces a few operational challenges, including:

  • How do you ensure your monitoring solution is installed only on specific environments?

  • Should you avoid creating a separate ARM template for each environment?

We can solve these challenges by putting the “Code” portion of IaC to work.

Condition is the Key

When working with ARM templates, It doesn’t take long for you to ask the question:

  • How do you deploy a resource based on a condition?

The Azure Resource Manager team answered with the condition attribute, which controls whether a resource will be deployed or not. If the condition check evaluates to “true,” the resource will be deployed. If not, the resource is skipped.

To enable the ARM template to be dynamic enough to deploy the AppDynamics Site Extension only when a condition evaluates to true, you must provide a parameter to contain your condition test, and add the condition attribute to your Site Extension resource.

Test Condition Parameter

"shouldInstallAppDynamicsExtension": {
  "type": "bool",
  "defaultValue": false,
  "metadata": {
    "description": "Conditional parameter to determine if AppDynamics Site Extension should be installed."
  }
}

Site Extension Resource with “condition” Attribute

{
    "apiVersion": "2015-08-01",
    "condition": "[parameters('shouldInstallAppDynamicsExtension')]",
    "name": "[parameters('appDynamicsSiteExtension')]",
    "type": "siteextensions",
    "dependsOn": [
    "[resourceId('Microsoft.Web/Sites/', variables('webSiteName'))]"
    ]
}

With the condition attribute added to your Site Extension resource, and a parameter waiting for you to give it a true or false value, you can easily determine—with a single template—when to deploy the AppDynamics Site Extension.

The next question becomes:

  • How can we configure the AppDynamics Site Extension automatically?

Object Parameters for the Win

One of the great options in ARM templates is the ability to create parameters of object type. This allows you to use a JSON object as a parameter value. Mix that capability with other ARM template magic, and you can easily configure the AppDynamics Site Extension without hard-coding any of template’s application settings.

AppDynamics Settings Object Type Parameter

"appDynamicsSettings": {
    "type": "object",
    "defaultValue": {
    "appdynamics.controller.hostName": "",
    "appdynamics.controller.port": "",
    "appdynamics.agent.accountName": "",
    "appdynamics.agent.accountAccessKey": "",
    "appdynamics.agent.applicationName": "",
    "appdynamics.controller.ssl.enabled": "",
    "appdynamics.agent.tierName": ""
    },
    "metadata": {
    "description": "Settings needed to get AppDynamics Site Extension configured."
    }
}

By setting the Application Settings Configuration Resource’s properties attribute value—the object type parameter for the AppDynamics Site Extension configuration—you can dynamically set the list of configuration settings without creating individual parameters for each setting. Then, as those settings change over time, your template doesn’t need to.

Application Settings Configuration Resource with Dynamic Properties

{
    "name": "appsettings",
    "type": "config",
    "apiVersion": "2015-08-01",
    "dependsOn": [
    "[resourceId('Microsoft.Web/sites', variables('webSiteName'))]"
    ],
    "tags": {
    "displayName": "appsettings"
    },
    "properties": "[parameters('appDynamicsSettings')]"
}

An important note about the Application Settings resource in an ARM template: it completely removes and replaces all the application settings in the App Service. If any application settings were manually added or changed after a deployment, they will be deleted.

The next challenge is determining how to configure your AppDynamics Site Extension configuration settings to deploy only when you deploy the Site Extension. Let’s explore how Template Functions can help with this.

To Union or Not to Union

One of the issues with the previous example—limiting the App Services application settings to only the AppDynamics parameter object—is that it doesn’t provides a place for adding additional settings. You can solve this issue by creating an object variable to contain the base application settings, and then figure out how to conditionally combine both groups of settings.

Object Variable to Define App Settings

variables": {
   "websiteName":"some-website-name"
   "appSettings": {
   "SomeRandomAppSetting": "Some Random Value"
   "AnotherRandomAppSetting": "Another Random Value"
   } 
}

ARM templates have a useful collection of functions to help make then more dynamic. To add the logic check for whether you should deploy the AppDynamics Site Extension configuration settings, you can use the if logical function and the union object function.

To begin, dynamically set the properties attribute by passing the previous condition test parameter—“shouldInstallAppDynamicsExtension”— to the if function. Based on that conditional check, you can then return a combination of the base “appSettings” variable and the “appDynamicsSettings” parameter with the union function, or just return the “appSettings” variable.

Conditionally Setting the Application Settings Properties Attribute

{
    "name": "appsettings",
    "type": "config",
    "apiVersion": "2015-08-01",
    "dependsOn": [
    "[resourceId('Microsoft.Web/sites', variables('webSiteName'))]"
    ],
    "tags": {
    "displayName": "appsettings"
    },
    "properties": "[if(parameters('shouldInstallAppDynamicsExtension'), union(variables('baseAppSettings'), parameters('appDynamicsSettings')), variables('baseAppSettings'))]"
}

Putting It All Together

You now have all the parts to dynamically deploy the AppDynamics Site Extension to an Azure App Service, based on a single boolean parameter. Let’s take a look at the ARM template as a whole.

The example below is a complete template for deploying a Hosting Plan (Service Plan), App Service (Web App), Application Settings for the App Service, and the Site Extension for the App Service. Included are the additional parameters and variables to enable the deployment of the AppDynamics Site Extension:

Complete ARM Template Example

{
 "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
 "contentVersion": "1.0.0.0",
 "parameters": {
"hostingPlanName": {
  "type": "string",
  "minLength": 1
},
"skuName": {
  "type": "string",
  "defaultValue": "F1",
  "allowedValues": [
    "F1",
    "D1",
    "B1",
    "B2",
    "B3",
    "S1",
    "S2",
    "S3",
    "P1",
    "P2",
    "P3",
    "P4"
  ],
  "metadata": {
    "description": "Describes plan's pricing tier and capacity. Check details at https://azure.microsoft.com/en-us/pricing/details/app-service/"
  }
},
"skuCapacity": {
  "type": "int",
  "defaultValue": 1,
  "minValue": 1,
  "metadata": {
    "description": "Describes plan's instance count"
  }
},
"appDynamicsSiteExtension": {
  "type": "string",
  "defaultValue": "AppDynamics.WindowsAzure.SiteExtension.4.4.Release",
  "allowedValues": [
    "AppDynamics.WindowsAzure.SiteExtension.4.4.Release",
    "AppDynamics.WindowsAzure.SiteExtension.4.3.Release",
    "AppDynamics.Java.Agent.4.4.Release"
  ],
  "metadata": {
    "description": "Full path name of the AppDynamics Site Extension to install."
  }
},
"shouldInstallAppDynamicsExtension": {
  "type": "bool",
  "defaultValue": false,
  "metadata": {
    "description": "Conditional parameter to determine if AppDynamics Site Extension should be installed."
  }
},
"appDynamicsSettings": {
  "type": "object",
  "defaultValue": {
    "appdynamics.controller.hostName": "",
    "appdynamics.controller.port": "",
    "appdynamics.agent.accountName": "",
    "appdynamics.agent.accountAccessKey": "",
    "appdynamics.agent.applicationName": "",
    "appdynamics.controller.ssl.enabled": "",
    "appdynamics.agent.tierName": ""
  },
  "metadata": {
    "description": "Settings needed to get AppDynamics Site Extension configured."
  }
}
 },
 "variables": {
"webSiteName": "[concat('some-webapp-', uniqueString(resourceGroup().id))]",
"appSettings": {
  "SomeRandomAppSetting": "Some Random Value",
  "AnotherRandomAppSetting": "Another Random Value"
},
 },
 "resources": [
{
  "apiVersion": "2015-08-01",
  "name": "[parameters('hostingPlanName')]",
  "type": "Microsoft.Web/serverfarms",
  "location": "[resourceGroup().location]",
  "tags": {
    "displayName": "HostingPlan"
  },
  "sku": {
    "name": "[parameters('skuName')]",
    "capacity": "[parameters('skuCapacity')]"
  },
  "properties": {
    "name": "[parameters('hostingPlanName')]"
  }
},
{
  "apiVersion": "2015-08-01",
  "name": "[variables('webSiteName')]",
  "type": "Microsoft.Web/sites",
  "location": "[resourceGroup().location]",
  "tags": {
    "[concat('hidden-related:', resourceGroup().id, '/providers/Microsoft.Web/serverfarms/', parameters('hostingPlanName'))]": "Resource",
    "displayName": "Website"
  },
  "dependsOn": [
    "[resourceId('Microsoft.Web/serverfarms/', parameters('hostingPlanName'))]"
  ],
  "properties": {
    "name": "[variables('webSiteName')]",
    "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', parameters('hostingPlanName'))]"
  },
  "resources": [
    {
      "name": "appsettings",
      "type": "config",
      "apiVersion": "2015-08-01",
      "dependsOn": [
        "[resourceId('Microsoft.Web/sites', variables('webSiteName'))]"
      ],
      "tags": {
        "displayName": "appsettings"
      },
      "properties": "[if(parameters('shouldInstallAppDynamicsExtension'), union(variables('appSettings'), parameters('appDynamicsSettings')), variables('appSettings'))]"
    },
    {
      "apiVersion": "2015-08-01",
      "condition": "[parameters('shouldInstallAppDynamicsExtension')]",
      "name": "[parameters('appDynamicsSiteExtension')]",
      "type": "siteextensions",
      "dependsOn": [
        "[resourceId('Microsoft.Web/Sites/', variables('webSiteName'))]"
      ]
      }
  ]
}
 ]
}

Stayed Tuned for More on ARM Templates

I hope these steps have given you an overview of Azure Resource Manager (ARM) templates, and how to leverage them for intelligent deployment of the AppDynamics Site Extension. In my next blog, I’ll show how to use the ARM template in a release plan on Visual Studio Team Services (VSTS) to configure and deploy a sample Azure App Service with the AppDynamics Site Extension.


Learn more to understand the big picture of AppDynamics’ seamless integration with Microsoft Azure.

The AppD Approach: Deployment Options for .NET Microservices Agent

There are numerous ways to develop .NET applications, and several ways to run them. As the landscape expands for .NET development—including advances in .NET Core with its cross-platform capabilities, self-contained deployments, and even the ability to run an ASP.NET Core app on a Raspberry PI with the upcoming .NET Core 2.1 ARM32 support—it’s only fitting that AppDynamics should advance its abilities to monitor this new landscape.

One of these advancements is our new .NET Microservices Agent. Like .NET Core, this agent has evolved to become more portable and easier to use, providing more value to our customers who monitor .NET Core applications. Its portability and refinement enable a couple of installation options, both of which align closely with the movement to host .NET applications in the cloud, the development of microservices, and the growing use of containers. This flexibility in deployment was a requirement of our customers, as they had concerns over the one-size fits all deployment options of some of our competitors. These deployment methods include:

  • Installing via the AppDynamics Site Extension in Azure

  • Installing via the NuGet package bundled with the application

Each method has its advantages and disadvantages:

AppDynamics Site Extension

    • Advantage: Azure Site Extension is an easy deployment method that decouples the AppDynamics agent from the code. A couple of clicks and some basic configuration settings and—voila!—an Azure App Service has an AppDynamics monitoring solution.

    • Disadvantage: It is an Azure App Service-only option. Should the application need to be moved to another service such as Azure Service Fabric, a different installation method would be needed.

AppDynamics NuGet Package

  • Advantage: the NuGet package installation method is super versatile. Since it’s bundled with the application, wherever it goes, the agent and monitoring go too. An excellent option for microservices and containers.

  • Disadvantage: It’s biggest advantage is also a drawback, as coupling the agent with the application increases operational requirements. Agent updates, for instance, would require small configuration changes and redeployments.

The Easy Option: AppDynamics Site Extension

Azure provides the ability to add Site Extensions, a simple way to add functionality and tooling to an Azure App Service.

In the case of AppDynamics’ .NET Microservices Agent, Site Extensions is a wonderful deployment method that allows you to set up monitoring on an Azure App Service without having to modify your application. This method is great for an operations team that either wants to monitor an existing Azure App Service without deploying new bits, or decouple the monitoring solution from the application.

The installation and configuration of the AppDynamics Site Extension is simple:

  1. Add the Site Extension to the App Service from the Site Extension Gallery.

  2. Launch the Controller Configuration Form and set up the Agent.

As always, Azure provides multiple ways to do things. Let’s break down these simple steps and show installation from two perspectives: from the Azure Portal, and from the Kudu service running on the Azure App Service Control Manager site.

Installing the Site Extension via the Azure Portal

The Azure Portal provides a very easy method to install the AppDynamics Site Extension. As the Portal is the most common interface when working with Azure resources, this method will feel the most comfortable.

Step 1: Add the Site Extension

  • Log into the Azure Portal at https://portal.azure.com and navigate to the Azure App Service to install the AppDynamics Site Extension.

  • In the menu sidebar, click the Extensions option to load the list of currently installed Site Extensions for the Azure App Service. Click the Add button near the top of the page (see below) to load the Site Extension Gallery, where you can search for the latest AppDynamics Site Extension.

  • In the “Add extension” blade, select the AppDynamics Site Extension to install.
    (The Portal UI is not always the most friendly. If you hover over the names, a tooltip should appear showing the full extension name.)

  • After choosing the extension, click OK to accept the legal terms, and OK again to finish the selection. Installation will start, and after a moment the AppDynamics Site Extension will be ready to configure.

Step 2: Launch and Configure

  • To configure the AppDynamics Agent, click the AppDynamics Site Extension to bring up the details blade, and then click the Browse button at the top. This will launch the AppDynamics Controller Configuration form for the agent.

  • Fill in the configuration settings from your AppDynamics Controller, and click the Validate button. Once the agent setup is complete, monitoring will start.

  • Now add some load to the application. In a few moments, the app will show up in the AppDynamics Controller.

Installing the Site Extension via Kudu

Every Azure App Service is created with a secondary site running the Kudu service, which you can learn more about at the projectkudu on GitHub. The Kudu service is a powerful tool that gives you a behind-the-scenes look at your Azure App Service. It’s also the place where Site Extensions are run. Installing the AppD Site Extension from the Kudu service is just as simple as from the Azure Portal.

Step 1: Add Site Extension

  • Login to the Azure Portal at https://portal.azure.com and navigate to the Azure App Service to install the AppDynamics Site Extension.

  • The Kudu service is easy to access via the Advanced Tools selection on the App Service sidebar.

  • Another option is to login directly to the secondary site’s URL by including a “.scm” as a prefix to the “.azurewebsite.net” domain. For example: http://appd-appservice-example.azurewebsites.net becomes http://appd-appservice-example.scm.azurewebsites.net. (You can read more about accessing the Kudu service in the projectkudu wiki.)

  • On the Kudu top menu bar, click the Site Extensions link to view the currently installed Site Extensions. To access the Site Extension Gallery, click the Gallery tab.

  • A simple search for “AppDynamics” will bring up all the available AppDynamics Site Extensions. Simply click the add “+” icon on the Site Extension tile to install.

  • On the “terms acknowledgement” dialog pop-up, click the Install button.

  • Finish the setup by clicking the “Restart Site” button on the upper right. This will restart the SCM site and prepare the AppDynamics Controller Configuration form.

Step 2: Launch and Configure

  • Once the restart completes, click the “Launch” icon (play button) on the Site Extension tile. This will launch the AppDynamics Controller Configuration form.

  • Follow the same process as before by filling in the details and clicking the Verify button.

  • The agent is now set up, and AppDynamics is monitoring the application.

AppDynamics Site Extension in Kudu Debug Console

One of the advantages of the Kudo service is the ability to use the Kudu Debug Console to locate App Service files, including the AppDynamics Site Extension installation and AppDynamics Agent log files. Should the Agent need configuration changes, such as adding a “tier” name, you can use the Kudu Debug Console to locate the AppDynamicsConfig.json file and make the necessary modifications.

The Versatile Option: AppDynamics NuGet Packages

The NuGet package installation option is the most versatile deployment method, as the agent is bundled with the application. Wherever the application goes, the agent and monitoring solutions go too. This method is great for monitoring .NET applications running in Azure Service Fabric and Docker containers.

AppDynamics currently has four separate NuGet packages for the .NET Microservices Agent, and each is explained in greater detail in the AppDynamics documentation. Your choice of package should be based on where your application will be hosted, and which .NET framework you will use.

In the example below, we will use the package best suited for an Azure App Service, for a comparison to the Site Extension.

Installing the AppDynamics App Service NuGet Package

The method for installing a NuGet package will vary by tooling, but for simplicity we will assume a simple web application is open in Visual Studio, and that we’re using Visual Studio to manage NuGet packages. If you’re working with a more complex solution with multiple applications bundled together, NuGet package installation will vary by project deployment.

Step 1: Getting the Correct Package

  • On the web app project, right-click and bring up the context menu. Locate and click “Manage NuGet Packages…”.  This should bring up the NuGet Package Manager, where you can search for “AppDynamics” under the Browse tab.  

  • Locate the correct package—in this case, the “AppService” option—select the appropriate version and click Install.

  • Do a build of your project to add the AppDynamics directory to your project.

  • The agent is now installed and ready to configure.

Step 2: Configure the Agent

  • Locate the AppDynamicsConfig.json in the AppDynamics directory and fill in the Controller configuration information.

  • Publish the application to Azure and add some load to the application to test if monitoring was set up properly.

I hope these steps give you an overview of how easy it is to get started with our .NET Microservices Agent. Make sure to review our official .NET Microservices Agent and Deploy AppDynamics for Azure documentation for more information.

Application Architecture With Azure Service Fabric

Is Azure the dominant cloud-based development infrastructure of the future? There’s some good evidence to support that claim. At last year’s Dell World conference in Austin, TX, Microsoft CEO Satya Nadella announced on stage that there are only two horses in the contest for control of the cloud. “It’s a Seattle race,” Nadella said. “Amazon clearly is the leader, but we are number two. We have a huge run-rate. All up, our cloud business last time we talked about it was over $8 billion of run-rate.”

Normally, you could dismiss that as typical marketing speak, but market analysts tend to agree with him. Gartner’s Magic Quadrant for Cloud Infrastructure as a Service Report found that there are only two leaders in the space. AWS is ahead, but Microsoft Azure’s offerings are growing faster. Gartner concluded, “Microsoft Azure, in addition to Amazon Web Services, is showing strong legs for longevity in the cloud marketplace, with other vendors falling further to the rear and confined to more of a vendor-specific or niche role.”

The Rundown on Azure Service Fabric and Microservices

Service Fabric is the new middleware layer from Microsoft designed to help companies scale, deploy, and manage microservices. Service Fabric supports both stateless and stateful microservices. In stateful microservices, Service Fabric computes your storage and application code together, reducing latency and automatically provides replication services in the background to improve availability of your services.

Azure Service Fabric improves the deployment process for customers embracing DevOps with features like rolling upgrades and automatic rollback during deployments.

Empowering customers to deliver microservices using Azure Service Fabric is a key contributor powering Microsoft’s revenue growth, expanding 102 percent year-over-year through the success of Azure.

Top enterprises betting on Azure services today include global chocolatier The Hershey Company, Amazon’s e-commerce competition Jet.com, digital textbook builder Pearson, GE Healthcare, and broadcaster NBC Universal. Azure is an optimized multi-platform cloud solution that can power solutions running on Windows and Linux, using .NET, Node.js, and a host of other runtimes in the market, making it easier to adopt regardless of the language or underlying OS for customers deploying applications that scale using microservices.

Why Microsoft Chose Microservices Over Monolithic

When Microsoft started running cloud-scale services such as Bing and Cortana, it ran into several challenges with designing, developing, and deploying apps at cloud-scale. These were services that were always on and in high-demand. They required frequent updates with zero latency. The microservices architecture made much more sense than a traditional monolithic approach.

Microsoft’s Mark Fussell defined the problem with monolithic: “During the client-server era, we tended to focus on building tiered applications by using specific technologies in each tier. The term ‘monolithic application’ has emerged for these approaches. The interfaces tended to be between the tiers, and a more tightly coupled design was used between components within each tier. Developers designed and factored classes that were compiled into libraries and linked together into a few executables and DLLs.”

There were certainly benefits to that methodology at the time in terms of simplicity and faster calls between components using inter-process communication (IPC). Everybody’s on one team testing a single software, so it’s easier to coordinate tasks and collaborate without explaining what each is working on at a given moment.

Azure and Microservices

Monolithic started to fail when the app ecosphere turbocharged the speed of user expectations. If you want to scale a monolithic app, you have to clone it out onto multiple servers or virtual machines (or containers, but that’s another story). In short, there was no easy way to break out and scale components rapidly enough to satisfy the business needs of enterprise-level app customers. The entire development cycle was tightly interconnected by dependencies and divided by functional layers, such as web, business, and data. If you wanted to do a quick upgrade or fix, you had to wait until testing was finished on the earlier work. Monolithic and agility didn’t mix.

The microservices approach is to organize a development project based on independent business functionalities. Each can scale up or down at its own rate. Each service is its own unique instance that can be deployed, tested, and managed across all the virtual machines. This aligns more closely with the way that business actually works in the world of no latency and rapid traffic spikes.

In reality, many development teams start with the monolithic approach and then break it up into microservices bases, in which functional areas need to be changed, upgraded, or scaled. Today, DevOps teams that are responsible for microservices projects tend to be highly cost-effective but insular. APIs and communications channels to other microservices can suffer without strong leadership and foresight.

How Azure Service Fabric Helps

Azure Service Fabric is a distributed systems platform that assigns each microservice a unique name, which can be stateless or stateful. Service Fabric streamlines the management, packaging, and deploying of microservices, so DevOps teams and admins can just forget about the infrastructure complexities and get down to implementing workloads. Microsoft defined Azure Service Fabric as “the next-generation middleware platform for building and managing these enterprise-class, tier-1, cloud-scale applications.”

Azure Service Fabric is behind services like Azure SQL Database, Azure DocumentDB, Cortana, Microsoft Power BI, Microsoft Intune, Azure Event Hubs, Azure IoT Hub, and Skype for Business. You can create a wide variety of cloud native services that can immediately scale up across thousands of virtual machines. Service Fabric is flexible enough to run on Azure, your own bare metal on-premise servers, or on any third-party cloud. More importantly — especially if you’re an open-source house — is that Service Fabric can also deploy services as processes or in containers.

Azure Container Services

Open-source developers can use Azure Container Service along with Docker container orchestration and scale operations. You’re free to work with Mesos-based DC/OS, Kubernetes, or Docker Swarm, and Compose and Azure will optimize the configuration for .NET and Azure. The containers and your app configuration are fully portable. You can modify the size, the number of hosts, and which orchestrator tools you want to use, and then leave the rest to the Azure Container Service.

Any of the most popular development tools and frameworks are compatible because Azure Container Services exposes the standard API endpoints for their orchestration engine. That opens the door for all of the most common visualizers, monitoring platforms, continuous integration, and whatever the future brings. For .NET developers or those who have worked with the Visual Studio IDE, the Azure interface presents a familiar user experience. Developers can use Azure and cross-platform a fork of .NET known as .NET Core to create an open-source project running ASP.NET applications for Linux, Windows, or even Mac.

Taking on New Challenges With Service Fabric

Microsoft’s role as a hybrid cloud expert gives Azure an edge over virtual-only competitors like AWS and Google Cloud. Azure’s infrastructure is comprised of hundreds of thousands of servers, content distribution networks, edge computing nodes, and fiber optic networks. Azure is built and managed by a team of experts working around the clock to support services for millions of businesses all over the planet.

Developers experienced with microservices have found it valuable to architect around the concept of smart endpoints and dumb pipes. In this approach, the end goal of microservices applications is to function independently, decoupled but as cohesive as possible. Each should receive requests, act on its own domain logic, and then send off a response. Microservices can then be choreographed using RESTful protocols, as detailed by James Lewis and Martin Fowler in their microservices guide from 2014.

If you’re dealing with workloads that have unpredictable bursting, you want an infrastructure that’s reliable and secure while knowing that the data centers are environmentally sustainable. Azure lets you instantly generate a virtual machine with 32TB of storage driving more than 50,000 IOPS. Then, your team can tap into data centers with hundreds of thousands of CPU cores to solve seemingly impossible computational problems.

AppDynamics for Azure

In the end, the user evaluates the app as a singular experience. You need application monitoring that makes sure all the microservices are working together seamlessly and with no downtime. AppDynamics App iQ platform is what you need to handle the flood of data coming through .NET and Azure applications. You can monitor all of the .NET performance data from inside Azure, as well as frameworks and runtimes like WebAPI, OWIN, MVC, and ASP.NET Core on full framework, deploying AppDynamics agents in Azure websites, worker roles, Service Fabric, and in containers. In addition, you can monitor the performance of queues and storage for services like Azure SQL Server and Service Bus. This provides end to end visibility into your production services running in the cloud.

The asynchronous nature of microservices itself makes it nearly impossible to track down the root failure when it starts cascading through services unless you have solid monitoring in place. With AppDynamics, you’ll be able to visualize the services path from end to end for every single interaction — all the way from the origination through the services calls. Otherwise, you’ll get lost in the complexity of microservices and lose all the benefits of building on the Azure infrastructure.

While we see many developers in the Microsoft space attracted to Azure, AppDynamics realizes Azure is a cross-platform solution supporting both Windows and Linux. In addition to .NET runtimes, AppDynamics provides a rich set of monitoring capabilities that many of the modern technologies being used in the Azure cloud require, including Node.js, PHP, Python and Java applications.

Learn more

Learn more about our .NET monitoring solution or take our free trial today.

A UNIX Bigot Learns About .NET and Azure Performance – Part 1

This blog post is the beginning of my journey to learn more about .NET and Microsoft Azure as it applies to performance monitoring. I’ve long admitted to being a UNIX bigot but recently I see a lot of good things going on with Microsoft. As a performance monitoring geek I feel compelled to understand more about these technologies at a deep enough level to provide good guidance when asked by peers and acquaintances.

The Importance of .NET

Here are some of the reasons why .NET is so important:

  • In a 2013 Computer World article, C# was listed as the #6 most important programming language to learn along with ASP.NET ranking at #14.
  • In a 2010 Forrester article .NET was cited as the top development platform used by respondents.
  • .NET is also a very widely used platform in financial services. An article published by WhiteHat Security stated that “.NET, Java and ASP are the most widely used programming languages at 28.1%, 25% and 16% respectively.” In reference to financial service companies.
  • The Rise of Azure

    .NET alone is pretty interesting from a statistical perspective but the rise of Azure in the cloud computing PaaS and IaaS world is a compounding factor. In a “State of the Cloud” survey conducted by RightScale, Azure was found to be the 3rd most popular public cloud computing platform for Enterprises. In a report published by Capgemini, 73% of their respondents globally stated that Azure was part of their cloud computing strategy with strong support across retail, financial services, energy/utilities, public, and telecommunications/media verticals.

    Developer influence

    Not to be underestimated in this .NET/Azure world is the influence that developers will have on overall adoption levels of each technology platform. Microsoft has created an integration between Visual Studio (the IDE used to develop on the .NET platform) and Azure that makes it extremely easy to deploy .NET applications onto the Azure cloud. Ease of deployment is one of the key factors in the success of new enterprise technologies and Microsoft has definitely created a great opportunity for itself by ensuring that .NET apps can be easily deployed to Azure through the interface developers are already familiar with.

    The fun part is yet to come

    Before I started my research for this blog series I didn’t realize how far Microsoft had come with their .NET and Azure technologies. To me, if you work in IT operations you absolutely must understand these important technologies and embrace the fact that Microsoft has really entrenched itself in the enterprise. I’m looking forward to learning more about the performance considerations of .NET and Azure and sharing that information with you in my follow-up posts. Keep an eye out for my next post as I dive into the relevant IIS and WMI/Perfmon performance counters and details.

    How to Run AppDynamics in Microsoft Azure
    “Is it possible to run the AppDynamics controller within my own Microsoft Azure IaaS?”

    I hear this question fairly regularly and would like to walk you through how to host the controller in your own Azure cloud. First off, the pros of having AppDynamics with Azure:

  • Have full control and ownership of the data collected by AppDynamics
  • Provide additional security to access the data (for example, lock it down to a corporate VPN only).
  • Enable easy integration between AppDynamics and your services, such as Active Directory for authentication or internal bug tracking system for alert notifications. These would typically require opening custom ports when you leverage the AppDynamics SaaS environment.
  • AppDynamics works by placing an agent running on your servers which reports to the controller. It’s common to have several agents monitoring your applications. To further the ease of use, we monitor Java, .NET, PHP, Node.js, and now, C++ all in one single pane of glass. Your Azure architecture might look something like this:

    Screen Shot 2014-09-24 at 3.32.03 PM
    A unique feature for AppDynamics is flexible deployment. Typically, legacy APM solutions rely on on-premise deployment, whereas newer companies are Saas-only. At AppDynamics you can run the controller on-premise, leverage the AppDynamics SaaS option, or deploy a hybrid mixture.

    To run the controller in your Azure IaaS you can leverage the security of the on-premise deployment option and install the controller the same way as if you would in your datacenter. This allows you to have full control over the your data and be the gatekeeper to access that data.

    Important to note:

  • Properly size the controller — you can estimate the CPU/memory/disk requirements based on number of agents you are going to deploy. This is covered in the AppDynamics online documentation.
  • Configure the VM for maximum I/O.
  • The second is very important to configure as the controller installs a database which requires high I/O throughput. The recommended best practice is to treat the VM the same as you would be running a SQL server on it. http://msdn.microsoft.com/en-us/library/azure/dn133149.aspx

    If you forget to do this, you run the risk that the performance of the controller will slow down. This will not slow down your monitored applications as the agents are implemented to be non-blocking. However, the slowness will cause controller UI to lag and hard to visualize the collected data.

    Hope this helps and you can choose the option which works the best for your organization! Try it out now, for FREE!

    Instrumenting .NET applications with AppDynamics using NuGet

    Introduction

    One of the coolest things to come out of the .NET stable at AppD this week was the NuGet package for Azure Cloud Services. NuGet makes it a breeze to deploy our .NET agent along with your web and worker roles from inside Visual Studio. For those unfamiliar with NuGet, more information can be found here.

    Our NuGet package ensures that the .NET agent is deployed at the same time when the role is published to the cloud. After adding it to the project you’ll never have to worry about deploying the agent when you swap your hosting environment from staging to production in Azure or when Azure changes the machine from under your instance. For the remainder of the post I’ll use a web role to demonstrate how to quickly install our NuGet package, changes it makes to your solution and how to edit the configuration by hand if needed. Even though I’ll use a web role, things work exactly the same way for a worker role.

    Installation

    So, without further ado, let’s take a look at how to quickly instrument .NET code in Azure using AppD’s NuGet package for Windows Azure Cloud Services. NuGet packages can be added via the command line or the GUI. In order to use the command line, we need to bring up the package manager console in Visual Studio as shown below

    PackageManager

    In the console, type ‘install-package AppDynamics.WindowsAzure.CloudServices’ to install the package. This will bring up the following UI where you can enter the information needed by the agent to talk to the controller and upload metrics. You should have received this information in the welcome email from AppDynamics.

    Azure

    The ‘Application Name’ is the name of the application in the controller under which the metrics reported by this agent will be stored. When ‘Test Connection’ is checked we will check the information entered by trying to connect to the controller. An error message will be displayed if the test connection is unsuccessful. That’s it, enter the information, click apply and we’re done. Easy Peasy. No more adding files one by one or modifying scripts by hand. Once deployed, instances of this web role will start reporting metrics as soon as they experience any traffic. Oh, and by the way, if you prefer to use a GUI instead of typing commands on the console, the same thing can be done by right-clicking on the solution in Visual Studio and choosing ‘Manage NuGet Package’.

    Anatomy of the package

    If you look closely at the solution explorer you’ll notice that a new folder called ‘AppDynamics’ has been created in the solution explorer. On expanding the folder you’ll find the following two files:

    • Installer of the latest and greatest .NET agent.
    • Startup.cmd
    The startup script makes sure that the agent gets installed as a part of the deployment process on Azure. Other than adding these files we also change the ServiceDefinition.csdef file to add a startup task as shown below.

    Screen Shot 2013-11-27 at 8.11.27 PM

    In case, you need to change the controller information you entered in the GUI while installing the package, it can be done by editing the startup section of the csdef file shown above. Application name, controller URL, port, account key etc. can all be changed. On re-deploying the role to Azure, these new values will come into effect.

    Next Steps

    Microsoft Developer Evangelist, Bruno Terkaly blogged about monitoring the performance of multi-tiered Windows Azure based web applications. Find out more on Microsoft Developer Network.

    Find out more in our step-by-step guide on instrumenting .NET applications using AppDynamics Pro. Take five minutes to get complete visibility into the performance of your production applications with AppDynamics Pro today.

    As always, please feel free to comment if you think I have missed something or if you have a request for content in an upcoming post.