 Hi, I'm Varshala Purva Manager on the Azure Service Fabric team. In this video, I'm going to talk about microservices and how you can benefit from Azure Service Fabric, our microservices platform. As for the agenda, first we'll look at why microservices architectures are gaining so much momentum and popularity in the IT industry. We will start by comparing a traditional monolith architecture with a microservices architecture. This, after the comparison, should be quite obvious why microservices are gaining so much momentum. We'll wrap up the microservices section by looking at some characteristics of a microservice. We then spend the second half of this little session looking into service fabric and why service fabric is such a great platform for building microservices-based applications. I will wrap up this little video by talking about a real-life customer scenario, blink box from talk-talk. So, let's look at the monolith traditional application first. The big square with the red, yellow and green squares represents a monolith application where we can think of each little square as a component or functionality. So for example, the red square could be a shopping cart and the yellow square could be a product catalog. Usually, they run within a single process and in order to scale them out, we would put them on multiple servers. The components also share one state or data store where they write to. As we can see, if we wanted to update parts of the application, we would need to wrap all of it, which means lots of integration testing, sophisticated deployments and so on and so forth. So the work here is not in the development itself, it's really more in the operational aspects. Now, on the other hand, if we look at the microservice application, we break it down into smaller pieces. Each bigger square still represents an application, but this time the application is more like a logical construct rather than a big monolith application. So it basically just contains those services. The application then consists of independent microservices and when we deploy and scale the application, the individual services get distributed within a set of machines, which we call a cluster in the service fabric world. Now, every single service is independently deployable, scalable and updatable. This is what makes microservices such an appealing architectural approach to the industry. So besides what I mentioned, why are microservices so popular? Well, first it allows us to build and especially operated services at scale. As we can manage services independently, we can easily scale them out based on the resources they need. This also offers better resource utilization and in turn you have a better cost optimization. We can run many of those services on a box until we have the optimized resource utilization. Another big advantage is the fault isolation of microservices. For example, assume there's a service that implements a shopping cart and one that implements a product catalog. Now, if one of those services encounters an issue, the other one is not impacted at all even if they run on the same box. As they are independent and usually and usually encapsulate business capabilities, teams can also react very quickly to new market or customer requirements. The service can be updated and shipped by a small focus team that implemented it without impacting the other teams. And finally, microservices offer language and platform freedom so you can choose the best language for the job. So for example, you can use .NET for your compute logic and Node.js or JavaScript for your front-end logic services. With that in mind, how would we define a microservice? Well, there is no real definition of a microservice but leading industry experts generally agree on the following. A microservice is an autonomous independent service that encapsulates a business scenario or is centered around the business scenario. It contains the code and state. So what does that mean? Usually a microservice even contain its own data store. That makes it truly independently versionable, deployable and scalable. A microservice is loosely coupled and interacts with other microservices through well-defined interfaces using protocols like HTTP. They remain consistent and available in the presence of failure, meaning even if the machine goes down that hosts a microservice, the functionality provided by the service should still be offered by the application. As one can imagine, while microservices are great, there's quite some work involved to build a scalable microservices application on a platform as you need to consider things like cluster management, service orchestration, inter-service communication and so on. And obviously you also need to put a lot of efforts in a very good DevOps practice. So now we've seen there's quite some work involved in making microservices applications work. So what is actually Azure Service Fabric? Azure Service Fabric is our reliable hyperscale microservices platform that solves all those hard problems for you and lets you focus on the development of microservices. Even though it is branded as Azure Service Fabric, you can run it anywhere. Obviously we offer an Azure service that allows you to spin off Service Fabric clusters using Azure Resource Manager templates, but you can also run Service Fabric on premises or in any other cloud. From a functional perspective, Service Fabric offers everything you need to run and scale microservices based applications out of the box. There is no need for additional configuration or tooling, such as service registry or service discovery tools. Microservices in Service Fabric are highly available out of the box. As Service Fabric offers a rich replication and failure over mechanisms. It also offers container orchestration and lifecycle management. And by containers, we mean like an encapsulated set of code and state. Also in the future, we will support like Docker containers and Windows containers as well as Hyper-V containers. It also supports like a service discovery because it's already built in. So there is no, as I mentioned before, there is no additional need for a tool. Service Fabric, thinking about like the DevOps perspective, it's really important to roll out upgrades. And if the upgrade doesn't go through to auto roll back or to have a no downtime upgrade. So let's say you want to roll out a new version of a service. Service Fabric offers that. And then key to a microservices platform is really a wealthy health monitoring and diagnostics system. Service Fabric comes with a very, very sophisticated health monitoring system that not only monitors your clusters or your nodes in your cluster, but also the services. It also offers self-healing. So for example, if a service goes down on one note, Service Fabric will spin up an instance of that service on another note. In addition to all of that, you may have the need that let's say you have a microservice that just offers a light API gateway or front end. So you don't want to place those services on very beefy machines. Service Fabric offers a way to use placement constraints that allow you to place certain workloads on certain machines, which is really great. Service Fabric has been used internally for a while, but we've also seen rapid adoption with external customers through our private preview program. Customer examples for building microservices-based applications on Service Fabric start from IOT, typical IOT scenarios, over content encoding, stream analytics, all the way to e-learning and online trading solutions. So with that in mind, what types of microservices can you build on Service Fabric? Service Fabric, we differentiate between two types. There is the traditional state less type and the new state full type. The stateless type is really like what you're known to when you write like cloud applications today. So you try to keep the state outside the service or the service itself. So the state is probably stored in a cache, it might be stored in a database and so on and so forth. So goal of a stateless service is that you can basically scale out and no state is impacted. We also offer what we call a stateful service. And as we have learned before, a microservice should not only contain the code, but it also should contain its state. And microservices on Service Fabric are really the only services right now that offer you stateful services. That not only offers advantages in management, but also in performance. Because if you think about a very large hyperscale applications, what you're trying to do here is to keep the state close to compute. And that's what our stateful services do. So with that, having explained what Service Fabric is, let's have a look at one of our launch customers. BlinkBox is the UK's leading video and demand service of the latest TV and movie content. It is available across Mac, PC, game consoles, tablet computers, and even smart TVs. Just to give you an idea about their content size, we're talking about 1.5 petabytes of content for streaming hosted on Azure. They offer a catalog of 30,000 items all delivered to millions of customers on multiple devices using Azure Media Services. Their current content platform runs as a service on IS virtual machines and the state is stored in a database. They have discovered that this type of architecture is not suitable anymore to quickly react to new business requirements. In addition, they had pain points with distributed programming edge cases, service management, data logs, and coordination across services via the database. So they decided to rebuild their content management platform on Service Fabric. The diagram shows the architecture in Service Fabric. So let's talk about it a high-level workflow. Let's say they want to encode the new James Bond film spectrum. A BlinkBox client or service will call the encode request which is exposed on the activity API controller. This is hosted using an OIN communication listener in Service Fabric. The activity stateful service will receive the encoding request on a reliable queue and will create a James Bond activity actor. The James Bond activity actor will create the activity step actors. This includes transcoding it into various formats. So it plays on Xbox, PlayStation, and others using Azure Media Services. Since it's an important movie, they also need to protect it, which is done using Azure Batch. The activity actor coordinates these activity step actors and ensures they execute in the right order. A simple graph is implemented on top-of-the-net collections to do this. Each of those activity step actors then communicate with the other white boxes. For example, the Azure Media Service job management application. This is another Service Fabric service which encapsulates all the required API calls to Azure Media Services and stores some state and actors. The Encryption Job Management app is another Service Fabric service that contains all the logic and reverence to the Azure Batch SDK assemblies so that they can protect this new James Bond movie using an encryption format. Once all the activity steps are completed, they notify the activity actor which then sends a notification pack to the original client. This is also a great example of how Azure Service Fabric is used with other Azure services. BlinkBox has really seen the following benefits of using Service Fabric. The programming model, using actors in reliable collections, orchestrating coding and resource resolution of all on-demand content. This avoids deadlock queue type issues that they had before. Service Fabric provides a simple array of orchestrating a process and handling failures. Stateful microservices also enable them to remove the database and target data stores for query requirements. So effectively, they reduce the layer in the architecture. And very important for microservices architecture, the ability to upgrade independently without downtime. So with that, I'm at the end of this little video. I hope you enjoyed watching it. So there is a bunch of related content I wanna point you to. So first of all, I would encourage you to download the Service Fabric SDK on aka.msServiceFabric. You can also find a huge amount of documentation on aka.msServiceFabric docs and even like working samples on github.com slash azure slash service fabric samples. Thanks for watching.