Microsoft Ignite 2018–Azure Service Fabric Mesh: The Serverless Microservices Platform

Speakers: Chacko Daniel and Deep Kapur.

This is a true dev session … but I’m here and I haven’t written an original line of programming since 1998. Why am I here? Because Service Fabric is cool and it fascinates me. If I wrote code, Service Fabric (along with functions for atomic trigger/action pieces and app services for interface) would be my choice.

Introduction to Service Fabric

  • Mission critical workloads
  • Used for Azure SQL, Power BI, Cosmos DB, IoT Hub, Event Hub, Skype, Cortana, and more.

Offerings

  • Service Fabric on Windows/Linux – bring your own infrastructure
  • Azure Service Fabric – runs on dedicated VM scale sets
  • Azure Service Fabric Mesh – serverless

Future of Application Development

  • Polyglob services connected by L7 networks
  • Multi OS environments
  • Deploy anything in a container
  • Bring your own network to connect to to your other services
  • State management and other stuff

Service Fabric Mesh (Public Preview Currently)

  • Focus on applications
  • Microservice and container orchestration
  • Pay for only what you use
  • Intelligent traffic routing
  • Azure manages all infrastructure
  • Auto-scaling on demand
  • Security and compliance
  • Health and monitoring

Mesh Resource Provider Architecture

Inventory Manager takes your input. Cluster allocator finds resources to run your code.

WIN_20180926_10_52_55_Pro

What Can You Use It For?

Ideal for cloud-native applications

  • Any language, any framework
  • Libraries to integrate with your favourite languages
  • Easy H/A state storage with reliable collections
  • Intelligent traffic routing and connectivity

Enable app modernization:

  • Deploy anything and everything in a container
  • Bring your own network
  • More

Demo

An app runs on a SF cluster. Each app is made up of 1+ services. A service can be made HA by running it on many nodes in the SF cluster (replicas or load balanced).

There is a mesh application resource. In the summary we see the services that make up the app, and how many replicas there are of each service. He opnes one service and we see the replica(s), numbered normally as 0,1,2,etc. The status shows a summary of recent events. In Details we see the physical consumption of the service, the ports (endpoints) it listens to, environment variables. In Logs we can see a screen output of app log data.

Service Fabric Resource Model

  • Applications and services
  • Networks
  • Gateways
  • Secrets
  • Volumes
  • Routing rules

Simple declarative way to define an application.

Applications and Services Resouces

Services describe how a set of containers run:

  • Container image, environment variables, CPU/MEMory, etc
  • And more

Gateway and Networks

Connecting two networks together:

  • L4: TCP
  • L7: HTTP/S

It’s a way of connecting the outside world, Internet or another network you own, to the isolated network of the SF cluster.

This is a service fabric gateway, not a VNet gateway.

Secrets Resource

Bad way: environment variable.

Better way: Use KeyVault.

Inline is in the public preview today, e.g. connection strings. Secrets by reference (key vault) is coming.

Volume Resource

General purpose file storage.The container can attach volumes. Read and write files using normal disk I/O file APIs. Backed by Azure File storage or Service Fabric volume disk. The SF volume disk is on the cluster and is faster – it is replicated to nodes where your service has a replica (stateful service).

Demo Application Architecture

Cloud based polyglob application demo that they have built. All built on Linux contianers

  • Front End – reactive.
  • Backend: .NET Core and Node.js.
  • Work gets dropped into a queue.
  • A Worker picks up the queue and stores data in persistent storage

Overview over.

They show us a JSON that is used to deploy the SF mesh application: Microsoft.ServiceFabricMesh/applications. Azure Files is being used as file storage. Secrets are being stored inline. A volume disk is also being used for file storage and they define a mount path in the Linux containers of /app/data. There are front end (1), backend (2) and worker services (3) in the application.

Auto Scaling

Horizontal scaling of services based on:

  • CPU
  • Memory
  • Application provided custom metrics (later)

Application Upgrade

He uses on-PC Azure CLI (PowerShell also available) to push a code upgrade to the SF application.

Routing Rules Resource

  • Services talk to each other inside the application by hostname.
  • They do not implement platform-specific discovery APIs
  • Not not deal with network level details.
  • Are unaware of the implementation details of other services

Intelligent traffic routing:

  • Done using “Envoy”
  • Advanced HTTP/S traffic routing with load balancing
  • Proxy handles partition resolution and key hashing

Diagnostics and Monitoring

  • Use your favourite APM platform to monitor apps inside containers, e.g. Azure Application Insights
  • Containers write out stdout/stderr logs to a data volume – can be sucked up by Application Insights
  • Azure Monitor for platform events and container metrics

Reliable Collections – Low Latency Storage

Reliable collections allow you to persist state with failover. Uses transactional storage. Storage on a network introduces a “cost”, e.g. latency. Low latency storage is often preferred.

Demo: Scale-Out

Dumps a load of pictures of cats & dogs. Worker numbers increase from 1 to 40 in seconds for 3 services (120 containers). The pictures are categorized and tagged on the fly.

Pricing

You pay for what you use. Container compute duration:

  • Cores per second
  • Memory in GB per second

Costs depend on the region. Container costs are the same in Azure, irrespective of the Azure offering you get them from. So you choose a container offering based on suitability, not price.

Stateful resources:

  • Volume disk: disk size, Max IOPS/Throughput per disk). Paid for per month.

Reliable collections:

  • Biller per hour based on: size of the reliable collection and the amount of provisioned IOPS.

Recap

What they see: Gaming, media sharing, mission critical business SaaS, IoT data processing for millions of devices, low latency storage applications.

Roadmap

  • Managed service ID
  • Secrets from key vault
  • Routing rules to/from applications
  • Applications across availability zones
  • Persisted state via reliable collections and volume drives
  • Bring your own network to connect to other systems
  • Tooling integration

GA is planned for early next year – probably Build 2019. The preview is free to use.

Go live licenses will be given to early adopters.

Please follow and like us:

1 Trackbacks & Pingbacks

  1. Azure Weekly: October 1, 2018 – Microsoft Ignite Aftermath – Build Azure

Leave a comment

Your email address will not be published.


*


This site uses Akismet to reduce spam. Learn how your comment data is processed.