Documenting serverless architectures could we do it better - o'reily sa conference 201

BLACKSWAN TECHNOLOGIES 2018.ALL RIGHTS
WWW.BLACKSWANTECHNOLOGIES.AI
1
Documenting
Serverless
Architectures
BLACKSWAN TECHNOLOGIES 2018.ALL RIGHTS WWW.BLACKSWANTECHNOLOGIES.AI
Asher Sterkin, VP Engineering, BST
London, October 2018

2
● (Strategic) Domain-Driven Design
● Serverless Architecture
● Cynefin
● Wardley Maps
● Promise Theory
Software Technologist/Architect
Who I am
VP Engineering at Black Swan Technologies

3
Big Data, Cognitive Computing &
Artificial Intelligence Software Company
BlackSwan Technologies
London, United Kingdom
Tel-Aviv, Israel
Who we are
100% current client engagements FS
65 employees
Delaware, United States

4
Strategic
Partnerships
ABOUT BLACKSWAN
Major brands that have committed resources and are now building their engineering teams
around BlackSwan solution to later release it to the market
4 Major Partnerships

5

6
● Nano probability event
● Huge, long lasting impact
● “Big surprise” for everybody

7
● detect weak signals
● assess risk exposure
● discover “connected dots” in data
● Nano probability
● Huge, long lasting impact
● “Big surprise” for everybody
for enterprise
You cannot predict it,
but could be better prepared

8
What is Serverless Architecture?
● Pure highly available on-demand computing
● Two flavors:
○ AWS Lambda - no pay for idle
○ AWS Fargate - log running containers
● Large and constantly growing number of fully managed services
● Tectonic shift in the software industry - has to be taken seriously
○ S. Wardley “Why the fuss about serverless?”

9
What’s the Problem?
AWS
Lambda
Lambda
Function
When to use this?
Lambda
Function
And when this?
And when that?
Without clear guidelines the
choice will most likely be arbitral,
informal and inconsistent

10
What Does this Mean?
AWS Service?
SAM Template?
AWS Lambda Deployment?
Running Instance?
AWS Service?
SAM Template?
DynamoDB Schema?
DynamoDB Table Deployment?
DynamoDB Table Instance?
SDK Function Call?
Data Flow?
Address Reference?
Access Rights?

11
Why Bother?
Yan Cui, “Yubl’s Road to Serverless Architecture”
● Is it correct?
● Is it efficient?
● Is it reliable?
● Is it secure?
● What it does?
All what I could atest, is that its
author is extremely smart
intellectual

Contrarily to the popular belief, the main responsibility of
software architect is not to show the world how smart (s)he
is, but to make the overall system structure abundantly clear
to the whole organization. Of course, there are other
responsibilities, but this one is utterly important and widely
ignored.

13
System Modeling Basics
(always good to repeat)
● “Reality”, its model, and the model’s representation are not the same
● Each model reflects only some limited aspect of “reality”
● Semantic consistency is hard to achieve and maintain
● The more coherent the model, the narrower its context
● For any non-trivial system, more than one model is needed
● To get the whole picture, multiple models are mapped onto each other

14
4+1 View of Software Architecture
...
...
P. Krutchen, “Architectural Blueprints - The “4+1” View Model of Software Architecture
Conceptual Physical
Process View Deployment View
Logical View
Use-Case View
Implementation View
End-user
Functionality
Programmers
Software management
Performance
Scalability
Throughput
System integrators
System topology
Delivery, installation
communication
System engineering
Analysts/Designers
Structure

15
View Definitions
View Reflects Documentation
Use Case HOW external actors interact with the system User’s Manual
Logical WHAT the system does Business Rules
Process HOW the system runs internally Operations Manual
Implementation HOW the system is built Developer’s Guide
Deployment HOW the system is deployed Operations Manual

16
4+1 View of Serverless Architecture
Conceptual Physical
Process View Deployment View
Logical View
Use-Case View
Implementation View
End-user
Functionality
Programmers
Software management
Performance
Scalability
Throughput
System integrators
System topology
Delivery, installation
communication
System engineering
Analysts/Designers
Structure
...
Lambda
Function
Spec
...
Lambda
Instance
Pool
AWS
Managed
Services
Lambda Function Deployment
Ideally, there should be a different icon set for each view, but it’s probably too much to ask for now

17
Views Interaction
Use Case View
Logical View
(use case realizations)
Process
View
Implementation
View
functional
Deployment
View
non-functional
Performance
Scalability
Throughput
Resilience
Security
Functionality
Business Agility
Development Agility
Quality
Security
System Topology
Cost
Security
feedback

18
Use Case View
● Here, we focus on architecturally essential use cases:
○ What justifies developing the system in eyes of external actors
○ Most important external integration points
● Normally traditional UML notation is enough
● All further analysis is conducted within the scope of particular use case(s)

19
Use Case View Examples
Sign Up
User
Upload
Pictures
Manage
Albums
Manage
Watchlists
User
Manage
Scoring
Perform
Screening
scaffolding
main service

20
Logical View
● How the core business logic is realized
● Interaction with managed services where appropriate
● Custom automation also fits there
○ Need to be kept separate, unless this is your core domain
● UML Sequence diagrams are usually enough
● Sometimes UML Collaboration diagrams might be more convenient
● For modelling complex workflows UML Activity Diagrams are suitable option

21
Example: Classify New Image (sequence)
classifyPhoto
Amazon Rekognitions3://mysite.com/photo MySitePhotoLabels
putObjectEvent
upload
detectLabels
getObject
put
labels
Good for analyzing multiple
interactions between limited
number of elements,
reflecting operation
sequencing, and reasoning
about latency

22
Example: Classify New Image (collaboration)
classifyPhoto
Amazon
Rekognition
s3://mysite.com/photo
MySitePhoto
Labels
2. putObjectEvent →1. upload →
3. detectLabels →
4. ← getObject
5. put →
Good for analyzing major
interactions between large
number number of elements,
reflecting whole interaction
graph, and reasoning about
dependencies

23
Process View
● Suitable for reflecting:
○ What deployment and concurrency units (Lambda Functions, Fargate Services) exist
○ How much RAM/CPU is allocated to each computation service
○ How many instances will run in parallel
○ What system resources, e.g. DynamoDB tables, are involved
○ Cost estimations
○ Access permissions
○ How internal concurrency is arranged (advanced topic)
● Could be treated as a basic skeleton of SAM template without extra details
● By structure is similar to Collaboration Diagram, but semantics is different

24
Process View
Browser
getAlbums
invoke
Albums
query
addAlbumDetails
invoke
get/put
/
GET
albums/{id}
PUT
DELETE
deleteAlbum
invoke
get/put
purgeDeletedAlbums
query/delete
invoke
api
api resource
http method
Good for getting a bird view of the
whole picture, accurate yet
comprehensible
api.pictures.com
...
256 MB, 30 secs, 100

25
Process View
Browser
getAlbums
invoke
Albums
query
addAlbumDetails
invoke
get/put
/
GET
albums/{id}
PUT
DELETE
deleteAlbum
invoke
get/put
purgeDeletedAlbums
query/delete
invoke
Reference and
access rights
Lambda
instance pool
comprehensible
api.pictures.com
...
256 MB, 30 secs, 100
Resource
Constraints
Within this context, an arrow means
visibility and access rights and NOT
data or command flow.

26
Process View
Browser
getAlbums
invoke
Albums
query
addAlbumDetails
invoke
get/put
/
GET
albums/{id}
PUT
DELETE
deleteAlbum
invoke
get/put
purgeDeletedAlbums
query/delete
invoke
DynamoDB
table
Cloud Watch
event
Locking
mechanism
comprehensible
api.pictures.com
...
256 MB, 30 secs, 100

27
Process View
Browser
getAlbums
invoke
Albums
query
addAlbumDetails
invoke
get/put
/
GET
albums/{id}
PUT
DELETE
deleteAlbum
invoke
get/put
purgeDeletedAlbums
query/delete
invoke
api
api resource
http method
Reference and
access rights
Lambda
instance pool
DynamoDB
table
Cloud Watch
event
Locking
mechanism
comprehensible
api.pictures.com
...
256 MB, 30 secs, 100
Resource
Constraints

28
Public Watchlist
Sources
PUT
/watchlists/{id}
/screenings/
teal.zara.ai
index.html
TEAL client
custom_sanctions_index
custom_peps_index
upload_watchlist
delete_watchlist
matching_engine
scoring_engine
POST
W
BEcustom
BEbackbone
match_properties
scoring_rules
api.teal.zara.ai
watchlist_engine
perform_screening
DELETE
BEscreening

29
Process View: Ingest New Image Workflow
pictures.com
ingestNewImage imageIngestion
Workflow
queryResolutions
Client Devices
Amazon Rekognition
extractMetadata
Images
transformImage
uploads
pictures
get
put
In Process View, we deal with
concurrency, visibility and access
rights since all three aspects are
closely related.
…
Step Function
Fork
Join

30
Scaling Process View Diagrams
bvd-source-proxy
be-identity
be-elasticsearch-
service
be-adverse-news
be-custom
be-cdc
be-storm-cluster
be-kycbe-entity
Microservice wrapped in
a Cloud Formation Stack

31
Implementation View
● Here, we reflect
○ How deployable units are built
○ Source code sharing, if any
○ Run-time environments and versions
○ 3rd party packages
○ CI/CD pipeline organization
● Could be considered as further clarifications on SAM template plus
○ AWS Build script
○ AWS Pipeline script
○ AWS CodeStar template

32
Example: Image Transformation Stack
ImageIngestoringestNewImage
transformImage
extractMetadata
queryResolutions
pictures.com
Images
ClientDevices resolution resolution-gsi
IimageIngestWorkflow
Avoid putting excessive details where it’s not
necessary, e.g. do not depict embedded roles
and policies as in this case.
uploads
pictures
dynamoDbBackoffClient

33
Deployment View
● Here, we reflect:
○ How the system is deployed across multiple accounts/regions
○ Cross-region replication
○ CDN
○ Network routing
○ Network security

34
Example: Cross-Region Replication Deployment
eu-west-1 eu-west-2
mysite.com
api.mysite.com
siteData
mysite.com
api.mysite.com
siteData
mysite.com
api.mysite.com
mysite.com
api.mysite.com
rewriteHeader
mysite.com
api.mysite.com
default

35
Concluding Remarks
● All views in full detail would seldom be required
● Process View is often the most actively used
● Custom resources help with improving clarity
● Concentrate on the most important architectural decisions
○ Pickup relevant views to reflect these decision in high fidelity
● Might constitute a form of Lightweight Architecture Decision Records

36
What Could We Do About It?
● Developers and solution architects do not like to be told how to work
● Greedy platform and tool vendors could ruin any good initiative
● Too often great achievements of industry leaders are forgotten or ignored
● Grassroot community project with true organic growth might work better:
○ Open source catalog of modeling elements collected so far
○ Case studies of real-life projects
○ Collaborative research of implications on important operational aspects such as security,
monitoring and disaster recovery
○ Meetup presentations and blog posts
○ Consulting and mentoring services where appropriate

37
More Information
● P. Krutchen, “Architectural Blueprints - The “4+1” View Model of Software Architecture”
● S. Wardley “Why the fuss about serverless?”
● E. Evans, “Domain-Driven Design Reference”
● A. Sterkin, “Serverless Architecture Language”
● A. Sterkin, “Consistent Modeling of Serverless Long-Running Background Tasks”
● A. Sterkin, “Serverless Steps”

38
Contact/Follow
asher@blackswan-technologies.comhttps://www.slideshare.net/AsherSterkinhttps://medium.com/@asher.sterkin
asher.sterkin@gmail.com

Documenting serverless architectures could we do it better - o'reily sa conference 201

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Documenting serverless architectures could we do it better - o'reily sa conference 201

Similar to Documenting serverless architectures could we do it better - o'reily sa conference 201 (20)

More from Asher Sterkin

More from Asher Sterkin (10)

Recently uploaded

Recently uploaded (20)

Documenting serverless architectures could we do it better - o'reily sa conference 201