Technology

If you read this far, you’re probably curious about my technical experience. I’m primarily a .Net developer with a focus on Azure and CI/CD pipelines.

Azure

A few years ago we moved all new development to Azure. I created the ARM templates to automatically stand-up our resources. Since the ARM templates are Infrastructure as Code (IaC), they can easily be deployed in every environment using our CI/CD pipelines.

When we opened our new season this year, we kept an eye on our performance metrics. Our Azure Sql instance needed to be scaled up, but that happened with a click. We also saw that we could scale back our App Host Plans late at night and on weekends, so we just set up a schedule in Azure to handle that.

Logic Apps and Service Bus

We deployed some Logic Apps to handle some out-of-band work for our normal user workflows. The Logic Apps triggered on Service Bus messages, and we were only interested in a small subset of the messages. I miscalculated the number of messages I thought we would see (we were getting many more) and we were getting charged for all the messages we weren’t interested in. Yikes!

It turns out the fix was pretty simple; I just slapped a filter on our subscription, so the subscription only saw messages we were interested in. I added some properties to the messages when they were generated and now our Logic Apps ran only when they were needed.

Cosmos DB and Redis cache

Azure makes things easier, but you can’t neglect your monthly spend. Architecture choices should take into consideration the dollar cost of Azure resources.

I wrote a feature switch library to keep our unfinished code from being seen in production. Because we were familiar with Cosmos DB, I chose that as the backing store, not realizing the how expensive it would be in our production environment. Our feature switches get read frequently during app execution and we had to increase the RUs our Cosmos collection to a painful level.

To take the load off Cosmos DB, I used a much less expensive cache, Redis. Putting Redis cache into the feature switch library allowed us to drop the RUs on Cosmos to the lowest level and keep our costs down.

CI/CD

We’re using Azure DevOps (Visual Studio Team Services) for all of our builds and releases. We have multiple lower environments that we can easily promote code through until we end up in production.

Why is CI/CD so important?

For years, my teammates and I wrote code, had it pass QA, and then prayed it made it into production without problems. And when we did have problems, we were comparing files and directories to figure out what was different or trying to remember if some config file needed special consideration on the prod boxes. And of course, the boss is wondering when the new code is going live, and hopefully the sites aren’t down too long, and… what a mess.

Now I help our developers setup their CI/CD pipelines and we work together to make sure new code is working in each environment, including production. Once the pipelines are set, we rarely have to touch them.
Our QA team can promote up the latest builds whenever they need to test features or fixes and scheduling a worry-free release to production happens with a couple of clicks.

I recently helped one of our developers and a contractor get their pipelines setup to release to WP Engine. It took some concentrated effort, but we ended up with a solution that used an SSH key to automate our file transfers with SCP.

Once our developers realized that they’re code wasn’t “done” until it was running in production, everyone’s life became much easier.

Unit Tests

I’m the champion for unit tests in our shop, they give me a great feeling of security.
We actually run our unit tests in our CI/CD pipeline during the build. After leap day (Feb 29th), we had a few pipelines stopping because of broken builds. It turns out that we had some wonky age calculations that our unit tests failed after leap day. We knew it was fixed when the unit tests passed.

Load Tests

It can be a tough sell to leadership but making time to load test critical infrastructure and code can eliminate doubts about performance. Your CIO will sleep better at night knowing that her bases are covered.

Prior to opening our busy season, we load tested a critical API and its underlying storage layer. This revealed a missing database index and also gave us a good starting point on how to scale the App Host Plans. We used artillery.io to quickly build GET and POST requests with a single YAML file.
We used our ARM templates to quickly stand-up a new environment for load testing so we didn’t disrupt our developers and QA team from their critical work. When the tests were done, we tore everything down, so the cost was minimal.

Load testing a historically poor performing legacy application required some more mature tooling. We switched to JMeter to generate a load test for a subset of our Web Forms application. After removing some un-needed sql queries, the JMeter tests showed that our modifications had the desired effect and eliminated database deadlocks that had been a headache for years.

Security

We use OpenId Connect to secure our APIs and our client facing applications. This allows us to use Azure Active Directory as an IDP when needed or use our own user store. Getting new Api Resources and Clients into our CI/CD pipeline was an interesting challenge but paid big dividends.

Tools

• .NET, .NET Core
• Azure
  • Service Bus
  • Azure Sql
  • Cosmos DB
  • App Service Plans
  • App Host Plans
  • Logic Apps
  • Storage Accounts
  • Application Insights
  • Redis
• CI/CD
  • Azure DevOps
  • Jenkins
• git
• Angular
• Graylog
• Unit testing
  • Xunit
  • Fixie
  • Moq
  • Autofixture
• MS SQL Server
• SSIS
• IIS
• Entity Framework
• Dapper
• Load testing
  • Artillery.io
  • JMeter

Technology that’s more of a hobby

• F#
• Docker
• Kubernetes
• JavaScript game building