TechPount

I find that most business growth problems don’t come from surprise events but rather exposed costs of past decisions made by yourself or others. A network or storage system designed for 40 employees in one office and surprisingly found to be handling 90 sessions in 3 locations is a common problem. Also storage that costs only a fraction of the value it provides but charged at egress rates that were never modelled for current usage.

This post is about being ready for growth not buying growth in advance. I have designed and run large amounts of architecture to grow at the same rate as spend on growth (and some to grow faster than that).

Designing networks that absorb load without redesign

The real test of a scalable network is to add capacity and see if you can add it without having to re-architect it. In other words, will it scale with new spend, or will it cost more than you bargained for down the road? As mentioned above, flat networks fail this test very quickly. As soon as you start to approach a few hundred hosts in a single broadcast domain, troubleshooting becomes hit or miss and often must be solved via after-the-fact segmentation in an emergency upgrade cycle.

Work to segregation of functions so that work can continue in a disaster before it occurs. Work out the segmentation for functions such as voice, guest access, corporate endpoints, operational technology and management interface functions. It will only take a few hours to design the segmentation but it will cost an arm and a leg to implement later.

Capacity signals worth tracking

• Uplink utilisation at the ninety-fifth percentile rather than the average, which hides the peaks that cause complaints
• DHCP scope exhaustion rates per segment, a reliable early warning that addressing plans need revision
• Wireless client density per access point during busy periods, not the total client count
• WAN latency variance between sites, which degrades well before throughput does

Cloud architecture that stays portable

It is now almost de rigueur for organisations to use cloud services of some sort. However, the much harder decision is how deeply to embed a particular cloud provider’s managed services within your own architecture given the huge costs of later trying to change direction.

To reach the Tier of the core applications use cloud provider services on a tier by tier basis starting with the core of your business. Within the core use standards-based database services such as SQL or NoSQL and contain your applications in containers that can be re-hosted as required. For the Tier of peripheral functions and services such as analytics, messaging etc use the proprietary services of cloud providers where they add sufficient value to the organisation.

Comparing deployment approaches

Security controls that scale with headcount

When security is growing faster than the organisation, Identity is usually the biggest scaling challenge of all, account provisioning for 30 people can be a manual administrative task, but for 300 people it becomes a major compliance challenge. Using a Role-Based Access Control (RBAC) model on top of the authoritative HR system and automating de-provisioning of user accounts on employee departure is the best way to deal with access risk and the huge administrative overhead of user account management.

Conditional access policies are better written against risk signals (unknown location, unmanaged device etc) rather than against individuals or specific devices. These policies will grow with your organisation.

What growth tends to break

1. Shared administrative credentials, which become untraceable once more than a handful of people need them
2. Firewall rule sets accumulated over years, where nobody can safely remove anything
3. Endpoint coverage gaps, as contractors and acquired teams arrive with unmanaged devices
4. Logging retention that was sized for a smaller estate and silently drops events

Maintenance as a planned discipline

Reactive support does not scale. As incidents in your environment increase in volume, it becomes unmanageable. However, scheduled maintenance of your environment is lovely to plan for and catch problems before they occur. Test your scenarios for patches and run them between releases. Set up your firmware updates for your network equipment for scheduled maintenance as well. Lastly, test the restore of your scheduled backups on a quarterly basis and verify results (i.e. Verify you can restore, not that the backup completed successfully).

Regular reviews of the afore-mentioned key factors can help anticipate growth and negotiate better commercial terms with your chosen capacity planning provider, before it is too late. If your own team cannot hold that cadence, a provider offering managed IT services in Sydney is usually the more reliable way to keep the maintenance calendar honest.

Deciding what to run internally

Leave routine service work like service monitoring, patch management, service desk support to the managed services specialists. Negotiate service level commitments against your Sydney based incident records with the managed IT services providers. Look past the nice sounding Service Level Agreements and find out the real commitments. Ensure only the people that need access have administrative access and find a way to audit access addressing, segmentation design, identity management for user provisioning/de-provisioning and service restoration for critical services.

Where to start

Auditing the addressing scheme, segmentation architecture, user identity management for account provisioning/de-provisioning as well as testing the restore of critical services. Most of these items can be audited and fixed within a few weeks, not months, to enable your growth without problems.