Principles of Software Architecture Modernization
Delivering engineering excellence with the art of fixing microservices, monoliths, and distributed monoliths (English Edition)
1st Edition
Published on 15. December 2023
474 pages
978-93-5551-783-8 (ISBN)
Description
No detailed description available for "Principles of Software Architecture Modernization".
More details
Other editions
Additional editions
Diego Pacheco
Principles of Software Architecture Modernization
Delivering engineering excellence with the art of fixing microservices, monoliths, and distributed monoliths
Book
12/2023
BPB Publications
€41.70
Article not available for order
Content
- Intro
- Cover
- Title Page
- Copyright Page
- About the Authors
- About the Reviewer
- Acknowledgement
- Preface
- Table of Contents
- 1. What's Wrong with Monoliths?
- Structure
- What are monoliths?
- Big codebase
- Few deployment units
- Other monolith smells
- Centralized
- Old
- Sidebar: Does size matter?
- Issues with monoliths
- Patterns in software engineering
- What is an anti-pattern?
- Living with Monoliths: Anti-patterns, side effects, and amplifiers
- Monolith anti-patterns
- High coupling
- Wrong abstractions
- Lack of isolation
- Monolith side effects
- Difficult deployments
- Insufficient testing
- Lack of ownership
- Slow adoption of new technologies
- Slow development cycle
- Sidebar: Automation and anti-patterns
- Amplifiers
- Broken windows/copy and paste
- Microservice envy
- Lack of Talent Density
- Fear of change
- Are all monoliths bad?
- Monoliths are a form of software architecture
- Monolith benefits
- Refactoring and change impact
- Simplify some migrations
- A good starting point
- Simplified infrastructure
- Types of monoliths
- Classical, distributed, and modular monoliths
- Modular monoliths: The good kind of monolith
- Modular monoliths: Istio
- Modular monoliths: Mobile SuperApps
- Can bad monoliths be avoided?
- Things to remember
- 2. Anti-Patterns: Lack of Isolation
- Structure
- What is isolation?
- Isolation in software
- Isolation temptations
- Exposure
- Existing components, BFF
- Existing components, change existing endpoint
- Existing service, add new endpoint
- New service, share the database
- Sidebar: What is a Backend for Frontend?
- New service, share the data
- What is event sourcing?
- Event sourcing in software
- Sidebar: CQRS and its relationship with ES
- New service, share via API
- Centralization
- Benefits of centralizing engineering teams
- Issues with over-centralization
- Delivery bottleneck and innovation bottleneck
- Centralization versus standardization for observability and deployments
- Bad shared libraries
- Breaking Isolation
- Sharing databases
- When is it ok to share databases?
- Big Data sharing application databases
- Hidden contracts and preserving isolation
- Legacy system integrations
- Shared libraries
- Binary coupling
- Lack of stable contracts
- Pushing complexity upwards
- Granularity and distribution: Side effects
- Let us isolate everything
- Databases
- Shared libraries
- Stable contracts
- Sidebar: Deep modules and A Philosophy of Software Design
- Operating Systems and infrastructure
- Advanced isolation
- Failure isolation and bulkheading
- Fallbacks
- UX isolation: Degradation and exploration
- How to prevent isolation issues
- Design reviews and tooling
- Things to remember
- 3. Anti-Patterns: Distributed Monoliths
- Structure
- What is a distributed monolith?
- Traits of distributed monoliths
- How are distributed monoliths created?
- Sharing databases across services
- Shared persistence libraries
- Shared contracts
- Issues with distributed monoliths
- Binary coupling
- Temporal coupling
- Push the complexity upwards
- Embrace async with an Event-Driven Architecture
- Vulnerabilities and security fixes
- Testing
- Management problems
- Reasoning problems
- Amplifiers
- Team erosion
- Software ownership
- Anti-science mentality
- Features and bugs
- Sidebar: Landmines
- Bad environments
- Types of distributed monoliths
- Backend
- BFF and frontend
- Serverless
- Complexity in serverless architectures
- Backfire: worse again!
- Architects as gatekeepers do not scale
- New capability/feature
- New table
- EOL technology
- Stop the bleeding
- Consider going back to the monolith
- Team and process advice
- Technology and software architecture advice
- Things to remember
- 4. Anti-Patterns: Internal Shared Libraries
- Structure
- What is a library?
- Types of libraries
- Sidebar: Libraries versus frameworks
- Issues with libraries
- Constant migrations
- Lack of stable contracts
- Binary coupling / breaking isolation
- Incentives for library creation
- The Framework Anti-Pattern
- In defense of libraries
- Performance
- Reliability path
- Language idiomatic
- Code centralization
- Avoid reinventing the wheel
- Pitfalls: Bad practices to avoid
- Internal shared libraries
- Short blanket effect
- Big frameworks
- Bloated libraries
- Highly popular libraries
- Libraries shipping configurations
- Team erosion in shared libraries
- Service drivers
- Utils
- Wrappers
- Extension
- New abstractions
- Lack of governance
- Better options
- When should we create a library?
- When should we NOT create a library?
- Leverage services
- No binary coupling
- Much improved flexibility
- Easier migrations or no migrations at all
- Critical reliability path
- In some cases, performance
- Sidecar pattern
- Modern sidecars
- Sidecars and proxies
- Sidecars and Kubernetes
- How can you build a Sidecar? Types of Sidecars
- Sidebar: Service meshes
- Simple alternatives
- Leverage existing SDKs and libraries
- Do it yourself
- Copy and paste the code
- Contribute to open source
- Proper library design
- Duplication vs re-use
- Bad duplication: Business code
- Bad duplication: Compliance
- Good duplication: Migrations
- Good duplication: Configuration and setup code
- Reuse: The double edged sword
- Proper dependency management
- Cherry pick dependencies
- Avoid company-wide parent POMs
- Explicitly declare dependencies
- Lean libraries
- The spectrum of options
- Things to remember
- 5. Assessments
- Structure
- What is an assessment?
- Why perform assessments?
- Typical modernization projects
- Successful modernization projects
- Motivations
- Assessments
- Mind the Cone of Uncertainty
- Technology and business needs
- Modernization strategy
- Decisions and tradeoffs
- Build versus buy
- The case to buy
- The case to build
- Rewrite versus refactor
- The power of backward compatibility
- Elements of proper assessments
- Code analysis at scale
- Classification and judgment
- Ownership
- Rate of business change
- Public contracts
- Downstream dependencies
- Upstream dependencies
- User facing?
- Complexity
- Pass rate / test coverage
- Database analysis
- Classifying the level of independence
- Classical monolith
- Microservices or proper services
- Distributed monolith
- Different persistence frameworks
- Isolated schemas
- Isolated tables
- Domain mapping
- List all the domains
- Quarantine the system
- Assessment outcomes
- Quick wins
- Prioritization, expectations, and strategy
- Business Impact versus effort
- Order of events
- Radical change
- Things to remember
- 6. Principles of Proper Services
- Structure
- Service oriented architecture
- Types of services
- When to use a service
- When to avoid services
- SOA benefits
- Faster time to market
- Lower costs and easier maintenance
- Extensibility and adaptability
- Independence
- Summary of SOA benefits
- Contract first
- New service
- Existing component
- Coding contracts with OpenAPI
- Backward compatibility
- SOA and isolation
- Isolate datastores
- Isolate libraries
- Sidebar: flavors versus bridges in libraries and monoliths
- Isolated public contracts
- Design reviews
- Automating contract health
- Non obvious things
- Handling errors in contracts
- Service exposure
- Things to remember
- 7. Proper Service Testing
- Structure
- Why testing?
- Correctness
- Change impact
- Production ready
- Traits of software tests
- Types of Tests
- Traits of bad tests
- Inconsistent failure rate
- Refactoring fragility
- Data dependency entanglements
- Inefficient testing cycles
- Constant test tweaking
- Test independence
- Traits of good tests
- Constant success rate
- Refactoring resiliency
- Data dependency isolation
- Direct inputs
- Internal state
- Fast feedback cycles
- Hands-off tests
- Self-contained
- Testing manifesto
- Testing throughout over at the end
- Preventing bugs over finding bugs
- Testing understanding over checking functionality
- Building the best system over breaking the system
- Team responsibility for quality over tester responsibility
- Testing diversity
- Why testing matters to software architecture
- Best practices testing services
- Practical stress testing
- Gatling for performance testing
- Test Pyramid
- Strategies for testing in production
- Edge router
- Beta users
- Live auditing / compare and discard results
- Replaying traffic
- Chaos Testing
- Netflix Simian Army
- Toxiproxy
- Resiliency matrix
- Internal state - advanced deep dive
- Synthetic data generation
- Testing interfaces
- Test data setup
- Mocking interfaces
- Things to remember
- 8. Embracing New Technology
- Structure
- Embrace the new, with principles
- On demand resources - cloud computing
- Stable contracts
- Proper isolation
- One account per service
- One account per business domain
- One account for everything
- Account organization impacts contract granularity
- Internal shared libraries
- Serverless
- How the cloud impacts team organization
- Pre-built capabilities - cloud services and SaaS
- Relational and NoSQL datastores
- AI and analytics
- Isolated deployment units
- Containers and Kubernetes
- Cloud spectrum
- Real time access to data - streaming
- Apache Kafka
- Kafka architecture
- Kafka and CQRS / ES
- ksqlDB
- Efficient engineers
- Modern languages
- Language spectrum
- JVM languages
- Flexible data models
- NoSQL databases
- Going beyond the relational model
- Lean communications - binary APIs and GraphQL
- Service-to-Service communication: REST, gRPC, and GraphQL
- What REST got right
- Interoperability vs performance
- GraphQL
- gRPC
- Things to remember
- 9. Code Migrations
- Structure
- Why do code migrations matter?
- Inventory, use cases, and POCs
- Red vs green migrations
- Elements of proper code, migrations
- Migration target
- Difficulty
- Customer impact - online vs offline
- Execution - service team vs. platform team
- Code migration patterns
- Backward compatibility
- Lazy migrations
- Strangler Fig
- Converting a classical monolith to proper SOA
- Converting a classical monolith to a modular monolith
- Converting a distributed monolith to proper SOA
- Amazon two - way doors
- Migration roadblocks
- Roadblock - leftovers
- Double down on inventories and POCs
- Distributed migrations and team dependencies
- Repetition, repetition, repetition
- Roadblock - friction and entropy
- Roadblock - high WIP limits, business pressure, compliance, and other traps
- Post-migration
- Rollback strategies
- Things to remember
- 10. Data Migrations
- Structure
- Data migration risks
- Pre-data migrations
- Inventory and analysis
- Planning and identifying quick wins
- Data migration patterns
- Revisiting - lazy migrations
- Export and import
- Database replication
- Table diff
- Triggers
- Change Data Capture
- Dual writing
- Cold data
- Failure in one write operation
- Transaction delay and complexity
- Data migration strategies
- Online vs offline
- Schema first versus multiple migrations
- Revising: Strangler Fig
- Classical monoliths, Strangler Fig, and data migrations
- Executing migrations
- Testing
- Pre-migration sanity testing
- Performance testing
- Practical database performance testing with NDBench
- Sanity test: Post-migration structure and data
- Observability
- Post-data migrations
- Ghost hunting
- Clean up and decommissioning
- Things to remember
- 11. Epilogue
- Structure
- Encore!
- Principles matter the most
- Education
- City planning
- Vision
- Onward
- Index
