Tokyo Azure Meetup #5 - Microservices and Azure Service Fabric

Download Tokyo Azure Meetup #5 - Microservices and Azure Service Fabric

Post on 20-Mar-2017




6 download

Embed Size (px)


PowerPoint Presentation

Build Microservice-based Applications with Azure Service Fabric

Use Case - Shared Data Context

API #1API #2API #3API #4API #5Azure SQL Database, Code First Approach

Issues Schema change affects all

API #1API #2API #3API #4API #5DBSchema Change

Initial State


MicroservicesSmall Autonomous services that work together, modelled around a business domain

Small - 2 weeks to rewrite / few hundred lines of code

Independently scalable and deployable

Microservices ExamplesProtocol gatewaysUser profilesShopping cartsInventory processingQueuesCaches

API RelationsAPI #3API #8API #1API #4API #5API #2API #7API #6API #9

6 Callers4 Callers

2 Callers

Why now?Build and operate a service at scale

Enable greater customer reach

Faster delivery of features and capabilities

Improved resource utilization to reduce costs

Lean Startup

Why Microservices?Scale specific application parts based on demand

Development teams are more agile in rolling out changes

Provide features to faster and more frequently

SOA vs MicroservicesSOAMicroservicesService Deployed in a Shared BusServices Deployed at the EdgeOne Team GoalTeam aligned with Business UnitsCentralize MediationDumb interfacesNot prescriptive on the back-end implementationPrescribes back-end implementation pattern

Fine-grained SOA

Independent changes to each

Decoupled federation of services

Agreed-upon standards for communication

Microservices Model

Microservices CharacteristicsEncapsulate a customer or business scenario

Developed by a small engineering team

Any programming language / framework

Code (state) independently versioned, deployed, and scaled

Microservices Characteristics

Well-defined interfaces and protocols for communication

Unique names (URLs) for resolving

Remain consistent and available during failures

Breaking Process

Begin with a monolith

Break it in stages

Start with parts that need to be more scalability or agility

Bounded Context

Microservices PrinciplesModel around business domain

Hide Implementation (database)


Chunky, not Chatty

Microservices PrinciplesDumb pipes, smart endpoints

Deploy independently

Isolate Failure

Highly Observable

VersioningMultiple different versions are rolled out

Multiple different versions run side by side

Rolling back to an earlier version

Perform A/B-style testing

Upgrade for a specific customers to test new functionality

LoggingCorrelation context across services

Independent logging

Standard for health and diagnostic events

Different teams agree on a single logging format

Application wide log events view

Microservices Challenges

Significant Operations Overhead

DevOps skills required

Implicit Interfaces

Microservices ChallengesManaging the big number of separate entities

Complex deployments and versioning

More network traffic between the microservices

Network latencies

Hard to see the whole system.

Microservices Challenges

Distributed Computing Complexity

Duplication of Effort

Testability Challenges

What do these have in common?

Azure Core Infrastructure

thousands of machinesPower BIIntune

over 1m devicesAzure SQL Database

millions of databasesBing Cortana

500m evals/secAzure Document DB

billions transactions/weekSkype for Business

Hybrid Ops

Event Hubs

20bn events/day

2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.5/27/201628

Azure Service FabricDistributed systems platform

Simplifies packaging, deployment, and management of microservices

Resolves challenges in developing and managing cloud applications

Azure Service FabricManagement of upgrades, detecting and restarting failed services

Service discovery

State management

Health monitoring


Hosts microservices inside containers

Containers deployed and activated across the cluster

Docker support coming

Azure Service Fabric

Generally Available

Preview for Windows Server:Install on premiseInstall on alternative clouds

Preview for Linux

Azure Service Fabric

Azure Stack support coming

Great tooling

Excellent Integration with Visual Studio

CapabilitiesPerform near real-time data analysis

In-memory computation

Parallel transactions

Event processing

API-sReliable Actors

Reliable Services

Make the job more straightforward

Integrate with the platform at a deeper level

Take advantage of built-in high availability.

Reliable ActorsStateless / Stateful objects via the Actor model

Lots of independent units of computation/state

Uses a turn-based threading model

Avoid code that calls out to other actors or services

An actor cannot process other incoming requests until all its outbound requests have completed

Reliable ActorsIndependent objects -actors

Service Fabric takes care:Deployment


Communication across actors

Reliable ServicesReliable Services:StatelessStateful (reliable collections)

StatelessExamples : protocol gateways, web proxies

Do not maintain a state outside of any given request or response

State maintained in dedicated data storage

Azure Examples: Web Apps, Cloud Services

Stateful Examples : user accountsdatabases shopping cartsqueues

Maintain a state beyond the request and its response.

Internet-scale applications have both - Stateless & Stateful

StatefulPartitions to spread state

Replication of state

Primary replica + Multiple secondary

StatefulWrite to the primary replica

Syncs with the secondary

Primary replica fails -> secondary becomes new primary

Why Stateful?High-throughput, low-latency, failure-tolerant online transaction processing (OLTP)

Examples: Search, IoT, Trading systems, Credit card processing and fraud detection systems, personal record management

Keep code and data close on the same machine

Why Stateful?

Application design simplification

Remove the need for queues and caches

Fewer moving parts to manage in your application as a whole

Stateless App

Stateful App



Any framework supported

Rolling upgrades

Automatically rolling back in case of error

Never leaves the application in an inconsistent or unknown state

Fully scriptable -> easy to integrate with CI / CD

Deploy Everywhere

Global Availability East USNorth Central USSouth Central USWest USWest EuropeJapan WestAustralia EastAustralia Southeast