Anthony Chu

One of the key principles of microservices is that each microservice encapsulates its own isolated data store. In reality, it can be costly to provision a separate, geo-redundant database for every microservice using a database-as-a-service offerings such as Amazon RDS. We can also do it ourselves using virtual machine or containers, but it's difficult to create something highly available.

This is where, I think, Azure SQL Database is very interesting. A single SQL Azure database starts at $5 a month, and provides a whole slew of features including active geo-replication.

In this article, I'll go over some features of SQL Azure DB and take a look at how it's the ideal relational database for microservices.

Microsoft's Bot Framework is awesome. It provides a really easy way to build a chat bot and connect it to many channels including Slack, Skype, and Facebook. The Bot Framework also provides an easy way to embed a chat widget on a web page. But it embeds as an iframe, so it doesn't behave like a typical chat widget that sticks to the bottom of the browser window and pops up and down when clicked.

During a recent hackathon, my team wanted to embed the Bot Framework web chat window with stick-to-bottom and and popup/collapse functionality. We managed to do this using a script and some CSS.

After over a year in preview, Azure Logic Apps reached general availability last month. As part of the GA announcement, a new serverless consumption pricing model was added. This meant that Logic Apps no longer need to be part of an App Service Plan. Instead, we have a new pay-as-you-go pricing model that starts at $0.0008 per action execution (that's 8/100 of a cent) and gets even cheaper with volume.

Together, Logic Apps and Azure Functions now provide a really interesting story for serverless compute and workflow orchestration on Azure. The possibilities are endless.

Today we'll take a look at how we can build a simple online form and send an email using an Azure Logic App, all without writing a single line of server-side code.

We'll assume that we're adding a "contact us" form to an existing website. The form will make an AJAX call to a Logic App to send an email.

In March at the Build Conference, Microsoft announced MongoDB wire protocol support in DocumentDB. This means we can take existing applications that connect to MongoDB and run them on DocumentDB instead, using the same native MongoDB drivers. In this article we'll take a random Node/MongoDB sample app from the web and connect it to DocumentDB.

Why DocumentDB

DocumentDB is Azure's NoSQL database-as-a-service. Here are some of its advantages:

• Fully managed - no VMs or database servers to manage, automatic backups
• Highly available (99.99% uptime SLA)
• Elastically scalable - scale storage and throughput up and down in seconds with no downtime
• Super fast - 99% of reads/writes are guaranteed to be under 15ms

There are vendors that offer MongoDB as a service, but they are simply managing MongoDB in VMs for you. Now that DocumentDB supports the MongoDB protocol, it's effectively the first fully-managed, elastically-scalable MongoDB service.

I think it's really important to write readable code. Readable code is easier to use, maintain, and reason about. It is also more difficult to create bugs in code that is readable.

I believe that code readability is more important than things like performance. That's not to say I don't care about performance, but I'd rather start with readable code and optimize where needed. A lot of readability problems in code often come from premature optimization.

Sometimes we write unreadable code simply because we don't know better. So I thought in this article I'd go through a few specific examples of how to make .NET code more readable. They're examples I've come across in code that I have written or reviewed.

TimeSpan Factory Methods

.NET's TimeSpan struct has four constructor overloads that take one, three, four, and five integer parameters. It's not uncommon to come across code like this:

var duration1 = new TimeSpan(1, 0, 0);
var duration2 = new TimeSpan(0, 1, 0, 0);

Both of these statements create a TimeSpan of 1 hour. But unless you have memorized the different constructor overloads or use IntelliSense, it is near impossible to figure out what the actual value is by reading it.

One might say we can solve this by giving the variables a proper name. I think it's incredibly important to give variables meaningful and descriptive names, but that can only get us so far. Take this example:

var oneHour = new TimeSpan(0, 0, 1, 0, 0);

What's wrong with this? Well, it turns out the signature of this particular overload is public TimeSpan(int days, int hours, int minutes, int seconds, int milliseconds); so we have a TimeSpan of 1 minute, not 1 hour. Whoops!

A better way to solve this is using TimeSpan's static factory methods:

var oneHour = TimeSpan.FromHours(1);
var fiveMinutes = TimeSpan.FromMinutes(5);