The Philosophical Developer -- Chapter 33: Three Clouds, One Methodology

The Pulumi port is complete. Seven AWS modules, five GCP modules, five Azure modules. Twenty unit tests across three cloud providers. All passing. All running in under 25 milliseconds. All part of the same methodology.

I sat down with my Padawan, OrsonRius, to reflect on what we learned.

The numbers

The full Pulumi port, across all three clouds, in numbers.

The Go code is more verbose than the equivalent HCL. The AWS Pulumi port is 934 lines of Go compared to about 400 lines of HCL. The extra verbosity comes from the Go type system, the error handling, and the struct initialization syntax.

But the verbosity comes with a trade-off. The Go code catches errors at compile time that HCL would catch at plan time. A misspelled field name, a wrong type, a missing required argument – all caught before the code ever runs.

The methodology

The experiment set out to answer a question: is the methodology provider-independent, or is it HCL-specific?

The answer is clear. The methodology is provider-independent. The same patterns work for OpenTofu and Pulumi. The same patterns work for AWS, GCP, and Azure. The methodology is about how you write infrastructure, not what syntax you write it in.

The four pillars of the methodology held across all three clouds.

Test-first. Write the test before the implementation. The test defines the contract. The implementation satisfies it. Red, green, refactor.

Mock-driven. Use mocks to simulate the provider API. No real infrastructure needed. No cloud credentials. No state files. The tests run in milliseconds.

Composable. Each module is a function. Each function takes a context and returns an error. The main function composes them in order. The order matters for dependencies, but the functions are independent units.

CI-verified. Every push runs the tests. The pipeline is fast enough to give feedback in under a minute. No broken code reaches the main branch.

The differences

The methodology transfers, but the details differ.

The Pulumi SDKs are not uniform. The AWS SDK uses flat argument lists. The GCP SDK uses nested structs. The Azure SDK is the oldest and least consistent of the three. Each SDK reflects the conventions of the underlying provider API, not a unified Pulumi interface.

The test patterns are the same, but the mock configuration is different. The AWS mock needs to handle 11 resource types. The GCP mock handles 9. The Azure mock handles 5. The complexity of the mock scales with the number of resource types, not the number of modules.

The CI pipeline is the same shape for all three clouds. Go build, go test, push to GitHub. The CI workflow is identical across all three repos. The only difference is the working directory.

The surprise

The biggest surprise was how easy the cross-cloud port was. The AWS port took the most time because it established the patterns. The GCP and Azure ports took about half the time each because the patterns were already defined.

The GCP port took about 30 minutes of coding time. The Azure port took about 45 minutes. The Azure SDK is less ergonomic than the GCP SDK, but the patterns held.

This is the power of a well-defined methodology. Once the patterns are established, the implementation becomes mechanical. Port to a new cloud, port to a new tool, it is the same process. Write the function. Write the mock. Write the test. Run the CI.

The open question

The experiment used Pulumi’s classic Azure provider (pulumi-azure), not the newer Azure Native provider (pulumi-azure-native). The classic provider is more mature and has better documentation. The native provider is faster and more complete. Would the methodology transfer to the native provider as easily?

The answer is probably yes. The function signatures would change, but the patterns would not. The test structure would be the same. The mock configuration would be different. The CI pipeline would be identical.

The closing

The Pulumi port is the first major expansion of the local-cloud methodology. It proved that the discipline is tool-independent and provider-independent. The same patterns that work for OpenTofu on AWS work for Pulumi on Azure.

The code is in the repos. The tests pass. The pipelines are live. The methodology holds.

But the experiment is not closed. The series is never concluded. The next chapter will explore a different direction. Maybe another tool. Maybe another cloud. Maybe something we have not thought of yet.

That is the point of the Philosophical Developer. The methodology evolves. The discipline deepens. The work continues.

Here I geek out with my young Padawan, OrsonRius.

Repos:

• github.com/dark5un/local-cloud – AWS Pulumi port
• github.com/dark5un/local-cloud-gcp – GCP Pulumi port
• github.com/dark5un/local-cloud-az – Azure Pulumi port

LinkedIn:

• The Philosophical Developer – Chapter 33: Three Clouds, One Methodology