Under the HOOD of the NEW AZURE PORTAL

http://jbeckwith.com/2014/09/20/how-the-azure-portal-works/

So-i Haven ' t been doing much blogging or speaking on WebMatrix or node recently. For the last year and a half, I ' ve been part of the team that ' s building the new Azure Portal-and It's been quite an exp Erience. A lot have been said about the end to end experience, theintegration of Visual Studio Online, and even some of the new serv Ices that has been released lately. All of the that's awesome, but it's not the what I want to talk about today. As much as those things is great (and I-mean, who doesn ' t like the design), the real interesting piece is the underlying Architecture. Let's take a look under the hood of the new Azure portal.

A LITTLE History

To understand how the new portal works, your need to know a little on the current management portal. When the current portal is started, there were only a handful of services in Azure. Off of the top of my head, I think they were:

• Cloud Services
• Web Sites
• Storage
• Cache
• Cdn

Out of the gate-this is pretty easy to manage. Most of those teams were all in the same organization at Microsoft, so coordinating releases was feasible. The portal team is a single group that is responsible for delivering the majority of the UI. There is little need to hand off responsibility to the individual experiences to the teams which wrote the services, as I T is easier to keep everything in house. There is a single ASP application, which contains all of the CSS, JavaScript, and shared widgets used throughout T He app.

The team shipped every 3 weeks, tightly coordinating the schedule with each service team. It works ... pretty much as one would expect a Web application to work.

And then everything went crazy.

As we started ramping up the number of services in Azure, it became infeasible for one team to write all of the UI. The teams which owned the service were now responsible (mostly) for writing their own UI, inside of the portal source repo Sitory. This had the benefit of allowing individual teams to control their own destiny. However-it now mean, we had hundreds of developers all writing code in the same repository. A change made to the SQL Server management experience could break the Azure Web Sites experience. A-change-to-a CSS file by a developer working on virtual machines could breaks the experience in storage. Coordinating the 3 week ship schedule became really hard. The team was tracking dependencies across multiple organizations, the underlying REST APIs that powered the experiences, a nd the release cadence of ~40 teams across the company, that were delivering cloud services.

SCALING to∞services

Given the difficulties of the engineering and ship processes with the current portal, scaling to different services di DN ' t seem like a great idea with the current infrastructure. The next time around, we took a different approach.

The new portal is designed a operating system. It provides a set of UI widgets, a navigation framework, data management APIs, and other various services one would expect To find with the any UI framework. The portal team is a responsible for building the operating system (or the shell, as we do), and for the overal L Health of the portal.

Sandboxing in the BROWSER

To claim we "re an OS, we had to build a sandboxing model. One badly behaving application shouldn ' t has the ability to bring down the whole OS. In addition to That-an application shouldn ' t is able to grab data from another, unless by an approved mechanism. JavaScript by default doesn ' t really lend itself well to this kind of isolation-most Web developers is used to picking Up something like JQuery, and directly working against the DOM. This wasn ' t going to work if we wanted to protect the OS against badly behaving (or even malicious) code.

To get the around this, each new service in Azure builds "What we call an ' extension '. It ' s pretty much an application to our operating system. It runs in isolation, inside of an IFRAME. When the portal loads, we inject some bootstrapping scripts to each IFRAME at runtime. Those scripts provide the structured API extensions use-communicate with the shell. This API includes things like:

• Defining parts, blades, and commands
• Customizing the UI of Parts
• Binding data into UI elements
• Sending notifications

The most important aspect is, the extension developer doesn ' t get to run arbitrary JavaScript in the Portal ' s window. They can only run the script in their Iframe-which does not project UI. If an extension starts to Fault-we can shut it down before it damages the broader system. We spent some time looking into web workers-but found some reliability problems when using > all them at the same t Ime. We ' ll probably end up back there at some point.

Distributed Continuous DEPLOYMENT

In the this model, each extension is essentially it ' s own Web application. Each service hosts their own extension, which are pulled into the shell at runtime. The various UI services of Azure aren ' t composed until they is loaded in the browser. This lets us do some really cool stuff. At no given point, a separate experience in the portal (for example, Azure Websites) can choose-Deploy an extension th At affects only their ui-completely independent of the rest of the portal.

IFRAMEs is not used to render the Ui-that's all-done in the core frame. The IFRAME is a used to automate the JavaScript APIs, which communicate over Window.postmessage ().

This architecture allows us to scale to∞deployments in a given day. If The Media Services team wants a new feature on a Tuesday, but the storage team isn ' t ready with updates the Y ' re planning-that ' s fine. They can each deploy their own changes as needed, without affecting the rest of the portal.

STUFF WE ' RE USING

Once you start poking around, you'll notice the portal is big single page application. That's came with a lot of challenges-here is some of the technologies we ' re using to solve them.

TYPESCRIPT

Like any single page app, the portal runs a lot of JavaScript. We have a ton of APIs which run internal to the shell, and APIs that is exposed for extension authors across Microsoft. To enormous codebase, and the many teams using our SDK to build portal experiences, we chose to use TypeScript .

• TypeScript compiles into JavaScript. There ' s no runtime VM, or plug-ins required.
• The tooling is awesome. Visual Studio gives us (and partner teams) IntelliSense and compile time validation.
• generating interfaces for partners are really easy. We distribute d.ts files which partners use to program against our APIs.
• there ' s great integration for using AMD module loading. This is critical to us for productivity and performance reasons. (More on the another post).
• JavaScript is valid typescript-so the learning curve isn ' t-high. The syntax is also largely forward looking to ES6, so we ' re actually getting a jump on some new concepts.

Less

Visually, there ' s a lot going on inside of the portal. To help organize our CSS, and promote usability, we ' ve adopted {less}. Less does a couple of cool things for us:

• We can create variables for colors. We have a pre-defined color palette-less makes it easy-define those up front, and re-use the same colors throughout O ur style sheets.
• The tooling is awesome. Similar to TypeScript, Visual Studio had great less support with full IntelliSense and validation.
• It made theming easier.

KNOCKOUT

With the new design, we were really going for a ' live tile ' feel. As new websites is added, or new log entries is available, we wanted to make sure it is easy for developers to update t Hat information. Given that goal, along and the quirks of our design (extension authors can ' t write JavaScript this runs in the main windo W),  knockout turned out to be a fine choice. There is a few reasons we love Knockout:

• Automatic refreshing of the UI-the data binding aspect of Knockout is pretty incredible. We make changes to underlying model objects in TypeScript, and the UI are updated for us.
• The tooling is great. This was starting to be a recurring theme:) Visual Studio has some great tooling for Knockout data binding expressions (Thanks Mads).
• The binding syntax is pure -We ' re not stuck putting invalid HTML in our code to support the specifics of the bin Ding Library. Everything is driven off of data-* attributes.

I ' m sure there is reasons our dev team could come up with on why we love Knockout. Especially the ineffable Steve Sanderson, who joined our dev team to work on the project. He even gave an awesome talk on the subject at NDC:

Steve sanderson-architecting Large single Page applications with knockout.js from NDC conferences on Vimeo.

What ' S NEXT

I ' m really excited about the future of the portal. Since our first release at//build, we ' ve been working on new features, and responding to a lot of the customer feedback. Either way-we really want to know what do you think.

Under the HOOD of the NEW AZURE PORTAL