Development Experience(s)

An application has traditionally run on a machine of some sort, utilizing the machine's hardware and software capabilities. A number of years back, I was responsible for a Windows based system, utilizing MSMQ as part of its operation, for example. These application servers, were the application runtimes for my system. These are my reflections, lessons learned and brief summary of chapters 11 and 12 of Infrastructure as Code and is  part of the Infrastructure as Code series . Servers are more complex than other types of infrastructure, like network and storage primitives. They have more moving parts and variation, so most teams still spend quite a bit of their time configuring and updating operating systems, packages and configuration files.  It is useful to assign a role  to a server, indicating its purpose. Is this an application server, a dedicated database service, a central monitoring repository? When provisioning servers, it's also useful to use role inheritance . You migh

The whole point of provisioning infrastructure, is to run applications on it. Depending on the technology behind your programming environment of choice, you might need an application runtime (JRE, .NET Runtime) to support its execution. Your application might also need other supporting systems to be available, e.g. a queuing system, a file system etc., all of which might require some configuration to work the way you intend them to. Finally, your application might need data structures and reference data available to it, not to mention connectivity configuration and, possibly, parameters passed into your application. These are my reflections, lessons learned and brief summary of chapter 10 of Infrastructure as Code and is  part of the Infrastructure as Code series . Although Docker, K8s and Helm charts are all the rage, other deployment package formats include Server Operating System packages such as RPM, DEB, MSI and Language Runtime Engine packages such as JARs. To manage data schemas

Just as a big benefit of TDD, is that your component design improves ; writing tests while designing and building systems - rather than afterwards - forces you to improve your designs. A component that is difficult to test in isolation, is a symptom of design issues.  These are my reflections, lessons learned and brief summary of chapter 9 of Infrastructure as Code and is  part of the Infrastructure as Code series . Design your components to be small and focused, e.g. installing an application runtime (.NET, JRE, ...) onto a server and then ensuring that it (dotnet, java) is available on the path. When it comes to testing, consider taking steps to syntax check and lint your infrastructure code, before you ask your cloud provider to provision resources for you. This will save you time and, money and headaches: Syntax checking: Execute a dry run ( terraform validate , aws cloudformation validate-template , using arm-tt ) on your infrastructure code to quickly get feedback when you've