Azure Scaffolding?
Remember the sleeves and pins!
For quite some time, Microsoft have provided architectural patterns to deploy an Azure hub and spoke architecture that forms the basis of a foundational design that handles some basic stuff such as access controls, traffic routing, administration boundaries, network boundaries and the likes to get customers up and running with an Azure deployment. Microsoft then extended this with more comprehensive guidance within the Azure Cloud Adoption Framework (CAF).
The Azure "scaffolding" provided a leg-up in establishing basic Azure foundations. That’s just the start of the journey. In any large business you will almost always find a large eco-system of technologies, processes, policies and organisational constructs that this Azure scaffold needs to integrate with. This includes (just to name a few) the existing architectures that deliver a global network, DNS, security, identity management, privileged access management, logging and analytics platforms, automation platforms, DevOps pipelines, ITSM toolsets, service catalogues and so on. Some of this may be obvious but when you start to consider large scale enterprise container platforms (ECP) there is another layer of scaffolding (lets call it ECP scaffolding) that will be integrated into the above as well as a host of other technologies that were not required before you started to think about running enterprise container platforms at real scale in a production context.
Construction scaffolding is joined with sleeves, pins and couplers. When thinking about Azure and ECP scaffolding, its important to consider how the Azure and ECP scaffold will be joined together as well as how those, in turn are integrated to the broader eco-system of technologies and processes. It’s this set of technology sleeves and pins that allows all of the above to co-exist in a way that helps make the whole platform robust and easy to manage at real scale. In designing these platforms there are some obvious considerations with just a few examples below:
When to choose cloud-native services to deliver key platform processes and when to use existing investments / technologies (in cloud or on-premises)?
When collecting large volumes of logging data, is it better to bring that back on premise to an existing platform you already own or are you more prescriptive about the cloud logging and storage services and indeed the retention, archiving and deletion of log data to ensure you manage costs wisely?
Does the existing naming and tagging strategies you have for other cloud services fit the bill for a large and quite fluid container platforms where instances come and go intra-day as part of a scale-up, scale-down activity?
Do the existing Active Directory group hierarchical structures give you what you need to manage the ECP environments at scale or should you be re-thinking your security posture and role-based access controls for these new services?
Does the existing IP address scheme/strategy used for general Azure platforms also support your needs for high volume container services or is there a risk of IP address exhaustion?
Does the existing cloud outer/edge security design satisfy your needs or do you also need a new service mesh design to secure traffic between different parts of the container platform architecture and environments?
Are your existing on-premise container management processes a fit for what you need in Azure? Do the existing CI & CD processes lend themselves fully to high cadence integration and deployment which is more typical for these architectures?
Does the right “hand-shake” exist in your organisation today between developers and technology infrastructure teams to allow the release cycle to make its way from sandbox all the way to production without business risk and in an automated way?
Does the existing IT organisational design lends itself to a cloud-native, Infrastructure as Code way of working or are there some adjustments necessary?
Getting back to the scaffolding building blocks and integrations, at BlakYaks we are developing and building additional pieces that extend upon the Azure scaffold and cloud adoption framework including (not limited to) the following:
A terraform implementation of this Azure hub and spoke architecture.
The next layer of architectural scaffolding needed to fully prepare the Azure platform for enterprise container implementations.
Testing our designs/builds against CIS benchmarks across the Azure and container platform layers to be fully prepared for hosting production container services at scale.
Creating a code base that is modular in design to provide solid building blocks that are easier to extend and integrate.
There are also some integrations required that are intra-scaffold and inter-scaffold. As we think about extending the Azure scaffolding and CAF framework with additional layers to accelerate cloud-native adoption, we are thinking and planning for the additional "sleeves and pins" that join the layers of scaffolding and make them fully functional in an enterprise context. We also want to use modular blocks of infrastructure code that interface and connect these architectures and systems together . This includes things like:
Holistic identity and access management across the entire platform (people and objects).
Logging, monitoring and log management for all components of the extended platform.
The integration of cloud-native services with existing backup, recovery and business continuity processes.
The role based access controls at multiple layers of this extended platform.
Major and minor upgrade automation and life cycle management tools, automations and processes.
Enterprise container reboot management to ensure security and desired configuration compliance.
Systematic naming and tagging strategy for all platform elements.
Azure policy and CIS benchmark compliance controls and reporting (where applicable).
Desired state controls and the associated monitoring and remediation processes.
Time series logging and management.
Dashboarding, reporting and MI.
Elegant DevOps pipeline integrations.
AD/LDAP/SAML integration.
Key vault and container registry integration.
Storage classes (disk, file, retained and non-retained).
Cost policies, controls and reporting.
The high level architecture below outlines some of our key focus areas and the areas getting the most attention in our Azure lab environments.
As we conceive, develop and build more "sleeves and pins" in the lab in the weeks ahead it helps us rapidly assemble enterprise-ready Azure platforms with a secure and repeatable implementation of Azure hosted enterprise container platforms. A key goal for us is to make the whole solution more developer friendly and cloud-native with all the right automations and security in place as part of the core design. This approach helps cloud infrastructure teams we work with to reduce the deployment and management overheads in their cloud environments. Watch out for technical blogs covering some of this in more detail as we plug components together in our Azure Labs. At the time of writing this, we have automated deployments for Azure + AKS, Azure + Redhat Openshift, Azure + Rancher all with a number important sleeves & pins already making key joins into an adjacent eco-system.
