unlocked workshop oscon 2013 - part i

OSCON

23 july 2013

Portland, ORButter Up your application

Tuesday, July 23, 13

welcome & introductions


your unlocked team

3

Wayne A. Walls@waynewalls

Alex Brandt@alunduil

Hart Hoover@hhoover


get social!

4

@rackspace #unlockedPDX#oscon


5


6

Business Strategy


7

Cloud Savvy


8

Cloud Freedom


9

Application Fit


cost of cloud apps

Wayne wallscloud evangelist


11


40%PRIVATE CLOUD

11


40%PRIVATE CLOUD

11

50%HOSTED ON-SITE


90% of Workloads Remain In-House...

40%PRIVATE CLOUD

11

50%HOSTED ON-SITE


Cost Considerations

Infrastructure

12


13

How many customers can you serve?


14

How easy would it be to scale?


Innovation

15


In-house?

16


Cost Considerations

17

Developers


18

Developer time translates into $


19

Apply effort where it matters


20

Be realistic about engineering time


21

Choose tools that scale


everything as code

Wayne wallscloud evangelist

hart hoovercloud evangelist


24

Self-service


25

On-demand


26

Metered


27

Resource pooling


28

Broad network access


NIST SAys...

29


NIST says...

30


NIST says...

31


multi-cloud

32


ENTER devops

33


34

Culture & Work Methodology


35

Tooling


36

Deployment Strategies


37

Measure All the Things


38

Automate All the Things


39


40


41

Gerrit


42

Gerrit


43


44


Infrastructure as code

45


46

Same Problems


47

What version is in production?


48

Issues are found, fixed & redeployed quickly


49

Test as you develop


50

Same Best Practices


51

Tag, branch & release code that defines infra


52

Coverage lifecycle over various stages


53

Continuously Test


54


Chef Server

Chef Workstation

Chef Client

knife

node

Chef Client

node

environment

55


•Nodes: Servers

•Environments: Groups of nodes (Dev/QA/Prod)

•Recipes: Describes the desired state of a node

•Cookbooks: Group of Recipes

•Roles: Group of Cookbooks (Web)

•Attribute: information about the current state of a node

56


Thinking like a developer57


Product Backlog

Sprint Backlog Sprint Working increment

of the software

58

1. Design

5. QA 2. Build

4. Release 3. Configure


59

1. Design

5. QA 2. Build

4. Release 3. Configure


Test Driven Development



Behavior Driven Development



Behavior Driven Development Domain Driven Development



Behavior Driven Development

Application Bliss

Domain Driven Development


POLYGLOT PERSISTENCE

alex brandtsr developer


62


63


64


65

RDBMS may not be the best fit


66


67


68

5 Characteristics


69

Non-relational


70

Distributed


71

Open-source


72

Horizontally Scalable


73

Schema-less


orders

customers

order lines

credit cards

ID: 1001

line items:

customer: Ann

0321293533

0321601912

0131495054

2

1

1

$48 $48

$39

$51

$39

$51

payment details:

Card: AmexCC #: 12345expires: 04/2001

74


75

There are several different types of data stores that are considered to

be NoSQL


76

Key/Value Databases


77

Document Databases


78

Column-Family Stores


79

Graph Databases


80

Types in Detail


Key/Value DatabaseS

81


Key/Value DatabaseS

• Good Use Cases:

• Storing Session Information

• User Profiles & Preferences

• Shopping Cart Data

• Bad Use Cases:

• Data Relationships

•Multi-operation Transactions

•Query by Data

82


Key/Value DatabaseS

• Good Use Cases:

• Storing Session Information

• User Profiles & Preferences

• Shopping Cart Data

• Bad Use Cases:

• Data Relationships

•Multi-operation Transactions

•Query by Data

83


document Database

84


document Databases

•Good Use Cases:

• Event Logging

• Blogging Platforms

• Real-time Analytics

• Article storage

• Bad Use Cases:

• Complex Transactions

•Queries against Varying Aggregate Structures

85


document Databases

•Good Use Cases:

• Event Logging


• Real-time Analytics

• Article storage

• Bad Use Cases:

• Complex Transactions

•Queries against Varying Aggregate Structures

86


COLUMN FAMILY

87


88


COLUMN-FAMILY datastores

•Good Use Cases:

• Event Logging


• Counters (page visits)

• Expiring Usage

• Bad Use Cases:

• ACID transactions required

• Early prototype applications

89


graph database

90


Amanda

KNOWS

KNOWS

KNOWS

Robert

Gerry

Lamar

KNOWS

App 1

BUILTBUILT

KNOWS

App 2

USES

BUILT

Christie

KNOWS

Destiny

Jessica

KNOWS

App 3

BUILT

USES

USES

USES

KNOWS

graph database

91


graph databases

•Good Use Cases:

• Connected Data

• Location-based services

• Recommendation engines

• Bad Use Cases:

• Ability to update specific aggregates

92


Companies using nosql

93

DATABASE COMPANIES


THE FUTURE IS POLYGLOT

94

Neo4Jdatabase

Cassandradatabase

Couchdatabase

MongoDBdatabase

RELATIONALDATABASE

Graph-structureddomain rules

Columnar dataaccess with

decentralization

Documentstructures

Document structureswith offlineprocessing

(Actors) (Actors)

(Actors)(Actors)

Asynchronous message passing

MODULE 1

MODULE 2

MODULE 3

MODULE 4

IEEE Software Sept/October 2010 - Debasish Ghosh / Twitter @debasishg


95

POLYGLOT PATTERN: cache

ORDERTAKING

RESTAURANTMANAGEMENT

REDISCACHE

MYSQL DATABASE SECONDFIRST

CONSUMERRESTAURANT

OWNER

Credit: @crichardson


96

POLYGLOT PATTERN: write to sql and NOSQL

NEWTWEET

INSERT

LPUSHXLTRIM

MySQL

TWEETS

FOLLOWS

FOLLOWERS

Redis: Timeline

FOLLOWER 1

FOLLOWER 2

FOLLOWER 3

Avoidexpensive

MySQL joins



97

POLYGLOT PATTERN: REPLICATE FROM MYsql to NOSQL

QUERYSERVICE

UPDATESERVICE

REDISMYSQL

DATABASE

SYSTEMOF RECORD

MATERIALIZED VIEW

READER WRITER

replicate and

denormalize

query() update()



98

Atomic

Consistent

Isolated

Durable

ACID to base

Basically Available

Soft state

Eventually consistent


unlocked workshop oscon 2013 - part i

Technology