Scalling and right sizing of the OCI cloud services

OCI Services scaling to right-fit the performance and cost expectations

Often during project go-live the services are scaled and sized with some reserve to meet the customer expectation about stability and performance. Very often the performance tests cannot enough simulate real production load and the cloud architects tend to oversize the services which has a impact on higher costs. Also in the initial phase some migration takes place which also  requires higher compute power and throughput or storage.

The biggest advantage of cloud is that you can scale your services on the fly and one big advantage of OCI cloud is that you can dynamically allocate RAM and CPU to you compute instances. 

We will show on 2 simple usecases how can you influence and asses the right scaling .

Let us have a OCI managed Postgree SQL database, which should manage initial productive load and migration and should also absorb the initial peak of new users and orders. We tend to put more CPU and at least 32 GB RAM. After the GO-Live is successful the service should be monitored, CPU peaks, Memory allocations. What is important is to switch from onprem thinking of having reserve in compute power and rather fit the number of CPU to have peaks up to 80 %.

So this is first estimate for powerfull backend component PosgreSQL service with 2 CPU and 32 GB RAM

After Go-Live, initial load and end of development we reviewed the metrics. As we can see the CPU utilization is really low and there is no need for 2 OCPU and memory sizing can be also adapted.

 After resizing from 2 OCPU and 32GB RAM to 1xOCPU and 16GB RAM what is the smallest possible sizing we have better utilization going up to 60% and memory utilization looks also stable. Let us check what it makes to costs

 We can see savings from 221 EUR / months to 110.82 EUR a month what is a significant reduction in costs.

We face also some outages of the frontend and in the initial phase we decided to mitigate the risk by increasing the bandwidth of the load balancer. The root-cause of the outages was outside OCI cloud but we can also demonstrate the impact in costs.

Initial high bandwidth setup : 

Mid size bandwitdh load balancer

Checking the bandwidth

We decided also free tier is ok

Lesson learnt is it is never bad to size higher services in order to bring stability and performance but in the OCI cloud always monitor the usage and try to fit it to the needed scale and have the best power/cost ratio. Our lesson also showed it is always good to take oracle professional services and architects on board because they can really save you cost and consult you best fit architecture.

Contact us for you OCI cloud architecture and solution.