Creative Cloud Deployments:

The following are some novel proposals for cloud resource deployments using Infrastructure-as-code. They bring together technologies that have proven their value in other domains.

1.       Sidecar resource: The sidecar deployment is a common pattern that uses additional containers to extend the functionality of the main container. Sidecar containers run alongside the main application container, providing additional services and extending its functionality. They are active throughout the pod’s lifecycle and can be started and stopped independently of the main container. In the cloud resources. Although not quite as popular on Azure, there are a few examples in AWS that make use of this deployment pattern. For example, the Open Policy Agent is a sidecar deployment in the Amazon Elastic Container Services (Amazon ECS) which runs in its own process with high levels of isolation and encapsulation. The Open Policy Agent aka OPA is an open source, general-purpose policy engine that lets us specify policy as code and provides simple APIs to offload policy decision-making from the applications.  A connection classifier is a popular policy evaluation module that can receive incoming requests and perform a policy evaluation against stored data and policy documents. Logging, monitoring, and authorizations are some of the other usages of sidecar deployment, but they have become primary citizens of the Azure public cloud that enable a consistent experience across resources which is more popular and less restrictive than the sidecar model. Also, sidecar models suffer from increased resource consumption and complexity, potential performance degradation and latency, security and reliability risks. Central Infrastructure deployment teams for various business divisions or campaigns can leverage new sidecars for working with specific deployment templates such as for app services, their alerts, and network infrastructure to provide analytical models using machine learning or data mining algorithms. By virtue of deployment templates, the models target highly scoped and cross-resource activities and artifacts to make their inferences and avoid the use of large analytical public cloud resources such as Data Explorers that can become quite expensive.

2.       Pseudo-resources: an extension of the sidecar pattern to be more acceptable across deployments but scoped at a higher level than what sidecar applies to, which could even be the entire subscription and not just the resource group, is the idea that a custom cloud resource can be deployed that effectively works as a combination of existing resource types. By giving the designation of a pseudo resource, the combination is given a name and visibility akin to out-of-box cloud resources. T-shirt sizing and deployment templates are very popular in this regard. For example, if a shopping store has dedicated microservices for catalog, cart, rewards, credit and so on, then providing infrastructure to the shopping store can be done in the form of a custom resource which can even be sized as small, medium, and large.

3.       Functionality and analytics are different from one-another, and this can be leveraged to package custom queries and data connections that can provide ease of use for the owner of the functionalities needed from the infrastructure. The cloud resources offer graph explorer and data explorer as analytical platforms that can work with many published data connections and include new custom data connections, but the analytical solutions dedicated to the functionality can abstract the query, interactivity, and data to make it simpler and easier for owners to know more about their pseudo-resources or deployments.

References: previous articles on IaC