Application Driven Infrastructure

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 and structures, there are tools such as Flyway to help you. 

K8s uses DNS services for service discovery and that seems to work pretty well. If you need to manage the network between services in a graceful and scalable way, consider a Service Mesh.

To extract the management of endpoints to a third-party service (in order to create mocks for not-yet-existing services and much more), consider an API Gateway. Be warned however, that this central piece of infrastructure easily grows out of hand - just like the enterprise service busses did - if you're not careful and put too much logic in there.


Comments

Popular posts from this blog

Auto Mapper and Record Types - will they blend?

Unit testing your Azure functions - part 2: Queues and Blobs

Testing WCF services with user credentials and binary endpoints