This is a continuation of previous articles on IaC shortcomings and resolutions. One of the favored
patterns is the shared nothing pattern that provides complete isolation,
protection from cross-contamination, and improved scalability and security.
Case in point is the app services to app service plan mapping.
If there is a one-to-one relationship
between app services and their plans, then each app service plan provides
independent scalability for the app service. The use of a subnet with the app
service plan allows customizations for just that app service including its
inbound and outbound connections.
The other pattern is a shared
pattern. For example, a gateway might have more than a dozen app services as
its backend members and each member might be allowing public access. If the
gateway must consolidate access to all the app services, then there are changes
required on the gateway to route traffic to each app service as intended by the
client and a restriction on the app services to allow only private access from
the gateway.
Between the application of these patterns, one of the
factors determining the outcome is their purpose and utility. For example, a
smaller subnet with only /28 suffix will have a smaller ip range and these can
be issued as many as needed from the same virtual network. On the other hand,
consolidation of app service plans across app services allows us to use just
one subnet as outbound for traffic from all the app services because the VM is
assigned only one NIC card This is favored when the set of app services belong
to the same category and the traffic does not impact the performance of the app
services.
An upgrade of all the subnets to the latest IaC
definitions and the creation of new subnets to replace the non-functional
subnets will be an ongoing maintenance. As the deployment grows with age, the
versions of the toolset and definitions also change. New properties get added
while the old ones get deprecated. Changing the definitions poses a risk across
many resources and resource types that are hosted on the subnets, so they must
be changed methodically.
The changes could be initiated progressively and in an
incremental manner such that the round of tests is minimized and only applied
to the changes made. The first step is to update the toolset before any changes
are made. Then the existing definitions are assigned to a reference for their
source before the new definition is used. If they did not have a reference,
they would have pointed to the latest and updating the source to a new
definition would affect more resources than intended. Next, the common definition
for the subnet was updated, and a new tag was generated so that it could be
referenced only from those callers that required the new definition. Once the
reference is available, all the resources in the deployment that require the
new definition are pointed to the new reference
Some app services might start out the same way but end up
differently. The initialization of
resources as well as their potential growth are important factors for the
choice of patterns.
In this way, the choice of patterns must be decided on a
case-by-case basis.
No comments:
Post a Comment