Cloud
Cloud environments for business applications, designed as simply as the requirements allow, with named access, backups, monitoring and a repeatable deployment process.
Many cloud setups grew one server at a time. Everything runs in one account under a shared login, test and production share a machine, and nobody has tried restoring a backup.
An infrastructure choice, not a destination
Cloud is treated as an infrastructure option. The design should be as simple as practical while meeting the required reliability, security, deployment and recovery needs. An existing environment may remain appropriate. Migration is not recommended merely because cloud infrastructure is available.
Separate test and production environments, tested recovery, cost attribution and particular deployment patterns are used where the application and the risk require them. They are not automatic features of every cloud project.
Typical situations
No safe place to try a change
Changes go straight to production because test and live share the same server.
The account belongs to someone who left
The person who set up the cloud account has gone, and the bill keeps arriving.
Recovery has never been exercised
Backups are scheduled, but nobody knows whether a restore works or how long it takes.
Costs nobody can explain
The monthly bill includes resources no one can identify.
What we do
Ryoss can work with existing cloud environments as well as create new ones.
Design the environment
Account and environment boundaries, compute, storage, databases and networking sized to the application.
Set up access and deployment
Named administrative access, DNS, TLS and a repeatable deployment process.
Add monitoring and recovery
Monitoring, logging, backups and a recovery procedure that has been tested.
Migrate and document
Applications and data are moved where required, with operating notes for whoever runs the environment.
What you end up with
An environment built for the application
Sized and structured for what the software needs, and no more complex than that requires.
Named access and tested recovery
Each person and service has its own account, and a restore has been exercised.
Operating notes
How the environment is built, where credentials are kept and how to recover it, written down.
How a typical engagement works
01Stocktake
Take stock
We list what is running, who has access, how deployments happen and what the application needs in reliability and recovery.
02Design
Design as simply as the requirements allow
The environment is designed around the application, with separate test and production only where the risk justifies it.
03Build
Build or migrate in stages
Changes are made in steps and tried outside production first, with a way back if something fails.
04Handover
Hand over
Monitoring, backups and operating notes are put in place, and the environment is handed to the organisation's team or run under Managed Hosting.
05Review
Review as the application changes
Costs, capacity and recovery are reviewed as the application changes.
Frequently Asked Questions
Start with a conversation
Book a free 15 minute call. Describe the problem, the systems involved and what you already know, and we will tell you plainly whether we can help and what a sensible next step looks like. There is no obligation.