software as a service - sdd...

Allen Holub http://holub.com [email protected]

@allenholub

©2015 Allen I. Holub. All rights reserved. http://holub.com

Micro-services

©2015 Allen I. Holub. All rights reserved. http://holub.com 2

Software as aService

• Big • Monolithic • RESTful • Focus is on the API—no organizing principle • Tend to access data only


Service Micro-

• Small • Self-contained • Object like (they do work)


UI “guys”

Middleware specialists

DBAs

Conway’sLaw

UI Layer

Middleware Layer

Database Layer


Team1

Team2

Team3

Conway’sLaw


Services defined by what they do,NOT how they do it.

6

Holub Replacement Principle:

At any point, you should be able to change how a service (object) works internally, and provided that you haven’t changed the interface, the client should not care.

© 2014 Allen I. Holub www.holub.com ©2015 Allen I. Holub. All rights reserved. http://holub.com 7

DATA


Ask the service that holds the data to do

the work for you!

8

© 2014 Allen I. Holub www.holub.com ©2015 Allen I. Holub. All rights reserved. http://holub.com 9

REST


HTTP Transport ✔REST services do only one thing

They manipulate data: GET, PUT, …

We could care less about the data

Ask for help, not information!

POST as transport mechanism is not REST10


SecureAutonomous Reliable Scalable Concurrent/ stateless Fault tolerant Transactional Platform neutral Lenient/polyglot Distributable Monitorable

11

• If login: requests carry secure user-id “session” token.

• Requests carry secure token identifying authorized agent.

• Secure data is end-to-end encrypted (SSL is not enough).


Secure AutonomousReliable Scalable Concurrent/ stateless Fault tolerant Transactional Platform neutral Lenient/polyglot Distributable Monitorable

12

• Service is a stand-alone process.

• Underlying data not shared (access via API if necessary)

• Can be launched/shut down independently of rest of system

• Can be deployed independently of rest of system


Secure Autonomous ReliableScalable Concurrent/ stateless Fault tolerant Transactional Platform neutral Lenient/polyglot Distributable Monitorable

13

• Can be expected to be present at all times.

• Notifies client of all failures • Logs all failures


Secure Autonomous Reliable ScalableConcurrent/ stateless Fault tolerant Transactional Platform neutral Lenient/polyglot Distributable Monitorable

14

• Multiple instances can be launched or shut down based on load.

• Doesn’t require external load balancing.

• Multiple instances can run on multiple machines.

• Lightweight and fast.


Secure Autonomous Reliable Scalable Concurrent/ stateless Fault tolerant Transactional Platform neutral Lenient/polyglot Distributable Monitorable

15

• Multiple instances can run in parallel.

• Do not use server-side sessions (no caching, no “sticky” routing).

• Consistant behavior does not vary with “state.”


Secure Autonomous Reliable Scalable Concurrent/ stateless Fault tolerantTransactional Platform neutral Lenient/polyglot Distributable Monitorable

16

• Can come on and off line without consequences.

• Never throws exceptions or equivalent


Secure Autonomous Reliable Scalable Concurrent/ stateless Fault tolerant TransactionalPlatform neutral Lenient/polyglot Distributable Monitorable

17

• Transactions==single operation (method).

• Operations work completely or not at all.

• No change to external state (including underlying data) on failure.


Secure Autonomous Reliable Scalable Concurrent/ stateless Fault tolerant Transactional Platform neutralLenient/polyglot Distributable Monitorable

18

• Can be deployed easily on any platform (ideally without recompile).

• Does not leverage platform-specific behavior (e.g. Windows registry).

• Does not leverage platform-specific protocols (e.g. SOAP)

• Always supports standard communication protocols (e.g. tcp).


Secure Autonomous Reliable Scalable Concurrent/ stateless Fault tolerant Transactional Platform neutral Lenient/polyglotDistributable Monitorable

19

• Interacting services can be written in different (and any) languages.

• Requests are platform/language independent (e.g. ASCII + JSON).

• Flexible argument ordering (or existence).

• Flexible number/data formats - commas optional - locales unimportant - precision unimportant


Secure Autonomous Reliable Scalable Concurrent/ stateless Fault tolerant Transactional Platform neutral Lenient/polyglot DistributableMonitorable

20

• Services can run: - in process - on the same machine - on different machines - in different data centers

• Topology can change dynamically, even at runtime.


Secure Autonomous Reliable Scalable Concurrent/ stateless Fault tolerant Transactional Platform neutral Lenient/polyglot Distributable Monitorable

21

• Must log all requests (via messaging)

• Must also log locally • Must be possible to ping

service or listen to heartbeat.



Messaging

23


Load Balancer

requests (also publishes

heartbeat)


Multiple Services


Filter (Authentication Service)


Blog posts

29

☞ Blog posts live in the file system as .html files ☞ in a directory specified in the BLOGPOSTS environment. ☞ Each post has it's own subdirectory.

The name is the postID ☞ The file's creation date == the posting date. ☞ These elements are meaningful:

<meta name="keywords" content="category"> <div class=“blurb"> … </div> <h1> The post title </h1>


☞ Comments in the same directory as the post, in a file called Comments

☞ New comments are appended to the end of the file. ☞ Comments displayed in the order they occur in the file. ☞ Approved comments only are displayed. Initially false. ☞ Service creates file called NeedsWork when it adds a

comment ☞ Comment is represented as:

{ "approved" : true, "thumbsUp" : 0, "thumbsDn" : 0, "from" : "UserID of the commenter" "content" : "(plain) comment text” }

Comments

© 2014 Allen I. Holub www.holub.com ©2015 Allen I. Holub. All rights reserved. http://holub.com

post:

{ "id" : "PostID", "blurb": "blurb text (html)" "date": "1970/01/01" "content": "html content" "comments": [ { … }, { … } ]}

request:

{ "authToken" : "theToken", "request" : "methodName" "arguments" : [ {"argName": "argValue"}, … ]}

response:

{ "status" : "OK" "result" : {…}

}

31


software as a service - sdd...

Documents