How do you grapple with a legacy portfolio? What strategies do you employ to get an application to cloud native?
How do you grapple with a legacy portfolio? What strategies do you employ to get an application to cloud native?
This talk will cover tools, process and techniques for decomposing monolithic applications to Cloud Native applications running on Pivotal Cloud Foundry (PCF). The webinar will build on ideas from seminal works in this area: Working Effectively With Legacy Code and The Mikado Method. We will begin with an overview of the technology constraints of porting existing applications to the cloud, sharing approaches to migrate applications to PCF. Architects & Developers will come away from this webinar with prescriptive replatforming and decomposition techniques. These techniques offer a scientific approach for an application migration funnel and how to implement patterns like Anti-Corruption Layer, Strangler, Backends For Frontend, Seams etc., plus recipes and tools to refactor and replatform enterprise apps to the cloud. Go beyond the 12 factors and see WHY Cloud Foundry is the best place to run any app - cloud native or non-cloud native.
Speakers: Pieter Humphrey, Principal Product Manager; Pivotal
Rohit Kelapure, PCF Advisory Solutions Architect; Pivotal
Hungry for more? Check out this blog from Kenny Bastani:
http://www.kennybastani.com/2016/08/strangling-legacy-microservices-spring-cloud.html
Unleash Your Potential - Namagunga Girls Coding Club
Breaking the Monolith
1. Breaking The Monolith
Migrating Your Legacy Portfolio to the Cloud with Spring and Cloud Foundry
Rohit Kelapure, Pieter Humphrey
2. We believe that monoliths are an
appropriate early stage choice, but
outlive their design in the later stages
of the application’s adoption lifecycle.
2
3. Legacy Portfolio Realities
Things we hear:
Our portfolio is complicated, documentation is sparse
and it’s a mix of many things
Architecture is often tightly coupled code and complex
dependencies
Many people spend their days working with legacy
technology; they lack new skills
What we believe:
Pivotal Cloud Foundry is the comprehensive Cloud
Native platform to build the future
You get value by building apps on it
You see more value by moving existing apps
4. The Cloud Native Applications Journey
RUNS ON
LEGACY IT
RUNS ON
PIVOTAL CLOUD
FOUNDRY
RUNS WELL ON
PIVOTAL CLOUD
FOUNDRY
RUNS GREAT ON
PIVOTAL CLOUD
FOUNDRY
Your Existing Apps Running
on Current-Era Stacks
Supported by Time-Tested
People and Process
APPS REPLATFORMING
Suitable Apps Moved to
PCF with Minimal Code
Change; Better Ops Thanks
to Platform Automation
OPS & ORG TRANSFORMATION
Legacy Apps Refactored
Using 12-Factor Principles
and Modern Software
Process (TDD, CI/CD),
Optimized for PCF
Cross-Functional Teams
Delivering Continuous
Software Updates Into PCF
End-to-End Through
Modern Principles
APPS MODERNIZATION
CLOUD
NATIVE
Microservices,
Business Capability
Teams, API First Design
MICROSERVICES
6. A Legacy Maturity Model
4. CLOUD
NATIVE
3. RUNS GREAT
ON CLOUD
2. RUNS WELL
ON CLOUD
1. RUNS ON
CLOUD
• Microservice Architecture and Principals
• API First Design
• Use CI / CD tooling and methodology
• Design for failure, Proactive testing for failure (TDD)
• Apps unaffected by dependent service failure
• Metrics and Monitoring baked-in
• Cloud Agnostic runtime implementation
• Adherence with all 12-Factor App principals*
• Horizontally scalable
• Leverage platform for HA
• No file-system requirements or uses S3 API
• Self contained app (Fat JAR)
• Platform managed ports and addressing
• Consume off platform services using platform semantics
* We believe there are more like 15 “factors” that exemplify a true, “Cloud Native” application… more later
4 to 7 of the Factors
12-Factors + Advanced
Platform Automation
Product capability teams,
native microservices for
both App + Data
7. Why Bother Migrating Monoliths to PCF?BENEIFTS
Cloud Portability – free to run on any Cloud
Significant operational efficiencies – reduce headcount
Auto-scaling; efficiencies for spikey workloads
Automate patching, upgrading, and lifecycle
management
Standardize on dev stacks and platform-provided
services
Constant innovation of platform capabilities
Management and monitoring through the platform
Runtime consolidation and reduction of multiple vendors
9. Traditional Ways of Tackling Modernization
Lots of Upfront Study in a Multi-Phased Program
Uses Tools and/or Surveys to Gather Information
- Consultants who cast a wide net over everything
- Delivery of an expensive report and phased roadmap definition
Long projects with big budgets and large batches of work
- Failure is slow; it takes time and a lot of money to see problems
- Value is slow; measured returns often take years
PORTFOLIO ANALYSIS DESIGN MIGRATION TESTING ACCEPTANCE
10. Recommended Migration Path
Start here
Work up
from #2 to
#4 at your
own pace
4. CLOUD
NATIVE
3. RUNS GREAT
ON CLOUD
2. RUNS WELL
ON CLOUD
1. RUNS ON
CLOUD
• Microservice Architecture and Principals
• API First Design
• Use CI / CD tooling and methodology
• Design for failure, Proactive testing for failure (TDD)
• Apps unaffected by dependent service failure
• Metrics and Monitoring baked-in
• Cloud Agnostic runtime implementation
• Adherence with all 12-Factor App principals*
• Horizontally scalable
• Leverage platform for HA
• No file-system requirements or uses S3 API
• Self contained app (Fat JAR)
• Platform managed ports and addressing
• Consume off platform services using platform semantics
11. Don’t Plan Everything; Start Small and Let Your Work Inform the Strategy
To begin
SCOPE
DISCOVER &
FRAME
TIME BOUND
PILOT
13. http://12factor.net/
A “manifesto” of sorts published in 2012 by a team at Heroku
The goal of these 12-factors is to teach developers how to build
cloud-ready applications using declarative formats for automating
setup, had a clean contract with underlying operating system and
were prepared for dynamic scaling
The 12-Factors
14. I. One Codebase, One App*
II. Dependency Management*
V. Build, Release, Run*
III. Configuration*
XI. Logs*
IX. Disposability
IV. Backing Services
X. Environmental Parity*
XII. Administrative Process
VII. Port Binding*
VI. Process
VIII. Concurrency
VALUE, APPROACH
= Time to Market; find the seams; use good SDLC practices
= Dev Productivity; standardize & remove surprises
= Release Mgmt Hygiene; use CI/CD automation /w PCF
= Release Mgmt Hygiene; move to environment vars
= Real-Time Metrics; use PCF features; stdout / stderr
= Auto-Scale; move slow processes to backing services
= Resiliency / Agility; use circuit breaker; loose binding
= Reliability; use well architected PCF, get parity
= Reliability; move to backing service(s), expose as REST
= Ops Efficiency; use PCF features like routing, scaling, etc.
= Cloud Compatibility; move state to backing service(s)
= Auto-Scale, ZDD; design for cloud, use PCF features
15. Looking Beyond 12-Factors
12-Factor App Was Published in 2012
- In context of Heroku
- A LOT has changed
This Book Provides New Guidance
- With emphasis on Enterprise Java & PCF
- Adds 3 new “factors”
• API First
• Telemetry – APM, Logs, Domain-Specific
• Authn / Authz – Security First Design
A Must Read for Cloud App Architects
16. Evaluating Migration Suitability
WON’TRUNONCLOUD
Accepts inbound connections for non-HTTP protocol
Application Container Hosted Clustering
- Relies on container-based clustering for resiliency and scale
- Relies on container for shared state (see stateful process)
Stateful Process
- Uses in-memory cache (in-process)
- Could cause corruption or data loss if application was restarted without warning
Filesystem I/O (Reading files from disk; Writing files to disk; I/O with NFS mount)
Logging to any destination other than STDOUT or STDERR (console)
Use of distributed transactions of any kind, including XA
Extremely long application startup and shutdown time – those measured in minutes
Use of Java properties files/.NET web.config files
Use of hardcoded configuration – URLs, Credentials, Database connection information, Queues and Topics
Nonstandard security - App relies on a nonstandard security mechanism that conflicts with standardized
Siteminder security in customized buildpacks
Batch Processing - Autosys or cron invoke shell or batch scripts to invoke ad hoc functionality
17. Work with One Group; Move “10s” of Apps in 10 Weeks
Start by Replatforming Suitable Applications
REVIEW
MODIFY
TEST
TYPICALACTIVITIES
PATTERNS
& SAMPLES
PRODUCTION
PCF APPS
Discovery & Framing
Suitability Workshops; Technology Planning
Backlog Development, Grooming & Prioritization
Platform Extensibility
Buildpack Engineering; Apps Configuration
Test Automation
Build CI/CD Pipelines; Automate Testing for App
& Backing Services (e.g. Connectivity, Perf.)
Refactoring
Backing Service Location / Configuration
File System Usage, Messaging, etc.
Process and Documentation
CI Everything (Including Docs)
Reference Patterns Informed by Work
18. Replatforming Java apps
SPRING
TYPEOFAPPLICATION
Java EE
.NET
OTHER…
FULL
PROFILE
MODERNIZE
WEB
PROFILE
DOCKER
BUILDPACKORPCF1.6+FEATURE
JAVA
(BUILDPACK)
DIEGO
(GARDEN LINUX)
3rd PARTY
(BUILDPACKS)
Spring Java
Buildpack
Java EE
3rd party
Buildpack
Full Profile
Web Profile
Other Java
Groovy, Grails,
Scala, Play Java
Buildpack
PCF Garden
Linux
Docker
19. Replatforming to Spring Boot
● Introduce Spring Boot Dependencies
● Introduce Cloud Profile that can read
configuration settings from
VCAP_SERVICES
● Application should be able to run on
PCF and on standalone Tomcat
● Modify the spring boot packaging to
use executable jar/war
● Profile Cleanup - A separate profile for
every environment / easy and clean
● Tune your CI / CD pipeline to take full
advantage of Spring Boot
22. Breaking the Monolith – Picking Seams
Stability and Point of Evolution
Inbound and Outbound Coupling
Tools - Xray, JDepend, Structure101
Databases & Data Stores
Transaction Boundaries
Modes of Communication
Team Organization and Structure
Use Cases/User Journeys
Business Processes
Verbs & Operations
Nouns & Resources
Separated models for reading and writing
23. Generic Bounded Context Refactoring Recipe
BOOT+HEXARCHITECTURE
Search for all the call sites into the bounded context
Analyze the current interfaces exposed by the bounded context
Define the required ports for the bounded context
Analyze external dependencies used by the bounded contexts
Define the required adapters for the bounded context
Analyze how the bounded context will stay in sync with the rest of the system
Define what domain events the bounded context will emit
Define what events the bounded context will listen for
Copy and paste the code from the old project s
Create a new spring boot project for hosting the refactored code
Add the newly configured project to the CI / CD Pipeline
Write unit and integration tests
Cut and paste code and refactor it
Iterate until done
29. Wrapping software
features in a way
that let you turn
them on or off
Dark Launching/Feature Flags
Why?
- Private beta release
- Commit your code in logical chunks
- Release a new feature to all your users at a specific
date
- Not confident in how stable or how scalable a new
feature is
How?
- Boolean – Feature will be on or off
- Percentage – Certain % of Users, Cookie, Random,
Group
- List – User ID, Group ID, Organization ID, …
- Identity – Always on! and cannot be turned off.
- Nil - Always off! and cannot be turned on.
Cloud Foundry Constructs
- cf scale, Configuration Server, Route
Services
30. Migrating
Data
Tools – SchemaSpy – graphical
relationship viewer
Tools - Liquibase, Flyway, jooQ to
Auto apply bundles of database
refactorings
Require a transition period during
which both the original and new
schemas exist in production
Expose a Facade service to
encapsulate DB changes
Move logic and constraints to the
edge aka services
Implement retry and compensations
Database Transformation Patterns
cataloged in “Refactoring Databases”
seminal book by by Scott J Ambler
and Pramod J. Sadalage
31. ESB to Microservices
DECENTRALIZTION
• Follow a phased approach to migrating ESB composite and provider
services
• Business logic should reside in Java apps and only fundamental ESB
functions like legacy adapters and pure transformation and mediation
should be handled by the ESB
• Where existing ESB services do not already exist, start greenfield net
new development with a pure microservices based approach
• 5 Step Evolution of the ESB to the Cloud
• 1. Co-exist 2. Lift & Shift 3. Refactor 4. Replace 5. Transform
32. Modernizing Batch
Address Concurrent Batch
and Online
z/OS v2 Connect
Eliminate needless Data
Movement
Eliminate file transfer and
unnecessary app integration
Scheduling and Job
Management
Technical Solutions
Leverage Distributed Batch
33. A word about organization structure
Conway's Law asserts that organizations are constrained
to produce application designs which are copies of their
communication structures
Leads to unintended friction points.
Evolve your team and organizational structure to promote
your desired architecture
Break down silos to foster collaboration
Your technology architecture is then isomorphic with your
business architecture.
35. Persist operation state in the client microservice and track to success or
compensate
Application Level Eventual Consistency
Databases SQL or NoSQL Gemfire
Queues ( RabbitMQ, JMS, WebSphereMQ, Tibco .. etc)
Spring State Machine
Java 8 Completeable Futures
“Distributed transactions in Spring, with and without XA” from
Dave Syer http://www.javaworld.com/article/2077963/open-
source-tools/distributed-transactions-in-spring--with-and-
without-xa.html
36. Make a UI Microservice that is exposed to end users and have it serve up the UI?
Monolithic Edge UI Gateway
A B C
Browser
UI
Native Mobile
37. How are Foreign Key Constraints Validated Across Table is Different Bounded Contexts
Foreign Keys Constraints
Enforcing Foreign Key Constraints between microservices
becomes an application level problem to be handled by
the microservices rather than the database
Usage of Immutable Stable URI’s to identify Foreign keys
can be helpful
38. Turn Static Shared Data into Code Accessible via dependency manager
Shared Static Data Becomes Code
39. Extend each UI experience with a dedicated backend component for UI
http://samnewman.io/patterns/architectural/bff/
Back End For Front End
A B C
Browser
WE
B
BFF
Android Mobile
Androi
dBFF
40. Use JSON Web Token to pass user info between microservices
Use JWT Tokens
Microservice A Microservice BJWT
JSON Web Tokens are an open, industry standard
RFC 7519 method for representing claims securely
between two parties.
41. Pivotal has got you covered!
Distributed Systems are Hard!
Spring Cloud Services
for PCF
Notes de l'éditeur
Scope
Get the right people in a room
Define the business value to drive
Identify candidate apps
Discover & Frame
Assess from a 15-factor standpoint
Decide on migration flows
Flag risks and assumptions
Begin With a Time-Bound Pilot
Designate the right people
Work for 6 to 10 weeks
Translate lessons into patterns
One Codebase: Single code base managed in SCC; or set of repositories from a common root. Look for “the seams” in the “app” and try and break things up a bit if possible. Getting to a single codebase makes it cleaner to build and push any number of immutable releases across various environments. The best example of violating this is when your app is composed of a dozen or more code repos. Or when one code repo is used to produce a bunch of applications.
Dependency Management: The classic enterprise might rely on either “bootstraping” (bundling all dependencies with the app binary) or use of a “mommy server” (providing everything the app needs – a server to host and all it’s dependencies). Most contemporary languages take advantage of facilities like Maven and Gradle or Nuget for .NET. Regardless of tool the idea is … allow developers to declare dependencies and let the tool ensure it’s satisfied. Just need to ensure the tool being used doesn’t package dependencies in a folder structure under the app itself.
Build, Release, Run: a single codebase taken through a build process to produce a single artifact; then merged with configuration information external to the app. This is then delivered to cloud environments and run.
Configuration: this is about externalizing your config is easy to say but can be challenging depending on how the app was built. There are various solutions – refactor your code to look for environment variables. You could use Spring Config server or other products
Logs: should be treated as event streams, that is a time-ordered sequence of events emitted from an app. You can’t log to a file in a cloud. You log to stdout / stderr and let the cloud provider or related tools deal with it
Disposability: in a cloud process is disposable – it can be destroyed and created at any time. Designing for this is important to ensure good uptime and to get the benefit of auto scaling, etc. If you have processes that take a while to start up or shut down they should be separated as a backing service and optimized to accelerate performance
Backing Services: a backing service is something your app depends on – like a database or some kind of REST service. The app should declare it needs a backing service via external config. The Cloud will bind your app to the service. And it should be possible to attach and reattach without restarting the app. This loose coupling has a LOT of advantages. It also allows you to use a circuit breaker (part of the Netflix OSS and SCS) to gracefully handle an outage scenario.
Environmental Parity: we’ve all probably worked in situations where a shared dev sandbox has a different scale and reliability profile than QA, which is also different than prod. Keeping environmental consistency is much easier in a Cloud environment like PCF. Doing this and automating as much of the SDLC as possible will help you confidently deploy smaller things more often
Administrative Process: these are things like timer jobs, one-off scripts and other things you might have done using a programming shell. These are fine in the monolithic world but get complicated when you scale horizontally with multiple instances of the same app trying to kickoff a job. An alternate approach might be to break apart the job into it’s own microservice with a rest end point for controlled invocation
Port Binding: in the non-cloud world it’s typical to see a bunch of apps running in the same container, separating each app by port number and then using DNS to provide a friendly name to access. In the Cloud you avoid this micro-management – the Cloud provider will manage port assignment along with routing, scaling, etc.
Process: the original 12-factor definition here says that apps must be stateless. But state needs to be somewhere! Our guidance is to move any long-running state into external, logical backing services that rely on Redis or Mongo or whatever to manage what they need.
Concurrency: PCF and other cloud platforms are built to scale horizontally. There are design considerations here – your app should be disposable, stateless and use share-nothing processes. This allows you to leverage features like auto-scale, blue-green deployment, etc.
API First – this is about design; from the beginning of a project, it’s the notion that every functional requirement will be met through consumption of an API. Teams of developers interact with APIs using public contracts without interfering with internal development processes.
Telemetry – falls into categories like APM (keep tabs on performance), health and system logs (keep tabs on system events and domain-specific (event stream fed into a big data system for processing)
Authentication / Authorization – RBAC all end-points and use of Oauth, OpenID, etc. for security
http://cloud.rohitkelapure.com/2016/06/replatforming-net-applications-to-cloud.html
• For Greenfield Applications Try “Core First” approach
• For Replatforming and migrating Existing Apps Probably ASP.NET 4.x
• Dependencies and framework requirements will likely dictate choice
• All versions of the .NET SDK supported by Windows Server 2012 R2 are supported on PCF including 3.5, 4.5, 4.5.1 and 4.6
Global Assembly Cache (GAC) file system usage
Migration issues must be addressed:
• Nearly every app will need refactoring to use Console logging and tracing. Customers who mess with applicationHost.config can interfere with tracing, logging, etc.
• Reading/Writing to the Registry.
• Reading/Writing to the local disk. File systems are ephemeral. Replace usage of the file system e.g. disk logging even temp files with a S3 compatible blob store or external file store.
• Replace Integrated Windows Auth. with ADFS/OAuth2 to leverage UAA and Pivotal SSO Tiles
• In-Process Session State / Sticky Sessions. Replace InProc, StateServer with out-of-process data store e.g. Redis, SQL Server
• Externalize environment-specific config in web.config into VCAP environment variables. If value changes between environments, don’t get it from web.config. Don’t use externalization methods that only work in Azure. If app relies on machine.config or applicationHost.config, could have issues in PCF.
• For MSI-Installed services or drivers, Bin deploy dependencies with app.
• 32 bit ASP-Net builds/References/Builds/apps depending on 32-bit libraries will not work.
• WCF Self-hosted services and SharePoint apps will not work in CF.
• Apps requiring assemblies in Global Assembly Cache won't work in CF.
• Backing Service Drivers requiring native installers / DLLs may not work in CF.
• On Demand Apps and ones triggered by job controller will need to be refactored to run in CF to use CF one-off task support coming in the CC v3 API.
• MSMQ and tight integration with other MSFT server products via on-server dependencies will need to be refactored to use external backing services. .NET Core is now supported in the RabbitMQ .NET client.
• Routing to non-HTTP WCF endpoints and listeners for third party middleware will not work since only HTTP based inbound traffic is routed to the windows containers.
http://changelog.ca/log/2012/07/19/dark_launching_software_features
Why ?
Private beta release
Commit your code in logical chunks
Release a new feature to all your users at a specific date
Not confident in how stable or how scalable a new feature is
How ?
Boolean – Feature will be on or off
Percentage – Certain % of Users, Cookie, Random, Group
List – User ID, Group ID, Organization ID, …
Identity – Always on! and cannot be turned off.
Nil - Always off! and cannot be turned on.
Cloud Foundry Constructs
cf scale, Configuration Server, Route Services
Operators
Responding to individual developer needs is time consuming
Responding promptly is difficult, and requests may not be aligned with policies
We want to provide operators with solution they can put in place once, configured with policy, and enable developers to pick and choose, self-service
Developers
Features like authorization and rate limiting are common requirements in application development and operation
Currently developers must either build these features into their applications or coordinate with IT to provide them
Eliminate unnecessary development and support ticket wait-time
Automated, self-service, on-demand, integrated services