Evolving Serverless Architectures • Emily Shea • GOTO 2024

Evolving serverless architectures should be treated as an ongoing process, not a one-time effort - code should be viewed as a liability rather than an asset to encourage simplification

Key reasons to evolve architectures include:

• Changing business requirements and application needs
• New AWS platform capabilities becoming available
• Opportunities to improve runtime characteristics
• Cost optimization potential
• Reducing operational complexity

Common evolution patterns:

• Replacing custom Lambda code with managed service integrations
• Moving from choreography to orchestration for complex workflows
• Using EventBridge Pipes instead of Lambda functions for event filtering
• Leveraging direct service integrations in Step Functions
• Replacing polling patterns with callbacks

Best practices for evolution:

• Make it a regular part of development sprints
• Build evolution goals into planning cycles
• Consider the whole system impact, not just individual components
• Translate technical improvements into business value
• Use infrastructure-as-code to document architecture changes

Operational considerations:

• Monitor latency impacts
• Evaluate cost implications across the full system
• Consider team skills and maintainability
• Test performance in your specific environment
• Plan for gradual migration of existing workloads

Success metrics should include:

• Reduced code complexity and maintenance burden
• Improved system visibility and debugging
• Lower operational costs
• Better scalability and reliability
• Enhanced developer productivity

DVLA case study showed benefits of:

• Modernizing legacy applications incrementally
• Moving from custom code to managed services
• Improving photo processing workflows
• Reducing application complexity
• Leveraging new AWS capabilities like Bedrock