About Landscape Tiers

If you strongly believe in Too Long; Didn’t Read (TL;DR)
as a way of life, then you should probably avoid this website.

All digital landscape architectures are a a journey
down the rabbit hole of evolving technologies,

schema compabilities, data integrity, process,

policy, compliance, risk and continuous learning.

For the bits you know you don’t know thoroughly.

Let alone the philosophy and techniques that you
don’t know, that you don’t know.

Genonimo … it is time for an Adventure. šŸ––

Adventures about Landscape Tiers plugin for WordPress.

WordPress ā€¦ the free software platform available for motivated internet enthusiasts to setup their own website, while focusing more on the content to share with their community. Supported by the combined and continuous improvement of thousands of contributers who keep the WordPress platform thriving.

Download, install, configure and explore hundreds of standard WordPress features plus thousands of customised Plugins and Themes to extend what the platform can do.

Always striving to combine simplicity for website owners, users and publishers; with under-the-hood flexability for maintainers and developers.

Like all internet hosted platforms, the enterprise maturity of running a Production environment is a shared responsability. Each service provider contributes to the journey, looking after their focused specality, leaving the website owner to be ultimately accountable for the whole show.

It can be a steep learning curve if you are running the whole platform on your own dedicated server; while performing maintenance activities yourself, minimising service dependancies, optimising performance and engaging with your community.

Ultimately, there are plenty of options and combinations available that enable a true choose-your-own-adventure for the responsabilities you might do, defer, delegate or ignore.

In turn, this convience seems to naturally start with a single Production system, then the maturing organisation processes solidify, as an after-thought when the business gets burned by avoidable incidents.

Unlike larger organisations, with a healthy awareness of overlapping technology, policy, processes and portfolio profiles that will usually skip the cowboy-phase of developing in the one-and-only Production website.

Mindful organisations will start with at least a 2 tier landscape architecture … a Development Tier and a Production Tier. Each tier is fully self-contained and mostly isolated from the other.

Hence, each landscape tier will be self-sufficient and have all the necessary services available and connected within that specific tier; and not be connected or using services from any other tier (in theory, in a perfect world).

As technology has evolved over the decades with the usual pendulums of focus and priority swinging (software vs hardware, optimised opcodes vs abstracted reusable library layers, security vs convienence, etc) there is always an underlying intersection where capability & process meets risk & reward.

It is always a dance, no matter what your bias or pre-judgement might be.

In the end, there is no absolute right or wrong way to maintain your WordPress website or manage the application and content updates. There are only consequences to chose, lessons to learn and others peoples experience that can be leveraged.

In the end, you get what you get for the journey you have chosen for your website.

Just make sure you start, plan, act, learn, decide, grow and pivot to evolve the processes and priorities that work for your WordPress website adventure.

Websites are not created equally, and their purpose defines the resilience required.

Does this sound familiar?

Lets assume there is only one public website (aka Production).
Next step was to evolve and do regular backups.
Then you got busy with everything else … no more improvements.

One way to continue evolving the website landscape adventure is to leverage what you already have … production backups that contain the most recent data and configurations that are probably 99.999% aligned with any website issues you might need to research.

Then we all hit a learning curve (frustrating hard lessons) that the simple idea of restoring a backup as a separate staging website (aka a Clone) demands a fair bit of effort, additional under-the-hood knowledge, maintenance of connecting services, undesired automated actions, data becomes stale, different system maintenace scenarios, etc, etc, etc.

The best way forward is to understand the purpose of the website Clone.

Clarity of purpose will provide decision boundaries and help visualise what the next steps might be for your specific journey.

Start by picking one of these basic Landscape Tiers, as you next target environment to setup. Pick one that will help you the most with todays biggest pain points.

  • [Tier][Production] Can you restore a Production backup into the Production environment, at a moments notice and be confident of the outcome?
    • Like, as a way to rewind a major upgrade that failed basic validation.
    • Like, as a way to gain confidence in a new hosting provider configuration.
  • [Tier][Staging] Can you restore a Production backup into a Staging environment, to be updated with the latest round of release patches for end-user testing and not interfere with the real Production environment resources?
    • Like, applying new major, minor and early release updates for WordPress, plugins and themes.
    • Like, applying significant configuration changes? Change internal directories, switch security services, database caching, page caching, lazy loading, etc.
  • [Tier][Stress] Can you restore a Production backup into a dedicated Stress environment, to conduct performance stress testing on hardware, network, service, software, configuration schemas and not interfere with the real Production environment resources?
    • Like, how many website homepage concurrent WordPress endpoint requests before the webserver starts issuing ‘503 Service Unavailable’ responses.
    • Like, how many concurrent WordPress endpoint requests before the web firewall kicks in? Was it an appropoate response or does the configuration need tweeking?
    • Like, is the private coordinating attack server resources & network pipe in the isolated stress environment sufficient enough to overwhelm a replica of the Production environment?
    • Like, can the Stress environment also be used for Cyber purposes? Posture assessment, vulnerability scanning, penetration testing, API testing, gray-box testing, double-blind testing, etc. Especially since a replica production environment usually takes quite a bit of time, money and resources to maintain.
  • [Tier][Training] Can you restore a Production backup into a Training environment, to conduct a private training session, with obfuscated data and not interfere with the real Production environment resources?
  • [Tier][Project] Can you restore a Production backup into a dedicated Project environment, to conduct a unit tests, features tests, integration tests for all project deliverables and not interfere with the real Production environment resources?
  • [Tier][Test] Can you restore a Production backup into a Test environment, to conduct a private investigation under-the-hood and not interfere with the real Production environment resources?
  • [Tier][Development] Can you restore a Production backup into a local Development environment on your personal computer and be confident it won’t mis-behave with the stale production data or interfere with the real Production environment resources?

Still not sure where to start … try aiming for a landscape architecture with 4 tiers. It might seem like overkill. However, it is where website maintainers and developers would get the most benefit day-to-day, while trying to lower the Production risk profile …

Development -> Test -> Staging -> Production

… if only we could ensure that the instant the Production backup was restored, it knew it was no longer in the Production environment.

This is where a Landscape Tiers plugin for WordPress could automatically apply passive limits and optional aggressive actions to protect the Production data and Production environment from that restored backup, that is no longer in the Production environment.

Then it would be nice to have WordPress Administration area [Quick-Configure] buttons for when you want to truly commit to changing the purpose of that active WordPress instance.

  • In a local Development environment on your personal computer.
    • For development and unit testing.
    • Enable code step-debugging capability.
    • Using different operating system and cron scheduling capability.
    • No like-for-like comparisons due to different CPU, memory and harddrive.
    • Less likely to integrate with replica-production services (Redis, etc).
    • Less likely to integrate with replica-external services (Email, Zapier, etc).
  • In a Test environment.
    • For feature testing and additional integration services.
    • No code step-debugging capability, but should if not on the internet.
    • Preferrrably same operating system and cron scheduling as Production.
    • More likely to integrate with replica-production services (Redis, etc).
    • More likely to integrate with replica-external services (Email, Zapier, etc).
  • In a Staging environment.
    • As a locked-down domain in Production host to test application changes.
    • Or a separate environment for hardware, network, service, host changes.
    • No code step-debugging capability. Environment is for release testing.
    • Using same operating system and cron scheduling as Production.
    • Integrate dummy data with replica-production services (Redis, etc).
    • Integrate dummy data with replica-external services (Email, Zapier, etc).
  • In a Production environment on the public internet or your organisation intranet.
    • Probably exposed publically to the internet, wrapped in firewalls.
    • No code step-debugging capability, because it is a security concern.
    • Integrate Production data with Production services (Redis, etc).
    • Integrate Production data with External services (Email, Zapier, etc).

Yes … that would be awesome.

Q: Why bother having separate Test versus Staging environments?
Q: Can’t we just use one and save a bunch of time, money and effort?
A: In theory, yes … but you will miss out on testing a Release Package as a bundle of combined changes for a target environment. A Test environment brings individual changes together for Quality Assurance testing, which would then be leveraged as a false confidence to by-pass Release Readiness testing in a Staging environment. Having said that, the best way forward is generally a bit-by-bit tiny steps approach; so, pick one and evolve your landscape, then pick another and keep growing … it is just a choice.

[Disclaimer] The above discussion is an introduction to landscape tier termonology to get your imagination started toward visualising a possible way forward for your simple website adventure. It is intentionally overly simplified and way too broard to cover the nuasnces of most complex ogranisation requirements; but, we have to start somewhere.

Who am I?

My name is John Lang, an Aussie from the land down under, with 40-ish years experience in building practical computer solutions. Originally, a solid foundation in application programming, internet technologies, distributed computing, SAP Business Warehouse (BW) and HANA Data Modelling; which has evolved into leading project teams to deliver successful outcomes for their clients, customers and user communities.

I started this website because my WordPress development journey involves occasionally frustrating administration activities. Every now and then, when I wanted to tinker and dig deeper into a topic, Iā€™d waste a few hours getting the required local development environment and services back up and running on my personal computer. The missing software services, the mis-behaving PHP step-debugger and full log files would distract me from the real goal of being able to quickly explore an idea and prove a code-snippet works.

My passion is to find practical solutions that help fellow explorers overcome their challenges with using a PHP local development environment for WordPress. This allows a truly curious website maintainer, developer and tester to get on with the adventure of delivering; while minimising the time and effort spent on repetitive activities.

Survey ā€“ What is Stopping You?

If you are sick and tired of wasting time finding just the right configuration required to quickly start-up a local WordPress development environment on your personal computer, then vent your frustraightion and tell me ā€¦

What is Stopping you from having the WordPress Development environment you Desire?