Cloud to the Rescue!

At my company we have been on a mission to outsource our IT department, including the outsourcing of custom applications. We are not a software company goes the mantra. That’s not what we do. So we buy a product from a vendor, in most cases this is the obvious thing to do. We are not going to write our own Email system or word processing application, but what about those custom applications that is specific to our own industry, and directly support our employees in their daily work. Should we find a vendor that offers broadly the functionality that we need. This seems to be a popular thought. We will buy the products, do a small amount of customization and we will be responsible for the “Glue” to make all of these disparate systems work. The net result should be smaller more cost effective IT departments.

Ok that’s a possibility and I don’t want to get into the risks this plan has I will save that rant for another post, but instead I want to look at the impact of the Cloud, and in particular Platform as a Service (PaaS). This substantially lowers the overall cost of custom applications. I can recall projects where a third of our time is taken up moving from QA to production, troubleshooting the same bugs over and over again because of environmental differences and the need to do most things manually with production engineers in place of developers. But not only does PaaS save us some time and resources it rebalances who we need on the team. A much higher proportion of our spend should be on meeting the functional business requirements – developers writing code, with a lower spend on engineers and hardware. The cost of quality requirements like scale and performance can also be reduced with solid cloud architectures, rather than big databases, and big hardware. This much larger percentage of our resources allocated to the meeting of functional business requirements means that the knowledge of our business process is much more valuable. Who better to know those processes than your own employees the developers who have been building and maintaining you systems. And who would you rather have this intimate knowledge of your business? Will the cloud save a few of our jobs?

Advertisements

Async Await or ContinueWith

So what’s the difference with these 2 code snippets?

var result = await subscriber.RunAsync((T)messagePacket.Body, cancellationToken);

 

await subscriber.RunAsync((T)messagePacket.Body, cancellationToken) .ContinueWith(anticedant => { //do something });

Well not much really, except for the error handling. What to do with those pesky exceptions. Especially since we are handing in a cancelation token. If the operation is canceled then an exception will be thrown. In the first instance the await keyword is kind of hiding the task that the Async operation returns. It will catch the exception and in this instance re-throw a new exception. You can choose how to handle it either wrapping the call or allowing it to percolate up the call stack.

In the second snippet we can do something without a new exception being thrown. We can look at the task that is returned and do something depending on the state of the task.

await subscriber.RunAsync((T)messagePacket.Body, cancellationToken)
    .ContinueWith(anticedant =>
    {
       switch (anticedant.Status)
       {
           case TaskStatus.RanToCompletion:
               //do something ... or nothing
               break;
           case TaskStatus.Faulted:
               subscriber.Abort();
               Trace.WriteLine("Request failed");
               break;
           case TaskStatus.Canceled:
               subscriber.Abort();
               Trace.WriteLine("This task timed out"); 
               break;
    }
    });

We lose a little of the readability of the Async await keyword paring and of course we could always wrap the first method in a try catch block and handle the second exception thrown, but I was taught that throwing exceptions is bad and expensive and for me I can understand what’s going on so I am going to stick with ContinueWith when I need to handle a cancelled or timed out request.