Over the past two weeks I've begun moving a lot of my hosting infrastructure onto Microsoft Azure. This has consisted of all sorts of configuration – virtual networks, VPN's, backups, servers, databases and sites. One of my sites uses Code First Migrations at it's core, and during the migration simply nothing would work. After much pain and frustration I made the worst mental leap a developer can make: I came to the simple conclusion that is was everyone else's fault. Like most of these kinds of problems, I was to blame all along.
When configuring an Azure Virtual Network one of the most common things you'll want to do is setup a Point-to-Site VPN so that you can actually get to your servers to manage and maintain them. Azure Point-to-Site VPNs use client certificates to secure connections which can be quite complicated to configure so Microsoft has gone the extra mile to make it easy for you to configure and get setup – sadly at the cost of losing the ability to connect through the command line or through PowerShell – Let's change that.
Often you'll find yourself logged into a web or application server and need to simply test that you can get to the SQL server you've unsuccessfully been trying to point your app at. Luckily there is a nifty trick built into Windows that allows you to save the day without having to install anything on your box – and it works on both client and server operating systems just as well.
Web application security's had a lot of coverage in recent times with a lot of attention paid to approaches to dealing with user generated content or exposing form or query string data to users. Thanks to a number of big hacks over the years you commonly hear about the risks of not properly encoding user data and the risk it poses to your visitors. One thing you don't hear often is how user entered CSS can have just as much risk attached to it – thanks to accidental support for HTML Components (HTC's).
Offshoring – the business consultant's best friend. It's often used as "the grass is greener" answer to many large software development team's senior management. After seeing this sold in some way at nearly every role I've had for the last 10 years, the one question I don't often see asked alongside is what problem this solves and if there's other answers. Like many legitimate leadership questions this is overlooked not because managers are unintelligent, but because it's often a hard question to answer. Digging deeper delivers answers that can save a lot of time, stress and money.
Over the last few years we've seen a lot of blog posts floating around showing how to setup and deploy a website to Windows Azure. In my opinion they all cover the the "Azure 101" point of view and don't speak too much about migrating a website that already exists to Azure and some of the pains and gains experienced along the way. This post covers the migration of this very website to Azure websites and migration of my blogs database to SQL Azure.
Page level caching for ASP.Net webforms and MVC websites is pretty awesome, because it allows you to implement something that's quite complex; multilevel caching, without having to really understand too much about caching, or even write much code. But what if you want to clear a cached ASP.net page before it's due to expire?
Today starts this year's Microsoft TechEd conference up on the sunny Queensland Gold Coast and I'm lucky enough to be up here for the week watching many top Australian and international developers and IT professionals working on the Microsoft stack, hacking on new frameworks and tooling, and perusing product wares. This is my second year at TechEd and I'm looking forward to more of the same awesome everything that we saw last year.
New Relic's Deployment notes features have definitely been around for a while, but like a lot of things experienced by developers outside Microsoft's ecosystem, this is another service where we're a bit late to the party. The ability to track application performance against a certain release of your application is a great way to track the progress of any work your team has put in to improve your application's performance and visitor's overall experience. Implementing it is surprisingly simple which begs the question, if you're not doing it, why not?
Now that we're all configured at Amazon and we've got our solution in a state where we can easily package and deploy it's time to automate it all with TeamCity so you don't have to have any human intervention when you want to fire up a new instance of your website for testing.