Upload
wyn-devanter
View
52
Download
1
Embed Size (px)
Citation preview
Modern Architecture in an Agile World
An Overview of Modern Architectures and where the Agile process fits
Wyn Van Devanter
@wynv
Architecture in Agile
• Why is architecture important?
• Architecture is still important in Agile • Emergent and evolutionary architecture
• Bring architecture into the teams
• Define architecture iteratively (pace depends on project and new requirements)
• Create processes to facilitate this
• Set yourself up for architectural change
Architecture in Agile - Facilitate iterative architecture
• Exploration workshops • Draw relationships among people and the system
• List failure scenarios and solution
• Draw architecture based on solution with key use cases, and pass to the left & critique
• Critique vague architecture
Architecture in Agile - Facilitate iterative architecture
• Component-based thinking, steps (like for architecturally significant use case, analyze responsibilities for overlap and too much responsibility, validate components identified satisfy all known functional and non-functional requirements, refactor existing components • Include functional (eligibility determination, benefits calculation, salary calculator) and non-functional
(security manager, persistence manager, audit component) in architecture • Start with broad scope and work down (benefits calculation -> 401k contribution calculation, lump sum
calculation)• Coupling (low coupling, high cohesion) - look at sequence diagram
• Identify local vs remote components (based on local, scalability needs, etc) and associated protocol
• Document components -• Interface• Role and Responsibility statement • Access protocols • Dependencies • Non-functional considerations • Implementation Notes
Popular Architectural Patterns
• Layered• Ports & Adapters (Hexagonal)
• Onion
• Event-Driven
• Microkernel
• Spaced-based
• Service-Oriented
• Microservices
• Hybrids
Layered
• WHAT: One layer dependent on layer below only • Separation of concerns (Presentation, BL, persistence, database)• Closed layers• Classifies components in terms of layer• Changing something usually only requires changing layer above
• HYBRIDS: • Layer opened – all other layers can access
• NOTES: • Good starting point for most systems • Can lead to monolithic apps • Can be unintended result when architectural thinking hasn’t taken place• Must communicate what you can do at the boundaries
Layered – Quality Attributes
• Agility: Bad – i.e. 1 database call requires changes at ~4 layers
• Deployment: Bad – entire app
• Testability: Good – can mock layers
• Performance: Bad – nothing lending itself to performance
• Scalability: Bad – monolith
• Development: Good – can develop in 1 layer before starting another
• Complexity: Good – easy to understand
• Loose Coupling: Bad - monolith inside each layer, generally tightly coupled - decoupling b/t layers, but bound by contracts
Event-Driven
• WHAT: Highly decoupled, single-purpose event processing components that asynchronously receive and process events. Can be highly distributed.
• 2 main topologies • Mediator• Broker
• WHERE: Highly scalable applications; but adaptable to small and large, complex applications
• NOTES: • Expensive • Lack of transactions • Event processor contracts
Event-Driven - Mediator
• Need to orchestrate multiple steps within an event through a central mediator (to control order, which can be parallel, etc).
• COMPONENTS: • Event queues (dozen to several hundred) - can be a message queue, web
service endpoint, or any combination
• Event mediator
• Event channels - message queues or message topics (usually topics are most widely used with this topology so processing events can be processed by multiple event processors based on the event)
• Event processors
Event-Driven – Mediator workflow
• Initial event through mediator, and processing events generated by mediator to the event-processing components
Event-Driven - Mediator
EXAMPLE: Single-click stock trade might require:1) validate trade
2) check compliance of trade
3) assign to a broker
4) calculate commission
5) place trade with broker
Source: Software Architecture Patterns, Mark Richards
Source: Software Architecture Patterns, Mark Richards
Event-Driven – Quality Attributes
• Agility: Good - event-processor components are single-purpose and completely decoupled from other event processor components, changes are generally isolated to one or a few event processors
• Deployment: Good
• Testability: Bad - generate events, async
• Performance: Good - async, balance with cost of messaging
• Scalability: Good - each event processor scaled separately
• Development: Bad - async, contract creation, advanced error handling for unresponsive event processors and failed brokers
Microkernel
• WHAT: Core with additional functionality via plug-ins, providing extensibility and feature separation and isolation • Plug-ins are independent modules • Plug-in registry (i.e. name, data contract, remote access protocols)• Plug-ins can be invoked many ways (i.e. messaging, web services, instantiation),
often depending on small vs large app, and single or distributed deployment
• WHEN: • Product-based applications• OSes• Business logic with special cases, rules, or complex conditional processing as plug-ins
(i.e. insurance with different rules per jurisdiction)
• CONSIDERATIONS:• Can easily be used in just one part of an application • First choice for products
Microkernel – Quality Attributes
• Agility: Good - stable core, and changes isolated in plug-ins
• Deployment: Good - hot-deployments
• Testability: Good - plug-ins can be isolated, and mocked by core easily
• Performance: Good - streamline to only include features you need
• Scalability: Bad - most are implemented as single units
• Development: Bad - requires thoughtful design and contract governance; many complex choices in implementing like plug-in connectivity
Microservices
• Evolved from issues with other architectural patterns -• Monolithic apps using layered pattern needing CD (i.e. monthly deployment cycles as
everyone deploys as one), and • Distributed applications using the service-oriented pattern - often complex and
overkill, simplifies notion of a service, eliminating orchestration needs, and simplifying connectivity and access to service components
• Separately deployed units
• Service components, not services, which can vary in granularity from a single module to a large portion of the app. • Contain one of more classes responsible for a single purpose (i.e. weather for a
town) or independent portion of large business app (i.e. stock trade placement)
• Distributed - all components are accessed through remote access protocol
Microservices – Three Main Topologies
• API REST-based - useful for websites exposing small, self-contained individual services through an API. Fine-grained microservices, containing 1-2 modules
• Application REST-based –• Differs from the API REST-based approach in that client requests are received through
traditional web-based or fat-client business application screens rather than through a simple API layer.
• Service components tend to be larger, more coarse-grained, and represent a small portion of the overall business application rather than fine-grained, single action services.
• This topology is common for small to medium-sized business applications that have a relatively low degree of complexity.
• Centralized messaging - uses lightweight message broker instead of REST for remote access (doesn't do any orchestration, transformation or complex routing like in SOA). Typically found in larger business applications.
Microservices - Considerations
• Designing right service module granularity is one of the biggest challenges
• If you find yourself needing to orchestrate your service components from the UI or API layer, or if you find you need to perform inter-service communication between service components, they may be too fine-grained
• If you they aren't fine-grained enough, you won't realize all the benefits in deployment, scalability, testability and loose coupling
• Common to violate DRY for keeping service components independent (i.e. small utility classes)
• Hard to use atomic transactions across distributed nature of architecture
• Hot-deployments
• Distributed considerations - contract creation/maintenance/governance, remote systems availability, remote access authentication and authorization
Microservices – Quality Attributes
• Ease of deployment, increased scalability, high decoupling
• Agility: Good - separately deployed, isolated, loosely coupled service modules
• Deployment: Good
• Testability: Good - easier to regress individual service modules, loosely coupled prevents unexpected bugs
• Performance: Bad - must be heavily tuned for performance as distributed nature doesn't lend itself naturally to it
• Scalability: Good - scale needed service modules
• Development: Good - isolated functionality
Service-based hybrid
• Middle ground b/t SOA and microservices (varient of microservices); solves majority of problems with monolithic apps
• Service granularity• Single-purpose service to "portion of the application" (i.e. trading functionality
separate from portfolio rebalancing)
• Considerations -• Services harder to test b/c less granular• Deployment & change control is harder (better than monolith)• Resolves orchestration and transactional aspects• Less to do with size, and more with requirements (i.e. if you want to partition app, ie
shopping cart from admin functionality; if you're changing one part a lot (so you don't have to redeploy)
• Can share databases as needed to prevent remote hops• Could have a layered app within one of the service modules
Service-Based hybrid – Quality Attributes
• Agility: Good(app split into smaller chunks)• Deployment: Depends on granularity of service components (better than
layers, worse than microservices)• Testability: Depends again on granularity, but harder because it's
distributed• Performance: Bad(distributed, network hops across sections)• Scalable: Good• Development: Easier because of isolated components, but harder because
of potential integration hub• Complexity: Good• Loose Coupling: Good
Thanks! @wynv | [email protected]
techtalkdc.comResources:
• Cert process • Open Group nomination packet, $300
• Training • Software Architecture Fundamentals, Mark Richards, Neal Ford,
http://shop.oreilly.com/product/110000195.do• Idesign’s Architect’s Master Class and Clinic
• Books• Software Architecture Patterns, O’Reilly Report by Mark Richards• Coding the Architecture, Simon Brown
• Start practicing