C# is NOT Dead
It was the year 2002 when C# along with the .NET framework was released thanks to the assiduous effort of Anders Hejlsberg and the team at Microsoft. However, as more than ten years have passed, we must now address the white ‘Python’ in the room. Is C# dead? The answer simply is, no. Over these past years, C# as a language and the .NET framework have trudged into the current era, where there exists a plethora of open source projects, cloud services, and serverless enthusiasts. Not to mention the field of computer science thrusting the bounds of computer intelligence with Machine Learning and Deep Learning motifs. Considering the criticism that C# received with its release for being a cheap copy of Java, the language and the platform has managed to transform themselves into still being relevant in today’s world. This can be greatly attributed to Microsoft’s decision to push for open source projects and make .NET more accessible, hence .NET Core which is a cross-platform framework. The result of which is that serverless developers can now look towards .NET when developing microservices.
The race to dominate the world of serverless is being headed by the three giants of the software industry. AWS is definitely in the lead with its Lambda services, but Google Cloud is not far behind with it Machine Learning and Data Science capabilities. Microsoft Azure is also not far behind with its PaaS capabilities and .NET capabilities. Yes, you read correctly, one of the strong points of Microsoft Azure is its .NET capabilities. As a result, C# is one of the core languages supported by AWS along with Python, Node.js, Java, and Ruby. The decision to do so manifests the importance and relevance of C#, and its standing as a tool of choice in the world of serverless must be lauded. To ensure the value of C# is esteemed deservedly, Thundra decided to commit itself to providing monitoring capabilities for C# Lambda functions, and the result is that the first version of Thundra’s .NET agent is live and ready to be installed from NuGet. With this agent, Thundra hopes to continue its efforts to ensure that the transition to serverless is smooth for everybody, including the .NET gurus embracing serverless out there. Moreover, In doing so Thundra is now the only monitoring tool currently, that provides monitoring solutions to .NET serverless developers. Furthermore, Thundra now is also the monitoring tool to support the most core languages natively supported by AWS Lambda. That means all three pillars of observability are provided, and Thundra is determined to provide continuous enhancements.
At the moment Thundra’s .NET agent can provide monitoring data concerning metrics, logs, and trace data, thus covering the three pillars of observability. Moreover, Thundra has worked towards effortless monitoring configuration, so that .NET developers can get up and running as seamlessly as possible with monitoring capabilities under their belt.
.NET and Serverless
.NET and AWS Lambda share an enhanced relationship, different from other runtimes. This is mostly due to the dotnet CLI support that AWS has developed allowing the use of the dotnet. That means with the dotnet CLI, serverless developers can perform many of the tasks that they could with the serverless framework. This includes deploying, invoking, deleting, and a whole other set of tasks simply with AWS’s dotnet tools. For example, if someone wants to deploy his or her .NET Lambda function to the Lambda console, they can simply use the command as shown below:
dotnet lambda deploy-function yourFunction
The capabilities of the dotnet tools cannot be appreciated enough. When developing Thundra’s .NET agent, we were amazed by how it facilitates the entire serverless process. To gain more insight into the matter I suggest visiting the setup guide for deploying C# functions with the .NET Core CLI here.
Another feature that we fell in love with was dotnet templates as it allows anyone to get an entire .NET project up and running within seconds. Templates are ready-made projects with all the dependencies and configurations as per the purpose of the project. They allow you to get the base project and then continue to build on top of that project depending on your own personal needs and requirements. Using these templates is extremely simple thanks to the dotnet CLI. With a basic command, you can set up the entire template and continue developing on top of it.
AWS has greatly benefited from this feature and has created an assortment of templates ranging in complexity and purpose. These templates are extremely diverse and useful, ranging from simple Lambda functions to Step Function templates and even a chatbot tutorial template, all with the aim of making it easier for developers such as you and me to get started with .NET and serverless.
Thundra has also developed templates for those pursuing monitoring goals for the .NET Lambda functions. Just like the other language agents, which require the user to wrap his or her Lambda function with Thundra, the templates provide pre-wrapped Lambda functions within which you simply have to add in your business logic. Again, due to the dotnet CLI, adding and using Thundra templates is extremely simple, and thus making monitoring your Lambda functions with Thundra easier than monitoring your Lambda functions with CloudWatch. To use Thundra’s .NET templates, simply add the templates to the list of your dotnet CLI templates with the following command:
dotnet new -i Thundra.Templates
After installing Thundra templates to your dotnet CLI, you can see the full list of templates you have using the command below:
dotnet new -all
In the list you can see the Thundra templates listed, and using the ‘Short Name’ of your preferred function you can set up the project with the following command:
dotnet new thundra.Sample --key yourApiKey --region yourAWSregion --profile yourAMIrole
You should see after executing the command above with your correct Thundra API key, region, and IAM role, Thundra Sample is a ready to go project which simply needs to be deployed using the AWS dotnet tools. The entire process exhibits the simplicity and reliability of the highest form. Truly, .NET has managed to keep up its relevance, in a time where the only thing relevant is change. Taking note of .NETs applications, we, at Thundra, wanted to provide detailed monitoring with no overhead for the community, and we succeeded with the launch of the first version of our .Net agent.
Developing .NET Lambdas with Thundra APM
We have already seen how using Thundra dotnet templates can ease the set up of a Lambda ready to go with Thundra monitoring. However, let us take a step back and discuss how one would start using Thundra from scratch and how the added power of observability can help in development.
When creating a .NET project we list dependencies to our .csproj via Nuget or through an IDE’s Nuget package manager. Similarly, when you have your .NET project, you can simply add Thundra’s .NET agent via Nuget primarily from the command:
dotnet add package Thundra.Agent.Lambda --version 1.0.0
Upon doing so you should then be able to see the Thundra agent listed in your .csproj file.
Since Thundra is now added as a dependency, we can refer to it in our handler class file while wrapping our code with Thundra. This is done by extending my handler class with Thundra’s `LambdaRequestHandler` class and overriding the `DoHandleRequest` method within which we put all our business logic. Furthermore, we simply now have to change the referred handler function to Thundra’s `HandleRequest` and add our Thundra API Key and further configure how we would like to monitor our function if needed.
Referencing the handler occurs in the ‘aws-lambda-tools-defaults.json’ file. Since the convention with .NET and AWS Lambda is to use the AWS dotnet tools, we will be using the JSON configuration file commonly named ‘aws-lambda-tools-defaults.json’. In this file is the tag `function-handler` and the value is projectdll::namespaceName.className::HandleRequest, where `HandleRequest` is Thundra’s handler method.
Moreover, when developing a .NET Lambda function, this file holds all the basic configurations that are used upon deployment and invocation of the function, and this includes region and IAM roles. Hence Thundra allows you to use the file to also add your Thundra configurations under the `environment-variables` tag such as your Thundra API key, metric data configurations, and much more, as environment variables. In the demo project, I simply added my Thundra API Key, but to get a full list of environmental variables that you can use when configuring Thundra, check out the Configuration Variables and Parameters section of Thundra’s .NET agent documentation. Moreover, there are other means of configuration, but I personally like this approach. To read more about all the ways you can actually configure Thundra for your .NET Lambdas, please visit the Installation and Configuration section of Thundra’s .NET agent documentation.
After adding the Thundra dependency, and configuring how we would like to monitor our function, the only thing left to do now is to deploy and invoke the function. This we can do with AWS dotnet tools as mentioned earlier. After we invoke our function, we should be able to see the invocation data on the Thundra console.
The monitoring data that is received with the invocation includes monitoring metrics, logs, and trace data. All three forms of data can be analyzed through the Thundra APM console when clicking on the invoked function.
From the release of C# and .NET in 2002 to the release of its serverless monitoring in 2019, the journey of over 10 years truly has been a venturous one. This year is very different from what it was imagined to be at the start of 2002, and the world of software has evolved into what it is now without any forewarning. The .NET platform has constantly transformed to ensure its existence in this new era of software, and we, at Thundra, are facilitating its transition into the world of Serverless. With the release of monitoring support for C# Lambda functions, Thundra has once again pioneered in the field of serverless monitoring among many other things. The three pillars of observability have been brought to the .NET community, with the availability of crucial data such as logs, metrics, and trace data. Nevertheless, this is not enough for us as there are still many more things to improve, and you can expect further developments to the .NET agent in the near future. So next time you come across an article or post on the unforgiving internet propagating the death of C#, let them know of .NET and serverless, let them know of the dotnet CLI, let them know of Thundra. Change is not always easy, but it does not have to be hard either. Serverless is here, C# is not dead, and Thundra is making it easy.