Preface

Let’s take a drive down the memory lane. Imagine it is the 90’s, and you have been asked to build an application for an enterprise. You go to an IT shop and procure a server (or ask someone to do it for you), after several days or weeks the server shows up. Next, you configure the server, the network and the many settings it has. Finally, you deploy your application on the server and turn on the lights, and everyone is happy.  

Business requirements change and now your customer needs some changes to be made to the application. So you go back make the changes, take the now upgraded application package and dump it on the server. You shut down the machine and bring it back up to bring up your refreshed application. You make compromises with downtime but are happy with the convenience of bundling everything into a single package and pushing it to the server.

So, in this early period, the agility of hardware limited the agility of software. It wasn’t easy to scale infrastructure and therefore altering the systems at the snap of fingers wasn’t a possibility. Moreover, during those times internet applications were more of a value addition than a necessity. Thus, traditional hardware agility supported monolithic architecture, which requires building applications as one big bundle of tightly coupled services.

Fast forward a couple of years and the advent of cloud changed the game. With the cloud, infrastructure has become easy to provision on-demand, and it also eliminates any waste of developer time that traditionally went into preparing the servers to host applications. Today software is a differentiator and not a value addition for any enterprise. Owing to the competition, high frequency of change, and continually changing customer requirements require decoupling an application to make it easy to scale, test and deploy.

The advent of cloud and the need for applications to be decoupled into smaller components that fulfill a single responsibility (Single Responsibility Principle) for the ease of development, deployment, and scale lead to the rise of the Microservice architecture.

However, breaking down a monolith into small independent services comes with the overhead of management of these services. This need of managing the Microservices gave birth to Azure Service Fabric which apart from its many services acts as a cluster manager. Azure Service Fabric Cluster Manager governs a set of virtual machines and handles Microservice deployment, placement, and failover. Azure Service Fabric also governs the application model and has capabilities to drive Application Lifecycle Management (ALM).

Microsoft itself has used Service Fabric for many years to host its planet-scale services such as Azure SQL Database, Azure IoT hub, Skype for Business, Cortana, and Intune.

This book introduces its readers to the concept of Microservices and Microsoft Azure Service Fabric as a distributed platform to host enterprise-grade Microservices. Learning the concepts of technology is often not sufficient. In practical scenarios, developers and architects often search for guidance on some of the most common design challenges. This book addresses common architectural challenges associated with the Microservice architecture, using proven architectural patterns.