Tag: Serverless

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.

Overview of the Microsoft Azure Serverless Platform

Speakers:

  • Chris Anderson, Senior Program Manager
  • Raman Sharma, Senior Product Marketing Manager

Evolution of Application Platforms

We used to build applications on-premises. Find h/w, find someone to set it up, and then the bits, networking, etc. Counter to productivity.

IaaS meant that a VM could be provisioned faster, but still left with some delays, and still required on-going management. The current wave of SaaS is probably mostly built on IaaS.

Along came PaaS. VMs were abstracted, hiding the on-going management of the VM and guest OS. But we still have the same per-VM paradigm.

Serverless ideally reduces infrastructure to zero. There is really a server, but it’s not yours and there’s no hint of it. The app still has to run on something, but you never acknowledge its existence.

Traits of Serverless

  • Abstraction of servers
  • Event-driven start-up triggers/instant scale out or in.
  • Micro-billing instead of per-hour/month billing.

Benefits

  • Manage apps, not servers. Look after the thing you care about: the app and the code.
  • Reduced DevOps: there are no servers to fix/patch. You don’t have to scale out traditional PaaS.
  • Faster time to market

Your business can sell a service, consume data, seize an opportunity quicker than ever with serverless.

Serverless Application Platform Components

  • Functions: Execute your code based on events you specify.
  • Logic Apps: Design workflows and orchestrate processes. It’s the original serverless feature in Azure. Logic Apps tie together different things inside and outside of Azure in workflows made up of different steps.
  • Event Grid: A relatively new service in Public Preview. Manages all events that can trigger code or logic. A single interface for all such events. Manage where those events come from, and decide what you will do with those events (start Functions, Logic Apps, etc)

26-09-2017 16-18 Office Lens

  • Database: store the data
  • Storage: store data in blob/queue/NoSQL
  • Security services
  • IoT for massive numbers of devices inputing data
  • Analytics to process data realtime
  • Intelligence to use AI models to understand/action on data

Demo: Event Grid & Logic Apps (Chris)

In the Logic Apps Designer. Looks like Flow. When an event occurs to a storage account and is sent in from Event Grid, a post is sent to Teams. The body of the message is dumped into Teams, which is ugly JSON. They want to parse the JSON before posting it. A function is written in JavaScript. The function will do the required parsing of the JSON and create human-friendly output.

He adds an action between the two existing actions in the logic app designer. This will trigger the Function. The Function is passed the body of the JSON. The Function will return a response, and that is used as an input to the Teams action. That input is given a condition. If verbosity = ignore then the Teams action can be bypassed.

Now he deletes a storage account and Event Grid starts the logic app. He traces the logic app in the Portal job history – the trace shows that Team received the message from Logic Apps. After some debugging, the formatted event appeared in Teams. Quite a bit was accomplished in that process without a VM and with very little JavaScript.

Scenarios for Serverless

Short: Anything that is based on events.

  • Real-time stream processing, e.g. IoT. You have no idea when data is coming in, and how much will come in.
  • Time-based processing. E.g. collect logs and process them once per week. Why dedicate VMs/PaaS for that? Pay for the few seconds of compute that is required for the task.
  • Back-ends for mobile/IoT/web. E.g. someone uploads an image to a site, a function stores the image in a storage account, and another function processes the image (thumbnails, metadata, etc) and stores that data somewhere.
  • Real-time bot messaging. Use Logic Apps to workflow the processing of a question from a bot in Cortana Analytics and then send the result back to the bot.

Event Grid

26-09-2017 16-36 Office Lens

The list of services will grow – it’s only been in preview for a month and a half at this point.

It delivers at massive scale:

  • Sub-second end-to-end latency in 99th percentile
  • 10,000,000 events per second per region.
  • 24-hour retry with exponential back off for events not delivered

Logic Apps

  • A visual design experience without writing any code, no matter how complex it is.
  • Multiple connectors to Azure, third-party, or your own services/functions.
  • Uses a declarative definition format to work with CI/CD.

There are over 170 (and growing) connectors to orchestrate, e.g. Slack, SalesForce, Twitter, Box, Facebook, GitHub, DropBox, Pintrest, WordPress, etc.

Functions

An evolution of WebJobs from PaaS.

  • Develop locally using best of class developer tools
  • Boost productivity through triggers and bindings.
  • Choose from a variety of programming languages
  • Integrate with existing DevOps processes.

Lots of triggers: schedule, HTTP (REST or webhook), Blob storage, events, queues, queues and topics, storage tables, SQL tables, NoSQL DB, Push Notifications, Wwilio SMS Text … and one I missed.

What’s New in Functions

  • You can develop locally on Linux, MacOS, and Linux
  • Monitor serverless applications using Application Insights (now GA)
  • Trigger a function on changes in Cosmos DB
  • Securely provide access to information in Microsoft Graph through a function.
  • Trigger a function from a real-time analytics pipeline in Stream Analytics

Demo

Four volunteers go on stage. There are two IoT buttons. When they are pressed, they’ll send a message to Azure IoT, and will trigger Functions. Fastest to answer questions get most points, last gets least points. And then questions on Serverless tech come up. The scores are processed by Serverless compute using Functions. In this case, the functions were actually running on a local host (WS2016).

Customer Stories

  • Fujifilm: Online service handling 1 TB data per day. Monolithic design where code change was hard. Cosmos DB and Functions reduced latency by 95%. Development time reduced by 75%. Higher reliability. Ability to add new features and release faster and more frequently.
  • Quest: Uses serverless for a SaaS application. Able to manage millions of objects. Cut time-to-market by 2/3. No costly on-premises h/w.
  • Plexure: Service to help retailers understand “signals” from their stores to optimize sales. Built serverless with functions, even hubs, IoT, machine learning and Cosmos DB. Reduced efforts and scales on demand. Used to build infrastructure for each retailer. Now they just publish APIs.