While software development is fun, the essential part of a software life cycle is production. This refers to serving actual client requests, doing business processes, and improving the industry in general by offering an amazing business service. For our application, this vital step is called release. Now, after being mainly under the guardianship of developers and testers, our software system is ready to meet the real world and the real production environment with its many hidden difficulties.

Taking into account how different target environments and extraordinary customer needs may be, or whatever operational qualities are required, we may notice that the release process itself could be complicated and deserves at least a few books on its own. Here, we do not cover topics related to delivering software but only take a quick look at different software deployment options and how these affect a reactive application.

With the IoT boom, although our reactive applications may soon be running on wearable devices such as smartwatches or heart-rate sensors, here we consider the most common target environments, which are on-premise and in the cloud. The introduction of the cloud changed the way we deploy and operate applications. In a sense, the cloud made us more reactive with regard to user demand, as we may now acquire new computation resources in minutes or sometimes even seconds instead of weeks or months in the era of on-premise data centers. However, from the developer standpoint, both these approaches are pretty similar. The main difference is that in the former case, actual servers are located in the building, and in the latter case, they are hosted by the cloud provider.

More critical differences arise in the way we use computation resources to deploy applications, and this distinction relates to both on-premise and cloud deployments:

The following is a brief description of the previous diagram:

• Hardware: These are bare-metal servers that do not run a hypervisor and consequently are not virtualized but still may be provided as a cloud service. Examples of these are Scaleway (https://www.scaleway.com) and Packet (https://www.packet.net). A user has to manage everything. Even though the setup does not provide a hypervisor, usually some OS is still installed on the server. From a developer's viewpoint, this option is not very different from IaaS.
• Infrastructure as a Service (IaaS): This cloud provider gives a virtual machine with a Software Define Network and attached storage. Here, a user has to manage an environment and deploy applications. Deployment options choose the user. An example of these are AWS (https://aws.amazon.com) and Microsoft Azure (https://azure.microsoft.com).
• Containers as a Service (CaaS): This is a form of virtualization where a cloud provider allows clients to deploy containers (for example, Docker or CoreOS Rocket containers). Container technology defines deployment mode, but inside a container, the client may use any technology stack. Examples of these are AWS Elastic Container Service (https://aws.amazon.com/ecs) and the Pivotal Container Service (https://pivotal.io/platform/pivotal-container-service).
• Platform as a Service (PaaS): This cloud provider gives everything for an application up to runtime and build pipelines, but it also limits the set of technologies and libraries. Examples of these are Heroku (https://www.heroku.com) and the Pivotal Cloud Foundry (https://pivotal.io/platform).
• Function as a Service (FaaS, Serverless): This is an extremely recent development. Here, a cloud provider manages all the infrastructure, and users deploy and use simple data transformation functions that are expected to start within milliseconds to handle individual requests. Examples of these are AWS Lambda (https://aws.amazon.com/lambda) and Google Cloud Function (https://cloud.google.com/functions).
• Software as a Service (SaaS): With this on-demand software, everything is managed by a vendor. End users have to use this and cannot deploy their own applications there. Examples of these are Dropbox (https://www.dropbox.com) and Slack (https://slack.com).

Reactive applications built with a Spring stack may deploy to any environment type except for SaaS as it does not offer a deployment option. Chapter 8, Scaling Up with Cloud Streams, describes potential options for running reactive applications in the form of FaaS. This chapter also describes the available options for deploying Spring applications to PaaS, CaaS and IaaS environments. The main difference between such target environments lies in the format of deployable artifacts and through the way in which such artifacts are built.