modern architectures and an agile world

27
Modern Architecture in an Agile World An Overview of Modern Architectures and where the Agile process fits Wyn Van Devanter @wynv w [email protected]

Upload: wyn-devanter

Post on 16-Jul-2015

52 views

Category:

Technology


1 download

TRANSCRIPT

Modern Architecture in an Agile World

An Overview of Modern Architectures and where the Agile process fits

Wyn Van Devanter

@wynv

[email protected]

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

Source: Software Architecture Patterns, Mark Richards

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

Source: Software Architecture Patterns, Mark Richards

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

Source: Software Architecture Patterns, Mark Richards

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.

Source: Software Architecture Patterns, Mark Richards

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

Source: Fundamentals of Software Architecture, Mark Richards

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