Cloud Adoption Patterns Guide

© 2015 IBM Corporation
IBM Cloud
Cloud Adoption
Patterns
Kyle Brown, Bobby Woolf, Robert Rafuse and many others…

IBM Cloud
2
Outline
 What is our problem?
– What is a pattern?
– What’s a pattern language?
 The Cloud Adoption Patterns
 What’s next?

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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?

IBM Cloud
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.

IBM Cloud
9
Deployment Styles DevOps
Adoption Process
Workload Assessment
Lift and Shift
API
Connector
Data Cache
Circuit Breaker
Bulkhead
Distributed Store
Microservices
Stateless Runtime
Common Log Fmt
Containerization
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

IBM Cloud
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

IBM Cloud
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

IBM Cloud
12
Deployment DevOps
Adoption Process
Workload Assessment
Lift and Shift
API
Connector
Data Cache
Circuit Breaker
Bulkhead
Distributed Store
Microservices
Stateless Runtime
Common Log Fmt
Containerization
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

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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

IBM Cloud
Adoption Process
Patterns

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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

IBM Cloud
App Architecture
Patterns

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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

IBM Cloud
Devops Patterns

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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…

IBM Cloud
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

IBM Cloud
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

IBM Cloud
Deployment Patterns

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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

IBM Cloud
Hybrid Cloud Patterns

IBM Cloud
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.

IBM Cloud
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.

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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

IBM Cloud
Data and Caching
Patterns

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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

IBM Cloud
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

Cloud Adoption Patterns Guide

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Cloud Adoption Patterns Guide

Similar to Cloud Adoption Patterns Guide (20)

Cloud Adoption Patterns Guide