Application Modernization Surgery Techniques

Our day job involves running around euthanizing monoliths and modernizing apps when porting them to Pivotal Cloud Foundry. App Modernization typically involves open heart surgery. During the recently conducted Partner Acceleration Lab in Denver, I had the opportunity to  come up with a taxonomy of modernization patterns with partner in crime Shaun Anderson to break apart monoliths, megaliths, Big Ball of Muds, Hair Scary apps, whatever you want to call it.....

Deployment Patterns

• Feature flags 
• Dynamic routing 
• Dark launching 
• Canary Routing 
• Service Control (versioning)

Behavior Control Patterns

• Message Based (Event Shunting / Starving)
• Decorator
• Bridge
• Router
• Proxy
• Facade
• Application
• Class Decorator
• Bridge
• Router
• Proxy
• Facade
• Wrapping
• Java Agent
• AOP
• AspectJ

Discovery Patterns - Breaking apart a complex domain

• Event Storming/Event Sourcing
• Top Down Analysis
• Duplo / Lego Arch

Management Patterns

• Inverse Conway maneuver
• Evolve the right team structure

Data Refactoring Patterns

• Migrating Schemas
• Data Sync
• Data Replication
• Migrating DB (eg. DB2 -> MySQL)
• Pulling Data from Master to Child
• TCP Proxy for JDBC
• CQRS

Edge Entry Controller Patterns

• Bridge
• Router
• Proxy
• Facade
• Backends 4 Frontends

Process Flow

• SOA / ESB -> Microservice
• Workflow (Central orchestration) -> Choreography
• Batch / ETL Jobs
• Scheduled Messaging to real-time services
• Starvation
• Transactional to Eventual Consistency

App Control

• Define layers and control points
• Routing
• Network
• Data
• App endpoint
• Messaging
• All above can use
• Bridge
• Router
• Proxy
• Facade
• Wrapping

Hybrid Cloud Caveats

Today we have a guest blog post from fellow PCFS Team member David Wallraff with contributions from Josh Kruck and David Malone. 

TL;DR: If your cloud deployment relies on infrastructure that is not part of your cloud; regional scaling and datacenter loss are going to be more painful than you think.

A hybrid-cloud strategy is a good great idea for agile companies in an agile world. This means having both a public cloud and a private, on-site (“on-prem”) cloud underlining your platform, because each has its own merits. A public cloud allows for dynamic provision of resources, multi-region scalability, etc., while an on-prem cloud allows for the total ownership of your resources, physically secured backend services, etc. A hybrid cloud architecture gives you the best of both: coupled cloud deployments give your group access to on-prem, backend services within a responsive, provisionable cloud. That said, like just about any technological choice, tightly-coupled hybrid cloud architectures come with caveats.

These concerns can be broken down into two main categories:

• On-prem resources
• Shared cloud resources

On-prem resources

Some of the most common resources on-prem that an enterprise might want to utilize in the cloud are DNS, NTP, and auth services (LDAP, AD, etc). Some are good services (internal DNS resolution) and some are needed services (internal auth services).  The easiest, most common connection setup is a dedicated VPN tunnel linking the cloud to the on-prem datacenter. Unfortunately, this leaves vital services dependent on a single-point-of-failure should the VPN connection terminate due to an alien incursion, ISP failure, evil cats with lasers, and the like, leaving your customers with 404s. You can add redundant tunnels, but the single-point-of-failure isn’t just the connection, it’s the datacenter those resources live in.

The best way to handle this problem is to create strategic redundancy with local resources in the cloud, syncing where possible, being authoritative when not. Cloud-based authentication services can federate to your on-prem authentication services, a cloud-based DNS solution can host your cloud DNS zone (DNS forwarding only lasts as long as the TTL and is, at best, a band-aid not a solution) and cloud-based DBs can replicate to their on-prem brethren. Taking these steps to ensure your cloud deployment can survive on its own, with its own infrastructure means that if, and when, that VPN connection goes down, your cloud deployment (and its apps!) can continue to function.

Shared cloud resources

We all know we’re supposed to share our toys. But in the cloud, we can just push a button and voila! New copies of our toys. Lots of copies. This is one of those things that makes the cloud, The Cloud™. On-demand provisioning and scaling enables us to say “No problem!” when we realize we need to double capacity or establish a presence in South Africa. But when cloud deployments are sharing resources, like IP space, or are being forced through shared resources like a single outbound proxy, your growth is bound by these self-imposed bottlenecks. Have a shared network across your cloud deploys? RFC 1918 addresses top out at 17,891,328. That may seem like a lot, but when you start adding multiple deploys in US-East, US-Central, US-West, South America, Europe, APJ, China North, China South, Lagrange Point 1, … well you get the idea.

This is one of those things that’s easier to fix during design, and much harder after execution. By limiting yourself to VPNs for specific applications (back-end data services, federated auth servers, on-prem DNS zone transfers) rather than a wide site-to-site VPN tunnel, you can utilize the same IP space in each cloud deployment, giving you an upper-bound 4,294,967,296 IPs per cloud deployment (at least until IPv6 is more widely utilized in the cloud). Utilizing the cloud primitives for a specific-region’s outbound proxy (or maintaining your own) and syncing datasets/rules let’s you grow without worrying about an outbound proxy sitting on a single pipe (you are planning on growing enough to saturate a single pipe right?).

Example diagrams

Public dependant on on-prem resources

Templated public cloud with own resources

So what then?

Why do it differently? Isolation and repeatability. Running local resources in a cloud and not sharing infrastructure across your deployments allows for greater flexibility and protection when it comes time to cut the cord. You’ll no longer be limited by shared IP space and the need to search through that spreadsheet you have, cause it’s always a spreadsheet, for enough IP space to deploy to another region (seeing a company run out of RFC 1918 IP addresses was not a fun day). With in-the-cloud resources, you can have true DR/BC, where the failure of one deployment doesn’t take down any or all of the other deployments. By using this pattern for hybrid-cloud deployments, you’ll be better able to stand up new deployments--or withstand the loss of one.

Cloud Foundry vs Kubernetes - A Story in Pictures and Numbers

A Tale of two PaaS CloudFoundry vs Kubernetes

Project	Cloud Foundry	Kubernetes
Estimated Cost	$68,583,603	$26,662,605
Contributors (All Time)	2,835 developers	1,145 developers
Commits (All Time)	103,373 commits	39,102 commits
Initial Commit	almost 14 years ago	over 2 years ago
Most Recent Commit	29 days ago	about 2 months ago
Contributors (Past 12 Months)	523 developers	668 developers
Commits (Past 12 Months)	19,526 commits	18,218 commits
Files Modified (Past 12 Months)	35,569 files	11,616 files
Lines Added (Past 12 Months)	4,449,908 lines	9,021,182 lines
Lines Removed (Past 12 Months)	3,508,508 lines	6,074,453 lines
Contributors (Past 30 Days)	122 developers	157 developers
Commits (Past 30 Days)	900 commits	1,708 commits
Files Modified (Past 30 Days)	2,137 files	5,457 files
Lines Added (Past 30 Days)	48,054 lines	1,802,098 lines
Lines Removed (Past 30 Days)	19,429 lines	1,701,092 lines
Lines of Code	4,197,111 lines	1,697,136 lines

These charts and numbers have been sourced from openhub.net. Take a look at the 12 month comparison between CF OSS and K8s.  Google Trends Link. 

Current State of Persistence in Cloud Foundry and Pivotal Cloud Foundry

----LATEST----

Below is the current status of the nfs integration with ERT.

The ERT alpha available right now has the CC property for volume services enabled by default. Customers can then follow the documentation to deploy the NFSv3 driver/broker pair manually. 

ERT has a radio button to enable NFS volume services on the advanced tab. When the button is enabled, two things have to happen:

1 - The NFS broker is deployed as a CF app and registered to the marketplace. Work is being tracked in the OSS backlog to deploy the driver as an App) https://docs.cloudfoundry.org/adminguide/deploy-vol-services.html

2 - The NFS driver is collocated on Diego Cells, disabled by default, and enabled when configured. (Windows Cells is not supported)

In PCF 1.10, the driver can be deployed via bosh add-on and broker can be pushed separately for testing.

Sample app thanks to Adam Zwickey
https://github.com/azwickey-pivotal/volume-demo

Container persistence shipped in 1.8 in a closed beta and will GA in PCF 1.10.  It is trivial to modify a PCF 1.9  to enable volume services. See above. To play with it locally use PCFDev.

There are a number of use-cases where we have to remediate the dependency on persistent filesystem when replatforming apps to PCF. We run into these use-case in all our app replatforming engagements. 

• Sharing data across apps  as an integration layer
• 2PC commit transaction logs
• Existing datasets on disk
• Disk caches
• Content management systems that r/w from mounted file volumes
• 3rd party dependencies and libraries that rely on persistent file systems
• Composite apps. some services runs on PCF and others run on the IaaS 

For Persistence Orchestration, a new project called Volman (short for Volume Manager) has become the newest addition to the Diego release. Volman is part of Diego and will live in a Diego Cell. At a high level, Volman is responsible for picking up special flags from Cloud Controller, invoke a Volume Driver to mount a volume into a Diego Cell, then provide access to the directory from the runtime container.

As of cf-242 and Service Broker API v2.10, Cloud Foundry now ships with support for Volume Services: filesystem-based data services. The v2.10 API is a release candidate, and will be considered GA unless a bug in the implementation is fond. An experimental version of the API was added in v2.9.

What is included in CF itself is the plumbing required to plugin driver/broker pairs that add support for specific kinds of external volumes. The support for EFS, NFS, Isilon, etc is added through separate BOSH releases not tied to a particular CF version. In https://github.com/cloudfoundry-incubator there is a local-volume-release and an efs-volume-release. In the Persi tracker there is an nfsv3 - "broker driver pair for existing nfs shares that can be mounted with nfsv3" epic almost complete.

Until recently, the only data services that have been allowed are ones with network-based interfaces, such as a SQL database. With Volume Services, brokers can now attach data services which have a filesystem-based interface.

Currently, we have platform support for Shared Volumes. Shared Volumes are distributed filesystems, such as NFS-based systems, which allow all instances of an application to share the same mounted volume simultaneously and access it concurrently.

This feature adds two new concepts to CF: Volume Mounts for Service Brokers and Volume Drivers for Diego Cells. Details can be found in the links below.

create-service

bind-service

Documentation:

• https://bit.ly/cf-volume-services 
• https://docs.pivotal.io/pivotalcf/1-8/services/volume-services-v2.10.html

CF Summit Talk: https://www.youtube.com/watch?v=ajNoPi1uMjQ

Slack: If you're interested in rolling out a volume service, please ask questions here, on the OSS #persi slack channel.

Finally if you want to play with persistence support with Cloud Foundry checkout PCFDev. CFDev team released a new version of PCFDev that includes local-volume services out of the box. This new release of PCFDev gives you an option to get up and running with volume services that is an order of magnitude easier than any of the options we had before. Here is a  post detailing the steps to try out volume services with your Cloud Foundry applications.

This feature does not mean we automatically revert to using persistent mounts when replatforming applications - I look at this as another weapon in our arsenal_  also see To be clear this just a stepping stone to a more cloud-native architecture. You have to treat blobs (files) as a construct supported by a backing service. All apps instances now will now see a common NFS mount - so app instance have to manage consistency when talking to the mount .... each app instance does NOT get its own mount

Adam Zwickey Pivotal platform architect validated the persistence feature in CF following these steps:

1) Enable volume-services on the cloud controller. Cloud Foundry must be deployed with the cc.volume_services_enabled BOSH property set to true.

2) Deploy a volume driver colocated with each Cell  (using bosh add-ons)

3) Deploy a service broker that implements the volume API.

For sample apps that require disk persistence you can employ Spring apps that leverage the @cacheable abstraction  and write the cache to disk. On app restart you should see cache hits for the content written to the disk. see 1 and 2.

References:

[1] https://blog.pivotal.io/pivotal-cloud-foundry/case-studies/the-road-to-persistent-data-services-on-cloud-foundry-diego

[2] http://dojoblog.emc.com/persistence/cf-applications-persistence/

[3] http://dojoblog.emc.com/persistence/behind-scene-cloud-foundry-persistence/

[4] https://youtu.be/ajNoPi1uMjQ?list=PLhuMOCWn4P9gGrKEtCBKYpEl5BXGBCsQZ

[5] https://docs.google.com/document/d/1TFlbXAutgtYT63n0tasKZCP_NqS-G4dxZV0OKvi7rMk/edit#heading=h.s9fh85r5yfs0

credit:  Thanks to Greg Oehman & Julian Hjortshoj & Adam Zwickey

Migrating 1TB of Data from DB2 to MySQL

I would advise that you first insulate the application against this change by making all the app services interact with the backend using a Repository pattern. i.e. put the repository abstraction in place that will allow you to then switch the DB internally. I also like to follow the expand-contract-expand pattern for consumers explained in http://martinfowler.com/articles/evodb.html for existing data. 

When you refactor your application to use MySQL leverage something like Flyway or jOOQ to manage  future DB migrations.

At a raw DB2 data and schema level there are tools like DBConvert that can be used to move and sync the data.

So its a combination of both app and data patterns along with some Blue/Green routing magic that will be needed to move the data from DB2 to MySQL.

Breaking Apart a Complex Domain

One of the key problems when you are breaking a monolith are identifying the microservices and their respective domains. This is critical to get right otherwise you end up solving the wrong problem. How do we know which part of the monolith/megalith to attack first ? How does one identify the core domain and its supporting sub-domains.  

There are a couple of techniques that can serve as a launch point for this discovery. These techniques revolve around the idea of Visual Thinking i.e. mapping the domain as events or lego blocks and visualizing the data flow and system architecture. Three such techniques have emerged recently 1. Event Storming, 2. Visible Architecture and C-4 Model

Before breaking apart a complex domain its key to get a shared understanding of the current state of the domain. We need to establish a baseline where we label ALL the red flags and pain points of the system. Thereafter we move into problem solving and collaboration where we come up with solutions and approaches to move the system closer to our end-state, picking the features & approaches that give us the best chance of success. We need scientific techniques to break down a complex domain among a group of business and technical stakeholders. Fostering collaboration among people is a hard problem to solve. Event Storming and the Visible Architecture process outlined below, starts the conversation initiating the scientific process that leads to minimum viable microservices being carved from the monolith.

Event Storming

Event Storming is a group exercise to scientifically explore the domains and problem areas of a monolithic application. The most concise description of the process of event storming comes from Vaughn Vernon's DDD-Distilled book and the color around the process comes from Alberto Brandolini's book Event Storming. I have taken liberally from those two sources in this blog post. So how does one perform an exercise of event storming ?

1. Storm the business process by creating a series of Domain events on sticky notes. The most popular color to use for domain events is orange. The DomainEvent is a verb stated in past tense and represent a state transition in the domain. Write the name of the DomainEvent on an orange sticky note. Place the sticky notes on your modeling surface in time order from left to right. As you go through the storming session, you will find trouble spots in your existing business process. Clearly mark these with a purple/red stick notes. Use vertical space to represent parallel processing.

  src: Event Storming from Alberto Brandolini http://leanpub.com/introducing_eventstorming

2.  Create commands that cause each Domain Event. The command should be stated in the imperative. Place the light blue sticky note of the command left of the domain event that causes it. They are associated in pairs: Command/Event, Command/Event, ... If  there is a specific user role that performs an action and it is important to specify, place a small, bright yellow sticky note  on the lower left corner of the blue stickie. Sometimes a command can cause a Process to run. It is possible that creating commands will cause you to think about creating domain events. Place newly discovered events on the modeling surface along with the corresponding command. Sometimes one command may cause multiple events. Model that one command, and place it to the left of the multiple domain events. Once you have all commands associated with the domain events you are ready to move to the next step.

3. Associate the Entity/Aggregate on which the command is executed and that produces the Domain Event outcome. This is the data holder where commands are executed and domain events are executed. Other business friendly words for Aggregate are data or Entity.  Place the aggregate sticky behind the Command and domain event. If aggregates are repeatedly used then create the same aggregate noun on multiple sticky notes and place them repeatedly on the timeline where the corresponding Command/Event pairs occur. It is possible that as you think of data associated with the various actions you may discover more domain events. Never ignore new events, rather follow the same process as before to integrate the events with commands and aggregates.

4. Draw boundaries and lines with arrows to show flow on the modeling surface. You have discovered that there are multiple models in play and domain events flow between models. Use solid lines for  bounded contexts and dashed lines for subdomains. Draw lines with arrowheads to show direction of domain events flowing between bounded contexts. If you want to start bounding models with less permanence use ping stickies to mare general areas and withhold drawing boundaries with permanent markers till your confidence justifies it.

5. Identify the various views  that your users will need to carry out their actions, and important roles for various users. Use bright yellow stickies to identify user roles or personas.

An exercise in event storming may lead you to a CQRS Event Sourced architecture. If you pursue the path to using domain events as the system of record then leverage resources here to get deep into the world of Event Sourcing.

src: Event Storming from Alberto Brandolini http://leanpub.com/introducing_eventstorming

Visible Architecture:

src: Screenshot of Luke Hohmann's talk from Mucon

A visible architecture is a physical model of a system created by architecture teams using Duplo® bricks, with strings representing data flows. Visible architectures enable teams to collaboratively understand the “as-is” architecture and make better choices on the “to-be” architecture.

Quoting Luke ... 

The structured, yet creative freedom afforded by the technique enables teams to explore challenging concepts. For example, in one project, teams from Cisco represented known problems as “monsters” and outdated technologies as “dinosaurs” using plastic toys. In another project, teams from Rackspace used Visible Architectures as means to rapidly integrate acquired technologies.

Luke Hohmann has pioneered this technique and in this talk from Mucon, he presents an overview of the process, how to document desired changes in a structured manner, and how to augment Visible Architectures with powerful business frameworks that enable architects to "speak the business language" necessary to convert models into realities.

C-4 Model:

A software system is made up of one or more containers, each of which contains one or more components, which in turn are implemented by one or more classes. Some other techniques that I see of value in this space is the work done by Simon Brown in Modular Monoliths and the C-4 model. Checkout his book on Software Architecture for Developers. This book focusses on the visual communication and documentation of software architecture. The key facets of the software architecture are:

1. Context: A high-level diagram that sets the scene; including key system dependencies 

and people (actors/roles/personas/etc).

2. Container: A container diagram shows the high-level technology choices, how responsibilities are distributed across them and how the containers communicate.

3. Component: For each container, a component diagram lets you see the key logical components and their relationships.

4. Classes (or Code): Small number of high-level UML class diagrams  that explain how a particular pattern or component will be (or has been) implemented. 

These can be elicited from the code or drawn from scratch using tools like Structrizr

Moving Data Off An Mainframe

Recent developments have reinforced the need for change in our political system. In the same vein the blog post below provides a path to unlocking your data and compute from mainframe.  The content in this post is a straight ripoff from my buddy and colleague David Malone's postulation on this topic. The steps below from Dave and are the most cogent explanation of how to move data away from mainframe to distributed systems. It draw's from Dave's direct experience at a major retailer.  The same approach can be leveraged to starve and strangle data locked in any data store.

The Thin Line Between Application Replatforming and Refactoring

When migrating applications to the cloud there is a very thin line between application replatforming and refactoring. These terms are defined as follows: 

• Replatforming: Make the least amount of changes to move it to the cloud aka "lift-tinker-and-test-and-shift" 
• Refactoring: Modify the applications such that it becomes cloud native. Reimagine how the application is architected and developed, typically using cloud-native features.

What defines cloud native? Well we can use 12 factor/15 factor app as one set of heuristics to determine cloud nativeness. We will therefore explore the boundary between replatforming and refactoring along the 15 factors since they are as good as any, ubiquitous language to talk about the effort and the changes that differentiate lift-and-shift vs refactor. The examples below illustrate what it means to replatform vs refactor the application. The context of these words changes in some cases from applications to environment.

TL;DR: Always replatform first and then based on business and technical strategic objectives refactor. The line between replatform and refactor is fuzzy.

One Codebase, One Application:
Adding automated maven or ant based build such that each build runs consistently and generates a deployable artifact is replatforming. If the code is not in source control checking in the code and applying a bug tracking system counts as replatforming. Moving the code from svn to git or across SCMs is refactoring. Modifying the build such that the single codebase is  split and reorganized among teams dedicated to individual apps and microservices is refactoring. If you split your code base into multiple microservices or shared libraries or common API then it counts as refactoring. 

API First:
If you apply the extract API from class pattern and use it to strangulate the monolith then  that is replatforming. If you have an API designed by product designer based on UX or user story flow mapping and are retrofitting implementation to this new API then it counts as refactoring. Putting API management tools or ambitious API gateways counts as refactoring. If you are fixing the implementation of an existing API i.e. modernizing from Axis1/2 to Spring REST MVC or switching the payload from XML to JSON then it counts as replatforming. If you are making semantic changes or additions or deletions to an existing API that falls in the category of refactoring. Getting messaging working with WebSphere MQ counts as replatforming whereas replacing WebSphere MQ with JMS or AMQP  is refactoring.  

Dependency Management: 
Modifying the existing packaging of the application such that all of the dependencies including the application server are vendored into the app like the spring boot fat jar packaging qualifies as refactoring. Modifying the packaging of the application such that a single monolithic ear file is broken into multiple war files that are deployed separately falls under replatforming.  Using an application server buildpack to vendor in your app dependencies like the TomEE or JBOSS buildpacks counts as replatforming. Removing dependence on older frameworks and JavaEE and building the app with spring-boot-starters counts as refactoring. Spring bootification i.e. the process of converting an app to spring boot of the app, ultimately leads to mavenization conflicts where the newer dependencies dragged in by boot and its cousins fight with the older frameworks ossified in the app. Surprisingly a large part of refactoring is spent harmonizing these dueling sets of dependencies.  

Design, Build, Release, Run: 
Using a CI tool like Jenkins to manage the CI pipeline counts as replatforming; however if you define the deployment pipeline through code instead of configuring a running CI/CD tool then you are refactoring. If you leverage blue/green deployment then you are replatforming; however if you are using feature flags and dark launching i.e. adhering to NO breaking changes then you are refactoring. If you do no* upfront design and dive straight into making the code run on the platform then you are replatforming; however if you indulge in model design with bounded contexts and all the good stuff with DDD you are in refactoring territory. If you run the application with the actuators that come by default with Spring Boot you are replatforming; however if you find your self writing a ton of custom actuator metrics and health end points you may be refactoring.

Configuration, Credentials and Code: 

If you have brute forced your configuration by getting rid of all of your configuration files and then went back through your codebase and modified it to expect all of those values to be supplied  by environment variables then you are replatforming. If you have modified your code to expect configuration based on profiles from an external configuration server then you are refactoring. If your credentials are fetched from an external service then you are refactoring; however if your credential management requires encrypted keys as environment variables or hard coded in environment specific property files then you are replatforming.

Logs: 

If you modify your application send logs to stdout and stderr you have replatformed the app. If you have modified the traces across your apps to take advantage of distributed tracing frameworks like Zipkin and corresponding log aggregation, indexing and visualization tools like ELK or Grafana you have refactored the app.

Disposability: 

If your application starts slowly and you have tinkered with timeout settings of the platform to allow the health checks to pass then you have replatformed. If you have fixed the slow app startup and shutdown issues then you have refactored the application. If your application is a mix of web request processing and batch tasks then you have simply replatformed the app; however if you have separated batch processing from the request or message processing bits into separate apps then you have refactored.

Backing Services:

If your cache or sessions are within the JVM or offloaded them to an external DB then you have replatformed. If you have eliminated the need to keep persistent state across requests then you have indulged in refactoring. If the configuration of the backing service happens outside of the application  i.e. there is no coupling between the app and the specific backing service then you have refactored the application. If the configuration and binding of the backing service is done explicitly within the application then you have replatformed the app. If you have protected your backing service interaction with circuit breakers then you have refactored whereas if you have simply gotten the backend service configured correctly with the app with externalized configuration then you have replatformed the app.

Environment Parity: 
If you have 8 different environments across 3 different tiers, each with their own databases, firewall rules and app specific configurations in properties files then you have replatformed the environment; however if you have a one-touch CI/CD deployment to production with appropriate process gates then you have refactored your environment. Unless every commit is a candidate for deployment and the gap between production and test environments basically comes down to different prioritized infrastructure resource pools you are replatforming. 

Administrative Processes:

If you have separated your admin processes like crons, database migrations, singleton services from your parent app then you are a refactorer otherwise if your app is a jack of all trades implementing different concerns then you are a replatformer. If you have extracted your one-off processes and implemented them using batching frameworks like Spring Batch or Spring Cloud Streams or Spring Cloud Data Flow then you have certainly refactored the app.

Port Binding: 
Table stakes here is eliminating hard-coded dependencies on specific ports for startup. When you have eliminated all other network protocols and refactored the application to exclusively communicate exclusively over HTTP then you have refactored the app. If you have NOT micromanaged your port assignments and can run with the ports exposed by the container you have replatformed the app. If you rely on a dynamic service registry like Eureka or Consul to discover other micro services and their ports then you have refactored the app.

Stateless Processes:

If all the long running state is external to application persisted in backing services then you have replatformed the application. If you have rearchitected the application to get rid of the need to carry long running state then you have refactored the application. Remediating the app dependency on a persistent filesystem like NFS or local disk to instead leverage s3 or sftp  is replatforming; however relying on an external service that provides a file caching abstraction or a user level file system like HDFS is refactoring the application.

Concurrency:
If the most efficient way to scale the application, is to vertically scale resources like memory or CPU or I/O then all you have done is replatformed the app; however if the app can be horizontally scaled without bound to maintain the same SLAs with a linear increasing load then you have refactored the application.

Telemetry: 

If your approach to monitoring involves third party APM tools and other health checks baked into the platform with Spring boot actuator libraries then you have replatformed; however if you have baked in business domain specific monitoring and metrics that can be leveraged by the business for A/B testing and used by the team to discuss feature rollout or blue/green deployment then you have reached refactoring nirvana.

Authentication & Authorization:

If you rely on integration with SiteMinder or other agent based protocols like Kerberos and have them working in the cloud via  a route service or via an API gateway or via a route interceptor then you are replatforming. On the other hand if the application is refactored to use federated lighter-weight user and application space based identity and authorization protocols like OAuth2, OpenID Connect and JWT then you have a reformed app on your hands.

Why Bother ? The Need for Rabbit and Redis through Pivotal Cloud Foundry

1. Need for self-provisonable reliable and production capable messaging and non-relational backing services in a time-bound fashion (typically less than 5 mins).

2. Reduce time to value for the application features and increase developer flow by giving the ability to create and bind services during application development avoiding ticket based speed bumps.

3. Existing IBM based messaging and relational stores are too heavyweight for cloud based applications and don't have quick turnaround for new instances.

4.  Pre-canned  recipes and collateral to leverage Redis and Rabbit to accelerate the migration to the Cloud. see blog posts https://medium.com/@KevinHoffman/migrating-apps-to-the-cloud-shunting-the-event-stream-8c2f6f309242#.5h3dpckl4 and https://medium.com/@KevinHoffman/orchestration-to-choreography-19686684fd44#.nxp73bxxk

5. Redis and RabbitMQ are the best-in-breed when it comes to session caching, event sourcing and messaging. Deep Integration and Ease of Usage with the Spring and the Spring Boot frameworks that automatically configure connections and credentials to Redis and Rabbit when an application is deployed to Pivotal Cloud Foundry.

6. Developer ramp-up time to Redis and RabbitMQ is much lower than other technologies in the same space.

7. These Pivotal Tech will help reduce IBM spend on DB2 and provide a pathway for migration away from MQ and DB2.