What does it take to run a reliable on prem application? It takes practice!
At Kinetic Data, we do a lot of work with customers that require our platform to run in a customer-managed, highly secure, sometimes air-gapped environment with no Internet access.
When partnering with Kinetic Data for an on-premises (on-prem) installation of our platform, we advocate a strategy of “triple preparedness”: establishing Development (Dev), Production (Prod), and Quality Assurance (QA) environments.
This structured approach mirrors the stages of a well-planned journey, guiding us through the intricacies of software management with ease and precision. It’s not about complexity; it’s about making each step in the process clear, manageable, and effective.
In the world of software, as in life, learning from experiences and mistakes is key. Rarely do we perfect complex tasks on the first try.
In managing on-prem software, this principle is magnified. With various factors at play during maintenance and upgrades, having dedicated spaces for development, testing, and production isn’t just beneficial; it’s essential. These environments allow us to anticipate and proactively address challenges, ensuring that our end users enjoy a seamless and uninterrupted experience with our applications.
Let’s delve into how the strategic setup of Dev, Prod, and QA environments acts as a streamlined process, enabling us to experiment, refine, and deliver with confidence and ease.
Development Environment (Dev)
At Kinetic Data, we view the development environment as a playground – a safe, no-risk zone for practical testing. Imagine it as a sandbox where architects and builders (our developers) can freely experiment with different designs and materials (software features and updates) without the fear of toppling over a skyscraper.
When working on installing, updating, or migrating our application resources – or sometimes the entire environment – this playground approach becomes invaluable. Just take a glance at our Installation Guide; it’s evident that we cater to a wide array of infrastructure setups, each with its unique quirks and characteristics.
While we diligently test our changes and upgrades across the various environments we support, the reality is that every Kinetic Data customer has their own unique blend of infrastructure – with nuances that our standard testing might not always capture.
This is where the true magic of the development environment comes into play. It allows us to replicate and navigate these unique customer infrastructures to test and tweak in a space that mirrors real-world conditions yet remains safely isolated from live environments.
Think of it as a dress rehearsal before the big show – ensuring every scene is perfect, every line is memorized, and every potential hiccup is smoothed out. By doing similar tests in a customer’s environment, we can foresee and address specific challenges, making sure that when the curtain rises, the show runs flawlessly. That’s the essence of why we need a development environment – it’s our backstage, where we prepare to wow the audience.
Quality Assurance (QA) Environment: The Crucial Handoff
Imagine a relay race: the first runner (our Development environment) has sprinted with agility, navigating through various hurdles and passing the baton smoothly. Now, it’s time for the second runner, the Quality Assurance (QA) environment, to take over.
In this leg of the race, we’ve already learned a great deal about how our changes will interact within the customer’s environment. Any necessary adjustments have been meticulously applied and retested in the Development environment. Confidence is high, but there’s a crucial step before we can claim victory.
This environment mirrors the production environment as closely as possible. The main goal here is to test the steps that will be executed in the production environment, functioning like a rehearsal. This setup allows for additional tasks beyond operations, such as enabling users to test new features or allowing developers and consultants to test functionalities with beta users. The QA environment serves as a critical checkpoint to ensure that everything works as intended before moving to production.
This stage of the process is also the ideal time to make critical “go/no-go” decisions. Based on the feedback and results from the QA environment, the team can confidently decide whether the software change is ready to move to Production or if it needs further refinement. This decision-making point is pivotal – it’s about ensuring quality and readiness and minimizing risks.
Production (Prod) Environment: The Grand Finale
The baton has been passed successfully through Development and QA, and now we arrive at the climax of our relay race – the Production environment. This is where everything we’ve meticulously prepared is visible to our final audience – our end users.
In Production, the software must run flawlessly, delivering the impeccable experience we’ve promised to our users. It’s a delicate environment that should be modified only when there’s high confidence in the changes, i.e., after rigorous testing and validation in the previous environments.
The production environment is where the end users interact with the software, so stability and reliability are paramount.
Even in the well-rehearsed world, occasional updates and maintenance challenges are sometimes inevitable. However, with this approach, we can carefully plan and execute changes with minimal disruption to the live environment while accounting for discoverable variables based on testing done in an identical environment (QA) and better prepare users for expected interruption estimates based prior experience.
When everything works as intended, and our users are happy, it’s like receiving a standing ovation at the end of a spectacular performance. It’s the culmination of teamwork, planning, and execution across all three environments – Development, QA, and Production – that leads to this triumphant moment.
Rollback Strategy
In our operational tasks, particularly with server patches, system and infrastructure upgrades, rolling back changes typically necessitates reverting the server to a point-in-time snapshot. This approach often represents the only feasible method to undo changes in these scenarios.
To enhance this process, we’ve tailored our installation architecture to segregate the data layer (e.g., databases) from the Platform infrastructure. This design decision makes rollback strategies via server snapshots less volatile and more manageable.
It’s important to clarify that while this discussion doesn’t directly address databases or the data layer, our approach to data isolation ensures that reverting the Kinetic Platform environment to a recent snapshot leaves the data layer untouched, thereby preserving its integrity.
In the Development environment, where testing involves less risk and does not encompass real user data, this rollback method is acceptable. It allows us to safely test the implications of patches and upgrades, and if necessary, revert to a previous state without major repercussions.
However, in the Production and QA environments, we exercise greater caution. Here, the stakes are significantly higher due to the potential impacts on end-users and overall system stability. Therefore, we strongly recommend against employing rollbacks in these environments unless absolutely necessary (i.e., in case of a compromised system).
Best Practices
- Keep development agile: Allow freedom to innovate without fear of breaking the live system.
- Replicate real-world scenarios in QA: Ensure the QA environment closely mirrors Production to catch potential issues.
- Monitor and maintain production rigorously: Regular checks and updates keep the system running smoothly.
- Encourage feedback at every stage: User and stakeholder feedback is invaluable for continuous improvement.
- Document everything: Keep detailed records of changes and tests for future reference and compliance.
Conclusion: Orchestrating Environments for On-Prem Software Management
Managing on-prem software with Dev, Prod, and QA environments is like conducting a complex technical orchestra. Each environment plays a critical role in ensuring that server patches, infrastructure changes, and platform upgrades contribute to a harmonious and successful outcome.
In the world of on-prem software management, this approach is not just a best practice – it’s a testament to our commitment to technical excellence and reliable service delivery.
Cassy Lueneburg