Self-deploying applications: deployment automation that works anywhere

How to deploy to any environment in seconds without deployment code

Self-deployment is a technology used by federated applications to deploy themselves upon request. In a previous article, we defined a federated application as one whose components are loaded from multiple network locations and repositories at runtime. As we’ll see, just how they’re loaded has important implications. Strictly speaking, the components (also called federated microservices or microservice libraries) are never installed on the server. This aspect has several important consequences, but we’ll restrict ourselves to its impact on the CI/CD process.

As part of their continuous integration and delivery pipelines, organizations invest significant time and resources automating the deployment of their applications. One of the main reasons deployment automation is such a big effort is lack of standardization. Every cloud and environment has its own set of tools, and within these, consideration must be given to the method of compute delivery, e.g. bare-metal vs virtual machine vs container vs serverless; the target runtime, and so on. Developers must learn a different set of tools for each environment. One approach is to integrate each vendor with a generalized tool (e.g. Terraform, Serverless.com, AWS Proton). This helps but still requires considerable effort. Can federated applications ease this burden?

As far as the application is concerned, federated apps not only ease but obviate the need for deployment automation. For example, if you were working in AWS, once you automated installation of the server component (also known as the host in module-federation parlance), that is the last time you would need to touch AWS CodeDeploy, or Proton, or serverless.yml, or SAM, or whatever the toolchain is. Further, you wouldn’t need to concern yourself with the method of compute delivery. Whether it’s serverless, WASM, container, VM or baremetal, federated applications are always deployed the same way: just tell the server where the code is and when it’s been updated. When there’s new code the server streams it over the network and hot reloads itself. That’s it. The video above shows the process in action, with federated components loaded directly from GitHub by a server running in AWS.