Last week, I had the opportunity to be Runscope's eyes and ears at the Microsoft Build Conference in San Francisco. Although this is the first Build event that I have physically attended, I have followed closely many of the previous Build and PDC events. I think it is fair to say that this Build has had some of the most significant announcements of any of the past events. Microsoft has made some major course corrections over the past few years and its vision seems to be both internally consistent within its major divisions and also consistent with the goals of its developers.
Build had a number of major announcements and demonstrated several products, many of which I believe will have an impact on the API space.
ASP.NET Web Framework Goes Cross-Platform
While it wasn’t formally announced, Microsoft presented a number of of sessions on ASP.NET MVC6, its new combined web application and web API framework. With the pending release of Visual Studio 2015, MVC6 is starting to approach release quality. Usually I would complain about framework releases being tied to Visual Studio releases because it indicates a dependency on Visual Studio. However, this release removes any of those doubts—MVC6 not only can be developed and built independent of Visual Studio, but it is also independent of the Windows operating system.
In the API world, being able to develop APIs in a programming language that is independent of an operating system is not new for developers who are familiar with Python, Java, Go and others. However, MVC6 brings a whole new world of possibilities.
What is often forgotten in the discussion of MVC6 becoming cross platform is the fact that MVC6 is now freed from the monstrosity known as System.Web, a binary component whose roots date back to the year 2000. Being free of this legacy system means that the new framework is much more lightweight, more testable and independent of the host server.
Furthermore, previous iterations of ASP.NET web frameworks were dependent on the correct version of the .Net framework being pre-installed on the target server. With the new DNX (formerly K Runtime) execution engine, the correct version of framework components can be deployed alongside the application. This isolation solves many potential deployment, testing and maintenance headaches.
Deploy Web Applications and APIs Using Docker
Further efforts to simplify deployment and scaling were announced with support for deploying ASP.NET Web Applications/APIs to Docker containers. Currently containers are only supported running on Linux VMs, but Windows Containers are supposedly on the horizon. While deploying APIs on Docker containers is nothing new, the fact that Visual Studio can do remote interactive debugging on a Web API deployed to a Linux-based Docker container is quite impressive.
Azure App Services Bring “API Apps”
A large number of the Build announcements were around the new Azure App Service, a set of infrastructure and tooling for hosting, managing and connecting APIs. The App Service allows you to build self-contained Web APIs and deploy them as an "API App". You can also create connector API Apps that expose an interface to a third-party API. The App Service comes with a marketplace for sharing API Apps and a promise of future monetization capabilities.
A common thread among all these API Apps is a Swagger definition of the HTTP resources that they expose. This enables a concept called Logic Apps to provide an orchestration/workflow mechanism between the API Apps—think IFTTT for the enterprise. A purported benefit of API Apps providing a Swagger definition is that Microsoft is able to bake tooling into Visual Studio that allows the generation of client proxy code to allow quick access to the API App. Even so, I'm still waiting for someone to explain why generating client code from Swagger will produce better results than the client code generated from WSDL descriptions, but that's just my jaded perspective.
The frustrating part for me is that Microsoft has designed Workflow description languages multiple times in the past. Even though previous implementations of the workflow engine may not be suitable for running at Azure scale, there should be no need to reinvent the language to describe the workflow. From the demos I saw at Build, the Windows Workflow description language has many more capabilities than the current App Logic workflow description language. Plus it already has a working designer. I hope this isn't another case of curly braces are cooler than angle brackets.
Office 365 Unified API: Showing Signs of Consistency
Microsoft online services have gone through quite a few growing pains over the years. Services have come and gone, and products have been renamed repeatedly. These changes have led to significant confusion in the space. Following Build, I get the sense that things are starting to coalesce into a more consistent set of offerings. I suspect that under the covers, there is still quite a mess that needs sorting out, but at least the story being presented to the customer is more consistent.
This consistency is demonstrated by the new Office 365 Unified API. At the core of this concept is the Graph API which connects together most of Microsoft Office-related APIs and provides a single discovery and authentication mechanism for resources. From a short time working with this API, there is still a fair amount of work to be done, but it does feel like Microsoft is heading in the right direction.
Heading in One Direction
These are exciting times to be involved in the Microsoft community and it is nice to see the vast majority of the ecosystem heading in "One Direction". If you haven’t been following Microsoft’s work in the API space due to their lack of cross platform support or missing cloud offerings, it might be worth your while to take another look.