Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AWS re:Invent 2016: Migrating Enterprise Messaging to the Cloud (ENT217)

1,070 views

Published on

Enterprises rely on messaging to integrate services and applications and to exchange information critical to running their business. However, managing and operating dedicated message-oriented middleware and underlying infrastructure creates costly overhead and can compromise reliability. In this session, enterprise architects and developers learn how to improve scalability, availability, and operational efficiency by migrating on-premises messaging middleware to a managed cloud service using Amazon SQS. Hear how Capital One is using SQS to migrate several core banking applications to the cloud to ensure high availability and cost efficiency. We also share some exciting new SQS features that allow even more workloads to take advantage of the cloud.

Published in: Technology
  • Be the first to comment

AWS re:Invent 2016: Migrating Enterprise Messaging to the Cloud (ENT217)

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Trevor Dyck, Senior Product Manager, AWS Messaging Quinn Easterbrook, Director Platform Engineering, Capital One November 30, 2016 Migrating Enterprise Messaging to the Cloud
  2. 2. Agenda Enterprise messaging overview • Enterprise messaging challenges • Cloud hosted messaging • AWS messaging—Amazon SQS and Amazon SNS • New: FIFO queues Capital One use case • Migrating retail application messaging to the cloud
  3. 3. What is “enterprise messaging ”? Corporate data center Inventory CRM Ordering Front end Ordering Back endMoM “Message-oriented middleware” (MoM) Examples: IBM MQ, TIBCO Active MQ, RabbitMQ (open source)
  4. 4. Messaging patterns • Message queuing • Publish-subscribe (pub-sub)
  5. 5. Message queueing • Asynchronous • Point-to-point Producer Consumer Consumer Queue
  6. 6. Publish-subscribe (pub-sub) • Broadcast • Point-to-multipoint Publisher Subscriber Subscriber Topic Subscriber
  7. 7. Use cases for message queues Decouple application components or microservices Application integration Batch and burst processing
  8. 8. Decouple application components or microservices • Web tier instances create work, worker instances complete it • Scale and manage tiers separately • More resilient to failure vs direct RESTful communication
  9. 9. Application integration • Applications exchange information asynchronously • Apps can be independent, fault-tolerant • Allows apps to be in different environments (OS, language)
  10. 10. Batch and burst processing • Resilient to spikes in traffic • Perform work only as fast as necessary to lower costs • Never lose data
  11. 11. Challenges: message-oriented middleware (MoM) Operational overhead Capacity planning Reliability Cost
  12. 12. AWS managed messaging services
  13. 13. Amazon Simple Queue Service (Amazon SQS) • Fast, reliable, scalable, fully managed queue service • AWS SDK or Java Message Service (JMS) APIs
  14. 14. Amazon Simple Notification Service (Amazon SNS) • Fast, reliable, scalable fully managed pub-sub service • Use topics to fan out messages to: • Amazon SQS queues • HTTP endpoints (web servers) • AWS Lambda functions • Mobile push, SMS, and email
  15. 15. Amazon SQS: key features • Persistent message queue with high durability and availability • Messages are stored across multiple AZs • Messages retained until deleted— up to 14 days • Nearly unlimited throughput
  16. 16. Amazon SQS: key features • Amazon CloudWatch metrics and alerts • Message payloads up to 256 KB (5 TB using AmazonS3) • Message batching to increase throughput and reduce cost • Secure: uses AWS Identity & Access Management (IAM) and HTTPS/TLS
  17. 17. No infrastructure to manage Focus on business logic, not infrastructure. Just write your code. Amazon SQS handles: Capacity Scaling Deployment Fault tolerance Monitoring Logging Security
  18. 18. New! FIFO (first-in, first-out) queues • Message ordering is strictly preserved • Exactly once processing • Message groups allow multiple ordered streams within a single queue • Essentially the same features and API as standard SQS queues • FIFO queues are limited to 300 transactions per second (TPS) • Standard SQS queues provide unlimited throughput
  19. 19. FIFO queues - ordering ABC Producer Consumer
  20. 20. FIFO queues – message groups A Producer ConsumerGroup 1 Consumer SendMessage (A, MessageGroupID=1)
  21. 21. FIFO queues – message groups A Producer Consumer X Group 1 Group 2 Consumer SendMessage (X, MessageGroupID=2)
  22. 22. FIFO queues – message groups A Producer Consumer XY Group 1 Group 2 Consumer SendMessage (Y, MessageGroupID=2) SendMessage (B, MessageGroupID=1) B
  23. 23. FIFO queues – message groups A Producer Consumer X Group 1 Group 2 Consumer ReceiveMessage Y A X Invisible B
  24. 24. FIFO queues – message groups Producer Consumer X Group 1 Group 2 Consumer ReceiveMessage Y X B
  25. 25. FIFO queues – message groups Producer ConsumerGroup 1 Group 2 Consumer ReceiveMessage Y Y B
  26. 26. FIFO queues – message groups Producer ConsumerGroup 1 Group 2 Consumer ReceiveMessage Y Y B B
  27. 27. FIFO Queues - deduplication FIFO queues prevent duplicate messages On send: • For example, if producer retries before SQS acknowledges, want to avoid a duplicate • FIFO queues include MessageDeduplicationID for duplicate detection • Alternatively, content-based deduplication is also available
  28. 28. FIFO queues – deduplication Producer Consumer Consumer SendMessage (A, MsgDedupID = foo) A FIFO Queue
  29. 29. FIFO queues – deduplication Producer Consumer Consumer A ReceiveMessage FIFO Queue Dedup buffer A
  30. 30. FIFO queues – deduplication Producer Consumer ConsumerSendMessage (A, MsgDedupID = foo) A Retry: FIFO Queue Dedup buffer A
  31. 31. FIFO queues – deduplication Producer Consumer Consumer FIFO Queue Dedup buffer A OK
  32. 32. FIFO queues – exactly-once processing On receive: • If consumer reads but does not process and delete a message (for example, network failure) • SQS will make the message available to another consumer • If the consumer detects a failed ReceiveMessage action, it can retry as many times as necessary, using the same ReceiveRequestAttemptId
  33. 33. FIFO queues – exactly-once processing A Producer Consumer Consumer ReceiveMessage A (AttemptID = bar) BC FIFO Queue
  34. 34. FIFO queues – exactly-once processing Producer Consumer Consumer ABC FIFO Queue
  35. 35. FIFO queues – exactly-once processing A Producer Consumer Consumer ReceiveMessage A (AttemptID = bar) BC FIFO Queue
  36. 36. FIFO queues – pricing • Low cost, per–API request pricing. Pay only for what you use, no upfront costs. • FIFO queues are priced at $0.50 per million requests. • In conjunction, the price of SQS standard queues was reduced to $0.40 per million requests. • First 1 million SQS requests per month are free.
  37. 37. Move from risk-laden upfront expense to flexible variable expense Stop guessing at capacity planning Go global in minutes Hosted messaging: harness the cloud Remove complicated infrastructure management
  38. 38. Enterprises using AWS messaging services BMW Johnson & Johnson Nordstrom
  39. 39. Migrating retail application messaging to the cloud
  40. 40. A leading diversified bank with $339.1 billion in assets, $235.8 billion in loans and $221.1 billion in deposits1 • 8th largest bank based on U.S. deposits2 • 5th largest retail depository institution in metro New York3 • Largest consumer and commercial banking institution headquartered in the Washington, DC, region • 4th largest credit card issuer in the U.S.4 • The 3rd largest issuer of small business credit cards in the U.S.5 • The 4th largest financial institution auto loan originator6 • Largest U.S. direct bank7 Major operations in 15 U.S. cities, Canada, U.K. More than 65 million customer accounts, and 45,000 associates A FORTUNE 500 Company - #112 Numerous recent awards including: • Named to 100 Best Companies to Work For by FORTUNE Magazine • Best Places to Work for LGBT Equality by Human Rights Campaign • Received J.D. Power & Associates Call Center Certification • Aon Hewitt’s Top Companies for Leaders • Named to Working Mother’s 100 Best Companies list & Best Companies for Hourly Workers • Ranked #10 on Military Times’ 2016 “Best for Vets” • Recipient of the Secretary of Defense Employer Support Freedom Award Capital One at a glance 1) Source: Company reported data as of Q2’16 2) Source: FDIC, Domestic deposits ranking as of Q2’16 3) Source: FDIC, June 2015, deposits capped at $1B per branch 4) Source: Company-reported domestic credit card outstandings, Q2’16, 5) Source: The Nilson Report, Issue 1089, June 2016 6) Note: Financial institutions includes banks & specialty finance lenders, Source: AutoCount, FY 2015 7) Source: FDIC, company reports as of Q2’16
  41. 41. Retail messaging cloud migration Benefits and cost saving associated with moving to the cloud Focus on iterative improvements • Maintaining existing architecture while providing modern components • Provide integration points that work with existing applications • Minimalize code changes where possible Areas of upgrade • Modernizing message queuing with Amazon SQS vs. self-managed systems • Migrating hardware systems to Amazon EC2 with fully-automated build-out • Leveraging Auto Scaling for resiliency and usage-based model
  42. 42. Current queue system JBOSS JMS message queues used for legacy applications JBOSS has been relatively stable, but has challenges: • Downtime related to maintenance on servers running the queues • Upgrades to the JMS client and server due to recoding efforts required • Database system patching and issues with tablespace growth • Visibility into queues and performance with homegrown monitoring Challenges with queue administration and segregation • Segmentation among applications required explicit separation of applications and queues Excessive overhead to administer multiple servers: • 10 JBOSS JMS queue servers to 5 applications
  43. 43. Existing queue integration 2 1. User submits request to Web APP 2. Web App sends message to Jboss MQ 3. Middleware clusters poll Jboss MQ for new messages. 4. Middleware sends Queries to Backend Databases and 3rd party App Vendors. 5. Middleware sends the reply message to the application topic in JbossMQ 6. Jboss MQ topic pushes the message back to the Web App. Users 1 3 4 6 3rd Party Apps 5 CustDB1 CustDB2 Web App Jboss MQ Middleware Tomcat
  44. 44. Current queue system is complex • Queues are distinct to each server, applications lack visibility • Instances are provisioned based on theoretical load not actual load • Requires timely build of supporting infrastructure • Multiple queues on each server make it difficult to find failures • Inability to identify bottlenecks and resolve issues across systems • Significant effort to manage multiple costly systems and administer services
  45. 45. SQS selection criteria Simplified administration • Dynamic queue creation on startup of applications • Requirement for patching and database maintenance removed • Increased monitoring with Amazon CloudWatch built-in Utilization patterns govern the number of queues required • Static server builds not required for application demand Required to be highly secure • SQS provides TLS1.2 connectivity and strong authentication Flexibility in queue types • Can utilize FIFO as well as standard queues to allow for more performance • FIFO use cases for ordering on pickup and classic for variable timed responses
  46. 46. SQS selection criteria Ease of integration • With small client changes can easily integrate into existing application • Utilize existing JMS coding for application queues Reliability/scaling • Ability to scale as the applications grow without having to pre-plan sizing • Inherent reliability with Multi-AZ deployments Capacity planning • Scaling of queues/resources based on when they are used vs. always on Infrastructure simplification • Elimination of costly physical systems with reliable serverless services
  47. 47. Private beta and SQS team interactions Direct engagement with product team to develop features and solutions that meet our specific needs Successful process to collaborate and achieve key goals • Examples: FIFO and exactly once processing Exchange feedback on how solutions will work and solve complex issues • Example: Solve for queue queries for message interaction reliability
  48. 48. Application queues Existing New
  49. 49. New SQS Integration RetailBank CustDB1 AppSendQueue 2 1. User submits request to Web App. 2. Web App instance sends message to Shared AppSendQueue for Middleware. 3. Middleware Instances polls the AppSendQueue for new messages. 4. Intra-Cluster message traffic. 5. Middleware sends Queries to Backend Databases and 3rd party Vendors. 6. Middelware sends reply message to the Instance Specific Reply Queue. 7. WebApp Instance polls it’s specific reply queue for messages and correlates messages with initial request. On-Prem Users Au to Scaling Middleware MW01 Queue MW02 Queue MW03 Queue Inst01RplyQueue CustDB2 1 3 4 5 67 3rd Party Apps 5 Inst02RplyQueue Inst0nRplyQueue Au to Scaling WebTop App ASG WebTopInstance01 WebTopInstance02 WebTopInstance0n 7 7 6 6 FIFO
  50. 50. SQS migration wrap-up Delivers significant benefit to overall migration efforts • Lets us leverage existing systems without complex development • Enables a seamless migration with limited overhead and administration • Exceeds overall goals of resiliency and visibility • Delivers future-proof solution that will grow with our needs
  51. 51. Summary • Messaging is a common requirement in enterprise architectures • Managed messaging services remove administrative overhead & “pain” • FIFO queues enable more use cases • AWS is investing in more key enterprise messaging features… stay tuned!
  52. 52. Thank you!
  53. 53. Remember to complete your evaluations!

×