One area of IT solutions in which the cloud has had a dramatic impact is around deployment. Traditional system builds, certainly at the infrastructure level, were mostly manual in their process. Engineers would run through a series of instructions then build and configure the underlying hosting platform, followed by another set of instructions for deploying the software on top.
Manual methods are error-prone because instructions can be misunderstood or implemented wrongly. Validating a deployment is also a complicated process as it would involve walking back through an installation guide, cross-checking the various configurations.
Software deployments led the way on this with automated mechanisms that are scripted, which means they can be repeated time and time again consistently—in other words, we remove the human element.
We can define our infrastructure in code within Azure, too, using either Azure Resource Manager (ARM) templates or other third-party tools; the entire platform can be codified and deployed by automated systems.
The ability to consistently deploy and re-deploy in a consistent manner gives rise to some additional opportunities. Infrastructure as Code (IaC) enables another paradigm—immutable infrastructure.
Traditionally, when modifications are required to the server’s configuration, the process would be to manually make the configuration on the server and record the change in the build documentation. With immutable infrastructure, any modifications are made to the deployment code, and then the server is re-deployed. In other words, the server never changes; it is immutable. Instead, it is destroyed and recreated with the new configuration.
IaC and immutable infrastructure have an impact on our designs. PaaS components are more straightforward to automate than IaaS ones. That is not to say you can’t automate IaaS components; however, PaaS’s management does tend to be simpler. Although not a reason to use PaaS in its own right, it does provide yet one more reason to use technologies such as web apps over VMs running Internet Information Services (IIS).
You also need to consider which deployment tooling you will use. Again, Microsoft has its own native solution in the form of Azure DevOps; however, there are other third-party options. Whichever you choose will have some impact around connectivity and any additional agents and tools you use.
For example, most DevOps rules require some form of deployment agent to pull your code from a repository. Connectivity between the repository, the agent, and the Azure platform is required and must be established in a secure and resilient manner.
Because IaC and DevOps make deployments quicker and more consistent, it is easier to build different environments—development, testing, staging, and production. Solution changes progress through each environment and can be checked and signed off by various parties, thus creating a quality culture—as per the example in the following diagram:
Figure 2.5 – Example DevOps flow
The ability to codify and deploy complete solutions at the click of a button broadens the scope of your solution. An entire application environment can be encapsulated and deployed multiple times; this, in turn, provides the opportunity to create various single-tenant solutions instead of a one-off multi-tenant solution. This aspect is becoming increasingly valuable to organizations as it allows for better separation of data between customers.
In this section, we have introduced how deployment mechanisms can change what our end-state solution looks like, which impacts the architecture. Next, we will look in more detail at how monitoring and operations help keep our system healthy and secure.