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:

Add the Site Extension to the App Service from the Site Extension Gallery.
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.

Understanding the Momentum Behind .NET Core

Three years ago Satya Nadella took over as CEO of Microsoft, determined to spearhead a renewal of the iconic software maker. He laid out his vision in a famous July 10, 2014 memo to employees in which he declared that “nothing was off the table” and proclaimed his intention to “obsess over reinventing productivity and platforms.”

How serious was Nadella? In the summer of 2016, Microsoft took the bold step of releasing .NET Core, a free, cross-platform, open-source version of its globally popular .NET development platform. With .NET Core, .NET apps could run natively on Linux and macOS as well as Windows.

For customers .NET Core solved a huge problem of portability. .NET shops could now easily modernize monolithic on-premises enterprise applications by breaking them up into microservices and moving them to cloud platforms like Microsoft Azure, Amazon Web Services, or Google Cloud Platform. They had been hearing about the benefits of containerization: speed, scale and, most importantly, the ability to create an application and run it anywhere. Their developers loved Docker’s ease of use and installation, as well as the automation it brought to repetitive tasks. But just moving a large .NET application to the cloud had presented daunting obstacles. The task of lifting and shifting the large system-wide installations that supported existing applications consumed massive amounts of engineering manpower and often did not deliver the expected benefits, such as cost savings. Meanwhile, the dependency on the Windows operating system limited cloud options, and microservices remained a distant dream.

.NET Core not only addressed these challenges, it was also ideal for containers. In addition to starting a container with an image based on the Windows Server, engineers could also use much smaller Windows Nano Server images or Linux images. This meant engineers had the freedom of working across platforms. They were no longer required to deploy server apps solely on Windows Server images.

Typically, the adoption of a new developer platform would take time, but .NET Core experienced a large wave of early adoption. Then, in August 2017, .NET Core 2.0 was released, and adoption increased exponentially. The number of .NET Core users reached half a million by January 2018. By achieving almost full feature parity with .NET Framework 4.6.1, .NET Core 2.0 took away all the pain that had previously existed in shifting from the traditional .NET Framework to .NET Core. Libraries that hadn’t existed in .NET Core 1.0 were added to .NET Core 2.0. Because .NET Core implemented all 32,000 APIs in .NET Standard 2.0 most applications could reuse their existing code.

Engineering teams who have struggled with DevOps initiatives found that .NET Core allowed them to accelerate their move to microservices architectures and to put in place a more streamlined path from development to testing and deployment. Lately, hiring managers have started telling their recruiters to be sure and mention the opportunity to work with .NET Core as an enticement to prospective hires—something that never would have happened with .NET.

At AppDynamics, we’re so excited about the potential of .NET Core that we’ve tripled the size of the engineering team working on .NET. And, just last month, we announced a beta release of support for .NET Core 2.0 on Windows using the new the .NET micro agent released in our Winter ‘17 product release. This agent provides improved microservices support as more customers choose .NET Core to implement multicloud strategies. Reach out to your account team to participate in this beta.

Stay tuned for my next blog posts on how to achieve end-to-end visibility across all your .NET apps, whether they run on-premises, in the cloud, or in multi-cloud and hybrid environments.

AppSphere Speaker Panel: Cloudy With A Chance Of Innovation

AppSphere Day One general sessions ended with a panel of cloud experts led in discussion by Jonah Kowall, research vice president – IT operations at Gartner, with questions prepared by Jonah and also submitted by the audience. The course of the discussion indicated that — like so many things in this time of transformation and generational shift — there’s still a lot of confusion and uncertainty about the vague but huge concept of “the cloud,” and at the same time, great opportunity.

Some misconceptions dispelled, guiding principles, and best practices offered by the panel:

The cloud can be a cost-efficient option, but innovation should be a bigger driver than any anticipated cost savings.

Speed, flexibility, faster time to market, speed of innovation, and efficient utilization of resources are all good drivers for cloud adoption.

You can’t just lift a chunk of infrastructure and drop it into the cloud. It doesn’t work that way. Assumptions about how things interact, latency, storage, etc. are no longer true. Things have to be re-architected.

You have to have a plan and a strategy; otherwise, don’t even start.

The network, and network latency, are critical factors for performance in the cloud.

The hour-long discussion took a number of paths: the challenges and opportunities of SaaS, IaaS, and PaaS; containers in general and Docker in particular; OpenStack; and others. The discussion ended with a five-year crystal ball look and not much agreement on which aspects of cloud will become commoditized and what services or layers will be the differentiators. But there was no disagreement that the cloud is where we’re moving, and that it will power amazing possibilities for business, and great benefits for consumers.

The esteemed panel of cloud experts included:

Mark Quigley, Vice President, Strategy, SoftLayer, an IBM Company
Krishnan Subramanian, Director, OpenShift Strategy, Red Hat
Matt Stine, Platform Engineer, Cloud Foundry, Pivotal
Vibhor Kapoor, Director of Product Marketing, Microsoft Azure
Allan Naim, Global Product Lead, Google Compute Engine, Google

Stay up to date with AppDynamics AppSphere on Twitter using the hashtag #AppSphere14

AppDynamics Now Offers More than 100 Extensions

At AppDynamics, it’s been our mission to equip enterprises with true Application Intelligence. As the expanded application ecosystem grows, many enterprises are using a combination of legacy, contemporary, and cutting-edge infrastructure components. So today we’re proud to announce we now integrate with over 100 extensions so users can leverage performance insights like never before. We strive to create a seamless extension ecosystem to merge with your current toolset.

The Application Intelligence Platform is open, extensible, and interoperable to fit any business need. Through our extension ecosystem, AppDynamics Exchange, our community comes together to share knowledge and contribute back extensions that provide deep integrations to the tools modern enterprises frequently use.

A few extension categories I’d like to highlight are:

Monitoring extensions – integration metrics from other monitoring systems and services such as Apache, RabbitMQ, CouchBase, IBM DataPower, and Apica.

Alerting extensions – allow creation of custom notifications to integration AppDynamics’ health rule violations and events with alerting or ticketing systems such as PagerDuty, VictorOps, ServiceNow, and Atlassian JIRA.

Cloud auto-scaling extensions – integration cloud orchestration functionality such as creating, destroying, restarting, configuring, and validating machine and image instances. These include Amazon Web Services (AWS) and Microsoft Azure.

REST API & SDKs – enable retrieval of data from the AppDynamics system, including application and infrastructure metadata, metrics, events, and transaction snapshots. AppDynamics developer SDKs are available on Github. Through our API, you can download our Java SDK and the Python SDK.

With these integrations, users can monitor metrics within a business context, rapidly remediate issues, and automate baselining to detect glitches. Extensions also leverage the core Application Intelligence Platform including APM, mobile, and analytics.

Using AppDynamics and our slew of extensions, companies can help foster a DevOps culture and enable IT Ops, developers, and business professionals understand their application data, troubleshoot performance issues, and make strategic business decisions.

Come check out our community of extensions here, and download a FREE trial of AppDynamics 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:

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!