anchor.diff:  
   In addition to passing in the appropriate configuration to the applications, the Data Flow server is responsible for preparing the target platform’s infrastructure so that the application can be deployed.  For example, in Cloud Foundry it would be binding specified services to the applications and executing the ‘cf push’ command for each application.  For Kubernetes it would be creating the replication controller, service, and load balancer.
   
  -The Data Flow Server helps simplify the deployment of multiple applications onto a target runtime, but one could also opt to deploy each of the microservice applications manually and not use Data Flow at all. This approach might be more appropriate to start out with for small scale deployments, gradually adopting the convenience and consistency of Data Flow as you develop more applications.  
  +The Data Flow Server helps simplify the deployment of multiple applications onto a target runtime, but one could also opt to deploy each of the microservice applications manually and not use Data Flow at all. This approach might be more appropriate to start out with for small scale deployments, gradually adopting the convenience and consistency of Data Flow as you develop more applications.
   ifdef::omit-tasks-docs[]
  -Manual deployment of Stream based microservices is also a useful educational exercise that will help you better understand some of the automatic applications configuration and platform targeting steps that the Data Flow Server provides. 
  -endif::omit-tasks-docs[]
  -ifndef::omit-tasks-docs[]
  -Manual deployment of Stream and Task based microservices is also a useful educational exercise that will help you better understand some of the automatic applications configuration and platform targeting steps that the Data Flow Server provides. 
  +Manual deployment of Stream based microservices is also a useful educational exercise that will help you better understand some of the automatic applications configuration and platform targeting steps that the Data Flow Server provides.
  +endif::omit-tasks-docs[]
  +ifndef::omit-tasks-docs[]
  +Manual deployment of Stream and Task based microservices is also a useful educational exercise that will help you better understand some of the automatic applications configuration and platform targeting steps that the Data Flow Server provides.
   endif::omit-tasks-docs[]
   
   [[arch-comparison]]
  
positive.code: 
  Spring Cloud Data Flow’s architectural style is different than other Stream and Batch processing platforms.  For example in Apache Spark, Apache Flink, and Google Cloud Dataflow applications run on a dedicated compute engine cluster.  The nature of the compute engine gives these platforms a richer environment for performing complex calculations on the data as compared to Spring Cloud Data Flow, but it introduces complexity of another execution environment that is often not needed when creating data centric applications.  That doesn’t mean you cannot do real time data computations when using Spring Cloud Data Flow.  Refer to the analytics section which describes the integration of Redis to handle common counting based use-cases as well as the RxJava integration for functional API driven analytics use-cases, such as time-sliding-window and moving-average among others.
  
  Similarly, Apache Storm, Hortonworks DataFlow and Spring Cloud Data Flow’s predecessor, Spring XD, use a dedicated application execution cluster, unique to each product, that determines where your code should execute on the cluster and perform health checks to ensure that long lived applications are restarted if they fail.  Often, framework specific interfaces are required to be used in order to correctly “plug in” to the cluster’s execution framework. 
   
  As we discovered during the evolution of Spring XD, the rise of multiple container frameworks in 2015 made creating our own runtime a duplication of efforts.  There is no reason to build your own resource management mechanics, when there’s multiple runtime platforms that offer this functionality already.  Taking these considerations into account is what made us shift to the current architecture where we delegate the execution to popular runtimes, runtimes that you may already be using for other purposes.  This is an advantage in that it reduces the cognitive distance for creating and managing data centric applications as many of the same skills used for deploying other end-user/web applications are applicable.  
  
  [[arch-streaming-apps]]
  == Streaming Applications
  
  While Spring Boot provides the foundation for creating DevOps friendly microservice applications, other libraries in the Spring ecosystem help create Stream based microservice applications.  The most important of these is Spring Cloud Stream.  
  
  The essence of the Spring Cloud Stream programming model is to provide an easy way to describe multiple inputs and outputs of an application that communicate over messaging middleware.  These input and outputs map onto Kafka topics or Rabbit exchanges and queues.  Common application configuration for a Source that generates data, a Process that consumes and produces data and a Sink that consumes data is provided as part of the library.
  
  [[arch-streaming-imperative-programming]]
  === Imperative Programming Model
  
  Spring Cloud Stream is most closely integrated with Spring Integration’s imperative "event at a time" programming model.  This means you write code that handles a single event callback.  For example, 
  
  [source,java]
  ----
  
negative.code: The component that is responsible for deploying applications to a runtime is the Data Flow Server.  There is a Data Flow Server executable jar provided for each of the target runtimes.  The Data Flow server is responsible for interpreting
  
  * A stream DSL that describes the logical flow of data through multiple applications.
  * A deployment manifest that describes the mapping of applications onto the runtime. For example, to set the initial number of instances, memory requirements, and data partitioning.
  
  As an example, the DSL to describe the flow of data from an http source to an Apache Cassandra sink would be written as “http | cassandra”.  These names in the DSL are registered with the Data Flow Server and map onto application artifacts that can be hosted in Maven or Docker repositories.  Many source, processor, and sink applications for common use-cases (e.g. jdbc, hdfs, http, router) are provided by the Spring Cloud Data Flow team.  The pipe symbol represents the communication between the two applications via messaging middleware. The two messaging middleware brokers that are supported are
  
  