This is the first in a series of posts about Exploring Azure Service Fabric. My goal here is to give you an idea of why you may want to use Service Fabric, provide an overview of the service itself, and demo a few deployment options. Below is a list of posts that I plan to include in this series so stay tuned if you find this of any interest..
In this first part of the series I wanted to talk about some of the driving factors for using something like Service Fabric. If you are reading this you probably are already familiar with the term microservices. If not, Wikipedia defines the term like so. “Microservices is a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task, facilitating a modular approach to system-building.”
Over the last few years microservices have emerged to replace the traditional tiered architectures and monolithic applications that are tightly coupled. So why is this? Think back to the days when you needed to update your application with a new feature, or worse, you hit the boundaries of your application and needed to scale up or out. It was no easy task and it caused updates and fixes to build up until a new version of the application was released. As a business, if you weren’t able to evolve your application to better suit your end users, then it slowly faded away as people stopped using it. With today’s technologies, when we talk about building applications, you need to consider the scope. Most conversations lead to the cloud in some form or fashion so we need to ensure that the applications are designed for scale and capacity. With scale and capacity being unpredictable, the cloud becomes an ideal platform for running our applications. If you need to scale it becomes much easier, provided that your application has been designed as a collection of fine-grained autonomous services that have their own lifecycles and collaborate together. This allows you to get feature updates and enhancements to your customers at a much faster pace all while continuing to improve your application based on customer feedback. This is what is known as the lean startup model wherein you start with an idea, build (code), measure (data), and learn (pivot if needed). This in turn creates more reliable releases. Does any of this sound somewhat like the concept of DevOps? Sure it does, after all our goal is to accelerate the flow of work through dev, test, and IT Ops in a way that speeds application delivery and increases efficiencies.
With that said, it isn’t as simple as flipping a switch and you go from a monolithic app design to a microservices app design. In some cases you may need to start with a monolithic approach and slowly move towards a microservices design. This sort of approach would allow you to slowly decompose the app starting with lower tier services that need to be more scalable, all while moving towards a microservices approach. Additional benefits of microservices include language-agnostic, interaction with other microservices, resilient to failures, and self-healing services. The end goal of a microservices approach is to compose your application into smaller, autonomous services running in containers across a cluster of machines. This allows smaller teams to focus on a service that is independently tested, deployed, scaled, and upgraded. Can you start to see how all of this fits together, the DevOps culture, the lean startup model, and microservices.
Microsoft was used to delivering applications in a monlithic form but soon realized they needed a way to deploy large scale services like Azure SQL databases, DocumentDB, along with other core services, that allowed for independent team development, was scalable and reliable, with low latency. This is where Service Fabric comes in. Essentially it is a platform for running microservices. We will get into more of its capabilities in a part 2 of this series.
An important concept that I want to cover, before we move on, is without a framework of principles and practices to guide your design, it will be quite difficult to deliver and maintain a microservices environment. You and your teams will want to review these and put together a framework covering these principles. Doing so will help you achieve success.
- Strategic Goals: high-level goals defining where the company is going so the technology is aligned to best suit the customer (ie. expand into European and Asian markets)
- Principles: rules defined that align with what you are doing from a strategic goal. Keep it small – no more than 10 so they can be remembered (ie. allow for portability)
- Practices: how to ensure the principles are carried out. Detailed guidance for performing tasks (ie coding and design guidelines)
Note: For smaller teams you may end up combining principles and practices.
Being able to articulate this in the form of a chart to summarize these concepts will be most useful and readable. This could be something as simple as the below diagram.
For additional information on this topic check out the book “Building Microservices” by Sam Newman.
Stay tuned for the next post in this series where we will dig deeper into an overview of Service Fabric and its features.