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.

Cloud adoption patterns

1,114 views

Published on

Updated version of the cloud adoption patterns.

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Cloud adoption patterns

  1. 1. © 2015 IBM Corporation IBM Cloud Cloud Adoption Patterns Kyle Brown, Bobby Woolf, Robert Rafuse and many others…
  2. 2. IBM Cloud © 2015 IBM Corporation 2 Outline  What is our problem? – What is a pattern? – What’s a pattern language?  The Cloud Adoption Patterns  What’s next?
  3. 3. IBM Cloud © 2015 IBM Corporation 3 What are Patterns?  What is a pattern? – A solution to a problem in a context – A structured way of representing information in prose and diagrams – A way of communicating information from an expert to a novice – A way of defining a vocabulary with which you can have conversations 3 • To many, the most familiar example is Design Patterns: Elements of Reusable Object-Oriented Software [GHJV95] • 23 basic design patterns found in many large OO systems • A pattern catalog • Patterns are not dependent on each other
  4. 4. IBM Cloud © 2015 IBM Corporation 4 The problem…  Lots of stuff on how to build a cloud…  Lots of stuff on how clouds work…  Some stuff on how a single user can use a cloud… BUT  Not a lot on how an IT organization can use clouds  How do you integrate cloud solutions into its IT Strategy for their systems portfolios? – Application – Data – Infrastructure – Process
  5. 5. IBM Cloud © 2015 IBM Corporation 5 Generativity – A set of patterns is Generative when they show when and how to apply solutions – Stems from the early paper “Patterns Generate Architectures” by Beck and Johnson – Think about Generativity as being guidance on how to find your way through a pattern language – What are your next options? Under what circumstances do you want to choose them? – Generativity is the difference between a pattern catalog and a pattern language – Each pattern leads to others – Combine to solve an entire domain of problems – Multiple solutions form multiple paths
  6. 6. IBM Cloud © 2015 IBM Corporation 6 Pattern Language Map Hybrid Connectivity App Arch Deployment Styles DevOps Adoption Process Cloud-Centric Design Cloud Tuning Workload Assessment Lift and Shift API Connector Data Cache Circuit Breaker Bulkhead Distributed Store Microservices Stateless Runtime Runtime and Services Common Log Fmt Containerization Container per Service Aggregate Artifact Injection Pipeline Log Aggregation Autoscaling Test Harness SPA Data and Caching Session Cache Result Cache Dynamic Content Functional Test Suite BFF Native Document Store Red/Black Deploy Feature Toggle Dark Launch
  7. 7. IBM Cloud © 2015 IBM Corporation 7 The categories in the pattern map  Adoption Process –How do you adopt cloud technologies into your organization?  Hybrid Connectivity –How do you connect your application to things outside the cloud?  Application Architecture –How do you construct or refactor your application to take advantage of cloud technologies?  Deployment Styles –How do you deploy the components of your applications into the cloud?  DevOps –How do you assemble and manage your application?  Data and Caching –How do you store the data for your application or cache data?
  8. 8. IBM Cloud © 2015 IBM Corporation 8 Migration Types  Three types of migration of applications to Cloud – applicable under different circumstances  Application Re-platforming (Lift and Shift) – Do you want the user experience to remain the same? – Are you comfortable with the existing code base in terms of quality and currency? – Are the equivalents for all of your dependencies in Bluemix or your IaaS? – If so: Minimal code changes; some repackaging may be required; create new deployment automation  Application Modernization (Cloud Tuning) – Do you have dependencies (middleware, libraries, etc) that are out of support? – Do you need to move to a more modern level of your platform (JEE, Ruby, etc.)? – Do you have connections into existing systems of record? Do you need to change your connectivity options? – If so: Some code changes required; at least require retesting of all subsystems and end- to-end testing to ensure that new code functions the same way as old code.  Application Re-envisioning (Cloud Centric Design) – What do you want your new user experience to be? Are you trying to embrace multiplatform development? – Do you want to repackage your application as Microservices? – If so: This is effectively brand-new development activity. You may be able to harvest some old code.
  9. 9. IBM Cloud © 2015 IBM Corporation 9 Pattern Language Map Hybrid Connectivity App Arch Deployment Styles DevOps Adoption Process Cloud-Centric Design Cloud Tuning Workload Assessment Lift and Shift API Connector Data Cache Circuit Breaker Bulkhead Distributed Store Microservices Stateless Runtime Runtime and Services Common Log Fmt Containerization Container per Service Aggregate Artifact Injection Pipeline Log Aggregation Autoscaling Test Harness SPA Data and Caching Session Cache Result Cache Dynamic Content Functional Test Suite BFF Native Document Store Test First Design Red/Black Deploy Feature Toggle Dark Launch
  10. 10. IBM Cloud © 2015 IBM Corporation 10 Criteria for cloud-ready applications 10 1. Application’s design is topology-agnostic Ex: Clustering is supported, no specific cluster size needed 2. Application’s management is infrastructure-agnostic Ex: Doesn’t depend on IP addresses, hostnames, or VLANs 3. Application doesn't use infrastructure-specific APIs 4. Application doesn't use OS-specific features 5. Application doesn't use the local file system 6. Application logs to persistent storage, not the file system 7. Application keeps session state only in the interaction layer 8. Application components connect via standard protocols 9. Application’s installation and configuration is scripted Ex: Deployment is easily repeatable
  11. 11. IBM Cloud © 2015 IBM Corporation 11 Packaging Considerations  Cloud Foundry is often the simplest scenario when your code is simple, standards-compliant, and does not require significant tuning of the runtime environment  Docker allows you more control over your runtime environment –Selection of middleware versions –Middleware configuration and tuning –Single-container deployment of >1 package  VM’s are still the gold standard for deployment of large, complex, multi- node systems –Although as the Docker Ecosystem matures, this becomes less true
  12. 12. IBM Cloud © 2015 IBM Corporation 12 Pattern Language Map Hybrid Connectivity App Arch Deployment DevOps Adoption Process Cloud-Centric Design Cloud Tuning Workload Assessment Lift and Shift API Connector Data Cache Circuit Breaker Bulkhead Distributed Store Microservices Stateless Runtime Runtime and Services Common Log Fmt Containerization Container per Service Aggregate Artifact Injection Pipeline Log Aggregation Autoscaling Test Harness SPA Data and Caching Session Cache Result Cache Dynamic Content Functional Test Suite BFF Native Document Store Test First Design Red/Black Deploy Feature Toggle Dark Launch
  13. 13. IBM Cloud © 2015 IBM Corporation 13 Design Principles for Cloud Centric Applications  There are a number of design principles that Bluemix applications follow that may make them a bit different from traditionally constructed applications  Bluemix applications are “Born on the Cloud” and that implies (or enables) a number of new design principles – The applications are often built using Microservices architectures – The teams follow DevOps principles – Most are built in accordance with the 12-factor.net rules  In general, Born on the Cloud applications – Have a shorter lifetime than traditional applications – new versions are rolled out very quickly – Are built using principles of polyglot programming and polyglot persistence
  14. 14. IBM Cloud © 2015 IBM Corporation 14 What are the Twelve Factors? I. Codebase - One codebase tracked in revision control, many deploys II. Dependencies - Explicitly declare and isolate dependencies III. Config - Store config in the environment IV. Backing Services - Treat backing services as attached resources V. Build, release, run - Strictly separate build and run stages VI. Processes - Execute the app as one or more stateless processes VII. Port binding - Export services via port binding VIII. Concurrency - Scale out via the process model IX. Disposability - Maximize robustness with fast startup and graceful shutdown X. Dev/prod parity - Keep development, staging, and production as similar as possible XI. Logs - Treat logs as event streams XII. Admin processes - Run admin/management tasks as one-off processes
  15. 15. IBM Cloud © 2015 IBM Corporation 15 Refactoring for microservices  Ways to Refactor your application – Each REST service is potentially a microservice – Each SOAP web service or EJB is potentially a microservice – Especially stateless session beans – Redesign function-oriented interfaces to asset-oriented interfaces – Make the interface RESTful, such as using Command objects – Use domain-driven design to discover your assets, they may be microservices  Refactor your data (for the microservices’ code) – Each microservice manages its own data – A set of tables that is only used by one module – A set of tables that is only used at a particular time, like a daily status summary – Refactor the tables so that each table is only used by one module – Optimize for query time, not storage efficiency
  16. 16. IBM Cloud © 2015 IBM Corporation 16 Repackaging your application  Split up your EAR files – Divide along functional lines – Package Independent WAR files – May require minor code changes  Apply “One Container Per Service” – Deploy each WAR separately in its own Bluemix Liberty instant runtime or Docker container  Build, Deploy and Manage Separately – Use independent DevOps Pipelines for each WAR. – Scale each separately and manage independently. 16 App Server WAR A WAR B WAR C App Server App Server App Server WAR A WAR B WAR C EAR Before After
  17. 17. IBM Cloud © 2015 IBM Corporation 17 Faster Complexity Speed of Delivery OperationalComplexity Adopting microservices means more complex ops environments in exchange for high-speed delivery & reduced time to market The true cost of microservice-based architectures
  18. 18. © 2015 IBM Corporation IBM Cloud Adoption Process Patterns
  19. 19. IBM Cloud © 2015 IBM Corporation 19 Adoption Process: Lift and Shift Context: You’re evaluating a number of different cloud provider options. You have an existing application in mind you want to move to the cloud, but you don’t have the luxury of rewriting it. Problem: How do you gain the advantages of cloud by deploying an application to the cloud while minimizing the changes needed to be made to the application? Solution: Choose an IaaS cloud provider that can create the closet possible match to the environment the application was designed for. Then perform a Lift and Shift of an existing application onto the cloud platform. Real examples: WellPoint PureApp experiences, SoftLayer migrations for Tangerine Bank
  20. 20. IBM Cloud © 2015 IBM Corporation 20 Adoption Process: Cloud Tuning Context: You want to migrate an existing application onto the cloud. You have a little bit of leeway on how many changes you can make to the application and its configuration. Problem: How do you minimally adapt an existing application to work with a PaaS while not requiring a complete rewrite of the application? Solution: Perform Cloud Tuning to remove the most egregious dependencies on existing environments until the application can easily be deployed as PaaS components. Real examples: DTCA PureApp patterns migration
  21. 21. IBM Cloud © 2015 IBM Corporation 21 Adoption Process: Cloud-Centric Design Context: You have a problem to solve, and also have the ability to write a brand new application (or rewrite an existing one) and the time in which to do that application development work. Problem: How do you design your application to take the maximum advantage of all the features of the cloud for the best future proofing and agility? Solution: Perform a full Cloud-Centric Design of your application to run natively on a cloud (PaaS) environment. Real examples: Published Bluemix Garage experiences
  22. 22. IBM Cloud © 2015 IBM Corporation 22 Adoption Process: Workload Assessment Context: You are in the process of moving two or more applications to the cloud. You need to determine which applications most deserve your attention and work. Problem: How do you determine which applications are best suited for IaaS, PaaS, or are not suitable for cloud at all? Solution: Perform a Workload Assessment that evaluates each application’s architecture, code, and topology for cloud compatibility. Real life examples: The PureApplication System PureStart Assessment, GTS Cloud migration assessments, Bluemix Adoption Success Workshop
  23. 23. IBM Cloud © 2015 IBM Corporation 23 Adoption Process: Test First Design Context: You are in the process of moving one or more applications to the cloud. You are performing changes to the application as part of CloudTuning or your are writing the entire application (or major sections of it) as part of a CloudCentricDesign. However, you are not entirely sure what the final topology and environment in which your application will function will be. Problem: How do you guarantee that your code will work in the cloud environment, and also ensure that as the environment changes underneath the application that it will continue to function? Solution: Develop your application using Test First Design. Build Test cases which test the functionality of the application independent of the particular topology of the environment and execute them in multiple different environment combinations as part of your standard Build and Deployment process. Real life examples: Test-Driven Infrastructure with Chef, Published Bluemix garage experiences
  24. 24. © 2015 IBM Corporation IBM Cloud App Architecture Patterns
  25. 25. IBM Cloud © 2015 IBM Corporation 25 Application Architecture: Single Page Architecture (SPA) Context: You are performing a Cloud-Centric Design or you are refactoring a small portion of an application as part of Cloud Tuning. Problem: How do you design the front end of your application to take advantage of the capability of modern browsers and provide the best mix of client responsiveness and server optimization? Solution: Design your application with a Single Page Architecture using HTML5, CSS3 and Javascript. Store page state within the client and connect to the backend through REST services. Real life examples: Tangerine Bank, Modern Web Development with IBM WebSphere
  26. 26. IBM Cloud © 2015 IBM Corporation 26 Application Architecture: Microservices Context: You are performing a Cloud-Centric Design or you are refactoring a small portion of an application as part of Cloud Tuning. Problem: How do you design an application with the most flexibility for reuse, composition, scalability, scalability, and continuous deployment? Solution: Design your application with a Microservices architecture Real life examples: Netflix
  27. 27. IBM Cloud © 2015 IBM Corporation 27 Application Architecture: Stateless Runtime Context: You are building an application using CloudCentricDesign Problem: How do you design your application to be able to take advantage of Autoscaling? Solution: Develop your application as one or more Stateless Runtimes that do not contain any application state and thus are instantly replaceable. See Building Microservices
  28. 28. © 2015 IBM Corporation IBM Cloud Devops Patterns
  29. 29. IBM Cloud © 2015 IBM Corporation 29 DevOps: Pipeline  Context: You are either building a new application with a Cloud Centric Design or reimplementing an application as part of Cloud Tuning.  Problem: How do you ensure that your application can be built, tested and deployed in an automated and standardized way?  Solution: Define a Pipeline of standard build and deployment stages.  Examples: Pipelines in UrbanCode Deploy or IBM DevOps Services
  30. 30. IBM Cloud © 2015 IBM Corporation 30 DevOps: Functional Test Suite  Context: Application Development  Problem: How do you guarantee that you can move an application from one development stage to another?  Solution: Develop a Test Suite that tests all the major external functionality of your application. The completeness of the functional test suite guarantees that your application can be fully tested and will show any environment-specific dependencies quickly.  Examples: Multiple tools exist for building full functional test suites, including Cucumber, Capybara, Rspec and also GUI-centric tools like Selenium
  31. 31. IBM Cloud © 2015 IBM Corporation 31 DevOps: Log Aggregation Context: You are building a new application with CloudCentricDesign using Stateless Runtimes and taking advantage of Autoscaling. Problem: How do you ensure that errors and problems in your code and tracked and identified regardless of changes in the runtime topology? Solution: Use Log Aggregation to centralize logs and do not regard the individual log files on the VM’s or containers as sources of truth. Examples: Splunk, CloudFoundry Loggregator Resulting Context: There are a lot of things you can do with Log Analysis and the ELK stack after you have aggregated the Logs…
  32. 32. IBM Cloud © 2015 IBM Corporation 32 DevOps: Autoscaling Context: You’d like your application’s capacity to adjust elastically based on load. Problem: How do you plan for handling unpredictable load while at the same time minimizing the per-unit cost of application hosting? Solution: Use Autoscaling to dynamically adjust the number of identical runtime instances to only the number required by current traffic loads. Ex: WebSphere Application Server Dynamic Clusters, PureApplication Scaling Policies, Bluemix Autoscaling Service. Amazon Elastic Beanstalk
  33. 33. IBM Cloud © 2015 IBM Corporation 33 DevOps: Automated Test Harness Context: Application Development Problem: How do you determine that changes to your application have not made functionality that previously worked no longer work, or that they fulfill the purposes for which they were written? Solution: Use an Automated Tests Harness that can be executed from an API and can be kicked off at any time, in any environment. Examples: Tools like Junit for Java were the first entries in this space, although Junit equivalents exist in most major languages. Execution of Automated tests is usually done as part of Development Pipeline stage
  34. 34. © 2015 IBM Corporation IBM Cloud Deployment Patterns
  35. 35. IBM Cloud © 2015 IBM Corporation 35 Deployment: Containerization Context: Application Development Problem: How do you package a section of an application such that its function will be absolutely consistent across lifecycle stages and deployment targets? Solution: Take advantage of Containerization and package your application code inside a container. Examples: Docker, Warden Containers in Cloud Foundry, Windows Server Containers and Hyper-V Containers in Azure
  36. 36. IBM Cloud © 2015 IBM Corporation 36 Deployment: Container per Service Problem: In a Microservices architecture, how do you distribute services across multiple runtimes when using Containerization? Solution: Create a Container per Service. If necessary, to minimize runtime footprint, group Microservices vertically. Examples: See Building Microservices
  37. 37. IBM Cloud © 2015 IBM Corporation 37 Deployment: Aggregate Problem: When performing Cloud Tuning, how do you define a reusable architecture that defines a generic application structure independent of particular application artifacts? Solution: Define an Aggregate of services, runtimes, and the connections between them Examples: PureApplication Patterns, HOT Templates, Docker Compose YML’s
  38. 38. IBM Cloud © 2015 IBM Corporation 38 Deployment: Artifact Injection Problem: How do you add application-specific runtime configuration and application code into a generic template in a repeatable way? Solution: Use Artifact Injection to introduce application-specific aspects specified from a configuration into the generic template. Examples: UrbanCode Deploy Plugins, Chef, Puppet
  39. 39. © 2015 IBM Corporation IBM Cloud Hybrid Cloud Patterns
  40. 40. IBM Cloud © 2015 IBM Corporation 40 Hybrid: Functional API Problem: How does your cloud-based app integrate with the functionality in an existing application? Solution: The existing application exposes its functionality as a general-purpose Functional API that can be invoked by separate applications, including applications hosted in the cloud.
  41. 41. IBM Cloud © 2015 IBM Corporation 41 Hybrid: Service Adapter Problem: How do you provide an API for a system that does not publish an existing API? Solution: Build a Service Adapter around the existing system that will be published as a Functional API. Examples: This is a standard use case for API Management – you build a service adapter using a technology like an ESB and then publish the API.
  42. 42. IBM Cloud © 2015 IBM Corporation 42 Hybrid: Managed API  Problem: How do you control which apps can use an API and control how they use it?  Solution: The application accesses an existing Functional API via a Managed API that authorizes use and managed how it can be used, such as when and how much.  Examples: This is also a common use case in API Management
  43. 43. IBM Cloud © 2015 IBM Corporation 43 Hybrid: Circuit Breaker Problem: How do you maintain resiliency and high availability in an application that relies on Functional APIs? Solution: Implement Circuit Breakers into your applications that surround API calls with alternate paths for failure cases. Example: Netflix Hysterix
  44. 44. IBM Cloud © 2015 IBM Corporation 44 Hybrid: Service Registry Problem: How do multiple Circuit Breakers know when a service provider should be avoided and when it’s available again? Solution: Circuit Breakers in the same location (i.e. platform region) use a Service Registry to coordinate. It keeps track of available and unavailable service providers, tests unavailable ones in the background to determine when they’re available again, distributes load, adapts for version, tracks usage, etc., etc., etc. Examples: Zookeeper, Consul, Netflix Eureka
  45. 45. © 2015 IBM Corporation IBM Cloud Data and Caching Patterns
  46. 46. IBM Cloud © 2015 IBM Corporation 46 Data and Caching: Distributed Store  Context: You are performing a CloudCentricDesign and want to build your application with Stateless Runtimes. However, your application will need runtime state to represent current and previous user interaction.  Problem: How do you represent user sessions or other runtime state in an application using Stateless Runtimes?  Solution: Put all state in a Distributed Store where it can be available to and shared by any number of application runtimes.  Ex: Bluemix Data Cache, Cloudant, Memcached
  47. 47. IBM Cloud © 2015 IBM Corporation 47 Data and Caching: Session Cache Context: You are performing CloudTuning and are working with an existing application that uses DynamicContent. However, your application must be able to scale its runtime state across multiple runtimes and persist session data across the termination of any specific runtime. Problem: How do you represent traditional user sessions in an application using Stateless Runtimes? Solution: Use a SessionCache that implements your runtime’s session caching API that is implemented as a DistributedStore. In that way the session data can be available to and shared by any number of application runtimes. Ex: Bluemix SessionCache, IBM ExtremeScale
  48. 48. IBM Cloud © 2015 IBM Corporation 48 What’s next?  All that you’ve seen today is a prolegomena – I’ve just stated that the problem exists and that there seems to be a solution that could fit!  We still need to write the complete patterns – Especially the contexts, the resulting contexts, and the examples and sample code – There are lots of additional patterns that need to be discovered and fleshed out  We need to come up with more paths through the existing patterns – Again, all we’ve shown is that some known paths exist, but we don’t know that the architectures they are generating are the absolute best ones
  49. 49. IBM Cloud © 2015 IBM Corporation 49 References  [Alexander 77] Christopher Alexander, et. al., A Pattern Language: Towns, Building, Construction, Oxford University Press, 1977  [Alexander79] Christopher Alexander, et. al., A Timeless Way of Building, Oxford University Press, 1979  [GHJV95] Erich Gamma, et. al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley 1995  [Newman15] Sam Newman, Building Microservices, O’Reilly, February 2015  [Turnbull14] James Turnbull, The Docker Book: Containerization is the new Virtualization, James Turnbull through Amazon Digital Services, July 2014

×