Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

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.

DeleteCancel

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

Modern Architectural Patterns for the Cloud - NDC London

No description
by

Mahesh Krishnan

on 8 June 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Modern Architectural Patterns for the Cloud - NDC London

Users
Presentation Layer
Domain Layer
Data Access Layer
Security
Op. Mgmt
Comms.
What is the cloud?
Computer processing power/resources over the internet, provided as a service. Benefits include:

Zero or low upfront cost
Lower ongoing $ (charged per minute in some cases)
Elasticity on demand (Scale out/in)

Re-cap
Arch. Characteristics
Design for high availability and resilience
Design for elasticity
Design for the future

ASP NET MVC or Web Forms
WS-* web services
SQL Server database
...
Demo App for this talk!
Create an app better than Twitter!
Cloud scale!!



CQRS
Event Sourcing
Non relational Datastores
Queue Centric Workflow
Map Reduce
Modern Patterns
Command Query Responsibility Segregation
Command
Query
Performs an action
The "Write" part of CQRS
No Read functionality: domain model offers true encapsulation
Domain model only exposes behaviours
Returns data to the user through a query
"Read" part of CQRS
Can skip the domain model altogether - thin read layer
Reads can go direct to DB - No complexity
Reads are quick
Concepts
Event sourcing:
A way of persisting app state, by storing history of events
Event:
Something that has happened in the past
Examples:
Chess application: storing every move that was made as a series of events
Accounting application: storing every payment made, every payment received as events
Can get the state of the application, by replaying events. Taking snapshots helps performance
The old way
Create Shopping Cart
Add book "Introducing .NET 4.5"
Add book "C# in a nutshell"
Remove book "C# in a nutshell"
Add book "SL 4 for Dummies"
Checkout cart
The new way
Shopping Cart has been created
Book "Introducing .NET 4.5" has been added
Book "C# in a nutshell" has been added
Book "C# in a nutshell" has been removed
Book "SL 4 for Dummies" has been added
Cart has been checked out
Relational DBs not great at horizontal scaling
CAP Theorem - Consistency, Availability and Partition tolerance. At most 2 guaranteed!
BASE vs ACID
Application
Query
(Read)
Command
Complex
Business
Logic
(Write)
Id
User
...
Id
CartId
Isbn
...
Xx Joe ...
1 Xx Blah1 ...
2 Xx Blah2 ...
More updates
How it all hangs together
Introducing.....
WhingePool
Shopping cart Cart Data
created
Event ...
Book added Book 1 Data
Book added Book 2 Data
Cart checked Checkout Data
out
Modern Architectural Patterns
for the Cloud

Put/Post
Web App
Get
Azure
Website
Command Queue
Command
Processor
Command
Handler
Materialized
Views
Event
Store
Query
@MaheshKrishnan
Mahesh.Krishnan@readify.net

How we've been doing things in the Microsoft Eco-system
BASE
Data is always available, even if data is stale.
Basically Available
Soft State
Eventually consistent
State may change.
There may be a delay before the final state is reached. But, it will.
Map Reduce
Pattern to deal with Big Data
Obtains results for embarrassingly parallel problems
Simple set of programming steps
Considerations
Not everything is a Big Data problem
While using HDInsight, use Blob storage to store data
Load
Balancer
Client Tier
Application Tier
Data Tier
Active Passive
Cluster
Shared Data
Cart
Cart Items
3 Xx Blah3 ...
Book added Book 3 Data
Book removed Book 2 Data
Considerations
Works well with other patterns such as Event sourcing
Commands being Asynchronous in nature, introduce complexity in App
UX/Application logic/Business flow may need to be changed to cater for this new design
*
Concepts
Considerations
Queries are not simple SQLs anymore.
Works well with CQRS; Materialized views can help in shaping data
Eventual consistency may need some business flow changes
NosQL Databases
Non-relational data that has no fixed schema
Highly scalable (horizontal)
Performance benefits
Stores Partitioned key-value pairs in tables
Examples - Google's BigTable, Azure's Table Storage, Amazon's DynamoDB, Redis, etc
Azure Tip: Use Partition Keys and Row Keys carefully to get the best performance from Azure Table Storage
Document DBs
Stores Documents in datastores
Documents can be XML, JSON, BSON, etc
Examples - Raven, Mongo, Couch
Azure Tip: Can build custom document store with Blob Storage, keeping indexes in Table Storage
Graph DBs
Works on "Graph theory" concept. Stores data as Nodes, Properties and Edges
Examples - Neo4J, Allegro, Virtuso
Key-Value pairs
BASE
Data is always available, even if data is stale.
Basically Available
Soft State
Eventually consistent
State may change.
There may be a delay before the final state is reached. But, it will.
Transaction consistency
Idempotency
Poison message handling
Money leak
NosQL Databases
Non-relational data that has no fixed schema
Highly scalable (horizontal)
Performance benefits
Stores Partitioned key-value pairs in tables
Examples - Google's BigTable, Azure's Table Storage, Amazon's DynamoDB, Redis, etc
Azure Tip: Use Partition Keys and Row Keys carefully to get the best performance from Azure Table Storage
Document DBs
Stores Documents in datastores
Documents can be XML, JSON, BSON, etc
Examples - Raven, Mongo, Couch
Azure Tip: Can build custom document store with Blob Storage, keeping indexes in Table Storage
Graph DBs
Works on "Graph theory" concept. Stores data as Nodes, Properties and Edges
Examples - Neo4J, Allegro, Virtuso
Key-Value pairs
BASE
Data is always available, even if data is stale.
Basically Available
Soft State
Eventually consistent
State may change.
There may be a delay before the final state is reached. But, it will.
Considerations
"Commands" are enqueued in a Queue
Processor de-queues, handles, and deletes command
Multiple processors can operate on a queue (scaling)
Command handlers can be dynamic
Concepts
Application
Query
Command
Complex
Business
Logic
Materialized
View
Data Store
Application
Query
Command
Queue
Processing
Database
Application
Query
Command
Complex
Business
Logic
Materialized
View
Data Store
Works well with patterns such as CQRS
Event Store is an append only store
Considerations
Application
Query
Command
Complex
Business
Logic
Materialized
View
Data Store
NoSQL Databases
Non-relational data that has no fixed schema
Highly scalable (horizontal)
Performance benefits
Key-Value Pair
Data stored as a key + values associated with the record.
Examples - Google's BigTable, Azure's Table Storage, Amazon's DynamoDB, Redis, etc
Document DB
Stores Documents in datastores
Documents can be XML, JSON, BSON, etc
Examples - Raven, Mongo, Couch
Graph DB
Works on "Graph theory" concept.
Stores data as Nodes, Properties and Edges
Examples - Neo4J, Allegro, Virtuso
Basically Available
Soft State
Eventually consistent
Data is always available, even if data is stale
State may change
There may be a delay before final state is reached, but it will
An Example
Split & Store data
Data is distributed
& counted
Results
sorted
Results
combined
Seemingly infinite inexpensive computing power/resources at your disposal
Steps involved
Store
Map
Shuffle
Reduce
Split & Store data
Data is distributed
& processed
Result is parallel
sorted
Shuffled results
combined
Red - 2
Red - 4
Red - 3
Orange - 4
Orange - 1
Orange - 0
Green - 2
Green - 3
Green - 1
...
Red - 24
Orange - 18
Green - 17
...
Conventional Design
Classic patterns
Classic Layered Approach
Deployment
Id Name Age Gender
12 Bob 24 M
13 Jane 19 F
...
Key Value
12 Name:Bob; Age:24; Sex:M
13 Name:Jane; Sex: F
30 Name:B; Email: b@a.com
Key Document
12 { Name:"Bob"; Age:"24"; ... }
13 { Name:"Jane"; Sex: "F"; ... }
30 ...
Id: 14
Name: Bob
Age: 24
Id: 15
Name: Jane
Age: 21
Id: 20
Name: Ajax Inc.
Id: 30
Label: works
Since: Jan 2011
Id: 32
Label: works
Since: Mark 2013
Application
Command
Query
Complex
Business
Logic
Materialized
View
Data Store
Full transcript