Infrastructure-as-Code (IaC)
How many third-party services and resources does your application use? For a regular web application, you need a place to host your frontend, deploy your APIs, store files, a database for user accounts and other application data, maybe some queues for decoupling tasks, monitoring integrated with every service you deploy,
Systems Architecture
Testing the changes in a pull request isn't intuitive: checking out the branch, waiting for Docker to launch all service containers, keep waiting for another bit, then getting to test the actual PR. By the time you reach the last step you might have forgotten what you initially
Systems Architecture
In my recent post, I talked about how we reduced deployment times of our Infrastructure-as-Code workflow with Pulumi. The benefits of managing all resources you're deploying in a declarative way are manifold, including observability of what you're running, security in the sense of using encrypted secrets,
Systems Architecture
The faster you can release changes, the faster you can ship new features, fix bugs, and solve incidents. But there's more: The less time it takes to think about deploying to production, the more time your engineers get back to work on meaningful tasks or spend their time
Continuous Deployment (CD)
Last week I published a piece on how running a CI-driven commit-based release infrastructure can improve your time-to-release drastically. I noticed that it wasn't super clear on how to get services running that aren't typically bundled or packaged up like container images, for example, frontend deployments.
Pulumi
Over the years plenty of tools to simplify managing your vast infrastructure and deployments emerged. Whether it was Terraform that sought to create declarative representations of cloud resources, or later on Kubernetes with its custom resource definitions (CRDs) connected to the underlying cloud platform, there were many attempts to reduce