If you’ve studied computer science then you know there are algorithms that calculate “complexity.” Unfortunately, these have little practical use for data center operators. My complexity rule does not require a PhD:

The 32nd rule: If it takes more than 30 seconds to pick out what would be impacted by a device failure then your design is too complex.

6 Hyperscale Network Design Rules

Cost Matters

Keep Networks Flat

Filter at the Edge

Design Fault Zones

Plan for Local Traffic

Offer load balancers (to your users)

Sorry for the teaser… I’ll be able to release more substance behind this list soon. Until then comments are (as always) welcome!

I’ve had a busy week with Azure Training and Cloud Camp Seattle. It’s going to take a few days to unwind specific posts about both, but I wanted to hit some shiny new thoughts.

Services helping each other

Adjacent Services are dedicated and/or public services (XaaS) that are offered along side generic public cloud offerings. For a company like Dell (my employer), this could be specific brands of storage or databases (e.g. Oracle). I believe these are much higher margin XaaS than IaaS.

Layer 7 Load Balancers represent a more intelligent link between load direction and the applications. I heard people using this term in multiple contexts. For example, In Azure, the apps can set themselves as “offline” and they will stop getting traffic then they can turn themselves online when they are ready for more.

Cloud Rollout/Migration is a rolling upgrade scheme where you can send traffic to 2 versions of your application at the same time! You upgrade by zones and if you have >2 zones then you’ll have two active versions at the same time. Your data models need to accommodate this.

We don’t have enough Agile Cloud programming books (like Dave Thomas’ RoR Intro). We need a cloud programming book that STARTS WITH INTEGRATION TESTS and shows how to use all the adjacent services. I may just have to write one (or three).