The Pillars of Platform Engineering: Part 4 — Connectivity
This guide outlines the workflows and checklist steps for the six primary technical areas of developer experience in platform engineering. Published in six parts, part one introduced the series and focused on security. Part four addresses network connectivity. The other parts of the guide are listed below, and you can download a full PDF version of The 6 Pillars of Platform Engineering for the complete set of guidance, outlines, and checklists:
- Security (includes introduction)
- Pipeline (VCS, CI/CD)
- Provisioning
- Connectivity
- Orchestration
- Observability (includes conclusion and next steps)
Networking connectivity is a hugely under-discussed pillar of platform engineering, with many legacy patterns and hardware still in use at many enterprises. It needs careful consideration and strategies right alongside the provisioning pillar, since connectivity is what allows apps to exchange data and is part of both the infrastructure and application architectures.
Traditionally, ticket-driven processes were expected to support routine tasks like creating DNS entries, opening firewall ports or network ACLs, and updating traffic routing rules. This caused (and still causes in some enterprises) days-to-weeks-long delays in simple application delivery tasks, even when the preceding infrastructure management is fully automated. In addition, these simple updates are often manual, error-prone, and not conducive to dynamic, highly fluctuating cloud environments. Without automation, connectivity definitions and IP addresses quickly become stale as infrastructure is rotated at an increasingly rapid pace.
To adapt networking to modern dynamic environments, platform teams are bringing networking functions, software, and appliances into their infrastructure as code configurations. This brings the automated speed, reliability, and version-controlled traceability benefits of infrastructure as code to networking.
If organizations adopt microservices architectures, they quickly realize the value of software-driven service discovery and service mesh solutions. These solutions create an architecture where services are discovered and automatically connected based on centralized policies in a zero trust network if they have permissions, otherwise the secure default is to deny service-to-service connections. In this model, service-based identity is critical to ensuring strict adherence to common security frameworks.
An organization’s choice for its central shared registry should be multicloud, multiregion, and multiruntime — meaning it can connect a variety of cluster types, including VMs, bare metal, serverless, or Kubernetes. Teams need to minimize the need for traditional networking ingress or egress points that bring their environments back toward an obsolete “castle-and-moat” network perimeter approach to security.
Workflow: Connectivity
A typical network connectivity workflow should follow these eight steps:
- Code: The developer commits code.
- Note: Developers may have direct network control plane access depending on the role-based access controls (RBAC) assigned to them.
- Validate: The CI/CD platform submits a request to the IdP for validation (AuthN and AuthZ).
- IdP response: If successful, the pipeline triggers tasks (e.g. test, build, deploy).
- Request: The provisioner executes requested patterns, such as building modules, retrieving artifacts, or validating policy against internal and external engines, ultimately provisioning defined resources.
- Provision: Infrastructure is provisioned and configured, if not already available.
- Configure: The provisioner configures the connectivity platform.
- Connect: Target systems are updated based on defined policies.
- Response: A metadata response packet is sent to CI/CD and to external systems that perform actions such as security scanning or integration testing.
Connectivity flow (the Connect box includes service mesh and service registry)
Connectivity Requirements Checklist
Successful network connectivity automation requires:
- A centralized shared registry to discover, connect, and secure services across any region, runtime platform, and cloud service provider
- Support for multiple interfaces for different personas and workflows (GUI, API, CLI, SDK)
- Health checks
- Multiple segmentation and isolation models
- Layer 4 and Layer 7 traffic management
- Implementation of security best practices such as defense-in-depth and deny-by-default
- Integration with trusted identity providers with single sign-on and delegated RBAC
- Audit logging
- Enterprise support based on an SLA (e.g. 24/7/365)
- Support for automated configuration (infrastructure as code, runbooks)
Check back tomorrow for the fifth pillar of platform engineering: Orchestration.
