As a managed service company, we see our customers and partners shifting their workloads to the cloud. There are various reasons for this decision, but the most important ones are cost and agility. Once on a cloud, the infrastructure team has great power, but often it is not used wisely enough. Talking with developers and the business is more important than ever for better decisions.
As an Oracle Applications Database engineer, here is my perspective. For EBS systems in the cloud, there is usually one primary working environment (production) and a disaster recovery site, which is an exact copy. On top of that, there is at least one or more test environments. Let’s talk about them specifically.
A typical test environment usually only has a few active users. For example, in a stable system, the DBA team does quarterly security patching and the testing team performs acceptance testing. At the same time, a growing business may be involved in active development, having multiple project teams working on a separate development instance. In any of these cases, the majority of the environment usage is one or a few groups working in the same time zone. 24/7 typical user volumes are rare. So why do we need to keep instances running and burn resources while not in use?
I’ve heard counterarguments like “it is too complicated to start EBS services” or “let’s keep it up as we never know who needs it“, etc. But these are excuses, and with properly established communication between parties, all these issues can be resolved.
Example
For demonstration purposes, let’s use the AWS pricing calculator and scope out two 8 VCPU/32GB machines (m5.2xlarge) serving the Oracle EBS workload.
Instance: Operating system (Linux), Quantity (2), Pricing strategy (On-Demand Instances), Storage amount (30 GB), Instance type (m5.2xlarge), General Purpose SSD (gp3) – IOPS (3000), General Purpose SSD (gp3) – Throughput (125 MBps)
The first line represents the two machines (application and database) running 24/7 (always on). The second line represents the same machines running from Monday through Friday for 12 hours each day (typically from 7 AM till 7 PM). Based on the example mentioned, this is $350/environment/month in savings. For three non-production environments per year that’s over $12,000.
Solutions
All the above sounds nice, but it is not a silver bullet. Once all parties come to an agreement to turn off dev/test instances through unused time slots, it is time for action.
- Start/Stop scripts – the essential item to set. In the Oracle EBS world, it is a bit complicated as the application depends on a database, and multiple components depend on each other.
- Monitoring – blackout management, if in use, to avoid unnecessarily paging. Otherwise, cost savings for infrastructure will be eaten by the managed services team dealing with tickets.
- Automation – how to automate those test/dev environment downtimes. The best approach can be using built-in cloud features such as AWS system manager. Ashish (a colleague of mine) recently posted an excellent article about how it can be used for cloning automation. A similar approach can be used in this scenario too. Or use an existing “bastion” host to control the automation scenarios (cron scripts, Ansible, and/or awscli).
Remember to always have an option to override off-cycles. For example, if there is a major issue and the team needs to debug or test in a lower test instance. In that case, how to communicate or initiate environment startup procedures should be crystal clear. It sounds simple and self-explanatory, but I have seen many incidents when a lack of communication hinders resolving critical issues quickly.
Conclusion
Being on the cloud infrastructure unlocks opportunities to be genuinely flexible. It is worth reviewing procedures and standards implemented in the organization. Think about the given options and ask whether it is still relevant today. Yes, adopting the cloud features and opportunities may require a learning curve, but it is truly worth it. At Pythian, we’ve been in the cloud game for a while now, so tell us how we can help you!
