How do you build features on #Azure?

For the past few months my team and I have been using git-flow to build a new REST API for an existing cloud native application. The challenge was impressive, but this is how we did it.

Our team is spread across many geographical locations. We use a mix & match of best practices to help us communicate. For example, we use Skype, it’s on all our devices (phones, tables, laptops and desktops…) and makes collaboration easy! Our code lives in Git and is continuously built and released to our integration environment for validation.

Our team isn’t unique. Many of my colleagues work in distributed teams. Surprisingly, we all share the same common challenges. Time zones, cultural differences and language barriers are now part of each decision we make. Fortunately we all speak a common language, C#.

With this added complexity, how did we go to production on time? We implemented a process that we continuously tweak and adjust to meet our goals.

Drive Productivity by Limiting Work in Progress

We were a team that finally worked as a team! Identifying and removing blocking issues from the work in progress (WIP) became everyone’s focus. Our communication improved and knowledge was shared. This resulted in more contributions from everyone on the team.

Continue Reading...

Temporary is The New Permanent

What’s your first impression when you look at this elevator control panel? To be honest, I find it confusing. What was the rush? I mean they could have waited for the new control panel buttons or the new software update to change everything at once. Who knows how long this patch will stay in place because it’s deemed to be “good enough”…

Personally, I see this all the time. Think about your projects, past and present, do any of them feel like this elevator control panel? It happens to all of us at some point. Typically, it happens when we’re rushed and think that temporarily commenting out a piece of code isn’t going to hurt anyone.

The Broken Windows Principle

The broken windows theory is a criminological theory of the norm-setting and signaling effect of urban disorder and vandalism on additional crime and anti-social behavior. The theory states that maintaining and monitoring urban environments in a well-ordered condition may stop further vandalism and escalation into more serious crime. (source)

In other words, if broken a window isn’t promptly fixed, the message conveyed by the owners of the building is that they don’t care. Consequently, vandalism will continue and chances are that a second window will also be broken. Eventually all the windows will be broken and the building will probably be abandoned.

Consider Using UTC (Coordinated Universal Time) When Designing REST APIs

With an ecosystem of devices that is constantly evolving, it’s hard to predict who will consume your REST APIs and how they will consume them. Devices as we know them are changing shape, consequently applications are constantly adapting to new platforms.

Lets face it, mobile apps are the norm and shouldn’t be ignored. They travel and shouldn’t be considered as sedentary.

Imagine a scenario where you are on a business trip and try to fetch today’s news from a different continent. Your device formulates a URI with a date and calls a service… no results…
That’s weird! Its 10 PM and I should get results for today’s news. This is probably the moment where you realize that you aren’t in your normal time zone… your phone has adapted to your new geographic location but the APIs the app is calling has not!

The Unity Application Block And The ServicerLocator : Reducing Risks While Introducing an IoC in a Brownfield Project

In my previous post Building Windows Azure Services Without Compromising Testability I demonstrated how the Unity Application Block can be used to build a testable Windows Azure Service. Since then I started to play with the ServiceLocator in order to introduce a new testable code base in a brownfield environment.

As many of colleagues would agree, the ServiceLocator is often considered to be an anti-pattern, but there are some scenarios where it shines. Introducing an Inversion of Control (IoC) container in a brownfield project is a scenario where the ServiceLocator can be leveraged in order to reduce risks.

When we start working on a brownfield project, the outcome of our modifications is usually quite unpredictable. Rewriting the entire code base is costly and very risky. The lack of documentation makes it hard for a team to rewrite modules without forgetting features and accounting for undocumented behavior. The ServiceLocator can be used to introduce the IoC container without significantly altering the structure of the application. We can start introducing the new code base in very targeted areas. Consequently, allowing us to bring the application under test. Furthermore it allows us to refactor and reorganize the architecture of the application from within. As the project evolves its important to keep in mind that as we overhaul the brownfield project, the ultimate goal is to factor out the ServiceLocator in order to keep the IoC Container confined to the application’s bootstrap. This of course is not something that can be achieved instantly, it takes time and planning.

Midnight Universal Time is not Midnight Local Time!

A few of my peers have recently move to the cloud and some have found out that we can no longer ignore time zones!

DateTime is an object that is familiar to us. Most of the time we use it without any second thoughts. There lies our first mistake. Not using the DateTimeOffset in code that runs on the cloud can result in some strange and unwanted behavior.

The reason DateTime is usually the reason why our dates are off, is that by default it creates dates in local time. To create a date in UTC you are required to specify a DateTimeKind.Utc in the date’s constructor.

Imagine the following scenario. A developer is executing code in the Windows Azure emulator to debug the code before deploying to the production environment on the cloud. The configurations of the code running in the emulator if pointing to the production database and the code is creating dates using the DateTime object. These dates are then inserted into Windows Azure SQL Database. Then the developer, who is satisfied with the results, goes to production with the new code.

A few days go by, then suddenly a client calls to report weird dates and that the application isn’t working as expected. Tickets are created in the past! A second customer also reports this weird behavior, but he reports that dates are in the future!  Just so we’re clear, time travel is not a possible cause…

Why Are WebRequests Throttled? I Want More Throughput!

By default, a web browser – or in this case any .Net application that uses the System.Net.WebRequest class – will only allow up to 2 simultaneous threads at a time per host domain.

One way to lift this limit is to run Fiddler. It bypasses this limit and you can see much more throughput. I admit that this is a hack but it works when debugging.

When your code is running inside Windows Azure, Fiddler isn’t a possible hack, but wait there’s a better way!

Add the following configuration to your App.Config or Web.Config.

Size Matters!

 

Surprisingly, Size Matters in The Cloud

Incidentally, the size of your data stored and processed on the cloud really matters! In this post I will use a common scenario to illustrate just how much size matters.

The following scenario can augment the Worker Role’s throughput by 12x

Cutting Costs on Windows Azure Isn’t Always About Compromise

Cutting costs on Windows Azure Isn’t always about compromise, its about organization and using available resources to a maximum.