8 Reasons Why Microsoft Stack Is Still a Viable Choice

Life was great for Microsoft developers 10 years ago. Companies were happy with using the Microsoft development stack for most of their development projects. With ASP.NET on the frontend, .NET middle-tier and SQL Server on the backend, things worked very well for the most part. When they didn’t, developers just accepted that as something that came with territory. Microsoft was all but running the show. Then, at the end of the last decade, Microsoft’s 800-pound gorilla status started to unravel. Maybe it was due to the introduction of the iPhone and Microsoft missing the shift to mobile, or maybe it was because of the proliferation of open source projects, but things changed, and today those same companies need to be persuaded that going with Microsoft Stack is a good idea. This article presents eight reasons in favor of sticking with the Microsoft software stack.

Reason #1: .NET Is Still One of the Best

Introduced more than 10 years ago, .NET Framework is feature-rich and thoroughly battle-tested. While it was commonplace to have to combine native development with managed code in the early days of .NET, the vast majority of development tasks are supported out of the box today. Even companies such as Oracle released components that are 100 percent .NET managed code (i.e. ODP.NET managed driver) to interface with their products. .NET API is consistent, well documented and used by millions.

The knowledge-base available via MSDN, StackOverflow and thousands of forums and blogs is massive. In my years of developing in .NET, I cannot recall an instance where I would get stuck for long on a framework bug; each time, someone had already experienced, researched and posted an answer, not always the answer I was hoping for, but still something that moved me forward. With the upcoming 2015 release, .NET Core will be open-source and available on non-Windows systems.

Reason #2: ASP.NET Has Evolved

Looking back at the traditional web-to-database Microsoft stack from 10 years ago, it’s interesting to see which parts survived the test of time and which parts faded away. While the back-end of the Microsoft stack remained pretty much unchanged (we still use the same set of patterns and components, such as Dependency Injection, Tasks, Linq, EF or ADO) the front-end, the ASP.NET piece, saw a fundamental shift from “do it the Microsoft way “ (i.e. Web Forms) to “do it your way and use ASP.NET as a platform.” Today, ASP.NET is an MVC-based framework featuring robust infrastructure for authentication, bundling and routing that integrates with many non-Microsoft technologies such as Bootstrap and AngularJS. ASP.NET sites look nice on a wide range of form-factors, from phones to desktops, and its Web API capabilities make exposing web services a breeze. The framework has been open-source for a number of years, so if you get stuck on a problem, the source is available on GitHub. ASP.NET has changed, and changed for the better.

Reason #3: Simplicity of Web API and Power of WCF

My all-time favorite quote is from Alan Kay who said, “Simple things should be simple; complex things should be possible.” When Windows Communication Foundation (WCF) first came out in 2006, it was anything but simple; behaviors, endpoints, and bindings were overwhelming. So, Microsoft released Web API, an easy-to-use framework that makes exposing HTTP web services a piece of cake. With a few lines of configuration, your API turns into a secure, “industry-standard” web service.

If your use case does not fit the “standard” mold, and you need full control over how your API is exposed over the wire, you can always fall back on WCF. With the myriad of configuration options and hooks, WCF lets you custom-serialize your data, log, intercept, route message, use peer-to-peer and queuing, and much-much more. Web API, together with WCF, delivers on both tenets of Kay’s quote: if you need a simple web service, you are done in minutes with Web API; if your service requirements are complex, “all” is possible with WCF. These two technologies provide a comprehensive coverage of service scenarios and come prepackaged with the .NET framework.

Reason #4: SQL Server Is as Solid as Ever

For many years, it seemed like the tidal wave of new development languages, frameworks and patterns came through the front and middle tiers and spared the database back-end. After all, the good old “SELECT” is still as much in use today as it was 20 years ago. I suppose this is due to the fact that many companies view their data as the core of their business, and keeping the integrity of that core far outweighs the excitement of trying “something new” at the database layer.

SQL Server excels at its primary role of a data keeper with a myriad of features for transactions, referential integrity, backups, mirroring and replication, but what sets SQL Server apart from competition is how well it integrates with the rest of the Microsoft stack. For rapid development, there is the Entity Framework, currently in version 6, passed adolescence and delivering well on its promise of streamlining data access. If you need computing power, the .NET Framework is loaded in-process with SQL Server, meaning you can embed .NET code as stored procedures, functions or aggregates without sacrificing performance. Pair that with the fact that SQL Server 2014 comes with in-memory tables, and you can come up with some pretty slick real-time solutions that could not be made fast enough solely with SQL and regular tables. After years in the industry, SQL Server is still on top of my list of RDBMSs.

Reason #5: It’s Easily Testable

So many times, working in corporate IT, I saw software turning into these untouchable black boxes because there were no tests, and nobody wanted to mess with the code for fear of “breaking something else.” Then, I worked on systems that had thousands of tests, and it was a great feeling to be able to tell business that, “yes, we can make these changes,” years after software had been released. The Microsoft stack is designed with testability in mind. ASP.NET MVC has hooks for dependency injection, and in version 5, dependency injection will be included in the framework itself. In the middle tier, it’s a similar story: we use dependency injection to disassociate implementation from the interface, which lets us swap production types with mocks at test time. Even on the database side, there are SQL Server Data Tools that come with templates for testing against the stored procedure layer. Testing is an inseparable part of the software development process today, and the Microsoft stack comes well equipped for this new reality.

Reason #6: Elaborate Support Ecosystem

When it comes to support, it’s nice to have a range of options, starting with community forums and ending with an actual live human being working on-site on your server. The online ecosystem for Microsoft products is one of the largest in the industry. After all, Microsoft was started by Bill Gates, a software developer himself, who saw the wide adoption by developers as the key to proliferation of Microsoft products. That meant providing these developers with lots and lots of support.

Microsoft was among the first to encourage its employees to blog about the technology they were working on, and while the rest of the industry has certainly caught up, the amount and the quality of instructional videos, guides and articles coming directly from Microsoft today is still very impressive. That layer of quality online content is supplemented by a large number of community-based support ecosystems such as StackOverflow, which are not as consistent when it comes to content quality, but are, nevertheless, far more helpful than not.

Lastly, there is always an option to pick up the phone and call Microsoft support. I rarely had to use it, but there were a handful of production emergencies when having Microsoft devs analyze core dumps saved the day. The range of support options is clearly a factor in favor for going with the Microsoft stack.

Reason #7: Microsoft Sticks to Their Products

A few years back, choosing Microsoft Silverlight as the front-end for an application seemed like a valid choice, but that’s no longer the case. With the mobile trend in full swing and JavaScript frameworks dominating the front-end space, Silverlight is no longer a feasible option; nevertheless, it’s still supported by Microsoft through 2021. Microsoft sticks to its guns, which is good for those of us who have to make technology choices without having a magic eight ball to tell us what technology trend will dominate the software landscape in the future. Going with the Microsoft stack ensures that time and money is invested into technology that will be supported even if it falls out of favor with the industry.

Reason #8: Visual Studio Umbrella

A decade ago, I was spending about 50 percent of my time working in Visual Studio and about 50 percent in other tools. Today, the split is overwhelmingly in favor of Visual Studio. Microsoft’s vision for Visual Studio to be a one-stop solution for hosting IDEs is coming to fruition with many Microsoft and non-Microsoft products offering some level of integration with Visual Studio. From database development with SQL Server Data Tools to writing iPad and Android apps with Xamarin, Visual Studio provides a familiar developer experience with a consistent user interface. The same can be said about working with Microsoft Azure, a cloud platform encompassing a variety of services from database hosting to mobile services.

Visual Studio obfuscated the complexities of distributed cloud infrastructure making the experience of developing cloud applications consistent with that of developing applications not hosted in the cloud. All the pieces seem to fit together nicely under the umbrella of Visual Studio, making the overall development process very efficient.

Microsoft Stack Technologies: The Best of Both Worlds

Today, there are far more choices for writing quality software compared to 10 years ago. That is certainly a good thing because competition forces big players, such as Google, Apple, Amazon and Microsoft, to continue to innovate and not get complacent. While Microsoft has been pushed from the top of the mountain by the tech evolution of the past decade, the company has shown that it’s willing to adapt and is attuned to realities of the current technological trends. ASP.NET embraced other technologies and methodologies, many of them open source, with the original Web Forms fading into history. The .NET framework continues to evolve, breaking new frontiers with libraries for multi-threading and many-core computing. With the imminent 2015 release, the core of the framework will be open-source and portable to non-Windows platforms, which is a step in the direction of inclusiveness and transparency.

These welcomed improvements come from a company that has long-established processes for releasing software that’s tested, documented and supported. Going with the Microsoft tech stack brings the excitement of working with modern languages and frameworks plus the stability of being backed by a software giant with decades of experience in the development industry. This is why I am recommending the Microsoft development stack today.