Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Implementing Microservices using Azure Service Fabric

No description

Alexander Laysha

on 22 February 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Implementing Microservices using Azure Service Fabric


Service Fabric

Monolithic Architecture
Implementing Microservices using
Azure Service Fabric

by Alexander Laysha
Lead .NET Developer
[Q & A]
Reliable Actors
Reliable Services
Monolithic Architecture Example
Simple to scale
Simple to test
Simple to deploy
Simple to develop
Development slows down
Modularity breaks down
Overloaded IDE & web container
Continuous deployment is difficult
Scaling the application can be difficult
Obstacle to scaling development
Requires a long-term commitment to a technology stack
Domain Entities
Bounded Contexts
Independent development
Easy to scale & integrate with 3rd services
Technology Diversity
Improved fault isolation
Easier to scale development
Strong module boundaries
Independent deployment
Testability challenges
Distributed system complexity
Operational complexity
Duplication of effort
Implicit interfaces
Eventual consistency
High-Level Overview
Service Fabric Cluster
Network connected set of Virtual or Physical machines
Scalable to 1000s of machines
Supports Fault & Upgrade domains
Resource Balancing
Application Model
relationship between application and service types,
code, data, and configuration packages
Application Model
relationship between applications
and service instances, partitions, and replicas
State Management
Asynchronous communication
Location transparency & Automatic Failover
Request/Response pattern (RPC)
Automatic GC
(actor-actor, client-actor)
Automatic lifetime management
Turn-based access
- state can be lost due to failovers
- state preserved across GC and failovers
Built-in providers:
Primary-Secondary replication
Readonly methods
Auto/On Demand save
- volatile state provider
- durable state provider
Actors are just objects
Other features
At the partition level
At the service name level
- Ranged partitioning
- Actor Id maps to Partition Id
- No partition control
- 1 Stateless Actor instance per 1 partition
Timers & Reminders
Simple Pub/Sub model
Designed for Actor-Client communication
No support for Actor-to-Actor communication
Trigger recurring tasks on Actors
Reminders are not lost upon failures
Reliable Service Architecture
Reliable Collections
Top-level programming model
Pluggable communication model
Background processing
Ability to control partitioning scheme
Ability to control the concurrency or granularity of state changes
Free-threaded runtime environment
Reliable Dictionary - IReliableDictionary<TKey, TValue>
Reliable Queue - IReliableQueue<T>
At the partition level
At the service name level
- Control over partition schema:
- N Stateless Service instances per 1 partition
Ranged partitioning
Named partitioning
Problems of monolithic architecture
Microservices: benefits & drawbacks
Overview of Azure Service Fabric
Reliable Actors
Reliable Services
Full transcript