SlideShare a Scribd company logo
1 of 78
Download to read offline
Architectural Decisions: Smoothly
and Consistently
Andrei Shakirin
VMware Tanzu Labs
Agenda
● Architector role and Architecture definitions
● Cases, when architecture decisions hurt team (*)
○ Context
○ Observations (what happens)
○ Solution and lesson learned
○ Discussion
● Conclusion
* Examples was taken from VMWare Tanzu Labs, TYMIQ GmbH and INNOQ projects
About Me
- Software Engineer at VMWare Tanzu Labs
- Committer in Spring and Apache projects
- Co-founder Tymiq GmbH
- Speaker at technical conferences
Architecture Definitions
⟨system⟩ fundamental concepts or
properties of a system in its
environment embodied in its
elements, relationships, and in the
principles of its design and evolution
(ISO 42010)
Architecture represents the significant
design decisions that shape a system,
where significant is measured by cost
of change." -- Grady Booch.
Architecture is anything that team
considers important enough for
the system development and
evolving
Architecture is NOT:
Upfront activity performed by somebody in charge of telling
everyone else what to do
It is not a description or a document, it is a property of your
system or even: it is your system (intentional or accidental)
What is Good Architecture?
What is the good car?
ISO Software Product Quality
Sounds clear and obvious, but people still missing this
Simple
Admin GUI
Twitter
Netflix
Facebook
Amazon
Insurance policy
managment system
Scaling vs Complexity
Written over weekend
Some users
Half of planet
German tax low
Google Search
ChatGTP
Cases Structure
• Context
• Observation
• Lesson learned
• Discussion
#1 Painful shared responsibility
Context
• E-Commerce shop
• Migration from E-Commerce framework
• Development team 30 -> 100 persons
Online Shop Design
Customer Domain Article Domain Order Domain
User Service Cart Service Article Service Order Service
SAP
Messaging
REST REST REST REST
Core Domain
DAOs
DB DB DB
SAP Connector Messaging Connector
• Modification and maintenance of common domains
is hard
• Deployment in single container causes dependencies
and fragility between teams
• Migrations to new versions of Java, Hibernate, CXF
are extremely difficult and took very long time
Observation
Step 1: Split Codebase due Domain Code Duplication
User Customer
Domain
Checkout
Article Domain
Order Domain
User Service Cart Service Checkout Service Order Service
SAP
Messaging
REST REST REST REST
User Core
Domain
DAOs
DB
Container
Cart Customer
Domain
Cart Core
Domain
Core Order
Domain
Cart Article
Domain
Checkout Core
Domain
Core
framework as
thridparty
15
Step 2: Extract Services with High Availability Requirements
Gateway
Old Service2
inside Monolith
Price&Availability
Microservice
Monolith container
Consumer 1 Consumer 2 Consumer 3
Routing / Canary release
90% 10%
Old Service1
inside Monolith
Old Service3
inside Mnolith
• Service belongs to different
bounded context and has multiple
rates of change
• Request load is essentially higher
(or lower) as rest monolith
components
• Service has independent lifecycle
• Service isolates external system
dependency
• Service uses innovative
technology
Step 3: Decentralize Data Management
Docker
Order Service
REST
R
E
S
T
Docker
Checkout
Service
REST
R
E
S
T
Docker
Cart Service
REST
R
E
S
T
Docker
User Service
REST
R
E
S
T
SAP
Messaging
DB
DB
DB DB
• Think twice before share module, especially across bounded
contexts
• Duplication is less critical as common dependencies
• Common utils can be treated as third party libraries and
make them as thin as possible
• Making decisions, system evolving and maintenance inside
team is a lot of easier as a cross teams
• Clear teams responsibility is important
Lessons Learned
#2 Non-extensible extensibility
Context
• E-Commerce (retail) provider
• Global customer base
• Platform for the clients that served their clients
• Catalog/CMS/Shop/Fulfilment
• Multi-tenant
• Highly customizable
Large
strategic
customers
Small
customers
The solution
General
Low
High
Specific
Costs
Customization
grade
• If you attempt to satisfy everyone, you will likely end up
to satisfying no one
• Specific solution is often more preferable as highly
configurable one
• Complex configuration often evolves to discovering own
programming language
Lessons Learned
#3 Microservices is the solution for all problems
• Bookkeeping software
• Synchronization with online payment transactions
• 6 developers team
Context
Architecture
Transaction
Service
Transaction
Fetcher
Scheduled
Job
REST API
Internal
Storage
Online
Payment
Provider
Consumer Consumer Consumer
• Legacy technology
• Code difficult to support and maintain
• Hard to extend for new payment providers
Problems reported by customer
• Split to microservices to make code maintainable
• Microservices architecture will help to make architecture
more extensible
Initial plan from customer
• There is only single bounded context
• Both modules service and job belong to this bounded
context
• There is single business domain model
• Splitting to other modules / microservices doesn’t make
sense at all and can make problems even worse
Analyse shows
• Service and Job were rewritten using TDD and pair
programming
• Both modules were migrated to SpringBoot, Spring Batch was
used for Job to get monitoring out of the box
• Huge amount of optimizations were done
• Both modules shared the same database and data model
Final Solution
• Unnecessary splitting of modules belonging in the same
bounded context can cause more problems in
architecture
• Microservices is not universal solution and wouldn’t
improved bad design automatically
• The main reasons of splitting are: business subdomain,
scalability requirements, lifecycle, failure isolation,
different technology stack
Lessons Learned
#4 Your system WILL be dynamic
Context
• Large scale insurance system
• Model driven development
• 2 releases per year
• > 100 developers (more maintain)
Lessons learned
• Centralized responsibity hurts
• Faced too much rigidity, people always find a way around
the rules
#5 Horizontal Split
Context
• Platfom for trains control
• Straightforward business logic
• High scalability requirements
• 10 developers
Group 2
„You can‘t build reliable progams with
Java Script“
Group 1
„Java is legacy programming
language: Cobol of these days“
JSON API
Java Backend
HTML/CSS/JavaScript/Frontend
• Any feature requires communication between the teams
• One group should wait for another one
• If backend systems are unresponsive, frontend teams
quickly becomes secret „full stack“
From a Layered System …
and backend only split …
… to a system of systems
#6 Over fine-grained
• Large scale B2B food retailer
• New company wide shop and international logistic system
• 40 in the beginning, > 200 developers
Context
Tiny small Microservices:
Problem is overlapping:
Order Service
Order Service
Checkout Support Fullfilment Billing
Order Service
Checkout Support Fullfilment Billing
Lessons learned
• Small is not always beatifull
• Not what is popular is automatically useful (CDD, HDD)
• Don’t copy somebody else architecture unless you sure
your context is identical
#7 Cargo Cult
Melanesian Islanders Cargo Cult
Symtpoms
• Ritual inclusion of code or program structures that serve no
real purpose (redundant checks for null values, testing
whether a collection is empty before iterating )
• Copying existing code with little understanding of how it
works
• Applying a design pattern or coding style blindly without
understanding the reasons behind that design principle
• Trying to make system too flexible: adopting different types
of databases, configuration sources, communication
protocols even if they do not really needed
Context
• Framework to discover, configure and secure web
services
• Customer is flight modelling company
• 10 developers
Design
Database
Repository Layer
Model Layer
Configuration
Layer
API Layer
Configuration technical
service
Repository
Repository Layer
Wiring Layer
Artifact Layer
API Layer
Service Registry
SQL, Non-SQL DBs
Impl 2, 3
File, DB, Git
Other repos
Other wirings
Impl 2, 3
Mapping
Mapping
Mapping
Mapping
Mapping
Mapping
… …
Communication
abstraction
Communication
abstraction
http://
Queue
Lessons learned
• Abstractions in system design are often leaky
• Build new layers carefully: not because of fashion, coolness or
dreams
• Be pragmatic for now, but predict system evolving
• Upfront architecture often leads to over-engineering
#8 Improve with less intelligence
Context
• Bank with multiple collection of the shelf systems
• Highly proprietary integration solution phased out
by vendor
Visual Mapping Tool
• No Unit Test
• No CI/CD
• …
Java
adapters
Lessons learned
• Smart endpoints, dumb pipes (even with cool names)
• Value of specific over generic solutions
#9 Free style architecture
Context
• E-Commerce online shop / retail
• 100-120 developers
• 10 self contained teams
Coupling
methods
modules
components
micro services
systems
Decoupling
Number of
develpers
System of systems architecture
But …
• Luck of standartization led to ineffecient UI integration at
runtime (integration was done at hock)
• Vast differences in API style, formats, documentation created
needless extra work (json+hal, json+saron)
You cannot decide to not have an architecture; if you don‘t
actively create it, be prepare to deal with the one what emerges
There is a fine line between diversity (that adds value) and chaos
(that doesn‘t)
Extremely loose coupling requires a few rules, but they need to
be enforced strictly
Takeaways
• Don‘t be afraid about architecture
• Choose the simplest thing that will work
• Create evolvable structures, manage architecural evolution
• Don‘t built road blocks, create value and get out of the way
76
Sharing Modules and Services
Team A
Module A
Team B
API
Module A
API
Module B
Team A
Service A
Team B
API
Service B
API
77
Sharing Modules and Services
Team A
Module A
Team B
API
Module A
API
Module B
Team A
Service A
Team B
API
Service B
API
78
Shared Responsibility
Team A Team B
Module A
API
development
development

More Related Content

Similar to Architectural Decisions: Smoothly and Consistently

Understanding Microservices
Understanding Microservices Understanding Microservices
Understanding Microservices M A Hossain Tonu
 
Understanding Microservices
Understanding Microservices Understanding Microservices
Understanding Microservices M A Hossain Tonu
 
Building FoundationDB
Building FoundationDBBuilding FoundationDB
Building FoundationDBFoundationDB
 
Building FoundationDB
Building FoundationDBBuilding FoundationDB
Building FoundationDBFoundationDB
 
PHP Unconference Continuous Integration
PHP Unconference Continuous IntegrationPHP Unconference Continuous Integration
PHP Unconference Continuous IntegrationNils Hofmeister
 
PHP Unconference Continuous Integration
PHP Unconference Continuous IntegrationPHP Unconference Continuous Integration
PHP Unconference Continuous IntegrationNils Hofmeister
 
Microservices: The Best Practices
Microservices: The Best PracticesMicroservices: The Best Practices
Microservices: The Best PracticesPavel Mička
 
Microservices: The Best Practices
Microservices: The Best PracticesMicroservices: The Best Practices
Microservices: The Best PracticesPavel Mička
 
Containers, microservices and serverless for realists
Containers, microservices and serverless for realistsContainers, microservices and serverless for realists
Containers, microservices and serverless for realistsKarthik Gaekwad
 
Containers, microservices and serverless for realists
Containers, microservices and serverless for realistsContainers, microservices and serverless for realists
Containers, microservices and serverless for realistsKarthik Gaekwad
 
Why we got to Docker
Why we got to DockerWhy we got to Docker
Why we got to Dockerallingeek
 
Why we got to Docker
Why we got to DockerWhy we got to Docker
Why we got to Dockerallingeek
 
The Need of Cloud-Native Application
The Need of Cloud-Native ApplicationThe Need of Cloud-Native Application
The Need of Cloud-Native ApplicationEmiliano Pecis
 
The Need of Cloud-Native Application
The Need of Cloud-Native ApplicationThe Need of Cloud-Native Application
The Need of Cloud-Native ApplicationEmiliano Pecis
 
Microservices: Yes or not?
Microservices: Yes or not?Microservices: Yes or not?
Microservices: Yes or not?Eduard Tomàs
 
Microservices: Yes or not?
Microservices: Yes or not?Microservices: Yes or not?
Microservices: Yes or not?Eduard Tomàs
 

Similar to Architectural Decisions: Smoothly and Consistently (20)

Understanding Microservices
Understanding Microservices Understanding Microservices
Understanding Microservices
 
Understanding Microservices
Understanding Microservices Understanding Microservices
Understanding Microservices
 
Microservices.pdf
Microservices.pdfMicroservices.pdf
Microservices.pdf
 
Microservices.pdf
Microservices.pdfMicroservices.pdf
Microservices.pdf
 
Building FoundationDB
Building FoundationDBBuilding FoundationDB
Building FoundationDB
 
Building FoundationDB
Building FoundationDBBuilding FoundationDB
Building FoundationDB
 
PHP Unconference Continuous Integration
PHP Unconference Continuous IntegrationPHP Unconference Continuous Integration
PHP Unconference Continuous Integration
 
PHP Unconference Continuous Integration
PHP Unconference Continuous IntegrationPHP Unconference Continuous Integration
PHP Unconference Continuous Integration
 
Microservices: The Best Practices
Microservices: The Best PracticesMicroservices: The Best Practices
Microservices: The Best Practices
 
Microservices: The Best Practices
Microservices: The Best PracticesMicroservices: The Best Practices
Microservices: The Best Practices
 
Containers, microservices and serverless for realists
Containers, microservices and serverless for realistsContainers, microservices and serverless for realists
Containers, microservices and serverless for realists
 
Containers, microservices and serverless for realists
Containers, microservices and serverless for realistsContainers, microservices and serverless for realists
Containers, microservices and serverless for realists
 
Why we got to Docker
Why we got to DockerWhy we got to Docker
Why we got to Docker
 
Why we got to Docker
Why we got to DockerWhy we got to Docker
Why we got to Docker
 
The Need of Cloud-Native Application
The Need of Cloud-Native ApplicationThe Need of Cloud-Native Application
The Need of Cloud-Native Application
 
The Need of Cloud-Native Application
The Need of Cloud-Native ApplicationThe Need of Cloud-Native Application
The Need of Cloud-Native Application
 
Microservices: Yes or not?
Microservices: Yes or not?Microservices: Yes or not?
Microservices: Yes or not?
 
Microservices: Yes or not?
Microservices: Yes or not?Microservices: Yes or not?
Microservices: Yes or not?
 
Microservices Architecture
Microservices ArchitectureMicroservices Architecture
Microservices Architecture
 
Microservices Architecture
Microservices ArchitectureMicroservices Architecture
Microservices Architecture
 

More from Comsysto Reply GmbH

ljug-meetup-2023-03-hexagonal-architecture.pdf
ljug-meetup-2023-03-hexagonal-architecture.pdfljug-meetup-2023-03-hexagonal-architecture.pdf
ljug-meetup-2023-03-hexagonal-architecture.pdfComsysto Reply GmbH
 
Invited-Talk_PredAnalytics_München (2).pdf
Invited-Talk_PredAnalytics_München (2).pdfInvited-Talk_PredAnalytics_München (2).pdf
Invited-Talk_PredAnalytics_München (2).pdfComsysto Reply GmbH
 
MicroFrontends für Microservices
MicroFrontends für MicroservicesMicroFrontends für Microservices
MicroFrontends für MicroservicesComsysto Reply GmbH
 
Bable on Smart City Munich Meetup: How cities are leveraging innovative partn...
Bable on Smart City Munich Meetup: How cities are leveraging innovative partn...Bable on Smart City Munich Meetup: How cities are leveraging innovative partn...
Bable on Smart City Munich Meetup: How cities are leveraging innovative partn...Comsysto Reply GmbH
 
Smart City Munich Kickoff Meetup
Smart City Munich Kickoff Meetup Smart City Munich Kickoff Meetup
Smart City Munich Kickoff Meetup Comsysto Reply GmbH
 
Data Reliability Challenges with Spark by Henning Kropp (Spark & Hadoop User ...
Data Reliability Challenges with Spark by Henning Kropp (Spark & Hadoop User ...Data Reliability Challenges with Spark by Henning Kropp (Spark & Hadoop User ...
Data Reliability Challenges with Spark by Henning Kropp (Spark & Hadoop User ...Comsysto Reply GmbH
 
"Hadoop Data Lake vs classical Data Warehouse: How to utilize best of both wo...
"Hadoop Data Lake vs classical Data Warehouse: How to utilize best of both wo..."Hadoop Data Lake vs classical Data Warehouse: How to utilize best of both wo...
"Hadoop Data Lake vs classical Data Warehouse: How to utilize best of both wo...Comsysto Reply GmbH
 
Data lake vs Data Warehouse: Hybrid Architectures
Data lake vs Data Warehouse: Hybrid ArchitecturesData lake vs Data Warehouse: Hybrid Architectures
Data lake vs Data Warehouse: Hybrid ArchitecturesComsysto Reply GmbH
 
Java 9 Modularity and Project Jigsaw
Java 9 Modularity and Project JigsawJava 9 Modularity and Project Jigsaw
Java 9 Modularity and Project JigsawComsysto Reply GmbH
 
Distributed Computing and Caching in the Cloud: Hazelcast and Microsoft
Distributed Computing and Caching in the Cloud: Hazelcast and MicrosoftDistributed Computing and Caching in the Cloud: Hazelcast and Microsoft
Distributed Computing and Caching in the Cloud: Hazelcast and MicrosoftComsysto Reply GmbH
 
Grundlegende Konzepte von Elm, React und AngularDart 2 im Vergleich
Grundlegende Konzepte von Elm, React und AngularDart 2 im VergleichGrundlegende Konzepte von Elm, React und AngularDart 2 im Vergleich
Grundlegende Konzepte von Elm, React und AngularDart 2 im VergleichComsysto Reply GmbH
 
Building a fully-automated Fast Data Platform
Building a fully-automated Fast Data PlatformBuilding a fully-automated Fast Data Platform
Building a fully-automated Fast Data PlatformComsysto Reply GmbH
 
Apache Apex: Stream Processing Architecture and Applications
Apache Apex: Stream Processing Architecture and Applications Apache Apex: Stream Processing Architecture and Applications
Apache Apex: Stream Processing Architecture and Applications Comsysto Reply GmbH
 
Ein Prozess lernt laufen: LEGO Mindstorms Steuerung mit BPMN
Ein Prozess lernt laufen: LEGO Mindstorms Steuerung mit BPMNEin Prozess lernt laufen: LEGO Mindstorms Steuerung mit BPMN
Ein Prozess lernt laufen: LEGO Mindstorms Steuerung mit BPMNComsysto Reply GmbH
 
Geospatial applications created using java script(and nosql)
Geospatial applications created using java script(and nosql)Geospatial applications created using java script(and nosql)
Geospatial applications created using java script(and nosql)Comsysto Reply GmbH
 
Java cro 2016 - From.... to Scrum by Jurica Krizanic
Java cro 2016 - From.... to Scrum by Jurica KrizanicJava cro 2016 - From.... to Scrum by Jurica Krizanic
Java cro 2016 - From.... to Scrum by Jurica KrizanicComsysto Reply GmbH
 
21.04.2016 Meetup: Spark vs. Flink
21.04.2016 Meetup: Spark vs. Flink21.04.2016 Meetup: Spark vs. Flink
21.04.2016 Meetup: Spark vs. FlinkComsysto Reply GmbH
 
Spark RDD-DF-SQL-DS-Spark Hadoop User Group Munich Meetup 2016
Spark RDD-DF-SQL-DS-Spark Hadoop User Group Munich Meetup 2016Spark RDD-DF-SQL-DS-Spark Hadoop User Group Munich Meetup 2016
Spark RDD-DF-SQL-DS-Spark Hadoop User Group Munich Meetup 2016Comsysto Reply GmbH
 
Machinelearning Spark Hadoop User Group Munich Meetup 2016
Machinelearning Spark Hadoop User Group Munich Meetup 2016Machinelearning Spark Hadoop User Group Munich Meetup 2016
Machinelearning Spark Hadoop User Group Munich Meetup 2016Comsysto Reply GmbH
 

More from Comsysto Reply GmbH (20)

ljug-meetup-2023-03-hexagonal-architecture.pdf
ljug-meetup-2023-03-hexagonal-architecture.pdfljug-meetup-2023-03-hexagonal-architecture.pdf
ljug-meetup-2023-03-hexagonal-architecture.pdf
 
Invited-Talk_PredAnalytics_München (2).pdf
Invited-Talk_PredAnalytics_München (2).pdfInvited-Talk_PredAnalytics_München (2).pdf
Invited-Talk_PredAnalytics_München (2).pdf
 
MicroFrontends für Microservices
MicroFrontends für MicroservicesMicroFrontends für Microservices
MicroFrontends für Microservices
 
Alles offen = gut(ai)
Alles offen = gut(ai)Alles offen = gut(ai)
Alles offen = gut(ai)
 
Bable on Smart City Munich Meetup: How cities are leveraging innovative partn...
Bable on Smart City Munich Meetup: How cities are leveraging innovative partn...Bable on Smart City Munich Meetup: How cities are leveraging innovative partn...
Bable on Smart City Munich Meetup: How cities are leveraging innovative partn...
 
Smart City Munich Kickoff Meetup
Smart City Munich Kickoff Meetup Smart City Munich Kickoff Meetup
Smart City Munich Kickoff Meetup
 
Data Reliability Challenges with Spark by Henning Kropp (Spark & Hadoop User ...
Data Reliability Challenges with Spark by Henning Kropp (Spark & Hadoop User ...Data Reliability Challenges with Spark by Henning Kropp (Spark & Hadoop User ...
Data Reliability Challenges with Spark by Henning Kropp (Spark & Hadoop User ...
 
"Hadoop Data Lake vs classical Data Warehouse: How to utilize best of both wo...
"Hadoop Data Lake vs classical Data Warehouse: How to utilize best of both wo..."Hadoop Data Lake vs classical Data Warehouse: How to utilize best of both wo...
"Hadoop Data Lake vs classical Data Warehouse: How to utilize best of both wo...
 
Data lake vs Data Warehouse: Hybrid Architectures
Data lake vs Data Warehouse: Hybrid ArchitecturesData lake vs Data Warehouse: Hybrid Architectures
Data lake vs Data Warehouse: Hybrid Architectures
 
Java 9 Modularity and Project Jigsaw
Java 9 Modularity and Project JigsawJava 9 Modularity and Project Jigsaw
Java 9 Modularity and Project Jigsaw
 
Distributed Computing and Caching in the Cloud: Hazelcast and Microsoft
Distributed Computing and Caching in the Cloud: Hazelcast and MicrosoftDistributed Computing and Caching in the Cloud: Hazelcast and Microsoft
Distributed Computing and Caching in the Cloud: Hazelcast and Microsoft
 
Grundlegende Konzepte von Elm, React und AngularDart 2 im Vergleich
Grundlegende Konzepte von Elm, React und AngularDart 2 im VergleichGrundlegende Konzepte von Elm, React und AngularDart 2 im Vergleich
Grundlegende Konzepte von Elm, React und AngularDart 2 im Vergleich
 
Building a fully-automated Fast Data Platform
Building a fully-automated Fast Data PlatformBuilding a fully-automated Fast Data Platform
Building a fully-automated Fast Data Platform
 
Apache Apex: Stream Processing Architecture and Applications
Apache Apex: Stream Processing Architecture and Applications Apache Apex: Stream Processing Architecture and Applications
Apache Apex: Stream Processing Architecture and Applications
 
Ein Prozess lernt laufen: LEGO Mindstorms Steuerung mit BPMN
Ein Prozess lernt laufen: LEGO Mindstorms Steuerung mit BPMNEin Prozess lernt laufen: LEGO Mindstorms Steuerung mit BPMN
Ein Prozess lernt laufen: LEGO Mindstorms Steuerung mit BPMN
 
Geospatial applications created using java script(and nosql)
Geospatial applications created using java script(and nosql)Geospatial applications created using java script(and nosql)
Geospatial applications created using java script(and nosql)
 
Java cro 2016 - From.... to Scrum by Jurica Krizanic
Java cro 2016 - From.... to Scrum by Jurica KrizanicJava cro 2016 - From.... to Scrum by Jurica Krizanic
Java cro 2016 - From.... to Scrum by Jurica Krizanic
 
21.04.2016 Meetup: Spark vs. Flink
21.04.2016 Meetup: Spark vs. Flink21.04.2016 Meetup: Spark vs. Flink
21.04.2016 Meetup: Spark vs. Flink
 
Spark RDD-DF-SQL-DS-Spark Hadoop User Group Munich Meetup 2016
Spark RDD-DF-SQL-DS-Spark Hadoop User Group Munich Meetup 2016Spark RDD-DF-SQL-DS-Spark Hadoop User Group Munich Meetup 2016
Spark RDD-DF-SQL-DS-Spark Hadoop User Group Munich Meetup 2016
 
Machinelearning Spark Hadoop User Group Munich Meetup 2016
Machinelearning Spark Hadoop User Group Munich Meetup 2016Machinelearning Spark Hadoop User Group Munich Meetup 2016
Machinelearning Spark Hadoop User Group Munich Meetup 2016
 

Recently uploaded

TrustArc Webinar - How to Build Consumer Trust Through Data Privacy
TrustArc Webinar - How to Build Consumer Trust Through Data PrivacyTrustArc Webinar - How to Build Consumer Trust Through Data Privacy
TrustArc Webinar - How to Build Consumer Trust Through Data PrivacyTrustArc
 
The State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxThe State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxLoriGlavin3
 
Digital Identity is Under Attack: FIDO Paris Seminar.pptx
Digital Identity is Under Attack: FIDO Paris Seminar.pptxDigital Identity is Under Attack: FIDO Paris Seminar.pptx
Digital Identity is Under Attack: FIDO Paris Seminar.pptxLoriGlavin3
 
Visualising and forecasting stocks using Dash
Visualising and forecasting stocks using DashVisualising and forecasting stocks using Dash
Visualising and forecasting stocks using Dashnarutouzumaki53779
 
From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .Alan Dix
 
Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!Commit University
 
A Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptxA Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptxLoriGlavin3
 
What is DBT - The Ultimate Data Build Tool.pdf
What is DBT - The Ultimate Data Build Tool.pdfWhat is DBT - The Ultimate Data Build Tool.pdf
What is DBT - The Ultimate Data Build Tool.pdfMounikaPolabathina
 
SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024Lorenzo Miniero
 
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxUse of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxLoriGlavin3
 
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024BookNet Canada
 
TeamStation AI System Report LATAM IT Salaries 2024
TeamStation AI System Report LATAM IT Salaries 2024TeamStation AI System Report LATAM IT Salaries 2024
TeamStation AI System Report LATAM IT Salaries 2024Lonnie McRorey
 
How to write a Business Continuity Plan
How to write a Business Continuity PlanHow to write a Business Continuity Plan
How to write a Business Continuity PlanDatabarracks
 
The Ultimate Guide to Choosing WordPress Pros and Cons
The Ultimate Guide to Choosing WordPress Pros and ConsThe Ultimate Guide to Choosing WordPress Pros and Cons
The Ultimate Guide to Choosing WordPress Pros and ConsPixlogix Infotech
 
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxThe Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxLoriGlavin3
 
DevoxxFR 2024 Reproducible Builds with Apache Maven
DevoxxFR 2024 Reproducible Builds with Apache MavenDevoxxFR 2024 Reproducible Builds with Apache Maven
DevoxxFR 2024 Reproducible Builds with Apache MavenHervé Boutemy
 
How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.Curtis Poe
 
Anypoint Exchange: It’s Not Just a Repo!
Anypoint Exchange: It’s Not Just a Repo!Anypoint Exchange: It’s Not Just a Repo!
Anypoint Exchange: It’s Not Just a Repo!Manik S Magar
 
What's New in Teams Calling, Meetings and Devices March 2024
What's New in Teams Calling, Meetings and Devices March 2024What's New in Teams Calling, Meetings and Devices March 2024
What's New in Teams Calling, Meetings and Devices March 2024Stephanie Beckett
 
Exploring ChatGPT Prompt Hacks To Maximally Optimise Your Queries
Exploring ChatGPT Prompt Hacks To Maximally Optimise Your QueriesExploring ChatGPT Prompt Hacks To Maximally Optimise Your Queries
Exploring ChatGPT Prompt Hacks To Maximally Optimise Your QueriesSanjay Willie
 

Recently uploaded (20)

TrustArc Webinar - How to Build Consumer Trust Through Data Privacy
TrustArc Webinar - How to Build Consumer Trust Through Data PrivacyTrustArc Webinar - How to Build Consumer Trust Through Data Privacy
TrustArc Webinar - How to Build Consumer Trust Through Data Privacy
 
The State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxThe State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptx
 
Digital Identity is Under Attack: FIDO Paris Seminar.pptx
Digital Identity is Under Attack: FIDO Paris Seminar.pptxDigital Identity is Under Attack: FIDO Paris Seminar.pptx
Digital Identity is Under Attack: FIDO Paris Seminar.pptx
 
Visualising and forecasting stocks using Dash
Visualising and forecasting stocks using DashVisualising and forecasting stocks using Dash
Visualising and forecasting stocks using Dash
 
From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .
 
Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!
 
A Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptxA Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptx
 
What is DBT - The Ultimate Data Build Tool.pdf
What is DBT - The Ultimate Data Build Tool.pdfWhat is DBT - The Ultimate Data Build Tool.pdf
What is DBT - The Ultimate Data Build Tool.pdf
 
SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024
 
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxUse of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
 
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
 
TeamStation AI System Report LATAM IT Salaries 2024
TeamStation AI System Report LATAM IT Salaries 2024TeamStation AI System Report LATAM IT Salaries 2024
TeamStation AI System Report LATAM IT Salaries 2024
 
How to write a Business Continuity Plan
How to write a Business Continuity PlanHow to write a Business Continuity Plan
How to write a Business Continuity Plan
 
The Ultimate Guide to Choosing WordPress Pros and Cons
The Ultimate Guide to Choosing WordPress Pros and ConsThe Ultimate Guide to Choosing WordPress Pros and Cons
The Ultimate Guide to Choosing WordPress Pros and Cons
 
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxThe Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
 
DevoxxFR 2024 Reproducible Builds with Apache Maven
DevoxxFR 2024 Reproducible Builds with Apache MavenDevoxxFR 2024 Reproducible Builds with Apache Maven
DevoxxFR 2024 Reproducible Builds with Apache Maven
 
How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.
 
Anypoint Exchange: It’s Not Just a Repo!
Anypoint Exchange: It’s Not Just a Repo!Anypoint Exchange: It’s Not Just a Repo!
Anypoint Exchange: It’s Not Just a Repo!
 
What's New in Teams Calling, Meetings and Devices March 2024
What's New in Teams Calling, Meetings and Devices March 2024What's New in Teams Calling, Meetings and Devices March 2024
What's New in Teams Calling, Meetings and Devices March 2024
 
Exploring ChatGPT Prompt Hacks To Maximally Optimise Your Queries
Exploring ChatGPT Prompt Hacks To Maximally Optimise Your QueriesExploring ChatGPT Prompt Hacks To Maximally Optimise Your Queries
Exploring ChatGPT Prompt Hacks To Maximally Optimise Your Queries
 

Architectural Decisions: Smoothly and Consistently

  • 1. Architectural Decisions: Smoothly and Consistently Andrei Shakirin VMware Tanzu Labs
  • 2. Agenda ● Architector role and Architecture definitions ● Cases, when architecture decisions hurt team (*) ○ Context ○ Observations (what happens) ○ Solution and lesson learned ○ Discussion ● Conclusion * Examples was taken from VMWare Tanzu Labs, TYMIQ GmbH and INNOQ projects
  • 3. About Me - Software Engineer at VMWare Tanzu Labs - Committer in Spring and Apache projects - Co-founder Tymiq GmbH - Speaker at technical conferences
  • 4. Architecture Definitions ⟨system⟩ fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution (ISO 42010) Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." -- Grady Booch. Architecture is anything that team considers important enough for the system development and evolving
  • 5. Architecture is NOT: Upfront activity performed by somebody in charge of telling everyone else what to do It is not a description or a document, it is a property of your system or even: it is your system (intentional or accidental)
  • 6. What is Good Architecture? What is the good car?
  • 7. ISO Software Product Quality Sounds clear and obvious, but people still missing this
  • 8. Simple Admin GUI Twitter Netflix Facebook Amazon Insurance policy managment system Scaling vs Complexity Written over weekend Some users Half of planet German tax low Google Search ChatGTP
  • 9. Cases Structure • Context • Observation • Lesson learned • Discussion
  • 10. #1 Painful shared responsibility
  • 11. Context • E-Commerce shop • Migration from E-Commerce framework • Development team 30 -> 100 persons
  • 12. Online Shop Design Customer Domain Article Domain Order Domain User Service Cart Service Article Service Order Service SAP Messaging REST REST REST REST Core Domain DAOs DB DB DB SAP Connector Messaging Connector
  • 13. • Modification and maintenance of common domains is hard • Deployment in single container causes dependencies and fragility between teams • Migrations to new versions of Java, Hibernate, CXF are extremely difficult and took very long time Observation
  • 14. Step 1: Split Codebase due Domain Code Duplication User Customer Domain Checkout Article Domain Order Domain User Service Cart Service Checkout Service Order Service SAP Messaging REST REST REST REST User Core Domain DAOs DB Container Cart Customer Domain Cart Core Domain Core Order Domain Cart Article Domain Checkout Core Domain Core framework as thridparty
  • 15. 15 Step 2: Extract Services with High Availability Requirements Gateway Old Service2 inside Monolith Price&Availability Microservice Monolith container Consumer 1 Consumer 2 Consumer 3 Routing / Canary release 90% 10% Old Service1 inside Monolith Old Service3 inside Mnolith • Service belongs to different bounded context and has multiple rates of change • Request load is essentially higher (or lower) as rest monolith components • Service has independent lifecycle • Service isolates external system dependency • Service uses innovative technology
  • 16. Step 3: Decentralize Data Management Docker Order Service REST R E S T Docker Checkout Service REST R E S T Docker Cart Service REST R E S T Docker User Service REST R E S T SAP Messaging DB DB DB DB
  • 17. • Think twice before share module, especially across bounded contexts • Duplication is less critical as common dependencies • Common utils can be treated as third party libraries and make them as thin as possible • Making decisions, system evolving and maintenance inside team is a lot of easier as a cross teams • Clear teams responsibility is important Lessons Learned
  • 19. Context • E-Commerce (retail) provider • Global customer base • Platform for the clients that served their clients • Catalog/CMS/Shop/Fulfilment • Multi-tenant • Highly customizable
  • 21. • If you attempt to satisfy everyone, you will likely end up to satisfying no one • Specific solution is often more preferable as highly configurable one • Complex configuration often evolves to discovering own programming language Lessons Learned
  • 22. #3 Microservices is the solution for all problems
  • 23. • Bookkeeping software • Synchronization with online payment transactions • 6 developers team Context
  • 25. • Legacy technology • Code difficult to support and maintain • Hard to extend for new payment providers Problems reported by customer
  • 26. • Split to microservices to make code maintainable • Microservices architecture will help to make architecture more extensible Initial plan from customer
  • 27. • There is only single bounded context • Both modules service and job belong to this bounded context • There is single business domain model • Splitting to other modules / microservices doesn’t make sense at all and can make problems even worse Analyse shows
  • 28. • Service and Job were rewritten using TDD and pair programming • Both modules were migrated to SpringBoot, Spring Batch was used for Job to get monitoring out of the box • Huge amount of optimizations were done • Both modules shared the same database and data model Final Solution
  • 29. • Unnecessary splitting of modules belonging in the same bounded context can cause more problems in architecture • Microservices is not universal solution and wouldn’t improved bad design automatically • The main reasons of splitting are: business subdomain, scalability requirements, lifecycle, failure isolation, different technology stack Lessons Learned
  • 30. #4 Your system WILL be dynamic
  • 31. Context • Large scale insurance system • Model driven development • 2 releases per year • > 100 developers (more maintain)
  • 32.
  • 33.
  • 34.
  • 35. Lessons learned • Centralized responsibity hurts • Faced too much rigidity, people always find a way around the rules
  • 37. Context • Platfom for trains control • Straightforward business logic • High scalability requirements • 10 developers
  • 38. Group 2 „You can‘t build reliable progams with Java Script“ Group 1 „Java is legacy programming language: Cobol of these days“
  • 40. • Any feature requires communication between the teams • One group should wait for another one • If backend systems are unresponsive, frontend teams quickly becomes secret „full stack“
  • 41. From a Layered System …
  • 42. and backend only split …
  • 43. … to a system of systems
  • 45. • Large scale B2B food retailer • New company wide shop and international logistic system • 40 in the beginning, > 200 developers Context
  • 47.
  • 50. Order Service Checkout Support Fullfilment Billing
  • 51.
  • 52.
  • 53. Order Service Checkout Support Fullfilment Billing
  • 54. Lessons learned • Small is not always beatifull • Not what is popular is automatically useful (CDD, HDD) • Don’t copy somebody else architecture unless you sure your context is identical
  • 57. Symtpoms • Ritual inclusion of code or program structures that serve no real purpose (redundant checks for null values, testing whether a collection is empty before iterating ) • Copying existing code with little understanding of how it works • Applying a design pattern or coding style blindly without understanding the reasons behind that design principle • Trying to make system too flexible: adopting different types of databases, configuration sources, communication protocols even if they do not really needed
  • 58. Context • Framework to discover, configure and secure web services • Customer is flight modelling company • 10 developers
  • 59. Design Database Repository Layer Model Layer Configuration Layer API Layer Configuration technical service Repository Repository Layer Wiring Layer Artifact Layer API Layer Service Registry SQL, Non-SQL DBs Impl 2, 3 File, DB, Git Other repos Other wirings Impl 2, 3 Mapping Mapping Mapping Mapping Mapping Mapping … … Communication abstraction Communication abstraction http:// Queue
  • 60. Lessons learned • Abstractions in system design are often leaky • Build new layers carefully: not because of fashion, coolness or dreams • Be pragmatic for now, but predict system evolving • Upfront architecture often leads to over-engineering
  • 61. #8 Improve with less intelligence
  • 62. Context • Bank with multiple collection of the shelf systems • Highly proprietary integration solution phased out by vendor
  • 63.
  • 64.
  • 65. Visual Mapping Tool • No Unit Test • No CI/CD • …
  • 67.
  • 68. Lessons learned • Smart endpoints, dumb pipes (even with cool names) • Value of specific over generic solutions
  • 69. #9 Free style architecture
  • 70. Context • E-Commerce online shop / retail • 100-120 developers • 10 self contained teams
  • 72. System of systems architecture
  • 73. But … • Luck of standartization led to ineffecient UI integration at runtime (integration was done at hock) • Vast differences in API style, formats, documentation created needless extra work (json+hal, json+saron)
  • 74. You cannot decide to not have an architecture; if you don‘t actively create it, be prepare to deal with the one what emerges There is a fine line between diversity (that adds value) and chaos (that doesn‘t) Extremely loose coupling requires a few rules, but they need to be enforced strictly
  • 75. Takeaways • Don‘t be afraid about architecture • Choose the simplest thing that will work • Create evolvable structures, manage architecural evolution • Don‘t built road blocks, create value and get out of the way
  • 76. 76 Sharing Modules and Services Team A Module A Team B API Module A API Module B Team A Service A Team B API Service B API
  • 77. 77 Sharing Modules and Services Team A Module A Team B API Module A API Module B Team A Service A Team B API Service B API
  • 78. 78 Shared Responsibility Team A Team B Module A API development development