Codemash Thursday 8:00am – Building Highly Scalable Apps on the Azure Platform: Real World Guidance


I am going to be posting my notes from each session I attend. These are raw and unedited, so I apologize for any grammar or spelling mistakes.

Building Highly Scalable Apps on the Azure Platform: Real World Guidance
#Kevin Grossnicklaus

You should sign up for an Azure account.
You get an Azure portal where you can access and create any kind of Azure service.
You can use bit and pieces – he sometimes uses Azure Service Bus with his AWS applications.
He puts an Azure deployment project in every Visual Studio solution.
He does not use the Azure emulator – he sets up a console app to run the service directly for development. It is just a wrapper around his Azure service. This is because it is faster to work with since it does not have to do the deployment, even to the local emulator.
He uses the Azure services that he needs from the console application (ASB, for example). This does require a constant internet connection, but it gives you full access to the services you need with all of the features. The emulator is not at parity with the real thing.
He believes very heavily in message-driven architectures. He uses MongoDB.
He has a logging service that takes in the log events and writes to a queue, and has a log writer service that actually writes to a DB.
All of the parts of Azure have libraries to support them available via NuGet if you are using .Net. There are SDKs available for non-.Net applications.
In order to work with other people, he appends things like the machine name or the environment to the front of the queue name so that messages aren’t stolen by the wrong computer or application.
Serialize small objects to the queue using a text format like JSON.
When you create Azure assets, you select what datacenter they will go in. Typically you want all of you stuff in the same datacenter to minimize latency (but what about redundancy – guess that is a different consideration and out of scope for this talk).
Send work via an async call to a queue to be done by a “backend server” if that work doesn’t need to be immediately visible to the user. For example, you might be able to do a simple form validation then queue up the form submission for later processing.
You can have multiple instances of a service running that listen to the same queue, and only the first one to pick it up will process it. If you want to have multiple consumers of the message, you would send it to a topic and all of the services that are interested in that topic would receive the message.
Now he is talking about precalculating things like a Facebook timeline. He didn’t use the terms “read model” or “eventual consistency” but that is what he is talking about here. He would use SignalR to send the updated read model to the client when it is ready.
Integrated Caching – use the memory in the servers you are already running instead of a dedicated cache. You can define the allocation. He allocates 1/3 of the memory for each of his web servers. This can save you money if you have the memory to spare. You can spin up dedicated cache – your application does not see any difference – it is just a different connection string. Redis is also available, but he doesn’t use it. It would require some code changes.
Azure Blob Store is like an unlimited disk. You put documents in containers, which can be public or private. You can use a public container as a CDN. It is probably better to wrap your blobs in an API instead of allowing direct access. This allows you to do things like reformatting (image size, for example).
He definitely spends a lot of time trying to figure out the best ways to use Azure cheaply, which makes sone sense.
He hosts MongoDB through mongolab, which actually runs on Azure so his databases end up in the same datacenter. You can even put the database in the same Azure network as the rest of your stuff. mongolab actually runs mongo on whichever cloud provider you want – it works with AWS as well.