Eric Kepes

Just some guy who cares about good software.

Azure Emulator Gotchas

I’ve been playing around trying to build up a sample application on Microsoft Azure to prove out how I’d build a distributed system. It’s still a work in progress (here’s hoping I actually blog it all the way through), but that’s not the point of this post.

Microsoft has provided an emulator that allows you to do a lot of things in your development environment without actually deploying to Azure. This is great when you are trying to figure things out and don’t have a lot of confidence that you are doing things right. The deploy to the emulator is a but faster (especially if you have an SSD) and you don’t have to worry about spending any money on a runaway process that you forgot to shut down.

This emulator has some fairly significant problems, however. The big obvious one is that it doesn’t support Azure Service Bus. You would think you can get around this by using Windows Service Bus, but I could not get web/worker roles in the emulator to see the instance of WSB on my machine. You can use an ASB hosted on Azure from the emulator, however. This can be tricky once you start sharing the codebase with others, of course, since you need to keep your connection info out of the source repository.

Another significant problem is that the emulator can’t use the latest version of the Azure libraries. It lags and so you have to find out how far behind, and then play NuGet magic to get the right versions. It’s not hard, but it’s a pain. Obviously this also prevents you from testing any new features of Azure, but for my purposes this hasn’t been a problem.

A workaround suggested to me by Chris Patterson would be to install the Azure dev environment on your machine (or go full bore and stand up a full Azure environment in your data center, which might be a good long term solution for development), but that was just more effort than I want to put in at this point.

The bottom line, if you are going to only use web/worker roles and the storage account features, you can make use of the emulator to get a proof of concept working on your machine, but if you want to really use it you need to deploy to Azure.

I Moved to Octopress

I really wanted to have a better way to paste in code snippets, and WordPress.com doesn’t have a Gist plugin. So, I needed to either self-host (which given the recent security problems WP seems to have had with people not keeping up to date seemed like a bad idea) or find something new. Octopress to the rescue! If you just follow the instructions, it wasn’t really that hard. And so here I am.

I Moved to Octopress

I really wanted to have a better way to paste in code snippets, and WordPress.com doesn’t have a Gist plugin. So, I needed to either self-host (which given the recent security problems WP seems to have had with people not keeping up to date seemed like a bad idea) or find something new. Octopress to the rescue! If you just follow the instructions, it wasn’t really that hard. And so here I am.

I Moved to Octopress

I really wanted to have a better way to paste in code snippets, and WordPress.com doesn’t have a Gist plugin. So, I needed to either self-host (which given the recent security problems WP seems to have had with people not keeping up to date seemed like a bad idea) or find something new. Octopress to the rescue! If you just follow the instructions, it wasn’t really that hard. And so here I am.

I Moved to Octopress

I really wanted to have a better way to paste in code snippets, and WordPress.com doesn’t have a Gist plugin. So, I needed to either self-host (which given the recent security problems WP seems to have had with people not keeping up to date seemed like a bad idea) or find something new. Octopress to the rescue! If you just follow the instructions, it wasn’t really that hard. And so here I am.

My Thoughts on What It Means to Be an Architect

An architect is like an Army Ranger, or an Old West scout. Their job is to go ahead of the main force to determine the best paths and clear obstacles when appropriate. This means it is up to them to figure out what technologies and architecture patterns to use. It is their job to find what the risky parts of the application or system will be and prototype them enough to remove the risks. If these prototypes are meant to become part of the production software (and let’s be honest, they always become part of the production software) they have to be built to the same standards as production code, which means good automated tests (unit, functional, and integration, as appropriate). They need to be prepared to discover that the approach they wanted to take is not the correct approach and abandon it before a lot of time and effort is spent trying to make the wrong tools or technologies work. Sometimes the seemingly obvious path is not the best path. You may have to attack a problem from an unusual direction to get to the best solution.

In order to do this, architects need to be able to see the big picture yet still write good code quickly. Good code is code that is easily understood and maintained, which means code with tests and low complexity and coupling. Not every developer can see the big picture - it is easy for us to get lost in the details or try to create the perfect solution instead of just doing enough to satisfy the requirement with solid code. This is not a bad thing if it can be kept under control, and the person qualified to keep it under control is an architect. A manger will want the developer to stop at satisfying the requirement.

Architects need to be concerned about the -ilities of a system. They need to keep an eye on performance - will the system be able to handle the expected number of peak users while still being responsive? Will it handle user load while background processes are under heavy load as well? Can it handle securing it’s data from malicious users and outside attack? The person qualified to make sure good technologies and development techniques are used to produce the system may not be qualified to define performance tests or security. This is why you often need a team of architects each specializing in one or more areas. Of course, this does not absolve an architect from knowing anything about these other concerns - an architect should know enough about these thing to call bullshit on bad ideas. But you need to have people with deep experience and knowledge in these important areas, and it is extremely unlikely that one person will be able to do the job. This is why you need an architecture team for any project of significant size.

Architects should not be treated in any special way. They will have knowledge that other people do not, but they should not horde this knowledge. They need to accept that other people may have good ideas as well and be ready to hear them out and employ these ideas when possible. In order to make this possible, they need to be approachable and respectful of these opinions and ideas. They should document decisions with the ideas considered and the reasons why they were not used as well as a compelling story for the idea that is being used. This provides a level of transparency and over time will give others an understanding of what values the organization holds when considering technologies and architectures.

Done properly, being an architect is still a very hands on job. You have to maintain your coding skills and keep in contact with other developers, or else you will stagnate and become of little value to your organization. You need to have solid teamwork skills because modern software requires lots of experts to get to a solidly built, long-lived result. The days when architects could hide in an ivory tower are completely gone, if they ever really were here.

My Thoughts on What It Means to Be an Architect

An architect is like an Army Ranger, or an Old West scout. Their job is to go ahead of the main force to determine the best paths and clear obstacles when appropriate. This means it is up to them to figure out what technologies and architecture patterns to use. It is their job to find what the risky parts of the application or system will be and prototype them enough to remove the risks. If these prototypes are meant to become part of the production software (and let’s be honest, they always become part of the production software) they have to be built to the same standards as production code, which means good automated tests (unit, functional, and integration, as appropriate). They need to be prepared to discover that the approach they wanted to take is not the correct approach and abandon it before a lot of time and effort is spent trying to make the wrong tools or technologies work. Sometimes the seemingly obvious path is not the best path. You may have to attack a problem from an unusual direction to get to the best solution.

In order to do this, architects need to be able to see the big picture yet still write good code quickly. Good code is code that is easily understood and maintained, which means code with tests and low complexity and coupling. Not every developer can see the big picture - it is easy for us to get lost in the details or try to create the perfect solution instead of just doing enough to satisfy the requirement with solid code. This is not a bad thing if it can be kept under control, and the person qualified to keep it under control is an architect. A manger will want the developer to stop at satisfying the requirement.

Architects need to be concerned about the -ilities of a system. They need to keep an eye on performance - will the system be able to handle the expected number of peak users while still being responsive? Will it handle user load while background processes are under heavy load as well? Can it handle securing it’s data from malicious users and outside attack? The person qualified to make sure good technologies and development techniques are used to produce the system may not be qualified to define performance tests or security. This is why you often need a team of architects each specializing in one or more areas. Of course, this does not absolve an architect from knowing anything about these other concerns - an architect should know enough about these thing to call bullshit on bad ideas. But you need to have people with deep experience and knowledge in these important areas, and it is extremely unlikely that one person will be able to do the job. This is why you need an architecture team for any project of significant size.

Architects should not be treated in any special way. They will have knowledge that other people do not, but they should not horde this knowledge. They need to accept that other people may have good ideas as well and be ready to hear them out and employ these ideas when possible. In order to make this possible, they need to be approachable and respectful of these opinions and ideas. They should document decisions with the ideas considered and the reasons why they were not used as well as a compelling story for the idea that is being used. This provides a level of transparency and over time will give others an understanding of what values the organization holds when considering technologies and architectures.

Done properly, being an architect is still a very hands on job. You have to maintain your coding skills and keep in contact with other developers, or else you will stagnate and become of little value to your organization. You need to have solid teamwork skills because modern software requires lots of experts to get to a solidly built, long-lived result. The days when architects could hide in an ivory tower are completely gone, if they ever really were here.