From one-off machines to a managed capability
My contribution: I built the platform-operated provisioning workflow, identity and access integration, persistent machine setup, and scheduled lifecycle controls.
Getting a cloud development machine ready used to take a week of manual, error-prone actions. The automated workflow reduced setup to minutes.
Developers and data engineers needed cloud workstations larger than laptops, sometimes with GPUs. One-off requests produced inconsistent sizing, access, storage, and shutdown behavior.
A usable machine needed an owner, repeatable infrastructure, secure login, persistent state, and cost-aware lifecycle, not merely a VM.
I built a platform-operated DevBox model that standardized those concerns while allowing workload-specific shapes.
Identity as provisioning input
Pulumi read Microsoft Entra ID to resolve approved users and groups instead of duplicating an identity list.
GCP resources were tied to known identities while the platform team retained provisioning control. Google OS Login avoided distributing machine-specific SSH keys.
This was identity-driven automation, not end-user self-service. Platform operators ran it; the planned developer interface is excluded from delivered work.
Supporting different workstation shapes
Reusable instance templates covered CPU, memory, disk, and GPU variants while Pulumi handled repeated resources and access policy.
Boot and data disks persisted across stop/start cycles, so compute could stop without discarding the workstation state.
Standardization applied to ownership, access, and lifecycle; sizing remained a workload decision.
Scheduling cost into the lifecycle
Cloud Scheduler triggered a Cloud Function to enforce start and stop schedules, making cost control platform behavior rather than a reminder.
A Go operator CLI paused, resumed, or rescheduled machines. It stored schedule changes as metadata while preserving unrelated metadata, supporting travel or long-running work without manual cloud edits.
Schedules were safe defaults, not absolute policy. Operator controls handled exceptions; persistent disks protected state.
Why the system remained platform-operated
Developer self-service would require a stable request interface, authorization, validation, support expectations, and expensive-machine guardrails. Keeping the delivered version operator-managed removed repetitive work without claiming an unfinished product surface.
Result
Cloud workstation setup fell from a week of manual, error-prone work to minutes. Machines became repeatable platform resources rather than bespoke VM tickets: identity came from an existing source, access used managed login, state survived normal lifecycle operations, and schedules reduced manual shutdown dependence.
Trade-offs
Platform operation kept a human step for requests and exceptions, but retained understood controls around expensive infrastructure. Persistent disks also kept storage cost while compute stopped, a deliberate exchange for durable developer state.
Related
Part of: Building Azure Landing Zones, Then Expanding Across Clouds
Related work: