Grady Booch wrote about this a long time ago. It was written as a response to Test Driven Development (TDD). He spoke about architecture decisions, language choices, and library choices. He talked of the importance of prototyping your system, stress testing alpha builds, and making decisions on scale vs power early on and throughout the lifecycle.

If you are moving to Service Orientated Architecture and Micro Architecture you need to have your infrastructure at the forefront.

  • How much traffic do you need to handle now?
  • How much traffic do you expect in a X period?
  • How do you want to scale your infrasctructure?
  • How important is latency?
  • How important is data integrity?
  • Have you used that database/messaging queue/etc service before?
  • How quickly can you prototype/alpha the infrastructure?
  • How will you stress test the instrastructure?

We don’t want to over-engineer at this point, but we do want to understand requirements and growth projections.

That three server setup might work for half a year until traffic explodes; can we add extra ones easily? Traffic might spike, can we drop servers when traffic drops?

Throughout all of this the underlying applications need to know what can happen on a infrastructure level. Will data ALWAYS make it through? Can the application flow break halfway, how can my application find out?

Having answers, or agreeing to provide numbers to requirements/questions early on in a project will provide safety nets and clear watches on dangers before they hit.

Stress drive out your infrastructure as you test drive out the applications. Have the experience of these pass onto the future projects. Nothing is set in stone, and errors will occur but identifying the bottleneck/danger zones will enable safer, cleaner programming and infrastructure management.

Simulate network partitions in DBs Load test functional behaviour and measure performance