cloud adoption patterns

© 2015 IBM Corporation

IBM Cloud

Cloud Adoption Patterns

Kyle Brown, Bobby Woolf, Robert Rafuse and many others…

IBM Cloud

© 2015 IBM Corporation2

Outline What is our problem?

– What is a pattern? – What’s a pattern language?

The Cloud Adoption Patterns

What’s next?

IBM Cloud


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


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


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


Pattern Language Map

Hybrid Connectivity App Arch

Deployment Styles DevOps

Adoption Process

Cloud-Centric Design Cloud Tuning

Workload Assessment

Lift and Shift

API

ConnectorData 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 andCaching

Session Cache

Result Cache

DynamicContent

FunctionalTest Suite

BFF

NativeDocument

Store

Red/Black Deploy

Feature Toggle

Dark Launch

IBM Cloud


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


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




Deployment Styles DevOps

Adoption Process


Workload Assessment

Lift and Shift

API

ConnectorData Cache

Circuit Breaker

Bulkhead

Distributed Store

Microservices

Stateless Runtime


Common Log Fmt

Containerization


Aggregate

Artifact Injection

Pipeline

Log Aggregation

Autoscaling

Test Harness

SPA

Data andCaching

Session Cache

Result Cache

DynamicContent


BFF

NativeDocument

Store

Test First Design

Red/Black Deploy

Feature Toggle

Dark Launch

IBM Cloud


10

Criteria for cloud-ready applications1. Application’s design is topology-agnostic

Ex: Clustering is supported, no specific cluster size needed2. Application’s management is infrastructure-agnostic

Ex: Doesn’t depend on IP addresses, hostnames, or VLANs3. Application doesn't use infrastructure-specific APIs4. Application doesn't use OS-specific features5. Application doesn't use the local file system6. Application logs to persistent storage, not the file system7. Application keeps session state only in the interaction layer8. Application components connect via standard protocols9. Application’s installation and configuration is scripted

Ex: Deployment is easily repeatable

IBM Cloud


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




Deployment DevOps

Adoption Process


Workload Assessment

Lift and Shift

API

ConnectorData Cache

Circuit Breaker

Bulkhead

Distributed Store

Microservices

Stateless Runtime


Common Log Fmt

Containerization


Aggregate

Artifact Injection

Pipeline

Log Aggregation

Autoscaling

Test Harness

SPA

Data andCaching

Session Cache

Result Cache

DynamicContent


BFF

NativeDocument

Store

Test First Design

Red/Black Deploy

Feature Toggle

Dark Launch

IBM Cloud


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


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


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

15

IBM Cloud


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.

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


Faster

Complexity

Speed of Delivery

Ope

ratio

nal C

ompl

exity

Adopting microservices means more complex ops environmentsin exchange for high-speed delivery & reduced time to market

The true cost of microservice-based architectures


IBM Cloud

Adoption Process Patterns

IBM Cloud


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


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


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


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


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


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


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


Application Architecture: Stateless Runtime

Context: You are building an application using CloudCentricDesignProblem: 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


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


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


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


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


DevOps: Automated Test Harness


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


Deployment: Containerization


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


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


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


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


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


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


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


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


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


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


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


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


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

Internet