This is a continuation of the article originally written here.

This diagram depicts the organization of deployment-as-a-service stack.

Some of the features for the above platform include:

·        best practice in deployment for all tenant's
·        automatic migration for all cloud dependencies
·        Virtualization of deployment technologies and migrations from one set of artifacts to another
·        Asynchronous and background processing with continuous monitoring
·        Programmability options to work with various clients.
·        Analysis and Reporting dashboard
·        Ability to scope down deployments from cloud to on-premises.
·        Curated collection of recipes in automation
·        App-Store integration for allowing clients to opt into deployment stack via published and downloadable applications.
·        Support for browser-based request-response processing
·        Isolated and protected data for all tenants
·        Globally accessible and remote invocable deployment automations
·        Scalable number of client connections allowed for same repository of artifacts.
·        Extensions and customizations for all tenants.
·        Full transparency in the form of logs and events
·        Continuous availability of Deployment stack
·        Ability to provide service-levels for clients.
·        Providing multiple language support including internationalization and globalization
·        Opt-in modernization of existing deployment dependencies
·        One-stop-shop for all deployment activities in the public cloud

Some of the challenges that would be encountered in this regard would include the following:

1) The scope and the environment for a deployment might be different between technologies and mapping must be formed to enable declarations against one form of technology to be repurposed for another.

2) There are many external data stores where configurations may be kept.  File-system or source control is not the only source. Collecting and collocating all the configuration poses a significant task.

3) Artifacts might vary in syntax and semantics and a one-to-one correspondence might not exist between two technologies. This would require some canonicalization, reconciliation and prior translations to be setup.

4) Even if the same technology is used, the artifacts might have different scope and levels of change which may vary widely across deployments. Rolling one deployment to another environment or topology might require additional steps.

5) The recipes must be portable across infrastructure to allow them to vary independently. The more hardcoded literals are used in a script, the tougher it becomes to move or re-purpose the script for another angle.

6) There are several deployments where the environment variable and transient data are used a lot. These must be eliminated in favor of declarative syntax.

Conclusion:  This article tried to pose deployment options for a cloud software maker to be one that is repetitive and requires continued investments over time. In such a case, outsourcing the deployment logic to a deployment-as-a-service offering provides opportunities to save costs and develop best practices.