Deconstructing IIS to Explain Azure Service Fabric and Microservices

Evolution of ASFThe recent announcement of Azure Service Fabric Preview has become an increasingly favourite topic of discussion across the board .  Not only amongst developers who stand to benefit most directly but also amongst those focused on infrastructure, business delivery, and operations.  To these groups the concepts may not come so readily as they are abstracted from BAU.  I certainly fell into this category. By deconstructing something traditional and familiar I was able to paint a picture that made sense and that could be communicated to a variety of audiences.

Using the attached whiteboard I try to explain in four high level  snippets.  I’ve taken some liberty when describing how IIS works for illustrative purposes.


Point 11.  The Traditional Landscape

The story begins with the three tier web application model.  You normally have a SQL backend, an application, or logic, secondary tier, and a web front end tier manned by IIS – at least in the MSFT world.  It is easy to consider an IIS server as a single entity.  After all it’s just a server that serves web pages, right?

Well, yes and no.

2.  The Anatomy of IIS

Traditionally when we expected traffic to increase we needed to build up the various tiers of our solution which meant adding additional servers – physical or virtual – to the relevant tier.  In this example the tier that needs to be expanded is commonly known as the Web Front End tier which is the entry point for any client trying to access* for example.Point 2

As it turns out an IIS server often performs multiple functions.  For example when you install IIS you have the options to also include services such as SMTP (for sending and receiving email), MSMQ (for managing messages a queues between tiers of a given solution), .NET, or a multitude of other platforms) and the like.  So, you see, an IIS server is often times does much more than serve up web pages.

3.  The Scalability Challenge

So now we have a server that in reality is running a number of supporting services.  During times of increased traffic we might choose to light up additional IIS servers.  Whether those servers are physical or virtual the problem is the same:  management.  Patching, avoiding so-called configuration drift, accommodating continuous integration and deployments, maintaining security, etc.Point 3

In the case of a high fidelity solution it may be that the web service itself isn’t the bottleneck.  Maybe we need to scale out one of the supporting services like MSMQ or the .NET logic tier.

Either way we’re deploying additional servers.  Some times just to handle these small but critical additional services.

4.  The Azure Service Fabric and the Microservice paradigm

Depending on who you ask the Azure fabric can mean many things. It’s the control plane.  It’s the data plane.  It’s the ‘brain’ of the Azure platform.  For me it’s all of the above.  And it’s powerful.

The Azure Service Fabric erodes the physical and virtual machine footprint for solutions built cloud-first from the ground up.  These services can now be deployed in a roaming, ‘head-less’ state throughout the world.  A developer can ‘hook’ into the fabric, access the service of her or his choice, and operations doesn’t have to be concerned with yesterday’s problems; not all of them any way.  Better yet these services when used optimally can be self-healing and self-spawning.

Point 4

When correctly designed and architected your PaaS based, Service Fabric integrated solution should match or exceed the general SLA of Azure at 99.95% at a fraction of the cost of traditional H/A deployments.