Times have changed, Keep Up!

UPDATE: This post was written in 2014, and continues to stand the test of time. The Azure universe keeps expanding and the rate at which services and features make their way to general availability is astounding. This can definitely become a challenge. Nevertheless, don’t think of this as a hindrance to your business because the reality is that it’s an opportunity. Through the use of DevOps and agile business processes, the fast pace that is the cloud today, empowers us to respond to customer demands and capitalize on what could have been missed opportunities.

Building a cloud solution is a dynamic experience. Most cloud platforms evolve very fast and churn out new SDK (Software Development Kit) versions every couple months. Naturally, this also means that prior versions deprecate at a much faster rate than our industry is accustomed to.

Platforms don’t live forever anymore. Windows XP, has been around for far too long. It was supported for so long, that many software vendors never felt the need adapt to the new releases of Windows. In 2014, some of these vendors are obliged to rewrite most of their software, because the ecosystem they used to build their software has evolved at a different pace.

SDKs used to build our cloud solutions have a reasonably short lifespan. Take the Microsoft Azure .NET SDK version 1.5, it was released in September of 2011 and was retired in June of 2014. Version 1.5 of the SDK has lived for 32 months. In contrast Windows XP was released on August 24th, 2001 and was said to retire on January 12, 2016. That’s 172 months of support!

As I am writing this post, I realize that solutions who haven’t kept up with the latest SDKs may be in trouble, June is just a few months away.

Alright let’s get back to the cloud.

As of January 2014, the support policy for Microsoft Azure SDKs states that retirement notifications will be sent out 12 months prior to the official retirement of an SDK. Microsoft will support no fewer than the latest two SDK Versions. In other words, if we built our projects using the .NET SDK version 2.2, you are supported for the lifetime of the next version. If we fall behind by more than 2 versions, there are no guarantees in regards to support.

Falling behind on SDK versions has significant impacts on our development environments. Consequently, Microsoft will support side-by-side Cloud Service debugging for the current version and its predecessor. For example, if you are developing a Cloud Service using the .NET SDK version 2.2, you will not be able to debug and support an application built using the .NET SDK version 1.8.

Working with previous versions of the SDK also means that you can’t take advantage of the latest tools. For example, version 2.1 of the .NET SDK was the last to support Visual Studio 2010 and it doesn’t support Visual Studio 2013. Which means that I can’t use the latest version of .NET. Now I agree that it’s not that big of an issue if you don’t have any dependencies on NuGet packages. But if you do, this could get you in trouble.

NuGet packages like Json.NET have regular updates. This is really good for most developers, because they benefit from a continuous stream of improvements. But if you stay behind and get stuck with an older version of .NET, chances are that you’re going to get stuck with issues that are probably fixed in subsequent versions of the NuGet packages. One example that comes to mind is Entity Framework. If you were developing in .NET 3.5 you would not be able to benefit from the full potential of Entity Framework 5.0 and above. Installing Entity Framework 5.0 from NuGet would actually install Entity Framework 4.5. The same type of limitations apply to the Windows Azure .NET SDKs.

Historically, Microsoft has release new versions of the Microsoft Azure .NET SDK every 4 months, leaving us with a minimum support window of 8 months. Starting with version 1.0 in November of 2009, the latest version of the .NET SDK was released in October of 2013. Since 2009 Microsoft has released no less than 12 versions of the Microsoft Azure SDK. Each version brings new features that help you build better Cloud Solutions. Version 2.2 of the .NET SDK brought us remote debugging for Cloud Services hosted on Microsoft Azure. Prior to this release, diagnosing an issue on the cloud was difficult and required an excellent logging / telemetry strategy.

My personal recommendation when it comes to developing for the cloud, is to never to fall behind on SDKs and tooling. Doing so will limit our ability to support and maintain our solutions. Therefore, we should always remember that our dependencies will keep moving forward leaving us behind with a greater technical debt than what we’re willing to admit.

2 years a long time in cloud years. Since 2014, Azure has changed drastically and SDKs have been open sourced on GitHub. Many different compute stacks have started to become the new defacto way of doing things on Azure. For example, I’ve started to favor Azure Batch over Worker Roles and I’ve also started to favor App Service over Web Roles. When it comes to Microservice architectures, I start with Service Fabric and Azure Container services.

Azure has come a long way, and it’s hard for me to imagine where it will be two years from now. The best advice I can share today, was given to me when I started in software architecture, push back on implementation details until you are forced to make a decision. Consequently, you’ll be able to take advantage of features and services that didn’t exist when the project started. This gives you an edge on competition.

Sources

• Support and Retirement Information for the Azure SDK for .NET and APIs
• Get the SDKs and command-line tools you need
• Azure SDK for .NET Release Notes
• Windows XP (From Wikipedia, the free encyclopedia)

Share your thoughts in the comments below