O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Implementing Service Oriented Architecture

3.335 visualizações

Publicada em

SaaS architectures can be deployed onto AWS in a number of ways, and each optimizes for different factors from security to cost optimization. Come learn more about common deployment models used on AWS for SaaS architectures and how each of those models are tuned for customer specific needs. We will also review options and tradeoffs for common SaaS architectures, including cost optimization, resource optimization, performance optimization, and security and data isolation.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Implementing Service Oriented Architecture

  1. 1. ©2015,  Amazon  Web  Services,  Inc.  or  its  affiliates.  All  rights  reserved Implementing Service Oriented Architectures Real World App Migrations to AWS Bradley Clerkin – Solution Principal @ Slalom
  2. 2. Assumptions •  You understand the “why cloud”. •  You are considering a set of applications or environments to move to AWS. •  You want to hear about the real challenges of executing an application migration to AWS.
  3. 3. Agenda •  Migration stories •  Realities of app migrations •  Approach to successful app migrations •  Q & A
  4. 4. Migration Stories
  5. 5. Retail Servicing Platform (Story 1) Primary facility goes down Secondary is deemed unusable 48 hour outage ensues “Customer impact was high, but the impact on reputation was almost immeasurable.” -CTO
  6. 6. The Ideal Lift & Shift + Big Bang Build advanced automation to support concurrent deployments Mirror production architecture in AWS Push the big red DR button to migrate everything 6 Months
  7. 7. The Actual Single Service Migrations Automation was complex and only feasible in AWS Apps required refactoring to run in AWS Pushed a red DR button for each service 12 Months
  8. 8. Financial Services Firm (Story 2) End of life, out of capacity on-prem infrastructure Home grown loan origination and servicing app running on open source technology Company looking to scale 10x in a few years “Our greatest challenge is in providing the capacity to meet the almost unknown future demands of the business.” –Senior Director of IT
  9. 9. The Ideal Lift & Shift + Big Bang Build advanced automation to support auto scaling Focus on building services Cause no impact on existing release cycles 4 Months
  10. 10. The Actual Two flops and one Big Bang Automation required large investment of time from App SMEs Building services was cost and resource prohibitive Impacted two release cycles in order to integrate AWS with development flows 8 Months +
  11. 11. Commonalties •  With estimation, the devil is in the details. •  Applications had to be refactored. •  Automation tools and AWS platform services were heavily utilized. •  It was a group effort including partner, AWS, and internal resources. •  SME resources from Slalom were utilized.
  12. 12. Realities of App Migrations
  13. 13. Lift & Shift migrations may not be as they seem •  L & S appears technically viable on the surface. •  Non cloud optimized architectures are expensive. •  Most goals of cloud require cloud optimized architectures. •  Outages are typical in L & S scenarios. •  This leads to failed cloud enablement efforts.
  14. 14. Applications will have to be refactored for AWS •  Fight the urge to fully rewrite the application. •  Avoid the shiny stuff when refactoring. •  Understand application dependencies and constraints. •  Complete a cost benefit analysis when determining what to refactor. •  Understand how much holding onto your existing architecture is going to cost.
  15. 15. Technical Debt Technical debt is a metaphor referring to the debt created from legacy systems and long-maintained architectures. If the debt is not repaid by correcting the suboptimal solution, then it will continue to accumulate interest. This interest takes the form of increasing complications when trying to resolve or repay.
  16. 16. Technical debt must be paid down •  Migrations are the collections agencies for technical debt. •  It can be embarrassing. Don’t play the blame game. •  Have a strategy for dealing with technical debt. •  Focus on education and prevention.
  17. 17. Automation tooling plays a critical role in migration projects •  New automation tools are like an inheritance check in the mail. •  Make sure that the “why” is clearly defined. •  Automation projects are continuous improvement projects. •  Treat your automation artifacts like codebases.
  18. 18. Big Bang migrations are troublesome •  BB delays critical production validation. •  Operational resources greatly benefit from gradual changes. •  The benefits of AWS are only realized at the end of BB migrations. •  The act of migration itself isn’t the benefit you want to share, but rather the new capabilities realized once an app is in AWS. •  In most cases, hybrid solutions are valid solutions.
  19. 19. Limit the focus placed on building your own services •  Cloud enables a constant conversation between BYO and service consumption. •  Focus on industry standard protocols and available features. •  Services that have proprietary components still fit into standard architectures. •  Make sure you select the right cloud vendor from the start.
  20. 20. Approaching Cloud Migrations
  21. 21. Phase Focused Approach App Analysis Backlog & T-Shirt Sizing Build Supporting Pipeline Non-Prod Migration Prod Migration Optimization
  22. 22. Perform an app analysis Outputs: Current State Gap Analysis & Product Roadmap Twelve-Factor Analysis •  Codebase •  Dependencies •  Config •  Backing services •  Build, release, run •  Processes •  Port binding •  Concurrency •  Disposability •  Dev/prod parity •  Logs •  Admin processes AWS Readiness Analysis •  Dependency mapping •  Security and compliance •  Licensing •  Instance •  Elasticity •  Load balancing / Proxy •  Authentication •  Design for failure •  Database •  Data storage •  File sharing •  AWS services parity More at 12factor.net and in AWS Architecture Center
  23. 23. Conduct a current state gap analysis •  There is no “right” format. •  Compare current state against a standard. •  Highlight gaps. •  Theorize how to close identified gaps.
  24. 24. Produce a product roadmap •  Contains a phased plan for architecture changes and migration activities. •  Allows for cross team and executive level communication. •  Drives the current and long term project efforts.
  25. 25. Construct a backlog and perform t-shirt sizing •  Document task details for implementing the first phase of the product roadmap. •  Assign a complexity rating of S, M, L. •  It’s critical to remember it’s not about time but rather complexity. Key Summary Issue Type Status Priority Description Acceptance Criteria Estimate (T-Shirt) Assumptions DR-­‐196   Build and Deploy Story Backlog Minor This story will encompass tasks necessary to complete the orchestration for standing up instances. Create build artifacts Deploy to AWS Jenkins project created to support standing up an application stack Cloudformation configuration created Large - Define Jenkins job to build the Ansible artifacts (in flight) - Create another job to build those jobs (based on monitoring new role creation; build chain) (in flight) - Deployment portion: next phase
  26. 26. Architect and build the supporting deployment pipeline •  Acts as a factor for migrating workloads and dealing with technical debt. •  Typically consists of repositories, build server, orchestration server, configuration management tooling, and log management.
  27. 27. Migrate non-prod •  Allows engineering teams to learn about AWS. •  Enables rapid realization of the advertised benefits. •  Limits the initial scope of operating in the cloud. •  Ensures environments are built from similar artifacts. •  Once non-prod is conquered, other environments follow suit quickly.
  28. 28. Migrate prod •  The greatest obstacles are in operational sign-off. •  Be prepared to answer the hard questions. •  Continuously educate others on the project. •  It is possible to automate a portion of this education. •  If possible, extend the pipeline to production.
  29. 29. Optimize prod •  Baseline production applications in AWS. •  Utilize logging extensively in optimization efforts. •  Improve cost and performance efficiency of components. •  Continue education and product roadmap efforts.
  30. 30. Questions? bradleyc@slalom.com
  31. 31. SAN FRANCISCO
  32. 32. Dashboards and Measurement •  Report on your migration project status. •  Introduce operational app status. •  Measure business metrics. •  Error dashboard. •  Present this information live.
  33. 33. Start in development environments •  Allows individuals building the applications to understand the new services and APIs. •  If you have to refactor the app the effort has to start in Dev. •  In many organizations the deployment of infrastructure is a major bottleneck. •  Limits the initial scope and risk of operating in the cloud. •  Plan to build Prod from Dev artifacts. •  Once Development is conquered other environments follow suite quickly.
  34. 34. Challenges once you start to win •  Limiting account sprawl •  Guard rails rather then lock down •  User education •  Auditing at scale •  AWS limits •  Inner cloud migrations
  35. 35. Someone has to own AWS •  Should be a cross functional team •  Sets the standards and guard rails •  Acts a center of excellence •  Publishes the right way to do things •  Spends time educating and enabling •  Owns cost optimization
  36. 36. Inter cloud migrations •  How to build the cloud for enterprise scale is hard •  Many patterns and “correct” solutions •  What worked at 50 instances likely won’t work at 500 •  Same is true for 5000 •  Trying to solve for 5000 at 50 doesn’t work either… because you’ll miss something •  Continuous improvement concepts should be applied to cloud architectures

×