CRAP - Complexity Remediating Application Proxy

CRAP is a term that has negative connotations; however in our world of application replatforming and modernization it is the most used application remediation pattern to shield the complexity of an external domain from your own domain allowing the microservices model of your core domain to remain pure. CRAP is a specific instantiation of an anti-corruption layer that bridges cloud native apps to non-cloud native apps. 

Permit me a quick segway here into terminology ... 

So what the hell is a cloud native application ? There are two definitions* of cloud native apps that I really like : 

1. A cloud-native application is an application that has been designed, architected and implemented to run on a Platform-as-a-Service installation and to embrace horizontal elastic scaling. Cloud native architectures take full advantage of on-demand delivery, global deployment, elasticity, and higher-level services. They enable huge improvements in developer productivity, business agility, scalability, availability, utilization, and cost savings.

2. A cloud native application is an application that satisfies ALL 15 factors  that define the DNA of Highly Scalable, Resilient Cloud Applications.

Note none of these definitions are mine. 1. is from Kevin Hoffman and 2. is from Adrain Cockroft

What is a non cloud or anti-cloud application ? - An application that cannot and does NOT want to run in the cloud and cannot be easily remediated to run well in the cloud is a cloud-angry or anti-cloud application. Big COTS packages and other monstrosities like WebSphere Commerce and WebSphere Portal from IBM and ORCL generally fall into this category. Cloud angry apps can range to mammoth application server to small shared kernel libraries that rely on assumptions of a particular OS or file-system characteristics.  

So when do you CRAP ?

Simple answer when you have a bowl of mud or shit that you need to front. This shit front typically lives outside your application and is responsible to front all the non-cloud-native nastiness. CRAP puts lipstick on the pig of non cloud native code allowing other cloud native applications to live in kumbaya.  

In computer science terms CRAP manifests itself as a proxy, facade or an adapter or an edge gateway that bridges the legacy application with the cloud native applications. CRAP is inserted transparently in a legacy system and is attached to the downstream consumer of the anti-cloud native service. 

A practical example of CRAP is a service that provides an API that fronts a library or service that cannot run on the cloud for a variety of reasons. If for some reason your application cannot run on the target platform then the best thing to do is to put CRAP in front of it to consume this library. For instance 32 bit libraries of native code extensions that cannot run on the VMs of the target platform are fronted by a service that provides an API aka a published language via an open hosts service that other applications running on the target platform can consume.

# Credit to the entire #app-transformation team @ Pivotal.
Please note opinions expressed are mine only and not representative of Pivotal.