AWS re:Invent 2016: Accenture Cloud Platform Serverless Journey (ARC202)

386 views

Published on

Accenture Cloud Platform helps customers manage public and private enterprise cloud resources effectively and securely. In this session, learn how we designed and built new core platform capabilities using a serverless, microservices-based architecture that is based on AWS services such as AWS Lambda and Amazon API Gateway. During our journey, we discovered a number of key benefits, including a dramatic increase in developer velocity, a reduction (to almost zero) of reliance on other teams, reduced costs, greater resilience, and scalability. We describe the (wild) successes we’ve had and the challenges we’ve overcome to create an AWS serverless architecture at scale. Session sponsored by Accenture.

AWS Competency Partner

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
386
On SlideShare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
63
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

AWS re:Invent 2016: Accenture Cloud Platform Serverless Journey (ARC202)

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Tom Myers, Sr. Cloud Architect, Accenture Cloud Platform Matt Lancaster, Lightweight Architectures Global Lead Accenture Cloud Platform Serverless Journey ARC202 November 29, 2016
  2. 2. What Makes an Offering a “Platform” *Platform Ecosystems: Aligning Architecture, Governance, and Strategy, Amrit Tiwana, 2014, Section 1.2. The common denominator of all platforms is that they facilitate interactions between distinct groups (the two “sides”) that want to interact with and need each other.*
  3. 3. What is the Accenture Cloud Platform? Accenture Cloud Platform (ACP) offers clients an on-ramp to the cloud. ACP provides governance, analytics, and services to support the transition to and provide ongoing support of their cloud journey. ACP services enable clients on one side, and Accenture solution providers on the other. ACP has transitioned over time from on- premises data center, to cloud virtual data center, and is now transitioning to serverless platform.
  4. 4. How Does ACP Support its Ecosystem? ACP Accenture Business Groups Clients AWS Service Catalog Development Process
  5. 5. Why Serverless? ACP is fundamentally a collection of services coordinated by an orchestrator and ordered via service catalog. A microservices architecture – services orchestrated and interacting via APIs – is well-suited for such an offering. A serverless design can optimally host highly available and scalable microservices.
  6. 6. Why AWS? The serverless options available from AWS are the most mature from any cloud provider. Scalability, availability, reliability, performance and other architectural concerns are well- addressed in AWS. A number of good tools exist to design and deploy complex microservices to the AWS Cloud service environment. The Accenture AWS Business Group is our 1-year old partnership with Amazon Web Services, to bring clients the power of cloud through AWS.
  7. 7. Ring 0 • Core Services • APIs to support Ring 1+ • Continuous Delivery Ring 1 • Applications/ Services • Rely on Ring 0 • Agile Releases Ring 2 • Client Applications/ Services • Rely on Rings 0 & 1 • Client Control ACP Ring Model
  8. 8. Serverless Architecture
  9. 9. Serverless Architecture DNS Owned by Enterprise IT Dept.
  10. 10. Serverless Architecture Global CDN
  11. 11. Serverless Architecture Lambda execution with SNS, Redis, Amazon Kinesis for communication
  12. 12. Serverless Architecture DynamoDB, Amazon Redshift, Elasticsearch for persistent storage
  13. 13. Serverless Architecture
  14. 14. Serverless Architecture Components Accounts • API Gateway • Lambda • Amazon ElastiCache for Redis • DynamoDB, Amazon Redshift • Amazon Kinesis & DynamoDB Streams • Elasticsearch • SNS Topics/Subscriptions & SQS • CloudWatch Logs • CloudFront/S3 Flexible design allows components to be swapped • Rings – Core – Apps • Lifecycle – Sandbox – Dev – Test – Stage – Prod 10 accounts with cross-account roles Core ⇄ Apps
  15. 15. DevOps Pipeline
  16. 16. DevOps Model Continuous Delivery • Terraform + Apex – CloudFormation didn’t fully support API G/W when we needed it – Custom framework (code consistency, name checking, etc.) • Solved a lot of the initial inherent complexity in Lambda and API G/W deployment • Higher-level abstraction for all infrastructure with simple config files to generate Terraform • Supports cross project & AWS account Terraform dependencies and stores state on S3 • Accenture DevOps Platform – We currently use BitBucket, Jenkins, Sonar – Also supports Nexus, Kibana, Selenium, etc. – Deploys via ACP as an automated stack – https://github.com/Accenture/adop-docker-compose
  17. 17. Challenges • CloudFormation – Occasionally gets stuck requiring AWS Support to resolve – Monitoring status and completion of stacks – Diagnosing and fixing errors not always straightforward – Verbose JSON format for large stacks at times unwieldy (even with Troposphere) - YAML a welcome addition!! • API Gateway – Limited initial support in CloudFormation – Overhead of creating large API Gateway definitions – HTTP method mappings complex – Recent enhancements such as Swagger import and passthrough will help a lot! • Need to explicitly define all infrastructure, which gets complex at scale – IAM roles, policies, Lambda functions & SNS/stream mappings, etc. – Handled by custom framework
  18. 18. Lessons Learned • Lightweight frameworks can allow greater flexibility (e.g., AWS account per environment/stage) • Pick a Lambda runtime – lots will work, but less reuse opportunities • Operability and security must be considered and designed for • Plan for upgrades ahead of time (e.g., Elasticsearch) • Pay attention to limits (e.g. CloudWatch logs writes, batch size, and message dates in batch events, DynamoDB read/write) • Define Lambda logging conventions and how these fit into the monitoring components (Elasticsearch/Kibana) • Being an early adopter comes with risk and often requires workarounds
  19. 19. Benefits • Deploy in minutes (no delay waiting for other teams) – 10 deploys per day (or more) – Deployment triggers on code-commit • Bug fixes deploy more quickly with isolated functions and CD • Use of custom framework allows for rapid creation of complex components that use multiple AWS services • Swagger provides rapid deployment of documentation • API Gateway simplifies API versioning and deployments
  20. 20. Patterns • Write functions in Lambda functions – design for parallel execution – Small, idempotent routines – Built in restart, retry – Cache state (Redis, ElastiCache) • Surface Lambda functions with API Gateway – User Custom Domain Names and pathing to gather APIs together – This enables independent build with a consistent experience • Communicate with services – SNS to send messages – Amazon Kinesis to pass data • Target storage to Elasticsearch – Search queries are probably what you need anyway • Persist data with DynamoDB – Keep a date key (epoch) to partition and purge data – Send backup to low cost storage
  21. 21. Hybrid Integration Example
  22. 22. Operations and Monitoring Example
  23. 23. The Future of Serverless Applications Current State Future State • Heavy use of the console to manage different services • Lambda is over-utilized • Shoving existing code into Lambda • No real system health visualizations • Use a framework to manage resources • Use platform services (e.g., velocity templates, Amazon Kinesis streams) to supplement Lambda • Develop applications to ensure minimal code deployments • Use open source time series visualization tool for operational readiness
  24. 24. Don’t Use Lambda for Everything • Consider the capabilities available within AWS first, and use Lambda only when necessary • Take advantage of Apache Velocity for transformations in the API Gateway instead of using a Lambda function • If data ingestion is required, consider using an AWS Proxy to Amazon Kinesis for greater throughput and scalability • Most AWS services expose a RESTful endpoint for an API Gateway AWS proxy interaction • Use Lambda where you need to execute business logic
  25. 25. Use Velocity Instead of Lambda for Transformations
  26. 26. Use Streams to Optimize Throughput stream Lambda function • Using DynamoDB or Amazon Kinesis Streams allows bulk processing of data • Tuning the EventSourceMapping BatchSize to just under 100 ms ensures that you’re getting the greatest value from your Lambda functions
  27. 27. Be Nice to Your Lambda • Use bundlers like Webpack or Browserify to ensure only required dependencies are present in deployed Lambda functions. • Ensure that no dev dependencies are being included in your packaged Lambda functions. • Lambda containers have the ability to persist across invocations. Make sure to group multiple related methods in the same handler file to increase invocation rate, in order to avoid cold boot delays. • Instantiate persistent objects outside of methods to increase Lambda execution performance during container reuse conditions.
  28. 28. Don’t Bother with CloudWatch for Operations Metrics • CloudWatch is not a realistic choice for enterprise operations metrics • Dedicated time-series systems like Prometheus.io are a far better choice for near real-time operations dashboards CloudWatch Prometheusvs
  29. 29. Story Time!
  30. 30. Alexia – An Alexa Node.js Framework Written in ES6 Speech assets generation Cards support Works with Lambda, Hapi, Express Build in state machine Starter kit
  31. 31. Alexa Skill with Alexia Framework const alexia = require('alexia'); const app = alexia.createApp(); app.intent('HelloIntent', 'Hello', () => { return 'Hello from Alexia app'; });
  32. 32. Interaction API Demo Architecture Echo Alexa Skills Kit Lambda Handler API Gateway Catalog API
  33. 33. “Aspirin has been added to your cart. But I’ve found interactions between your medications. Please consult with your doctor or pharmacist” Case Study – Pharmacy Advisor
  34. 34. Showcase modern architecture principles and leverage from Amazon Web Services Case Study – Pharmacy Advisor
  35. 35. “Add Aspirin to my cart.” “Aspirin has been added to your cart. But I’ve found interactions between your medications. Please consult it with your doctor or pharmacist” Demo Conversation “Add Ibuprofen to my cart.” “Ibuprofen has been added to your cart.”
  36. 36. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Tom Myers thomas.w.myers@accenture.com @TomMyersACP Visit us at the Accenture booth #829 Matt Lancaster matthew.d.lancaster@accenture.com @urnamma
  37. 37. Remember to complete your evaluations!

×