TechBash 2018: The blazor and serverless microservices party

Part of being a team of Deep Technologists means keeping up with and having an opinion on new and emerging trends. As a Microsoft MVP, I do a lot of public speaking on new topics where I get to share knowledge on these new techniques. Recently, I spoke at TechBash in Pennsylvania alongside industry leaders from Microsoft and others on Blazor and Serverless Microservices. Each of these topics is something that we at West Monroe see as important as the landscape of technology continues to evolve.

Blazor: The WebAssembly SPA Framework

One of the problems with developing web applications is the lack of choice in terms of languages; realistically only JavaScript can be used to support the vast majority of consumer applications. This lack of choice has forced developers into using JavaScript for a large variety of tasks that it is ill suited for: photo editing, VR, and high res games.

WebAssembly is a new runtime being added to browsers that makes the web just another platform that can be compiled to and thus allows developers to use other languages besides JavaScript. As you can imagine, this opens up enormous possibilities and, to that end, WebAssembly has gained massive amounts of support with version 1.0 being available in every major browser (mobile and desktop)

Blazor is a new product offering being researched by Microsoft which enables developers to build client side web applications in C# with no plugins or extensions, it runs on top of WebAssembly. The idea of being able to legitimately, and without external plugins or extensions, use C# for client side applications has me, and many others, very excited. Blazor still has a ways to go both in terms of maturation and becoming a fully supported Microsoft product but, the potential is there.

At West Monroe, we see WebAssembly (and Blazor) as a new option when working with clients to build solutions to problems. We know from experience that a one size fits all mentality (as has been the case with JavaScript) is not efficient and creates unnecessary work. We look forward to supporting Blazor and using it to build client applications once it is ready and is officially supported by Microsoft.

Until then, we will continue to watch and learn. One thing we know for sure is the potential of WebAssembly is massive and could lead to a huge change in the way we approach building web applications.

Building Serverless Microservices with Azure

The Microservice design pattern has gained a tremendous amount of traction over the last few years and has demonstrated the ability to bring real value to organizations. It does this by enabling business units to be more distributed and better aligned with emerging cloud technology. This approach also enables the more effective distribution of complexity for an application with it being spread out among the various services. In fact, Martin Fowler describes this nicely with the following graph:

As you can see, the Monolith (single package for all code) does enable teams to be more productive at the onset of a project but quickly falls off as complexity increases. The most notable case of this transition is Netflix who, due to immense growth and demand, moved from a monolithic approach to a Microservice architecture that contains over 700 Microservices.

As you get into these larger Microservice deployments, operational complexity tends to increase as the size and scope of the system. In many cases, teams turn an Orchestration framework such as Kubernetes to mitigate this increase in operational complexity. The drawback is, Kubernetes requires teams to learn its supporting ecosystem and tools, both of which bring their own new set of challenges. The use of Serverless PaaS components as an alternative to Orchestration is an emerging pattern within industry. It has many benefits and can be a quicker approach for some teams. But it comes with vendor lock in (in most cases) plus a few implementation caveats:

• Execution of code is limited to a fixed window. Exceeding this window will cause code to be abruptly terminated. The size of the window is around 5 minutes for most providers.
• Serverless functions run on managed infrastructure and adhere to a consumption model for pricing. That being the case, Cloud Providers will spin functions down after a certain period being idle. The time to spin the functions back up is noticeable if a new request come in.
• Due to running on managed infrastructure the ceiling for scaling is limited based on the provider. For example, Microsoft Azure will only permit up to 200 instances of a single function to be running.

The advantage to using Serverless is the lack of management and configuration for the services as they will automatically scale based on usage. Plus, they are inherently reliable due to their running on managed infrastructure. Finally, modern cloud backends (AWS, Azure, GCP) raise events as part of their normal operation. By allowing custom code to listen and execute based on these events, teams can create robust backends that require less code and still scale with the platform.

Kubernetes does allow the creation of Serverless functions via the Kubeless project and the Cloud Native Compute Foundation (CNCF) is working on a proposal to standard events across Cloud Providers called Cloud Events. This is a clear indication that Serverless will continue to be important for future application development and could eventually be abstracted away from providers.

At West Monroe, we see Serverless as another way to build a microservice based backend that builds on top of a specific cloud vendor and avoids the maturing Cloud Native ecosystem, a good option for clients who are sure they want to stick with a particular cloud vendor and/or those that are unsure of the loads the final system will experience. If you’re interested in learning more contact us.