SlideShare una empresa de Scribd logo
1 de 108
Descargar para leer sin conexión
Timeless design in a cloud-native world
Ageless foundations, gently updated and applied to modern service design

Uwe Friedrichsen – codecentric AG – 2016-2018
Uwe Friedrichsen

IT traveller.
Dot Connector.
Cartographer of uncharted territory.
Keeper of timeless wisdom.
CTO and Fellow at codecentric.

https://www.slideshare.net/ufried
https://medium.com/@ufried
 @ufried
What is cloud-native?
“Cloud native computing uses an open source software stack
to deploy applications as microservices,
packaging each part into its own container,
and dynamically orchestrating those containers
to optimize resource utilization.”

Source: Cloud Native Computing Foundation Homepage (https://www.cncf.io/)
Consequences of cloud-native computing
Different processes at runtime
Remote communication between services
Distributed system
Cloud-native computing
Services packaged in containers
Distributed systems are not limited to cloud-native computing
(Almost) every system is a distributed system

-- Chas Emerick





http://www.infoq.com/presentations/problems-distributed-systems
The software you develop and maintain is most likely
part of a (big) distributed system landscape
Consequences of distributed systems
Everything fails, all the time.
-- Werner Vogels
Failures in distributed systems ...

•  Crash failure
•  Omission failure
•  Timing failure
•  Response failure
•  Byzantine failure
... lead to a variety of effects

•  Lost messages
•  Incomplete messages
•  Duplicate messages
•  Distorted messages
•  Out-of-order message arrival
•  Partial, out-of-sync local memory
•  ...
These effects are based on the non-determinism
introduced by remote communication
due to distributed failure modes
Understand that remote communication points are
predetermined breaking points of your application

Accept that the effects will hit you at the application level
What can we do against it?
Typical measures

•  High-availability (HA) hardware/software
•  Only applicable for very small installations
•  Usually not available in cloud environments
•  Delegate failure handling to infrastructure level
•  Partial relief, will not solve all problems
•  Implement resilient software design patterns
•  Very important, still will not fix a bad design
•  Minimize number of remote communication points
•  Minimize problem surface by design
Reducing remote communication points
Reducing remote communication points
Reduce the number of
distributed runtime artifacts




i.e., create coarser grained services
Reduce the need to
communicate across
runtime artifact boundaries




i.e., get the functional design right
Reducing remote communication points
Reduce the number of
distributed runtime artifacts




i.e., create coarser grained services
Reduce the need to
communicate across
runtime artifact boundaries




i.e., get the functional design right
Remember?






https://www.martinfowler.com/articles/
distributed-objects-microservices.html
If you can get away with a monolith, just do it!

You are still allowed to structure it well ... ;)
Still, your functional domain usually will be too big
to put it all in a single monolith

Thus, you will need to distribute your system landscape to a certain degree
Rule of thumb

Always think (at least) twice before distributing functionality
Only do it if you really need independent deployments
Addendum
You may also want to distribute your functionality if you have
very disparate NFRs for different parts of your functionality
(e.g., security *, availability, reliability, scalability **, portability,
resource utilization)
* forgotten most of the time
** less often needed than most people assume
Reducing remote communication points
Reduce the number of
distributed runtime artifacts




i.e., create coarser grained services
Reduce the need to
communicate across
runtime artifact boundaries




i.e., get the functional design right
Case study

(Very simple) eCommerce shop
•  Implements the core functionalities
•  Search & show
•  Add to shopping cart
•  Checkout
•  Shipment
•  Payments only touched as black box
•  No recommendations, etc.
The typical design approach ...

a.k.a. “the counter-example”
Typical design approach

Focus on avoiding redundancy and maximizing reuse

1.  Start with a comprehensive domain (actually: E/R) model
*
*
*
*
Customer

•  name
•  address
•  payment methods
E
Order

•  customer
•  payment information
•  shipping information
•  order items
•  product
•  quantity
E
Product

•  name
•  description
•  image(s)
•  price
•  items in stock
•  packaging information
(size, weight, special care)
E
Typical design approach

Focus on avoiding redundancy and maximizing re-use

1.  Start with a comprehensive domain (actually: E/R) model
2.  Wrap entities with services
CustomerService
S
Customer
 OrderService
S
Order
ProductService
S
Product
Typical design approach

Focus on avoiding redundancy and maximizing re-use

1.  Start with a comprehensive domain (actually: E/R) model
2.  Wrap entities with services
3.  Spread functionality over services
ProductService
OrderService
CustomerService
S
Customer
 OrderService

•  Add to shopping cart
S
ProductService

•  Search/show
S
Order
Product
Typical design approach

Focus on avoiding redundancy and maximizing re-use

1.  Start with a comprehensive domain (actually: E/R) model
2.  Wrap entities with services
3.  Spread functionality over services
4.  Add “process services” for “complex use cases”
•  i.e., use cases that touch more than one data service
CustomerService
S
Customer
 OrderService

•  Add to shopping cart
S
ProductService

•  Search/show
S
Order
Product
CheckoutService

•  Checkout
S
ShipmentService

•  Shipment
S
Typical design approach

Focus on avoiding redundancy and maximizing re-use

1.  Start with a comprehensive domain (actually: E/R) model
2.  Wrap entities with services
3.  Spread functionality over services
4.  Add “process services” for “complex use cases”
•  i.e., use cases that touch more than one data service
5.  Add missing data maintenance use cases
CustomerService
ProductService

•  Search/show
CustomerService

•  Customer self care
S
Customer
 OrderService

•  Add to shopping cart
S
ProductService

•  Search/show
•  Product catalog
maintenance
S
CheckoutService

•  Checkout
S
ShipmentService

•  Shipment
S
Order
Product
This (familiar) design looks innocuous at first sight

But how good is it in terms of remote communication?
CheckoutService
 OrderService
 ProductService
 CustomerService
 Payment Provider
<proceed to checkout>
read order
read price
loop [order items]
calculate price
read payment methods
<show price and ask
for payment method>
<proceed to payment>
pay
mark paid
<report back completion>
ShipmentService
 OrderService
 ProductService
 CustomerService
 Delivery Provider
<initiate shipment>
read order
read product and packaging information
loop [order items]
read delivery address
<show shipment
information>
<parcel(s) packed –
initiate delivery>
inform delivery provider
mark dispatched
update items in stock
loop [order items]
Findings



•  Core business use cases are failure-prone and slow
•  Data maintenance use cases are robust and fast
Congratulations!

You designed a system for a company
that's core business purpose is
to maintain data, not to make money!
Properties of the design
•  Focus on avoiding redundancy and maximizing reuse
•  Based on traditional OO design practices
•  Results in high coupling between services
•  Results in moderate cohesion inside services
•  Okay for CRUD applications
•  But then better use a generator, scaffolding framework, ...
•  Okay-ish for single-process applications
•  Tends to affect maintainability negatively
•  Not okay for distributed services
•  Big failure surface, bad response times
How can we do better?
Let’s do a bit of research ...
Structured design

by W. P. Stevens, G. J. Myers and L. L. Constantine




[Stev 1974]
“The fewer and simpler the connections between modules, the easier it is to
understand each module without reference to other modules.

Minimizing connections between modules also minimizes the paths
along which changes and errors can propagate into other parts of the
system, thus eliminating disastrous ‘ripple’ effects, where changes in one
part cause errors in another, necessitating additional changes elsewhere,
giving rise to new errors, etc.”

[Ste 1974]
“Coupling is the measure of the strength of association
established by a connection from one module to another.”

[Ste 1974]
Coupling
High
Low
Contributing factors
Interface
Complexity
Type of
Connection
Type of
Communication
Simple,
obvious
Complicated,
obscure
To module
by name
(depending
on interface)
To internal
elements
(depending on
implementation)
Data
(control flow handled
by environment)
Control
(Explicit passing
of control)
Hybrid
(Manipulation of internal
control flow by parameters)
[Ste 1974]
Realize that this paper was written at a very different time
and in a very different context than we face today

While the core concepts are timeless and still valid,
we usually need to rethink the concrete instructions
Contributing factors
Interface
Complexity
Type of
Connection
Type of
Communication
Simple,
obvious
Complicated,
obscure
To module
by name
(depending
on interface)
To internal
elements
(depending on
implementation)
Data
(control flow handled
by environment)
Control
(Explicit passing
of control)
Hybrid
(Manipulation of internal
control flow by parameters)
* Ability of a service to complete its task without the other service being present
Functional
Independence*
Independent
(does not need other
service to work)
Fully dependent
(does not work
without other service)
Partly dependent
(graceful degradation
of service)
Coupling
High
Low
“Coupling is reduced when the relationships among elements not in the
same module are minimized.

There are two ways of achieving this – minimizing the relationships among
modules and maximizing relationships among elements in the same
module. In practice, both ways are used. [...]

Binding is the measure of the cohesiveness of a module. The objective
here is to reduce coupling by striving for high binding.”

[Ste 1974]
On the criteria to be
used in decomposing
systems into modules

by David L. Parnas


[Par 1972]
“The effectiveness of a ‘modularization’ is dependent upon the criteria used in
dividing the system into modules.”

“The second decomposition was made using "information hiding" as a
criterion. [...] Every module in the second decomposition is characterized by
its knowledge of a design decision which it hides from all others. Its
interface or definition was chosen to reveal as little as possible about its
inner workings.”

“There are a number of design decisions which are questionable and likely to
change under many circumstances. [...] By looking at these changes we can
see the differences between the two modularizations.”


[Par 1972]
Separation of concerns

One concept/decision per module
Information hiding

Reveal as little as possible about
internal implementation
+
Better changeability

Changes are kept local
Independent teams

Teams can easier work
independently on different modules
Easier to comprehend

Modules can be understood on
their own easier
Research findings
•  High cohesion, low coupling leads the right way
•  Separation of Concerns and Information hiding
support implementing them
•  Concrete paper instructions should not be followed blindly
•  Different context (single process, very limited hardware)
•  Would lead to nano or pico services à lots of remote calls
•  You need to rethink instructions in the current context
•  Required for all CS papers from a different time & context
•  Leads to concept of Functional Independence in this context
•  Reduces risk of “vertical decomposition” (i.e., layered design)
<uses>
Functionality
vertical decomposition
(layer design, composition)
In practice, you typically
use a combination
of both approaches
Core functional decomposition approaches
horizontal decomposition
(pillar design, segregation)
Vertical decomposition

•  Based on “uses” relation
•  Typical drivers are reuse and avoidance of redundancy
•  Creates strong coupling (high functional dependence)
•  Often useful pattern inside a process boundary
•  Due to deterministic communication behavior
•  Problematic across process boundaries
à Should be avoided in service design
Horizontal decomposition

•  Based on functional segregation
•  Typical drivers are autonomy and independence
•  Creates low coupling (high functional independence)
•  Useful pattern across process boundaries
•  Can also be useful inside a process boundary
•  Less accidental "ripple" effects due to changes
à Should be preferred in service design
Watch out!

•  Vertical decomposition is our default design approach
•  We’ve learned it in our CS education (divide and conquer, ...)
•  It’s emphasized in our daily work (DRY, reusability, ...)
•  Even our IDEs support it (“Extract method”)
•  It's everywhere! It's predominant!
•  It takes energy not to apply vertical decomposition
•  Most people never learned horizontal decomposition
How to learn horizontal decomposition?
Domain-Driven Design

by Eric Evans


[Eva 2004]
DDD to the rescue?

•  Naive application of building block patterns leads
to the counter-example design we have seen before
•  Not useful in our context due to high coupling
•  “Service” pattern leads to process service working on entities
•  Anti-pattern in our context due to high coupling
•  “Conceptual contours” supports high cohesion
•  Yet, tends to be too fine grained for our context
•  “Bounded contexts” supports low coupling
•  Yet, tends to be too coarse grained for our context
à Mixed emotions: Good, but not the expected panacea
And now?
For good service design, look at the behavior first, not the data
Case study

(Very simple) eCommerce shop
•  Implements the core functionalities
•  Search & show
•  Add to shopping cart
•  Checkout
•  Shipment
•  Customer self-care
•  Product catalog maintenance
•  Payments only touched as black box
•  No recommendations, etc.
Core reasoning

To reduce the number of remote calls needed for a given functionality,
we need to spread the functionality between the services in a way
that a single use case/user interaction less often needs to cross service
boundaries.

Therefore, we try to organize services around use cases/user interactions.
Search & Show
Add to
shopping cart
Checkout
Shipment
Customer
self-care
Product catalog
maintenance
eCommerce shop
Customer
Back office
employee
Warehouse
employee
Search & Show
Add to
shopping cart
Checkout
Shipment
Customer
self-care
Product catalog
maintenance
eCommerce shop
Customer
Back office
employee
Warehouse
employee
Three different actors
•  Indicator for cohesion boundaries
•  (At least) three different UIs
•  Could be completely different architectures
•  Depending on user needs, usage patterns and other NFRs
•  As an architect this gives you additional options
Search & Show
Add to
shopping cart
Checkout
Shipment
Customer
self-care
Product catalog
maintenance
eCommerce shop
Customer
Back office
employee
Warehouse
employee
Could be a mobile-first FE
with service-oriented backend
Could be a special warehouse device FE
with a monolithic backend
Could be a rich
desktop app
Could be a
desktop browser
first FE with a
service-oriented
backend
Search & Show
Add to
shopping cart
Checkout
Shipment
Customer
self-care
Product catalog
maintenance
Behavior-based design approach

Focus on minimum cross-service communication
inside a use case/user interaction

1.  Each use case/user interaction is a service candidate
ProductCatalogService

•  Product catalog
maintenance
S
ShipmentService

•  Shipment
S
CustomerMDService *

•  Customer self care
S
ShoppingCartService

•  Add to shopping cart
S
CheckoutService

•  Checkout
S
SearchService

•  Search/show
S
* MD = Master Data
Behavior-based design approach

Focus on minimum cross-service communication
inside a use case/user interaction

1.  Each use case/user interaction is a service candidate
2.  Possibly split big use cases in multiple services
•  Only if really needed (e.g., multiple teams, disparate NFRs)
•  Look for functional clusters with low coupling between them
ShoppingCartService

•  Add to shopping cart
S
CheckoutService

•  Checkout
S
SearchService

•  Search/show
S
ProductCatalogService

•  Product catalog
maintenance
S
ShipmentService

•  Shipment
S
CustomerMDService

•  Customer self care
S
Splitting up use cases in multiple services not needed in this example
Behavior-based design approach

Focus on minimum cross-service communication
inside a use case/user interaction

1.  Each use case/user interaction is a service candidate
2.  Possibly split big use cases in multiple services
•  Only if really needed (e.g., multiple teams, disparate NFRs)
•  Look for functional clusters with low coupling between them
3.  Try to group several use cases in a single service
•  Strive for a sweet spot in terms of an overall trade-off
•  Look for service candidates that operate on the same data
ShoppingCartService

•  Add to shopping cart
S
ProductCatalogService

•  Product catalog
maintenance
S
CheckoutService

•  Checkout
S
ShipmentService

•  Shipment
S
SearchService

•  Search/show
S
CustomerMDService

•  Customer self care
S
Product catalog
Customer master data
Shopping cart
 Buying order
Inventory data / shipping order
 Product catalog
ShoppingCartService

•  Add to shopping cart
S
ProductCatalogService

•  Product catalog
maintenance
S
CheckoutService

•  Checkout
S
ShipmentService

•  Shipment
S
SearchService

•  Search/show
S
CustomerMDService

•  Customer self care
S
Product catalog
Customer master data
Shopping cart
 Buying order
Inventory data / shipping order
 Product catalog
Service candidates working on the same data
Architectural reasoning

•  Same data ...
•  ... but different actors

•  Option to work on a single product catalog database
here outweighs different actors using a single service

à  Unite in one service
(unless you decide to use a different architectural style
for the back office employee application)
ShoppingCartService

•  Add to shopping cart
S
ProductCatalogService

•  Product catalog
maintenance
•  Search/show
S
CheckoutService

•  Checkout
S
ShipmentService

•  Shipment
S
CustomerMDService

•  Customer self care
S
Customer master data
Shopping cart
 Buying order
Inventory data / shipping order
Product catalog
ShoppingCartService

•  Add to shopping cart
S
ProductCatalogService

•  Product catalog
maintenance
•  Search/show
S
CheckoutService

•  Checkout
S
ShipmentService

•  Shipment
S
CustomerMDService

•  Customer self care
S
Customer master data
Shopping cart
 Buying order
Inventory data / shipping order
Product catalog
Service candidates
working on the
same type of data
(shopping cart is a
preliminary order)
Architectural reasoning

•  Some (sequential) cohesion and could work on same data ...
•  ... but unification is still not imperative

•  Need to ponder other aspects and balance trade-offs
•  Different representations for shopping cart and order needed?
•  UI part of the service?
•  How does payment interfere (not considered in the example)?

à  Here we assume that it is best to unite the services
ProductCatalogService

•  Product catalog
maintenance
•  Search/show
S
OrderCreationService

•  Add to shopping cart
•  Checkout
S
ShipmentService

•  Shipment
S
CustomerMDService

•  Customer self care
S
Customer master data
Shopping cart / buying order
Inventory data / shipping order
Product catalog
Additional reasoning

•  Buying order vs. shipping order
•  Less commonalities than shopping cart and buying order
•  Shipping order is only “ephemeral” entity
•  Different actors using them
à Keep them separated (we need a signaling mechanism then)
•  Who updates items in stock?
•  No longer part of product catalog maintenance
•  Warehouse employee responsible (more reasonable anyway)
à Add additional use case “Fill up inventory”
CustomerMDService

•  Customer self care
S
Customer master data
OrderCreationService

•  Add to shopping cart
•  Checkout
S
Shopping cart / buying order
WarehouseService

•  Shipment
•  Fill up inventory
S
Inventory data / shipping order
ProductCatalogService

•  Product catalog
maintenance
•  Search/show
S
Product catalog
Nice, but is this design any better?

Again: How good is it in terms of remote communication?
CheckoutService
 Payment Provider
<proceed to checkout>
<show price and ask
for payment method>
<proceed to payment>
pay
<report back completion>
calculate price
WarehouseService
 Delivery Provider
inform delivery provider
<initiate shipment>
<show shipment
information>
<parcel(s) packed –
initiate delivery>
update items in stock
Findings




•  All use cases are robust and fast
Side note: It is not always as nice and simple as in this example
Hmm, any trade-offs?
1st law of architectural work:

Every decision has its price.
No decision is for free.

(Translation: No decision only has upsides. Every decision also has downsides.)
2nd law of architectural work:

A decision can only be evaluated
with respect to its context.

(Translation: Decisions are not invariably “good” or “bad”, but only in a given context.)
Trade-offs of the approach


•  Biggest concern: What about the data?
•  Data replication and reconciliation
•  Entity distribution (no single source of truth for an entity)
•  Question cannot be answered in general
•  Here we will evaluate it with respect to the given example
•  Plus some general considerations (but no general evaluation)
*
*
*
*
Customer

•  name
•  address
•  payment methods
E
Order

•  customer
•  payment information
•  shipping information
•  order items
•  product
•  quantity
E
Product

•  name
•  description
•  image(s)
•  price
•  items in stock
•  packaging information
(size, weight, special care)
E
This diagram is misleading!
*
*
*
*
Customer

•  name
•  address
•  payment methods
E
Order

•  customer
•  payment information
•  shipping information
•  order items
•  product
•  quantity
E
Product

•  name
•  description
•  image(s)
•  price
•  items in stock
•  packaging information
(size, weight, special care)
E
Only used as copy template
Only relevant for search/show
Only relevant for checkout
Just an ID for
business related
referencing purposes
Only relevant for checkout
(including invoice address)
Only relevant for shipment
Only relevant for shipment
(including delivery address)
Different for checkout and shipment
(only IDs and quantities needed) 
Immutable after completion
(all data copied into order)
CustomerMDService

•  Customer self care
S
Customer master data
OrderCreationService

•  Add to shopping cart
•  Checkout
S
Shopping cart /
buying order
WarehouseService

•  Shipment
•  Fill up inventory
S
Inventory data / shipping order
ProductCatalogService

•  Product catalog
maintenance
•  Search/show
S
Product catalog
Putting these use cases in a
single service avoids the need
for data replication
3
3
3
Putting these use cases in a
single service avoids the need
for data signaling
4
4
Needs to signal data
for shipment order

(signaling mechanism required)
2
2
2
Needs to copy some
product (and customer) data
into the order

(could be handled by the frontend)
1
1
1
1
Findings


•  All use cases are robust and fast
•  Minimal need to transfer data between services
•  Solvable via frontend and standard data transfer solution
(batch file, transfer table, message queue, ...)
•  No data replication and reconciliation solution needed

Side note: It is not always as nice and simple as in this example
Still, it is not always that nice and easy

Translation: There are situations where two or more copies of the same data need to be kept in sync
CustomerMDService

•  Customer self care
S
Customer master data
OrderCreationService

•  Add to shopping cart
•  Checkout
S
Shopping cart /
buying order
WarehouseService

•  Shipment
•  Fill up inventory
S
Inventory data / shipping order
ProductCatalogService

•  Product catalog
maintenance
•  Search/show
S
Product catalog
Might want to allow update
of payment methods in the
context of customer self care
and checkout

(requires two-way synchronization
of master data after change)
1
1
1
Might want to allow adding
items to shopping cart only if
items are in stock

(requires one-way synchronization
of transactional data after change)
2
2
2
It might even hit us
in our example
How can we keep the data in sync?
Options to keep data in sync

•  Shared database
•  Compromises original reasoning to use services
•  Distributed transactions (2-phase commit)
•  Tight coupling compromises service independence
•  Compromises availability and scalability
•  Eventual consistency
•  Sufficient for basically all functional requirements
•  Supports low coupling and high availability
•  Downside: Much harder programming model than ACID TX
✖
✖
✔
Options for eventual consistency
•  Batch pull
•  Consumer pulls data batch when ready to process data
•  Very robust approach (also suitable for legacy integration)
•  Data sync delay may be longer than acceptable
•  Batch bootstrapping & delta push
•  Initial state sync via batch pull, then push of delta updates
•  Often combined with event sourcing, CQRS, reactive, ...
•  Fast, robust (if done right) and still quite lightweight
•  Distributed log
•  Offers advantages of previous approach in one technology
•  Kafka currently is the best-known implementation
•  Still have a plan how to recover if the tool breaks
And the single source of truth issue?
Pondering single source of truth



•  Usually task for analytical data processing
•  Orthogonal, well-understood issue
•  Many solutions available
•  Sometimes needed in transactional systems (e.g., CRM)
•  Question if it is really a need or just a habit
•  Strive for eventual consistency
•  Go for event streams or distributed logs for fast updates
Wrap-up
Wrap-up
•  Think (at least) twice before distributing functionality
•  Strive for low coupling, support with high cohesion
•  Prefer horizontal decomposition in service design
•  Favor functional independence over reuse
•  The magic is in the behavior, not the data
•  Employ use cases to find service boundaries
•  Prefer eventual consistency for data synchronization
•  Value the timeless wisdom
•  But update the instructions to the given current context
Uwe Friedrichsen

IT traveller.
Dot Connector.
Cartographer of uncharted territory.
Keeper of timeless wisdom.
CTO and Fellow at codecentric.

https://www.slideshare.net/ufried
https://medium.com/@ufried
 @ufried

Más contenido relacionado

La actualidad más candente

Design Pattern in Software Engineering
Design Pattern in Software EngineeringDesign Pattern in Software Engineering
Design Pattern in Software EngineeringManish Kumar
 
Docker 101 - Nov 2016
Docker 101 - Nov 2016Docker 101 - Nov 2016
Docker 101 - Nov 2016Docker, Inc.
 
Devops - vision et pratiques
Devops - vision et pratiquesDevops - vision et pratiques
Devops - vision et pratiquesJoseph Glorieux
 
docker installation and basics
docker installation and basicsdocker installation and basics
docker installation and basicsWalid Ashraf
 
Continuous integration
Continuous integrationContinuous integration
Continuous integrationamscanne
 
Test Automation Tool comparison – HP UFT/QTP vs. Selenium
Test Automation Tool comparison –  HP UFT/QTP vs. SeleniumTest Automation Tool comparison –  HP UFT/QTP vs. Selenium
Test Automation Tool comparison – HP UFT/QTP vs. SeleniumAspire Systems
 
Release With Maven
Release With MavenRelease With Maven
Release With Maveneugenn
 
Software Development Methodologies
Software Development MethodologiesSoftware Development Methodologies
Software Development MethodologiesNicholas Davis
 
Software product line
Software product lineSoftware product line
Software product lineHimanshu
 
Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)Mohamed Sami El-Tahawy
 
Introduction à DevOps
Introduction à DevOpsIntroduction à DevOps
Introduction à DevOpsMicrosoft
 
Rational Unified Process
Rational Unified ProcessRational Unified Process
Rational Unified ProcessKumar
 
Devel::NYTProf 2009-07 (OUTDATED, see 201008)
Devel::NYTProf 2009-07 (OUTDATED, see 201008)Devel::NYTProf 2009-07 (OUTDATED, see 201008)
Devel::NYTProf 2009-07 (OUTDATED, see 201008)Tim Bunce
 
Lect-4: Software Development Life Cycle Model - SPM
Lect-4: Software Development Life Cycle Model - SPMLect-4: Software Development Life Cycle Model - SPM
Lect-4: Software Development Life Cycle Model - SPMMubashir Ali
 
Introduction to Docker - 2017
Introduction to Docker - 2017Introduction to Docker - 2017
Introduction to Docker - 2017Docker, Inc.
 
Tadx - Présentation Conteneurisation
Tadx -  Présentation ConteneurisationTadx -  Présentation Conteneurisation
Tadx - Présentation ConteneurisationTADx
 
Software development PROCESS
Software development PROCESSSoftware development PROCESS
Software development PROCESSIvano Malavolta
 
An Introduction to Test Driven Development
An Introduction to Test Driven Development An Introduction to Test Driven Development
An Introduction to Test Driven Development CodeOps Technologies LLP
 
AGILE Model (SDLC).pptx
AGILE Model (SDLC).pptxAGILE Model (SDLC).pptx
AGILE Model (SDLC).pptxMahithDias
 

La actualidad más candente (20)

Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)
 
Design Pattern in Software Engineering
Design Pattern in Software EngineeringDesign Pattern in Software Engineering
Design Pattern in Software Engineering
 
Docker 101 - Nov 2016
Docker 101 - Nov 2016Docker 101 - Nov 2016
Docker 101 - Nov 2016
 
Devops - vision et pratiques
Devops - vision et pratiquesDevops - vision et pratiques
Devops - vision et pratiques
 
docker installation and basics
docker installation and basicsdocker installation and basics
docker installation and basics
 
Continuous integration
Continuous integrationContinuous integration
Continuous integration
 
Test Automation Tool comparison – HP UFT/QTP vs. Selenium
Test Automation Tool comparison –  HP UFT/QTP vs. SeleniumTest Automation Tool comparison –  HP UFT/QTP vs. Selenium
Test Automation Tool comparison – HP UFT/QTP vs. Selenium
 
Release With Maven
Release With MavenRelease With Maven
Release With Maven
 
Software Development Methodologies
Software Development MethodologiesSoftware Development Methodologies
Software Development Methodologies
 
Software product line
Software product lineSoftware product line
Software product line
 
Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)
 
Introduction à DevOps
Introduction à DevOpsIntroduction à DevOps
Introduction à DevOps
 
Rational Unified Process
Rational Unified ProcessRational Unified Process
Rational Unified Process
 
Devel::NYTProf 2009-07 (OUTDATED, see 201008)
Devel::NYTProf 2009-07 (OUTDATED, see 201008)Devel::NYTProf 2009-07 (OUTDATED, see 201008)
Devel::NYTProf 2009-07 (OUTDATED, see 201008)
 
Lect-4: Software Development Life Cycle Model - SPM
Lect-4: Software Development Life Cycle Model - SPMLect-4: Software Development Life Cycle Model - SPM
Lect-4: Software Development Life Cycle Model - SPM
 
Introduction to Docker - 2017
Introduction to Docker - 2017Introduction to Docker - 2017
Introduction to Docker - 2017
 
Tadx - Présentation Conteneurisation
Tadx -  Présentation ConteneurisationTadx -  Présentation Conteneurisation
Tadx - Présentation Conteneurisation
 
Software development PROCESS
Software development PROCESSSoftware development PROCESS
Software development PROCESS
 
An Introduction to Test Driven Development
An Introduction to Test Driven Development An Introduction to Test Driven Development
An Introduction to Test Driven Development
 
AGILE Model (SDLC).pptx
AGILE Model (SDLC).pptxAGILE Model (SDLC).pptx
AGILE Model (SDLC).pptx
 

Similar a Timeless design in a cloud-native world

Software Architectures, Week 3 - Microservice-based Architectures
Software Architectures, Week 3 - Microservice-based ArchitecturesSoftware Architectures, Week 3 - Microservice-based Architectures
Software Architectures, Week 3 - Microservice-based ArchitecturesAngelos Kapsimanis
 
Declare Victory with Big Data
Declare Victory with Big DataDeclare Victory with Big Data
Declare Victory with Big DataJ On The Beach
 
Microservices architecture
Microservices architectureMicroservices architecture
Microservices architectureFaren faren
 
Microsoft Microservices
Microsoft MicroservicesMicrosoft Microservices
Microsoft MicroservicesChase Aucoin
 
Microservices Architecture - Cloud Native Apps
Microservices Architecture - Cloud Native AppsMicroservices Architecture - Cloud Native Apps
Microservices Architecture - Cloud Native AppsAraf Karsh Hamid
 
Microservices - stress-free and without increased heart attack risk
Microservices - stress-free and without increased heart attack riskMicroservices - stress-free and without increased heart attack risk
Microservices - stress-free and without increased heart attack riskUwe Friedrichsen
 
Microservices - stress-free and without increased heart-attack risk - Uwe Fri...
Microservices - stress-free and without increased heart-attack risk - Uwe Fri...Microservices - stress-free and without increased heart-attack risk - Uwe Fri...
Microservices - stress-free and without increased heart-attack risk - Uwe Fri...distributed matters
 
SOA (Service Oriented Architecture)
SOA (Service Oriented Architecture)SOA (Service Oriented Architecture)
SOA (Service Oriented Architecture)Annie Comp
 
CWIN17 Utrecht / cg u services - frank van der wal
CWIN17 Utrecht / cg u services - frank van der walCWIN17 Utrecht / cg u services - frank van der wal
CWIN17 Utrecht / cg u services - frank van der walCapgemini
 
building microservices
building microservicesbuilding microservices
building microservicesCisco DevNet
 
MuCon 2015 - Microservices in Integration Architecture
MuCon 2015 - Microservices in Integration ArchitectureMuCon 2015 - Microservices in Integration Architecture
MuCon 2015 - Microservices in Integration ArchitectureKim Clark
 
Microservices Gone Wrong!
Microservices Gone Wrong!Microservices Gone Wrong!
Microservices Gone Wrong!Bert Ertman
 
Technology insights: Decision Science Platform
Technology insights: Decision Science PlatformTechnology insights: Decision Science Platform
Technology insights: Decision Science PlatformDecision Science Community
 
Accelerate Delivery: Business case for Agile DevOps, CI/CD and Microservices
Accelerate Delivery: Business case for Agile DevOps, CI/CD and MicroservicesAccelerate Delivery: Business case for Agile DevOps, CI/CD and Microservices
Accelerate Delivery: Business case for Agile DevOps, CI/CD and MicroservicesRick Hightower
 
Kubernetes solutions
Kubernetes solutionsKubernetes solutions
Kubernetes solutionsEric Cattoir
 
The Reality of Managing Microservices in Your CD Pipeline
The Reality of Managing Microservices in Your CD PipelineThe Reality of Managing Microservices in Your CD Pipeline
The Reality of Managing Microservices in Your CD PipelineDevOps.com
 

Similar a Timeless design in a cloud-native world (20)

Software Architectures, Week 3 - Microservice-based Architectures
Software Architectures, Week 3 - Microservice-based ArchitecturesSoftware Architectures, Week 3 - Microservice-based Architectures
Software Architectures, Week 3 - Microservice-based Architectures
 
Declare Victory with Big Data
Declare Victory with Big DataDeclare Victory with Big Data
Declare Victory with Big Data
 
Microservices architecture
Microservices architectureMicroservices architecture
Microservices architecture
 
Microservices Architecture
Microservices ArchitectureMicroservices Architecture
Microservices Architecture
 
Microsoft Microservices
Microsoft MicroservicesMicrosoft Microservices
Microsoft Microservices
 
Let's talk about... Microservices
Let's talk about... MicroservicesLet's talk about... Microservices
Let's talk about... Microservices
 
Microservices Architecture - Cloud Native Apps
Microservices Architecture - Cloud Native AppsMicroservices Architecture - Cloud Native Apps
Microservices Architecture - Cloud Native Apps
 
Microservices - stress-free and without increased heart attack risk
Microservices - stress-free and without increased heart attack riskMicroservices - stress-free and without increased heart attack risk
Microservices - stress-free and without increased heart attack risk
 
Microservices - stress-free and without increased heart-attack risk - Uwe Fri...
Microservices - stress-free and without increased heart-attack risk - Uwe Fri...Microservices - stress-free and without increased heart-attack risk - Uwe Fri...
Microservices - stress-free and without increased heart-attack risk - Uwe Fri...
 
SOA (Service Oriented Architecture)
SOA (Service Oriented Architecture)SOA (Service Oriented Architecture)
SOA (Service Oriented Architecture)
 
CWIN17 Utrecht / cg u services - frank van der wal
CWIN17 Utrecht / cg u services - frank van der walCWIN17 Utrecht / cg u services - frank van der wal
CWIN17 Utrecht / cg u services - frank van der wal
 
building microservices
building microservicesbuilding microservices
building microservices
 
Cloud computing
Cloud computingCloud computing
Cloud computing
 
MuCon 2015 - Microservices in Integration Architecture
MuCon 2015 - Microservices in Integration ArchitectureMuCon 2015 - Microservices in Integration Architecture
MuCon 2015 - Microservices in Integration Architecture
 
Microservices why?
Microservices   why?Microservices   why?
Microservices why?
 
Microservices Gone Wrong!
Microservices Gone Wrong!Microservices Gone Wrong!
Microservices Gone Wrong!
 
Technology insights: Decision Science Platform
Technology insights: Decision Science PlatformTechnology insights: Decision Science Platform
Technology insights: Decision Science Platform
 
Accelerate Delivery: Business case for Agile DevOps, CI/CD and Microservices
Accelerate Delivery: Business case for Agile DevOps, CI/CD and MicroservicesAccelerate Delivery: Business case for Agile DevOps, CI/CD and Microservices
Accelerate Delivery: Business case for Agile DevOps, CI/CD and Microservices
 
Kubernetes solutions
Kubernetes solutionsKubernetes solutions
Kubernetes solutions
 
The Reality of Managing Microservices in Your CD Pipeline
The Reality of Managing Microservices in Your CD PipelineThe Reality of Managing Microservices in Your CD Pipeline
The Reality of Managing Microservices in Your CD Pipeline
 

Más de Uwe Friedrichsen

The hitchhiker's guide for the confused developer
The hitchhiker's guide for the confused developerThe hitchhiker's guide for the confused developer
The hitchhiker's guide for the confused developerUwe Friedrichsen
 
Digitization solutions - A new breed of software
Digitization solutions - A new breed of softwareDigitization solutions - A new breed of software
Digitization solutions - A new breed of softwareUwe Friedrichsen
 
Real-world consistency explained
Real-world consistency explainedReal-world consistency explained
Real-world consistency explainedUwe Friedrichsen
 
Excavating the knowledge of our ancestors
Excavating the knowledge of our ancestorsExcavating the knowledge of our ancestors
Excavating the knowledge of our ancestorsUwe Friedrichsen
 
The truth about "You build it, you run it!"
The truth about "You build it, you run it!"The truth about "You build it, you run it!"
The truth about "You build it, you run it!"Uwe Friedrichsen
 
The promises and perils of microservices
The promises and perils of microservicesThe promises and perils of microservices
The promises and perils of microservicesUwe Friedrichsen
 
Resilience reloaded - more resilience patterns
Resilience reloaded - more resilience patternsResilience reloaded - more resilience patterns
Resilience reloaded - more resilience patternsUwe Friedrichsen
 
DevOps is not enough - Embedding DevOps in a broader context
DevOps is not enough - Embedding DevOps in a broader contextDevOps is not enough - Embedding DevOps in a broader context
DevOps is not enough - Embedding DevOps in a broader contextUwe Friedrichsen
 
Towards complex adaptive architectures
Towards complex adaptive architecturesTowards complex adaptive architectures
Towards complex adaptive architecturesUwe Friedrichsen
 
Conway's law revisited - Architectures for an effective IT
Conway's law revisited - Architectures for an effective ITConway's law revisited - Architectures for an effective IT
Conway's law revisited - Architectures for an effective ITUwe Friedrichsen
 
Modern times - architectures for a Next Generation of IT
Modern times - architectures for a Next Generation of ITModern times - architectures for a Next Generation of IT
Modern times - architectures for a Next Generation of ITUwe Friedrichsen
 
The Next Generation (of) IT
The Next Generation (of) ITThe Next Generation (of) IT
The Next Generation (of) ITUwe Friedrichsen
 
Why resilience - A primer at varying flight altitudes
Why resilience - A primer at varying flight altitudesWhy resilience - A primer at varying flight altitudes
Why resilience - A primer at varying flight altitudesUwe Friedrichsen
 

Más de Uwe Friedrichsen (20)

Deep learning - a primer
Deep learning - a primerDeep learning - a primer
Deep learning - a primer
 
Life after microservices
Life after microservicesLife after microservices
Life after microservices
 
The hitchhiker's guide for the confused developer
The hitchhiker's guide for the confused developerThe hitchhiker's guide for the confused developer
The hitchhiker's guide for the confused developer
 
Digitization solutions - A new breed of software
Digitization solutions - A new breed of softwareDigitization solutions - A new breed of software
Digitization solutions - A new breed of software
 
Real-world consistency explained
Real-world consistency explainedReal-world consistency explained
Real-world consistency explained
 
Excavating the knowledge of our ancestors
Excavating the knowledge of our ancestorsExcavating the knowledge of our ancestors
Excavating the knowledge of our ancestors
 
The truth about "You build it, you run it!"
The truth about "You build it, you run it!"The truth about "You build it, you run it!"
The truth about "You build it, you run it!"
 
The promises and perils of microservices
The promises and perils of microservicesThe promises and perils of microservices
The promises and perils of microservices
 
Watch your communication
Watch your communicationWatch your communication
Watch your communication
 
Life, IT and everything
Life, IT and everythingLife, IT and everything
Life, IT and everything
 
Resilience reloaded - more resilience patterns
Resilience reloaded - more resilience patternsResilience reloaded - more resilience patterns
Resilience reloaded - more resilience patterns
 
DevOps is not enough - Embedding DevOps in a broader context
DevOps is not enough - Embedding DevOps in a broader contextDevOps is not enough - Embedding DevOps in a broader context
DevOps is not enough - Embedding DevOps in a broader context
 
Production-ready Software
Production-ready SoftwareProduction-ready Software
Production-ready Software
 
Towards complex adaptive architectures
Towards complex adaptive architecturesTowards complex adaptive architectures
Towards complex adaptive architectures
 
Conway's law revisited - Architectures for an effective IT
Conway's law revisited - Architectures for an effective ITConway's law revisited - Architectures for an effective IT
Conway's law revisited - Architectures for an effective IT
 
Patterns of resilience
Patterns of resiliencePatterns of resilience
Patterns of resilience
 
Modern times - architectures for a Next Generation of IT
Modern times - architectures for a Next Generation of ITModern times - architectures for a Next Generation of IT
Modern times - architectures for a Next Generation of IT
 
The Next Generation (of) IT
The Next Generation (of) ITThe Next Generation (of) IT
The Next Generation (of) IT
 
Why resilience - A primer at varying flight altitudes
Why resilience - A primer at varying flight altitudesWhy resilience - A primer at varying flight altitudes
Why resilience - A primer at varying flight altitudes
 
No stress with state
No stress with stateNo stress with state
No stress with state
 

Último

Boost Fertility New Invention Ups Success Rates.pdf
Boost Fertility New Invention Ups Success Rates.pdfBoost Fertility New Invention Ups Success Rates.pdf
Boost Fertility New Invention Ups Success Rates.pdfsudhanshuwaghmare1
 
Automating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps ScriptAutomating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps Scriptwesley chun
 
GenCyber Cyber Security Day Presentation
GenCyber Cyber Security Day PresentationGenCyber Cyber Security Day Presentation
GenCyber Cyber Security Day PresentationMichael W. Hawkins
 
Histor y of HAM Radio presentation slide
Histor y of HAM Radio presentation slideHistor y of HAM Radio presentation slide
Histor y of HAM Radio presentation slidevu2urc
 
Real Time Object Detection Using Open CV
Real Time Object Detection Using Open CVReal Time Object Detection Using Open CV
Real Time Object Detection Using Open CVKhem
 
Tata AIG General Insurance Company - Insurer Innovation Award 2024
Tata AIG General Insurance Company - Insurer Innovation Award 2024Tata AIG General Insurance Company - Insurer Innovation Award 2024
Tata AIG General Insurance Company - Insurer Innovation Award 2024The Digital Insurer
 
The Codex of Business Writing Software for Real-World Solutions 2.pptx
The Codex of Business Writing Software for Real-World Solutions 2.pptxThe Codex of Business Writing Software for Real-World Solutions 2.pptx
The Codex of Business Writing Software for Real-World Solutions 2.pptxMalak Abu Hammad
 
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdfUnderstanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdfUK Journal
 
A Domino Admins Adventures (Engage 2024)
A Domino Admins Adventures (Engage 2024)A Domino Admins Adventures (Engage 2024)
A Domino Admins Adventures (Engage 2024)Gabriella Davis
 
Scaling API-first – The story of a global engineering organization
Scaling API-first – The story of a global engineering organizationScaling API-first – The story of a global engineering organization
Scaling API-first – The story of a global engineering organizationRadu Cotescu
 
The 7 Things I Know About Cyber Security After 25 Years | April 2024
The 7 Things I Know About Cyber Security After 25 Years | April 2024The 7 Things I Know About Cyber Security After 25 Years | April 2024
The 7 Things I Know About Cyber Security After 25 Years | April 2024Rafal Los
 
TrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
TrustArc Webinar - Stay Ahead of US State Data Privacy Law DevelopmentsTrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
TrustArc Webinar - Stay Ahead of US State Data Privacy Law DevelopmentsTrustArc
 
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024The Digital Insurer
 
A Year of the Servo Reboot: Where Are We Now?
A Year of the Servo Reboot: Where Are We Now?A Year of the Servo Reboot: Where Are We Now?
A Year of the Servo Reboot: Where Are We Now?Igalia
 
🐬 The future of MySQL is Postgres 🐘
🐬  The future of MySQL is Postgres   🐘🐬  The future of MySQL is Postgres   🐘
🐬 The future of MySQL is Postgres 🐘RTylerCroy
 
2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...Martijn de Jong
 
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...apidays
 
Slack Application Development 101 Slides
Slack Application Development 101 SlidesSlack Application Development 101 Slides
Slack Application Development 101 Slidespraypatel2
 
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...Igalia
 
Powerful Google developer tools for immediate impact! (2023-24 C)
Powerful Google developer tools for immediate impact! (2023-24 C)Powerful Google developer tools for immediate impact! (2023-24 C)
Powerful Google developer tools for immediate impact! (2023-24 C)wesley chun
 

Último (20)

Boost Fertility New Invention Ups Success Rates.pdf
Boost Fertility New Invention Ups Success Rates.pdfBoost Fertility New Invention Ups Success Rates.pdf
Boost Fertility New Invention Ups Success Rates.pdf
 
Automating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps ScriptAutomating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps Script
 
GenCyber Cyber Security Day Presentation
GenCyber Cyber Security Day PresentationGenCyber Cyber Security Day Presentation
GenCyber Cyber Security Day Presentation
 
Histor y of HAM Radio presentation slide
Histor y of HAM Radio presentation slideHistor y of HAM Radio presentation slide
Histor y of HAM Radio presentation slide
 
Real Time Object Detection Using Open CV
Real Time Object Detection Using Open CVReal Time Object Detection Using Open CV
Real Time Object Detection Using Open CV
 
Tata AIG General Insurance Company - Insurer Innovation Award 2024
Tata AIG General Insurance Company - Insurer Innovation Award 2024Tata AIG General Insurance Company - Insurer Innovation Award 2024
Tata AIG General Insurance Company - Insurer Innovation Award 2024
 
The Codex of Business Writing Software for Real-World Solutions 2.pptx
The Codex of Business Writing Software for Real-World Solutions 2.pptxThe Codex of Business Writing Software for Real-World Solutions 2.pptx
The Codex of Business Writing Software for Real-World Solutions 2.pptx
 
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdfUnderstanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
 
A Domino Admins Adventures (Engage 2024)
A Domino Admins Adventures (Engage 2024)A Domino Admins Adventures (Engage 2024)
A Domino Admins Adventures (Engage 2024)
 
Scaling API-first – The story of a global engineering organization
Scaling API-first – The story of a global engineering organizationScaling API-first – The story of a global engineering organization
Scaling API-first – The story of a global engineering organization
 
The 7 Things I Know About Cyber Security After 25 Years | April 2024
The 7 Things I Know About Cyber Security After 25 Years | April 2024The 7 Things I Know About Cyber Security After 25 Years | April 2024
The 7 Things I Know About Cyber Security After 25 Years | April 2024
 
TrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
TrustArc Webinar - Stay Ahead of US State Data Privacy Law DevelopmentsTrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
TrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
 
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
 
A Year of the Servo Reboot: Where Are We Now?
A Year of the Servo Reboot: Where Are We Now?A Year of the Servo Reboot: Where Are We Now?
A Year of the Servo Reboot: Where Are We Now?
 
🐬 The future of MySQL is Postgres 🐘
🐬  The future of MySQL is Postgres   🐘🐬  The future of MySQL is Postgres   🐘
🐬 The future of MySQL is Postgres 🐘
 
2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...
 
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...
 
Slack Application Development 101 Slides
Slack Application Development 101 SlidesSlack Application Development 101 Slides
Slack Application Development 101 Slides
 
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
 
Powerful Google developer tools for immediate impact! (2023-24 C)
Powerful Google developer tools for immediate impact! (2023-24 C)Powerful Google developer tools for immediate impact! (2023-24 C)
Powerful Google developer tools for immediate impact! (2023-24 C)
 

Timeless design in a cloud-native world

  • 1. Timeless design in a cloud-native world Ageless foundations, gently updated and applied to modern service design Uwe Friedrichsen – codecentric AG – 2016-2018
  • 2. Uwe Friedrichsen IT traveller. Dot Connector. Cartographer of uncharted territory. Keeper of timeless wisdom. CTO and Fellow at codecentric. https://www.slideshare.net/ufried https://medium.com/@ufried @ufried
  • 4. “Cloud native computing uses an open source software stack to deploy applications as microservices, packaging each part into its own container, and dynamically orchestrating those containers to optimize resource utilization.” Source: Cloud Native Computing Foundation Homepage (https://www.cncf.io/)
  • 6. Different processes at runtime Remote communication between services Distributed system Cloud-native computing Services packaged in containers
  • 7. Distributed systems are not limited to cloud-native computing
  • 8. (Almost) every system is a distributed system -- Chas Emerick http://www.infoq.com/presentations/problems-distributed-systems
  • 9. The software you develop and maintain is most likely part of a (big) distributed system landscape
  • 11. Everything fails, all the time. -- Werner Vogels
  • 12. Failures in distributed systems ... •  Crash failure •  Omission failure •  Timing failure •  Response failure •  Byzantine failure
  • 13. ... lead to a variety of effects •  Lost messages •  Incomplete messages •  Duplicate messages •  Distorted messages •  Out-of-order message arrival •  Partial, out-of-sync local memory •  ...
  • 14. These effects are based on the non-determinism introduced by remote communication due to distributed failure modes
  • 15. Understand that remote communication points are predetermined breaking points of your application Accept that the effects will hit you at the application level
  • 16. What can we do against it?
  • 17. Typical measures •  High-availability (HA) hardware/software •  Only applicable for very small installations •  Usually not available in cloud environments •  Delegate failure handling to infrastructure level •  Partial relief, will not solve all problems •  Implement resilient software design patterns •  Very important, still will not fix a bad design •  Minimize number of remote communication points •  Minimize problem surface by design
  • 19. Reducing remote communication points Reduce the number of distributed runtime artifacts i.e., create coarser grained services Reduce the need to communicate across runtime artifact boundaries i.e., get the functional design right
  • 20. Reducing remote communication points Reduce the number of distributed runtime artifacts i.e., create coarser grained services Reduce the need to communicate across runtime artifact boundaries i.e., get the functional design right
  • 22. If you can get away with a monolith, just do it! You are still allowed to structure it well ... ;)
  • 23. Still, your functional domain usually will be too big to put it all in a single monolith Thus, you will need to distribute your system landscape to a certain degree
  • 24. Rule of thumb Always think (at least) twice before distributing functionality Only do it if you really need independent deployments Addendum You may also want to distribute your functionality if you have very disparate NFRs for different parts of your functionality (e.g., security *, availability, reliability, scalability **, portability, resource utilization) * forgotten most of the time ** less often needed than most people assume
  • 25. Reducing remote communication points Reduce the number of distributed runtime artifacts i.e., create coarser grained services Reduce the need to communicate across runtime artifact boundaries i.e., get the functional design right
  • 26. Case study (Very simple) eCommerce shop •  Implements the core functionalities •  Search & show •  Add to shopping cart •  Checkout •  Shipment •  Payments only touched as black box •  No recommendations, etc.
  • 27. The typical design approach ... a.k.a. “the counter-example”
  • 28. Typical design approach Focus on avoiding redundancy and maximizing reuse 1.  Start with a comprehensive domain (actually: E/R) model
  • 29. * * * * Customer •  name •  address •  payment methods E Order •  customer •  payment information •  shipping information •  order items •  product •  quantity E Product •  name •  description •  image(s) •  price •  items in stock •  packaging information (size, weight, special care) E
  • 30. Typical design approach Focus on avoiding redundancy and maximizing re-use 1.  Start with a comprehensive domain (actually: E/R) model 2.  Wrap entities with services
  • 32. Typical design approach Focus on avoiding redundancy and maximizing re-use 1.  Start with a comprehensive domain (actually: E/R) model 2.  Wrap entities with services 3.  Spread functionality over services
  • 33. ProductService OrderService CustomerService S Customer OrderService •  Add to shopping cart S ProductService •  Search/show S Order Product
  • 34. Typical design approach Focus on avoiding redundancy and maximizing re-use 1.  Start with a comprehensive domain (actually: E/R) model 2.  Wrap entities with services 3.  Spread functionality over services 4.  Add “process services” for “complex use cases” •  i.e., use cases that touch more than one data service
  • 35. CustomerService S Customer OrderService •  Add to shopping cart S ProductService •  Search/show S Order Product CheckoutService •  Checkout S ShipmentService •  Shipment S
  • 36. Typical design approach Focus on avoiding redundancy and maximizing re-use 1.  Start with a comprehensive domain (actually: E/R) model 2.  Wrap entities with services 3.  Spread functionality over services 4.  Add “process services” for “complex use cases” •  i.e., use cases that touch more than one data service 5.  Add missing data maintenance use cases
  • 37. CustomerService ProductService •  Search/show CustomerService •  Customer self care S Customer OrderService •  Add to shopping cart S ProductService •  Search/show •  Product catalog maintenance S CheckoutService •  Checkout S ShipmentService •  Shipment S Order Product
  • 38. This (familiar) design looks innocuous at first sight But how good is it in terms of remote communication?
  • 39. CheckoutService OrderService ProductService CustomerService Payment Provider <proceed to checkout> read order read price loop [order items] calculate price read payment methods <show price and ask for payment method> <proceed to payment> pay mark paid <report back completion>
  • 40. ShipmentService OrderService ProductService CustomerService Delivery Provider <initiate shipment> read order read product and packaging information loop [order items] read delivery address <show shipment information> <parcel(s) packed – initiate delivery> inform delivery provider mark dispatched update items in stock loop [order items]
  • 41. Findings •  Core business use cases are failure-prone and slow •  Data maintenance use cases are robust and fast
  • 42. Congratulations! You designed a system for a company that's core business purpose is to maintain data, not to make money!
  • 43. Properties of the design •  Focus on avoiding redundancy and maximizing reuse •  Based on traditional OO design practices •  Results in high coupling between services •  Results in moderate cohesion inside services •  Okay for CRUD applications •  But then better use a generator, scaffolding framework, ... •  Okay-ish for single-process applications •  Tends to affect maintainability negatively •  Not okay for distributed services •  Big failure surface, bad response times
  • 44. How can we do better?
  • 45. Let’s do a bit of research ...
  • 46. Structured design by W. P. Stevens, G. J. Myers and L. L. Constantine [Stev 1974]
  • 47. “The fewer and simpler the connections between modules, the easier it is to understand each module without reference to other modules. Minimizing connections between modules also minimizes the paths along which changes and errors can propagate into other parts of the system, thus eliminating disastrous ‘ripple’ effects, where changes in one part cause errors in another, necessitating additional changes elsewhere, giving rise to new errors, etc.” [Ste 1974]
  • 48. “Coupling is the measure of the strength of association established by a connection from one module to another.” [Ste 1974]
  • 49. Coupling High Low Contributing factors Interface Complexity Type of Connection Type of Communication Simple, obvious Complicated, obscure To module by name (depending on interface) To internal elements (depending on implementation) Data (control flow handled by environment) Control (Explicit passing of control) Hybrid (Manipulation of internal control flow by parameters) [Ste 1974]
  • 50. Realize that this paper was written at a very different time and in a very different context than we face today While the core concepts are timeless and still valid, we usually need to rethink the concrete instructions
  • 51. Contributing factors Interface Complexity Type of Connection Type of Communication Simple, obvious Complicated, obscure To module by name (depending on interface) To internal elements (depending on implementation) Data (control flow handled by environment) Control (Explicit passing of control) Hybrid (Manipulation of internal control flow by parameters) * Ability of a service to complete its task without the other service being present Functional Independence* Independent (does not need other service to work) Fully dependent (does not work without other service) Partly dependent (graceful degradation of service) Coupling High Low
  • 52. “Coupling is reduced when the relationships among elements not in the same module are minimized. There are two ways of achieving this – minimizing the relationships among modules and maximizing relationships among elements in the same module. In practice, both ways are used. [...] Binding is the measure of the cohesiveness of a module. The objective here is to reduce coupling by striving for high binding.” [Ste 1974]
  • 53. On the criteria to be used in decomposing systems into modules by David L. Parnas [Par 1972]
  • 54. “The effectiveness of a ‘modularization’ is dependent upon the criteria used in dividing the system into modules.” “The second decomposition was made using "information hiding" as a criterion. [...] Every module in the second decomposition is characterized by its knowledge of a design decision which it hides from all others. Its interface or definition was chosen to reveal as little as possible about its inner workings.” “There are a number of design decisions which are questionable and likely to change under many circumstances. [...] By looking at these changes we can see the differences between the two modularizations.” [Par 1972]
  • 55. Separation of concerns One concept/decision per module Information hiding Reveal as little as possible about internal implementation + Better changeability Changes are kept local Independent teams Teams can easier work independently on different modules Easier to comprehend Modules can be understood on their own easier
  • 56. Research findings •  High cohesion, low coupling leads the right way •  Separation of Concerns and Information hiding support implementing them •  Concrete paper instructions should not be followed blindly •  Different context (single process, very limited hardware) •  Would lead to nano or pico services à lots of remote calls •  You need to rethink instructions in the current context •  Required for all CS papers from a different time & context •  Leads to concept of Functional Independence in this context •  Reduces risk of “vertical decomposition” (i.e., layered design)
  • 57. <uses> Functionality vertical decomposition (layer design, composition) In practice, you typically use a combination of both approaches Core functional decomposition approaches horizontal decomposition (pillar design, segregation)
  • 58. Vertical decomposition •  Based on “uses” relation •  Typical drivers are reuse and avoidance of redundancy •  Creates strong coupling (high functional dependence) •  Often useful pattern inside a process boundary •  Due to deterministic communication behavior •  Problematic across process boundaries à Should be avoided in service design
  • 59. Horizontal decomposition •  Based on functional segregation •  Typical drivers are autonomy and independence •  Creates low coupling (high functional independence) •  Useful pattern across process boundaries •  Can also be useful inside a process boundary •  Less accidental "ripple" effects due to changes à Should be preferred in service design
  • 60. Watch out! •  Vertical decomposition is our default design approach •  We’ve learned it in our CS education (divide and conquer, ...) •  It’s emphasized in our daily work (DRY, reusability, ...) •  Even our IDEs support it (“Extract method”) •  It's everywhere! It's predominant! •  It takes energy not to apply vertical decomposition •  Most people never learned horizontal decomposition
  • 61. How to learn horizontal decomposition?
  • 62. Domain-Driven Design by Eric Evans [Eva 2004]
  • 63. DDD to the rescue? •  Naive application of building block patterns leads to the counter-example design we have seen before •  Not useful in our context due to high coupling •  “Service” pattern leads to process service working on entities •  Anti-pattern in our context due to high coupling •  “Conceptual contours” supports high cohesion •  Yet, tends to be too fine grained for our context •  “Bounded contexts” supports low coupling •  Yet, tends to be too coarse grained for our context à Mixed emotions: Good, but not the expected panacea
  • 65. For good service design, look at the behavior first, not the data
  • 66. Case study (Very simple) eCommerce shop •  Implements the core functionalities •  Search & show •  Add to shopping cart •  Checkout •  Shipment •  Customer self-care •  Product catalog maintenance •  Payments only touched as black box •  No recommendations, etc.
  • 67. Core reasoning To reduce the number of remote calls needed for a given functionality, we need to spread the functionality between the services in a way that a single use case/user interaction less often needs to cross service boundaries. Therefore, we try to organize services around use cases/user interactions.
  • 68. Search & Show Add to shopping cart Checkout Shipment Customer self-care Product catalog maintenance eCommerce shop Customer Back office employee Warehouse employee
  • 69. Search & Show Add to shopping cart Checkout Shipment Customer self-care Product catalog maintenance eCommerce shop Customer Back office employee Warehouse employee Three different actors •  Indicator for cohesion boundaries •  (At least) three different UIs •  Could be completely different architectures •  Depending on user needs, usage patterns and other NFRs •  As an architect this gives you additional options
  • 70. Search & Show Add to shopping cart Checkout Shipment Customer self-care Product catalog maintenance eCommerce shop Customer Back office employee Warehouse employee Could be a mobile-first FE with service-oriented backend Could be a special warehouse device FE with a monolithic backend Could be a rich desktop app Could be a desktop browser first FE with a service-oriented backend
  • 71. Search & Show Add to shopping cart Checkout Shipment Customer self-care Product catalog maintenance
  • 72. Behavior-based design approach Focus on minimum cross-service communication inside a use case/user interaction 1.  Each use case/user interaction is a service candidate
  • 73. ProductCatalogService •  Product catalog maintenance S ShipmentService •  Shipment S CustomerMDService * •  Customer self care S ShoppingCartService •  Add to shopping cart S CheckoutService •  Checkout S SearchService •  Search/show S * MD = Master Data
  • 74. Behavior-based design approach Focus on minimum cross-service communication inside a use case/user interaction 1.  Each use case/user interaction is a service candidate 2.  Possibly split big use cases in multiple services •  Only if really needed (e.g., multiple teams, disparate NFRs) •  Look for functional clusters with low coupling between them
  • 75. ShoppingCartService •  Add to shopping cart S CheckoutService •  Checkout S SearchService •  Search/show S ProductCatalogService •  Product catalog maintenance S ShipmentService •  Shipment S CustomerMDService •  Customer self care S Splitting up use cases in multiple services not needed in this example
  • 76. Behavior-based design approach Focus on minimum cross-service communication inside a use case/user interaction 1.  Each use case/user interaction is a service candidate 2.  Possibly split big use cases in multiple services •  Only if really needed (e.g., multiple teams, disparate NFRs) •  Look for functional clusters with low coupling between them 3.  Try to group several use cases in a single service •  Strive for a sweet spot in terms of an overall trade-off •  Look for service candidates that operate on the same data
  • 77. ShoppingCartService •  Add to shopping cart S ProductCatalogService •  Product catalog maintenance S CheckoutService •  Checkout S ShipmentService •  Shipment S SearchService •  Search/show S CustomerMDService •  Customer self care S Product catalog Customer master data Shopping cart Buying order Inventory data / shipping order Product catalog
  • 78. ShoppingCartService •  Add to shopping cart S ProductCatalogService •  Product catalog maintenance S CheckoutService •  Checkout S ShipmentService •  Shipment S SearchService •  Search/show S CustomerMDService •  Customer self care S Product catalog Customer master data Shopping cart Buying order Inventory data / shipping order Product catalog Service candidates working on the same data
  • 79. Architectural reasoning •  Same data ... •  ... but different actors •  Option to work on a single product catalog database here outweighs different actors using a single service à  Unite in one service (unless you decide to use a different architectural style for the back office employee application)
  • 80. ShoppingCartService •  Add to shopping cart S ProductCatalogService •  Product catalog maintenance •  Search/show S CheckoutService •  Checkout S ShipmentService •  Shipment S CustomerMDService •  Customer self care S Customer master data Shopping cart Buying order Inventory data / shipping order Product catalog
  • 81. ShoppingCartService •  Add to shopping cart S ProductCatalogService •  Product catalog maintenance •  Search/show S CheckoutService •  Checkout S ShipmentService •  Shipment S CustomerMDService •  Customer self care S Customer master data Shopping cart Buying order Inventory data / shipping order Product catalog Service candidates working on the same type of data (shopping cart is a preliminary order)
  • 82. Architectural reasoning •  Some (sequential) cohesion and could work on same data ... •  ... but unification is still not imperative •  Need to ponder other aspects and balance trade-offs •  Different representations for shopping cart and order needed? •  UI part of the service? •  How does payment interfere (not considered in the example)? à  Here we assume that it is best to unite the services
  • 83. ProductCatalogService •  Product catalog maintenance •  Search/show S OrderCreationService •  Add to shopping cart •  Checkout S ShipmentService •  Shipment S CustomerMDService •  Customer self care S Customer master data Shopping cart / buying order Inventory data / shipping order Product catalog
  • 84. Additional reasoning •  Buying order vs. shipping order •  Less commonalities than shopping cart and buying order •  Shipping order is only “ephemeral” entity •  Different actors using them à Keep them separated (we need a signaling mechanism then) •  Who updates items in stock? •  No longer part of product catalog maintenance •  Warehouse employee responsible (more reasonable anyway) à Add additional use case “Fill up inventory”
  • 85. CustomerMDService •  Customer self care S Customer master data OrderCreationService •  Add to shopping cart •  Checkout S Shopping cart / buying order WarehouseService •  Shipment •  Fill up inventory S Inventory data / shipping order ProductCatalogService •  Product catalog maintenance •  Search/show S Product catalog
  • 86. Nice, but is this design any better? Again: How good is it in terms of remote communication?
  • 87. CheckoutService Payment Provider <proceed to checkout> <show price and ask for payment method> <proceed to payment> pay <report back completion> calculate price
  • 88. WarehouseService Delivery Provider inform delivery provider <initiate shipment> <show shipment information> <parcel(s) packed – initiate delivery> update items in stock
  • 89. Findings •  All use cases are robust and fast Side note: It is not always as nice and simple as in this example
  • 91. 1st law of architectural work: Every decision has its price. No decision is for free. (Translation: No decision only has upsides. Every decision also has downsides.)
  • 92. 2nd law of architectural work: A decision can only be evaluated with respect to its context. (Translation: Decisions are not invariably “good” or “bad”, but only in a given context.)
  • 93. Trade-offs of the approach •  Biggest concern: What about the data? •  Data replication and reconciliation •  Entity distribution (no single source of truth for an entity) •  Question cannot be answered in general •  Here we will evaluate it with respect to the given example •  Plus some general considerations (but no general evaluation)
  • 94. * * * * Customer •  name •  address •  payment methods E Order •  customer •  payment information •  shipping information •  order items •  product •  quantity E Product •  name •  description •  image(s) •  price •  items in stock •  packaging information (size, weight, special care) E This diagram is misleading!
  • 95. * * * * Customer •  name •  address •  payment methods E Order •  customer •  payment information •  shipping information •  order items •  product •  quantity E Product •  name •  description •  image(s) •  price •  items in stock •  packaging information (size, weight, special care) E Only used as copy template Only relevant for search/show Only relevant for checkout Just an ID for business related referencing purposes Only relevant for checkout (including invoice address) Only relevant for shipment Only relevant for shipment (including delivery address) Different for checkout and shipment (only IDs and quantities needed) Immutable after completion (all data copied into order)
  • 96. CustomerMDService •  Customer self care S Customer master data OrderCreationService •  Add to shopping cart •  Checkout S Shopping cart / buying order WarehouseService •  Shipment •  Fill up inventory S Inventory data / shipping order ProductCatalogService •  Product catalog maintenance •  Search/show S Product catalog Putting these use cases in a single service avoids the need for data replication 3 3 3 Putting these use cases in a single service avoids the need for data signaling 4 4 Needs to signal data for shipment order (signaling mechanism required) 2 2 2 Needs to copy some product (and customer) data into the order (could be handled by the frontend) 1 1 1 1
  • 97. Findings •  All use cases are robust and fast •  Minimal need to transfer data between services •  Solvable via frontend and standard data transfer solution (batch file, transfer table, message queue, ...) •  No data replication and reconciliation solution needed Side note: It is not always as nice and simple as in this example
  • 98. Still, it is not always that nice and easy Translation: There are situations where two or more copies of the same data need to be kept in sync
  • 99. CustomerMDService •  Customer self care S Customer master data OrderCreationService •  Add to shopping cart •  Checkout S Shopping cart / buying order WarehouseService •  Shipment •  Fill up inventory S Inventory data / shipping order ProductCatalogService •  Product catalog maintenance •  Search/show S Product catalog Might want to allow update of payment methods in the context of customer self care and checkout (requires two-way synchronization of master data after change) 1 1 1 Might want to allow adding items to shopping cart only if items are in stock (requires one-way synchronization of transactional data after change) 2 2 2 It might even hit us in our example
  • 100. How can we keep the data in sync?
  • 101. Options to keep data in sync •  Shared database •  Compromises original reasoning to use services •  Distributed transactions (2-phase commit) •  Tight coupling compromises service independence •  Compromises availability and scalability •  Eventual consistency •  Sufficient for basically all functional requirements •  Supports low coupling and high availability •  Downside: Much harder programming model than ACID TX ✖ ✖ ✔
  • 102. Options for eventual consistency •  Batch pull •  Consumer pulls data batch when ready to process data •  Very robust approach (also suitable for legacy integration) •  Data sync delay may be longer than acceptable •  Batch bootstrapping & delta push •  Initial state sync via batch pull, then push of delta updates •  Often combined with event sourcing, CQRS, reactive, ... •  Fast, robust (if done right) and still quite lightweight •  Distributed log •  Offers advantages of previous approach in one technology •  Kafka currently is the best-known implementation •  Still have a plan how to recover if the tool breaks
  • 103. And the single source of truth issue?
  • 104. Pondering single source of truth •  Usually task for analytical data processing •  Orthogonal, well-understood issue •  Many solutions available •  Sometimes needed in transactional systems (e.g., CRM) •  Question if it is really a need or just a habit •  Strive for eventual consistency •  Go for event streams or distributed logs for fast updates
  • 106. Wrap-up •  Think (at least) twice before distributing functionality •  Strive for low coupling, support with high cohesion •  Prefer horizontal decomposition in service design •  Favor functional independence over reuse •  The magic is in the behavior, not the data •  Employ use cases to find service boundaries •  Prefer eventual consistency for data synchronization •  Value the timeless wisdom •  But update the instructions to the given current context
  • 107.
  • 108. Uwe Friedrichsen IT traveller. Dot Connector. Cartographer of uncharted territory. Keeper of timeless wisdom. CTO and Fellow at codecentric. https://www.slideshare.net/ufried https://medium.com/@ufried @ufried