Cloud solutions can be built with incredible flexibility around the resources they consume. We can create systems that dynamically respond to usage so that they scale automatically as needed. Serverless options also allow for solutions that cost near zero when not being used. By way of an example, services such as Azure functions are billed per execution – if there’s no execution, there is no cost.
This flexibility, however, leads to a problem with cost management – how do you define how much a service will cost? In a traditional on-premises architecture, projects will normally be costed based on the hardware and software licenses that need to be purchased. Whether the system is used a little or a lot, the costs will be the same.
Business leaders will often want to know how much a service will cost to run so that they can decide whether it is worth the expenditure. However, how can we state what a solution will cost until we can see how much it will be utilized?
We can start based on an estimate. We can estimate the number of users we expect to use the platform and we can create cost projections based on expected usage over time. But often, this will only be a best guess.
Therefore, any new solution needs to be monitored for resource and cost usage, especially in the first few months of operation. Some components can be purchased per execution – that is, serverless, or Functions as a Service (FaaS), or they can be provisioned using a service plan where you define an amount of CPU and RAM.
FaaS is great for more dynamic use of resources, allowing you to start very small and automatically expand as required. However, as your solution scales, there is sometimes a tipping point whereby opting for a provisioned service results in a more predictable and efficient cost.
By monitoring usage and costs, we can then feed back into the solution design and change either the component or the pricing model as we see fit.
As we saw in Chapter 15, Designing for Logging and Monitoring, Azure includes the Azure Advisor service, which will make recommendations on some services such as VM sizes.
When calculating costs for a solution, we need a way to group the components. We have several ways to achieve this – we can group resources into resource groups, we can tag resources with a cost center, or we could group solutions into their own subscription, creating a new subscription per system. However, when building solutions in their own subscription, we need a way to ensure that each subscription contains all the necessary security, monitoring, and reporting mechanisms – often called a landing zone, which we will examine next.
Creating landing zones
Using subscriptions is a useful way of segregating duties and application workloads. However, if you wish to use that model, you need to consider how this affects your security and governance posture.
For example, you may wish to ensure that all network traffic is routed through a central firewall, or to centralize logging and monitoring. We therefore need to ensure that any new subscription is set up correctly and in line with your overall design strategy.
Defining a landing zone methodology is concerned with leveraging the various Azure components and tools to create consistency and compliance across all your subscriptions in an automated fashion. The latter point is crucial – ideally, your patterns should be implemented automatically with as little manual intervention as possible.
When designing a landing zone, you must keep in mind that it needs to be scalable – changing how landing zone patterns work later can be time-consuming and costly. They should also be modular, which helps add additional features and functionality later or change how you’ll implement some services.
You must consider many different areas when designing a landing zone, including the following:
- Identity
- Network topology
- Governance requirements
- Disaster recovery and backup
- Maintenance operations
- Monitoring and logging
Your requirements for each will depend on your choice of technologies and implementation options, and of course, as all organizations are different, no one solution will be the same.
For each area, we can examine some of the considerations.
Leave a Reply