Image

DarylsCorner

Cloud Computing in Today's World

Category Archives: Azure

Azure Container Service and Docker Swarm

/ / Leave a comment

Today I wanted to talk about Azure Container Service, aka ACS. ACS went into Genearal Availability back in April of 2016. So what is ACS you ask? ACS is a service in Azure that allows you to create, configure, and manage a cluster of virtual machines that are preconfigured to run containerized applications. Microsoft is taking a bit of the hard work on for you in setting up a cluster to support containers. You could surely deploy a set of virtual machines on your own and install the docker engine and create a cluster. But why go through the hassle when you can let the Container Service handle it all while taking advantage of the enterprise features in Azure. With ACS, you select the size, the number of hosts, and choice of orchestrator tools, and Container Service does its magic. You can continue to use the tools you are familiar with and use the orchestrator of your choice. Azure Container Service leverages the Docker container format to ensure that your application containers are fully portable. Container Service offers you a choice of using DC/OS or Docker Swarm for scale and orchestration operations. Simply put, Azure Container Service is a container hosting environment that utilizes open source tools. With all the momentum around containers these days, ACS is a service that will allow you to start testing containers in a matter of minutes.

Getting Started

Some people may argue that they are not ready to start testing with containers. Maybe they think having a monolithic application excludes them from using containers. Well, thats the good thing about containers, you can do a lift-and-shift of a monolithic app into a container if desired. There are several advantages to moving to containers, such as fast deployment, scalability, portability and avoiding vendor lock-in. Based on a state of the app development survey done in early 2016, 80% of respondents felt that Docker would be central to cloud strategy with 3 out of 4 stating their top initiatives would revolve around modernizing legacy apps and moving to a microservices architecture. Some will argue that microservices has been around for a long time and debate how containers would help. Yes, microservices have been around for a while but what Docker and containers does is to allow it to be faster, more streamlined, and offers better collaboration across the dev and ops teams. Its all about Build, Ship, Run, any app, on any stack, anywhere. Are you starting to see the value of containers now?

Installation

Lets begin by deploying an ACS cluster using Docker Swarm as the orchestrator. Since this is our first introduction to ACS I will demonstrate how this is done in the portal. However, you can deploy a cluster using ARM templates which you can find in the GitHub repo for azure-quickstart-templates.

Login to the Azure Portal, click +New, type “azure container service” and select.

ACS

Select Azure Container Service and click Create.

Search

Note: You are going to need an SSH Public Key that will be used for authentication against the ACS VMs. It is important for the key to include a prefix of ‘ssh-rsa’ and a suffix of ‘username@acsdemo’. You can accomplish this by using PuttyGen to create a public and private key.

Open PuttyGen and click Generate. In order to create randomness move your cursor around the blank space while the key is being generated. Save the public and private key to a local folder. Optionally you can create a password to protect the private key. You can leave PuttyGen open as you will need the key in the next step.

PuttyGen

On the Basics blade fill in the appropriate info including the SSH public key you just generated making sure to add the suffix of ‘username@linuxvm’ and click OK. In my example I used ‘daryl@acsdemo55’.

basics blade

 On the Framework Configuration blade select your choice of orchestrator to use when managing the applications on the cluster. Here you have two options to choose from, DC/OS or Swarm. We will choose Swarm in this demo. So what is Docker Swarm you ask? Swarm is a simple tool which controls a cluster of Docker hosts and exposes it as a single virtual host. Since Swarm uses the standard Docker API, you can use any tool that understands Docker commands. In addition, Swarm follows the “batteries included but removable” principle meaning that its extensible with other 3rd party plugins.

Framework configuration blade

On the Azure Container Service Settings blade select the number of agents and masters, the size of the agent VMs, and a unique DNS name prefix. The agent count will be the initial number of VMs in the VM scale set and will be members of the swarm cluster that you will create.

Azure container service settings blade

On the Summary blade, ensure validation has passed. At this point you can download the template that will be used for the deployment. If you wanted to customize the deployment, you could cancel this deployment, edit the json template and then deploy the template. In our demo we will continue with the default. Click OK to continue and click on Purchase to agree to the terms.

Summary blade

At this point the container service is being deployed as per your configuration. You can see this pinned on the dashboard.

dashboard

Once the deployment has completed, mine took around 10 minutes, you will get a notification on the dashboard that the deployment was successful. In addition, you can click on the resource group and the Last deployment should say Succeeded.

Resource Group blade

Now that the deployment has completed, let’s see what we have from a resource standpoint. Here you can see that we have two load balancers, one for the swarm agent and another for the swarm master. In addition, we have an availability set that includes the three masters (spread across 3 fault domains and 5 update domains) and a VM scale set that includes the three agents. All of which makes up the container service.

Swarm resources

Here we have the virtual network along with the public IP for the LBs, and the associated nics for each master server.

Swarm resources 2

And finally the storage accounts. You may be wondering why are there so many. The storage account ending in …swarmdiag0 is for the diagnostic logs. The storage account ‘ye4r6pe25gdmsswarm0’ includes the 3 OS disks for the masters. The remaining 5 storage accounts are for the OS disks of the agents. Since the VMSS is limited to 100 VMs with the recommendation of 20 VMs per storage account, this gives us 5 storage accounts. Since we only have 3 agents you will notice that 2 of the storage accounts are empty. However, when you scale the VMSS, the VMs will be distributed across all 5 storage accounts. This will also help to avoid IO contention since standard storage accounts are limited to 20,000 IOPS.

Storage accounts

Now that we have the container service deployed and understand what our resources are, let’s see what this looks like from an architectural standpoint. Here you can see that by default there are 3 NAT rules configured with port 22 load-balanced for the swarm master. In addition, application traffic is being load-balanced for the swarm agents.

swarm architecture

Image courtesy of Microsoft

Connecting to ACS Cluster

To connect to the cluster we will create an SSH tunnel with Putty on Windows. If you don’t already have Putty downloaded to your system, you can find it from the link mentioned above. The reason for creating a tunnel is to have encrypted communications between my localhost and the ACS cluster (specifically the swarm master).

First, we need to locate the public DNS name of load-balanced masters by opening the Resource Group and clicking on the swarm master IP resource. Copy the DNS name.

swarm master IP

Open Putty and enter a host name that is comprised of the cluster admin user name and the public DNS name of the master (daryl@acsdemo55mgmt.westus.cloudapp.azure.com). Enter 2200 for the port. Select SSH and Auth and Browse for the private key we created earlier. Next, select Tunnel and enter 2375 for the Source Port and localhost:2375 for the Destination and click Add. Optionally you can give the session a name and Save it for later use. Click Open when you are ready to connect. Click Yes to accept the connection.

putty configuartion

We can confirm our connection by reviewing the Putty event log. Now we are ready to start using Docker.

Putty event log

Managing Containers with Docker Swarm

Now that we are connected to the master, let’s verify that we have two containers running on each of the masters by typing “docker ps”. The containers present are “swarm” and progrium/consul” which are used to create and manage the cluster.

master containers

Now lets check to see if we have a swarm cluster. Type “docker node ls” to view the nodes that are participating in the cluster. The response shows us that the node is not a swarm manager. To create the swarm cluster we type “docker swarm init” on the master. The response shows the node is now acting as a manager.

docker swarm init

If we have more than one master, which in most cases we would, we will need to join the other members to the cluster. You can type “docker swarm join-token manager” to get the command for joining another node as a manager to the swarm.

docker swarm join-token manager

Now we need to login to the other two masters and run this command. Following the same approach as connecting to the first master but changing the port to 2201 and 2202 respectively.

swarm join node 1

swarm join node 2

Once all the master have been joined to the swarm we will connect back to the first master and type “docker node ls” which will show all the masters that have joined the swarm as a manager. Notice the one marked with Leader.

Note: An important concept to understand is that this is not where you will run your application containers. Those will run on the agents.

docker node ls

(Optional) If we needed to remove a master we can do so by logging into that master and type “docker node demote <name>” then “docker swarm leave”. Then log back into the leader and type “docker node ls” shows that the master is in a down status. Now we can remove it by typing “docker node rm swarm-master-xxxxx-x”. Typing “docker node ls” will show the master has been removed.

remove docker node

(Optional) To add a master back into the swarm, we just log into that master and type the “docker swarm join <token> host:port” command that we discovered earlier.

docker swarm join node 1

After logging back into the leader again, we can also see the details of each master by typing “docker node inspect <ID>”.

docker inspect

Now that we have our swarm cluster. Let’s review the agent nodes and their status. Type “docker -H tcp://localhost:2375 info” which shows the swarm agents and their details.

swarm agent info

Now we need to export the the DOCKER_HOST variable to ensure that our application container will start against the agent endpoint and not on the local swarm master. Type “export DOCKER_HOST=tcp://172.16.0.6:2375” which can be found from the previous output listed as Primary. Now when we type “docker ps” we don’t see any containers.

export docker_host

Now we can create a container by typing “docker run -d -p 80:80 dubuqingfeng/docker-web-game” and verify that its running. If this image is not available you can swap it with another.

pull container

To verify that we can access our container we need to locate the DNS name of the swarm agent load-balancer. We can find this by selecting the swarm-agent IP resource and copy the DNS name.

swarm agent DNS

Open your favorite browser, paste, and voila. We have games. Translate the page if you like and select Get Started and you can play Mario Brothers.

games

Summary

Azure Container Service really helps to get containers up and running and allows you to use either Swarm or DC/OS as the orchestrator. In this blog post I showed you how to stand up ACS, how to connect to it, and then how to deploy a Swarm cluster with a simple container running on it. I hope that you have enjoyed this post and feel a little more comfortable with Azure Container Service and Docker Swarm. Stay tuned for more on Docker.

 

If You Build It, They Will Come

/ / Leave a comment

Have you seen the movie ‘Field of Dreams’ starring Kevin Costner? There was a saying in this movie that reminds me of how Microsoft and Amazon are expanding their datacenters at such a rapid pace. This brings me to today’s topic, ‘If You Build it, They Will Come’.

Today I wanted to spend a little time discussing Azure and AWS datacenter locations. I think we would all agree that there are two major players in the public cloud arena, AWS and Azure. Being in a consultant role we are constantly asked by customers which public cloud provider they should use. This brings up a much deeper conversation that I am not going to get into in this post. However, for simplistic sake, let’s just say they both have similar service offerings with each having their strengths. With that said, many times customers are looking for in-region support. This could be due to regulations and/or restrictions imposed. Now, the answer to their questions starts to become a little easier. Both AWS and Azure are constantly planning and building new datacenters so I thought it would be good to give an update on the actual datacenters that are in GA today as well as the planned datacenters.

Azure

Microsoft is continuously investing in the latest infrastructure technologies, with a focus on high reliability, operational excellence, cost-effectiveness, and environmental sustainability. This is apparent from the early days of the Gen1 datacenters to the newer Gen4 datacenters. Have you ever wondered what it would be like to tour one of these datacenters? Check out this video for a Microsoft Datacenter Tour. Along the way Microsoft has revolutionized the way they build and deploy their pods for the Gen4 datacenters. Check out this video for insights into the ITPAC. It is quite remarkable that technology has come so far to allow this sort of architectural design.

Today, Azure is generally available in 30 regions around the world with the latest additions being Germany Central and Germany Northeast. Microsoft has also announced plans for 6 additional regions which would bring their total count to 36 regions. Each Azure region is paired with another that is several hundred miles apart. For the most part the pairings are easily recognizable with exception of Central US/East US2 and Brazil South/South Central US.

Locations ( Generally Available)

 

For the most up-to-date listing of Azure regions and to verify if a specific service is available in a region, refer to this link. Keep in mind that not all services are available in all regions.

 

AWS

Amazon is continuing its AWS datacenter expansions across the globe as well. Some say its primarily due to the anticipation of new privacy laws and new regulations, some of which haven’t been passed into law just yet. Based on Amazon’s latest earnings report, they don’t seem to be slowing down any. Their AWS service accounted for 56% of the companies profit this past quarter and its Amazon’s most profitable business.

The AWS Cloud operates 35 Availability Zones within 13 geographic Regions around the world, with 12 more Availability Zones and 5 more Regions coming online throughout the next year. The AWS cloud infrastructure is built around regions and availability zones. Regions are physical locations each comprised of two or more availability zones. Availability zones are comprised of one or more datacenters. Some zones may not be available to new customers based on capacity.

Image courtesy of Amazon

Locations

AWS Region Location
US East Northern Virgina
US West Northern California
US West Oregon
AWS GovCloud US
South America Sao Paulo
EU Ireland
EU Frankfurt
Asia Pacific Singapore
Asia Pacific Tokyo
Asia Pacific Sydney
Asia Pacific Seoul
China Beijing
Asia Pacific Mumbai

Newly Announced Regions

AWS Region Location
TBA Ohio
TBA Montreal
TBA UK
TBA Paris
TBA Ningxia

 

For the most up-to-date listing of AWS regions and to verify if a specific service is available in a region, refer to this link.

However you want to read into this, its pretty impressive that both Microsoft and Amazon are able to continuously expand their public cloud offerings to meet customer demand. Whether you are running dev/test or production, wotking with IaaS or PaaS workloads, take advantage of what the public cloud offers.

 

Redeploy a Virtual Machine in Azure to a New Node

/ / Leave a comment

In today’s Azure Nugget I wanted to talk about how to redeploy a virtual machine in Azure to a new node? Recently I was working on a POC for a customer and deployed several VMs. One of the VMs just seemed to be having a hard time as it took quite a while to deploy. Once deployed I tried to connect to the VM using RDP. I received the RDP file and login screen and was able to establish connection but the desktop never came up. I simply had a black screen. I attempted a restart but that didn’t help. Azure has this concept of being able to redeploy a VM (support for Windows or Linux) to a new node so I figured it couldn’t hurt. There are two ways to accomplish this, via the Azure Portal or PowerShell. Let’s take a look at this.

In the Azure Portal, by clicking on a VM and going to its settings you will find a setting called “Redeploy” under the Support + Troubleshooting section. Clicking on “Redeploy” will open the Redeploy Virtual Machine blade. Simply clicking on the Redeploy button will migrate the VM to a new host in Azure. Keep in mind that this will cause the VM to restart and you will lose any data stored in the temp drive, since the temp drive is carved out from the host itself.

During this migration you will see the Status of the VM change from “Running” to “Updating” to “Starting” and finally “Running” again. This only took a few minutes to complete. Once it was done I was able to connect to the VM using RDP with no issues. Microsoft is trying to provide us with as many tools as necessary to avoid having to open a Support Request for issues that can be easily solved.

Although this is so simple to do in the portal, you can do this using PowerShell if you so desire via this one-liner.

In addition, if you haven’t checked out Azure Resource Health, have a look as it may help you out when issues arise. I hope this Azure Nugget has been helpful.

Deploying Service Fabric Cluster

/ / Leave a comment

Today, in part 3 of this series, I wanted to discuss some of the options available when deploying Service Fabric Cluster. In part 2 we presented an overview of the Azure Service Fabric. If you haven’t done so already, you may want to start at the beginning of this series which will help build the foundation of today’s topic.

Deploy Service Fabric Cluster

Note: You must have enough cores available in the region where you plan to deploy your service fabric cluster. You can verify this by using the command below and inserting the value for the region you plan to deploy to.

In my subscription I am only using 6 out of 100 cores available for this region. If you do not have enough cores, open a support request and increase your core quota. Make sure you select Resource Manager for the deployment model and specify the region.

When creating a Service Fabric cluster you have a few different deployment options available to you:

  • Setup a Service Fabric Cluster using the Azure Portal
  • Setup a cluster using an ARM template
  • Setup a cluster using Visual Studio
  • Setup a cluster in what is referred to as cluster anywhere
  • Setup a cluster using a Party Cluster
  • Setup a cluster on your development machine
  • Setup a cluster using PowerShell

As you can see we have many options to choose from. I will not be covering all of these in this post but plan to cover some of these in future posts.

Let’s cover the first option and deploy a Service Fabric Cluster using the Azure Portal.

Sign into the Azure Portal, if you haven’t done so already.

Click on +New, type “service fabric” and press Enter. In the Everything blade, click Service Fabric Cluster and select Create.

In the Service Fabric Cluster blade we need to provide details for the deployment. Give the cluster a name which must be between 4 and 23 characters and contain lowercase letters, numbers, and hyphens. Select your subscription and location, and choose to create a new resource group. Doing so will help in lifecycle management and billing.

In the Node Type Configurations we will select the number of node types, VM size and number of VMs to include in the cluster. We can have multiple node types, (ie. if we wanted to specify different size VMs and properties) but for this deployment we will just stick to one. For the VM size we will accept the default which is Medium (Standard A2). Enter a Node Type Name and choose the number of VMs to include in the cluster. The minimum number of VMs is set to 5 and is a requirement for the first node type, however this can be scaled up or down at a later time. For Application input endpoints enter the ports to open for your application. These can be added later as well. You can leave the Placement properties at the default for now and add additional name/value pairs for constraint if needed. Add a User Name and Password to use for the VMs.

For the Security Configuration, as this is a test environment, I will choose “Unsecure”. In a production environment you would want to use “Secure” to prevent unauthorized access. At a high level you would acquire a certificate, create an Azure Key Vault and upload the certificate to it, and provide the Source Vault, certificate URL and thumbprint during creation of the Service fabric Cluster. Optionally you can provide the details for the Admin Client and Read Only Client.

Under Diagnostic Settings, Support logs are enabled by default. This setting is required for the Azure Support team to resolve support issues. Application Diagnostics is disabled by default but can be enabled if desired.

Leave the Fabric Settings at default, review the Summary and click Create to start the deployment.

Deployment Status

The deployment took about 14 mins to complete. Now that its complete let’s look and see what was deployed. If we click on our resource group we see that there is a summary of the resources. Here is what we have as a part of our Service Fabric Cluster deployment.

We have a VM Scale Set called WebFE that has a capacity of 5 nodes labeled 0-4. VM Scale Sets are an Azure Compute resource that are used to deploy and manage a collection of virtual machines as a set.

We have a load balancer that has a public IP address assigned to it, 5 load balancing rules (the 3 we added for ports 80, 83, 8081, and 2 others that are added automatically for management operations; 19000, 19080), 5 probes configured for checking the health to see if the LB should continue to send new connections, and 5 inbound NAT rules for RDP to connect to each node as needed.

We have our public IP resource for the LB and the virtual network with 2 subnets.

There are 3 storage accounts; 1 blob service that stores the vhds, 1 table service for diagnostics, and another table service for log files.

Last but not least, we have our Service Fabric Cluster where we can see the health status of the nodes and applications (currently there are no applications deployed yet). Another important item here is the Service Fabric Explorer link.

Clicking on the link opens another browser tab which brings us this really nice portal for visualizing the cluster. Right away, from the Essentials menu, you get an easy to look at overall dashboard view of the cluster and its health. Clicking on the Details menu brings you Health Events, Load Information, and Upgrade info. Clicking on the Cluster Map menu we can see the Fault/Upgrade domain info for the cluster. Clicking on the Manifest menu will show the cluster manifest that was generated and used during upgrades.

Under the Cluster tree menu we have two subtrees, Applications and Nodes. Drilling down into Applications and into System we can see there are 5 services running. Those being:

  • ClusterManagerService
  • FailoverManagerService
  • ImageStoreService
  • NamingService
  • UpgradeService

Under each service is a partition showing each replica contained within it. You can see that node 2 is currently listed as Primary with the others being ActiveSecondary. Additional applications installed will show up here along with their stateless and stateful services, partitions, and replicas.

Drilling down into Nodes we can see all 5 nodes that make up the cluster and the details around the health state, status, upgrade/fault domain, IP address, unhealthy evaluations, and deployed applications. On the far right there is an Actions menu where you can Activate, Pause, Restart, Remove data, and Remove node state.

This has been a brief overview of a cluster just after deployment. For additional info on Service Fabric Explorer click here.

Now that the cluster deployment has completed, you can connect to your cluster and deploy your applications.

Connecting to the VM

To connect to an individual VM in a Scale Set, you can use either the DNS name or IP address of the Public IP address resource that is associated to the load balancer.

The NAT rules defined during the deployment define an incoming port range starting at say 3389 to port 3389 of the first VM, an incoming port of 3390 to port 3389 for the second VM, and so on. You can view these by clicking on the Inbound NAT rules setting of the load balancer resource.

Unfortunately this is the default setting when deploying through the Azure Portal. If you wish to change these port ranges you will want to download the json template prior to deployment and edit the resource for loadBalancers>inboundNatPools>frontendPortRangeStart and frontendPortRangeEnd values, then perform the deployment using the modified template.

I hope this helps to get you started deploying and testing Service Fabric. Initially this series was planned for 3 parts but I soon found there is just too much to discuss. So stay tuned for my next post as we continue to explore further.

 

Overview of Azure Service Fabric

/ / 1 Comment

Today, in part 2 of this series, I wanted to continue down the path of exploring Azure Service Fabric by presenting an overview of Azure Service Fabric. In part 1 of this series we talked about why you would want to use something like Service Fabric. That led us to a primer discussion around microservices which just so happen to run on the Service Fabric platform. If you haven’t done so already, you may want to read part 1 of this series first as it will help you build a better understanding.

My Journey to Service Fabric

Recently I was working on a project where the customer had an application that was hosted in Azure. They were utilizing the Cloud Services platform but soon came to terms that it may not be the best option for their application. With Cloud Services there are some limitations around being able to scale an application, primarily dependent upon how the application was architected. They soon realized that they needed a solution where their application workload would be scalable, reliable, and manageable. They had already begun to start working on a microservices approach for the application so it was only fitting that they explore Service Fabric. Hence, why I decided to write this blog series. I figured I could help others down the Service Fabric road to becoming DevOps Unicorns. So let’s see what Service fabric is all about.

What is Service Fabric

Service Fabric in its most simplest form is a platform for running microservices. It can’t be that simple right? Well, it is quite simplistic but there is much more to it than that. Service Fabric is a distributed systems platform that simplifies the packaging, deployment, and manageability of scalable and reliable microservices. This platform significantly changes how developers and administrators approach the deployment and management of mission-critical workloads. No longer do they have to deal with building and managing complex infrastructures. Instead they can focus their efforts on their application, increasing productivity and customer satisfaction.

Service Fabric itself is a shared pool of servers known as the Service Fabric Cluster. The cluster is made up of multiple nodes that host distributed microservices, those being stateful or stateless. By using microservices we have the ability to scale services independently of each other which allows developers to push out updates and fixes more frequently, not to mention reducing the chances of a broken service affecting the entire application. In addition, Service Fabric provides application management capabilities for provisioning, deploying, monitoring, upgrading, patching, and deleting of services. From a natural progression of application hosting we have gone from a physical server, to a virtual machine, to a container, to microservices. So whats next? Nanoservices? There is a concept of an application being too fine-grained and requiring more effort to stitch the services together but we won’t worry about that now. The image below shows a good representation of Service Fabric with many microservices deployed on top. Not only can Service Fabric be deployed in Azure, but it can be deployed in other clouds as well as on-premises.

 

Traditionally stateless applications required a database of some sort to maintain the state along with caches and queues to address latency. One of the problems with this is that it required more components to manage that didn’t scale really well together. In addition, each additional connection added to the latency. By using stateful microservices we remove the need for those additional components and can maintain high-availability and low-latency by keeping the application code close to the data.

Within Service Fabric there is support for application lifecycle management (ALM) from development, through deployment, during management, and decommissioning. By utilizing packaged microservices, multiple instances can be deployed and upgraded independently. Rolling upgrades can be performed to ensure the application is always available. In the event an upgrade fails, automatic rollback will kick in.

Additional Capabilities

  • self-healing applications
  • run Service Fabric on your laptop as a dev environment; same code runs in Azure
  • services can be built using framework of your choice
  • applications deploy in seconds
  • write once, deploy anywhere
  • deploy on Windows Server or Linux (coming soon)
  • deploy hundreds or thousands of applications per machine
  • manage using .NET APIs, PowerShell, or REST
  • monitor and diagnose the health state
  • scale up or down the cluster, capable of scaling to thousands of machines
  • redistribute and optimize load after failure

How Service Fabric Works

Briefly let’s discuss how Service Fabric works. Refer to the Azure Service Fabric documentation for a deeper dive.

In Service Fabric you have a cluster of nodes running a Windows service called FabricHost.exe that auto-starts upon boot. This service starts Fabric.exe and FabricGateway.exe which make up the node. Note: When running on your laptop as a dev environment you essentially just run multiple instances of these executables which show up as multiple nodes. An application package that references the service packages for each service type are copied to the image store. Once the package has been copied you can create an instance of the application within the cluster by specifying the type. The application type instance is then assigned a URI name of “fabric:/MyNamedApp“. Within the cluster you can create multiple named applications, each of which are managed and versioned independently. Named services instances are created under its named application which looks like “fabric:/MyNamedApp/MyNamedService“. During the named service creation you specify a partition scheme which spreads across cluster nodes allowing for scale. Within a partition stateless named services have instances while stateful named services have replicas which are kept in sync. Should a replica fail, Service Fabric builds a new replica from existing replicas. In addition, during named service creation, code, data and configuration packages are copied to the node(s) running the service where they can be used. You can create two types of service:

  • Stateless: use when persistent state is not required or using external storage
  • Stateful: use when persistent state is required. Uses Reliable Collections or Reliable Actors programming models.

Service Fabric Architecture

The diagram below shows the major subsystems of Service Fabric with a brief description of each.

  • Transport Subsystem – provides secure communication between nodes
  • Federation Subsystem – creates cluster of nodes into single entity for detecting failures, perform leader election, and provide consistent routing
  • Management Subsystem – manages lifecycle of applications and services
  • Testability Subsystem – help devs test services through simulated faults before and after deploying applications and services to production
  • Communication Subsystem – resolve service locations
  • Reliabilty Subsystem – responsible for reliability through replication, resource management and failover
  • Hosting and Activation – manages lifecycle of an application on a single node
  • Application Model – enables tooling
  • Native and Managed APIs – exposed to devs

In Summary

Service Fabric is being termed the next-gen platform for building and managing cloud-scale applications. If you are interested in seeing how this works or even deploying Service Fabric, stay tuned for the next post in this series where we will Deploy Service Fabric.

TwitterRSS