SOLID SERVICES Ond ej Kraj ek @hedragon @ysoftdevs A Little - - PowerPoint PPT Presentation

▶
solid services
SMART_READER_LITE
LIVE PREVIEW

SOLID SERVICES Ond ej Kraj ek @hedragon @ysoftdevs A Little - - PowerPoint PPT Presentation

Jun 11, 2023 464 likes •905 views

SOLID SERVICES Ond ej Kraj ek @hedragon @ysoftdevs A Little Disclaimer Today, I am trying to give you a perspective or - say - a point of view. What I am presenting today are my own opinions. But I am not presenting a new

slide-1
SLIDE 1

SOLID SERVICES

Ondřej Krajíček @hedragon @ysoftdevs

slide-2
SLIDE 2

A Little Disclaimer

  • Today, I am trying to give you a perspective or - say - a point of view.
  • What I am presenting today are my own opinions.
  • But I am not presenting a new invention. And if I have learnt anything,

it was from my cooperation with my colleagues at Y Soft.
 Hey guys... :-).

  • I am going to sometimes refer to buzzwords. I will try to make this

explicit.

  • No services were harmed during preparation of this talk.
slide-3
SLIDE 3

In a Galaxy Far Far Away...

Geecon Prague 2014 Open Spaces with Bruce Eckel

slide-4
SLIDE 4

Architecture (Latin architectura, after the Greek ἀρχιτέκτων – arkhitekton – from ἀρχι- "chief" and τέκτων "builder, carpenter, mason") is both the process and the product of planning, designing, and constructing buildings and

  • ther physical structures.
slide-5
SLIDE 5

Why do we have software architecture?

slide-6
SLIDE 6

Software Architecture gives answers to the most expensive questions.

slide-7
SLIDE 7

Software Architecture is a decomposition of software products into systems, based on their responsibilities and interactions.

slide-8
SLIDE 8

Architecture envelops software design.

slide-9
SLIDE 9

Software Architecture is the servant of high-priority stakeholder values. Is as simple as possible, but not simpler. Is designed to be replaceable.

(Tom Gilb)

slide-10
SLIDE 10

Functional vs. Non-Functional Requirements

slide-11
SLIDE 11

Functional vs. Non-Functional Requirements

slide-12
SLIDE 12

Functions (Features) and Qualities (Quality Requirements)

slide-13
SLIDE 13

Stakeholders Values Product Qualities System Qualities

slide-14
SLIDE 14

Microservices Architectural Style

slide-15
SLIDE 15

What is a SERVICE?

slide-16
SLIDE 16

Microservices (2014) "In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment

  • machinery. There is a bare mininum of

centralized management of these services, which may be written in different programming languages and use different data storage technologies." Martin Fowler

slide-17
SLIDE 17

Microservices (2014)

  • Single Service per Process
  • Lightweight Network Communication

and Interoperability

  • Based on Business Concepts
  • Programming Language Agnostic
  • Synchronous / Asynchronous
  • Independent from others

RPC (1991)

  • Single Service per Process
  • Encapsulated Network

Communication and Interoperability

  • Based on Business Concepts
  • Programming Language Agnostic
  • Synchronous / Asynchronous
  • Independent from others
slide-18
SLIDE 18
slide-19
SLIDE 19

Microservices vs. Monoliths

By popular demand, the new technology is replacing the

  • ld, obsolete one.
slide-20
SLIDE 20

Deja-Vu

Tight vs. Loose Coupling

  • Local vs. Remote Procedure Call

Pooling Resources

  • Database Connection Pools reused by several services

Memory and Latency Conservation

  • Micro-Kernel (Mach) vs. Modular Kernel (WinNT) vs. Monolith (Linux)

It all has been invented already (compare microservices to CSPs, WSRF, Globus Toolkit, OGSI, Agents, Actors, Data Driven Systems, Message Passing Systems, P2P Networks, etc.)

slide-21
SLIDE 21

Let's Apply some Engineering...

slide-22
SLIDE 22

SOLID

  • Single Responsibility Principle
  • Open for Extension / Closed for Modification Principle
  • Liskov Substitution Principle
  • Interface Segregation Principle
  • Dependency Inversion
slide-23
SLIDE 23

How can we apply principles from structured / object oriented design to (micro)services?

slide-24
SLIDE 24

A case for cohesion and coupling

slide-25
SLIDE 25

Single Responsibility Principle

slide-26
SLIDE 26
  • Single Responsibility = A Case for Coupling and Cohesion
  • How to measure and evaluate cohesion?
  • REACHABILITY
  • http://www.cs.colostate.edu/~bieman/Pubs/tse98.pdf
  • Or a simple concept of semi-connected graphs might suffice

(cohesion is the inverse of semi-connected components).

slide-27
SLIDE 27

B A C D

slide-28
SLIDE 28

B A C D E F

slide-29
SLIDE 29

B A C D E F

slide-30
SLIDE 30

Services abstraction: processes owning and exposing resources responding to messages

Location Resource Forecast Resource (PUT) Forecast for Berlin for Tuesday Data Store for Weather Information

slide-31
SLIDE 31

RESOURCE COHESION

  • There is a connection between resources iff…
  • There is a reference in a message directed at a resource

(forecast refers to location).

  • References induces edges in resource graph, then…
  • Cohesion is inverse to the number of semi-connected

components.

slide-32
SLIDE 32

HR Module in ERP System

a trivial example

slide-33
SLIDE 33

Salary Employee Experience Skills Renumeration

slide-34
SLIDE 34

Salary Employee Experience Skills Renumeration

slide-35
SLIDE 35

Salary Employee Experience Skills Renumeration

slide-36
SLIDE 36

Salary Employee Experience Skills Renumeration

slide-37
SLIDE 37

A Case for Dependency Inversion

slide-38
SLIDE 38

A problem of resource dependencies can be resolved on resource level.

Location Resource Temperature Trigger (PUT) Notify when temperature in Berlin < 5 Data Store for Weather Information

slide-39
SLIDE 39

A problem of resource dependencies can be resolved on resource level.

Location Resource Temperature Trigger

(PUT) Notify when temperature in URL < 5

Weather Resource

(PUT) Give me URL for Berlin (PUT) Give me weather forecast URL for this location

slide-40
SLIDE 40
  • The issue of trust…
  • The fact that I trust the client does not mean that I trust whatever

resource URL the client throws at me.

  • The issue of availability…
  • What happens if the resource identified by the client is no longer

available?

  • The issue of interoperability…
  • Does the service identified by the client speaks my language? A need to

for standard / conventional contracts arises (again).

slide-41
SLIDE 41

Food for Thought

slide-42
SLIDE 42
  • Brown, Simon. Distributed big balls of mud (http://

www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html)

  • Meilir Page-Jones. Practical Guide to Structured Systems Design. Prentice-Hall.

ISBN: 007-6092032779

  • Yourdon, Edward; Constantine, Larry L. (1979) [1975]. Structured Design:

Fundamentals of a Discipline of Computer Program and Systems Design. Yourdon Press. ISBN 0-13-854471-9

  • Gilb, Tom (2005). Competitive Engineering. Elsevier Butterworth-Heinemann.

ISBN 0-7506-6507-6.

  • Brown, Simon. Software Architecture for Developers. https://leanpub.com/

software-architecture-for-developers

slide-43
SLIDE 43

Principles over Patterns

(and definitely much less buzzwords)

THANK YOU!