During migration to public cloud, use native benefits of public cloud to speed up the closing of on-premise datacenters and get first savings. Then transform more the resources and applications for additional savings.
The energy and resources needed for the production of computing resources and for the use of computing services are neither infinite nor totally renewable. The sharing model of Public Cloud helps saving resources for our planet and money for IT teams.
The hyperscale cloud providers provide financial efficiency with a far higher infrastructure usage rate and server reuse that would not be achievable with on-premises resources. In 2017, 18% of Google servers were built from refurbished parts and 6 out of 14 GCP datacenters were zero waste.
Power consumption is at least 40% lower on public cloud than most on-premises infrastructures. The standard benchmark for data center efficiency is the PUE (power usage effectiveness). This indicator is lower to 1.2 for Google or AWS, and far lower to 2.0 ratio (that is very optimistic hypothesis about their DC infrastructures). These power efficiency provides immediate cost reduction (example: PUE = 1.09 for the Belgium region of Google that is used mainly by the Digital Factory).
The points above illustrate the impossibility for a company to reach this level of efficiency in reducing the environmental impact and cost savings without fully adopting Public Cloud.
Change your habits and catch the full benefits of cloud IaaS!
On-demand purchasing model of Public Cloud platforms (e.g. AWS, GCP) gives you the capability to iterate very regularly to chase cost savings with more options than ever. You get immediate reward of your actions at the end of the month that can be tracked and measured.
Let’s focus on IaaS options first.
First you need to measure infra and app usage. Only Data matters:
- VCenter provides you memory, disk, CPU usage metrics before your migration
- Amazon CloudWatch or Google StackDriver provide the same metrics for optimisation after your migration.
But the biggest mistake when comparing numbers on a spreadsheet is assuming that your current resources are provisioned appropriately. In reality, most on-premises workloads are overprovisioned — more than 80 percent according to this research.
They were oversized for many wrong reasons (e.g. the provisioning process was painful and long, or the software vendors provides too large infra specifications). RightSizing will almost always be translated into downsizing and big savings with no performance impact.
Once the server is migrated on public cloud, rightsizing should be iterated regularly. After your migration you will notice performance per CPU is really higher than on-premises CPU (30% to 100%) as you have access to last generation CPU on public cloud.
Embrace sharing model
T3 instance family provides the best CPU/cost ratio. The mechanism is closed to VMware CPU overallocation. Anyone who had worked on VMware had to work on tweaking this option that allows to allocate more virtual CPUs than available physical CPUs. AWS has improved the technical mechanism to be sure that CPU power requested by any machine is always fulfilled. No more performance penalty for the end-users!
Server storage can now be increased on AWS at any time & with no reboot. This is why you should resize your disk during migration close to the real used storage space.
Managed services are software environments that can be used for IaaS context, with no recurring tasks to be managed by IT people (e.g. OS patching, software deployment, software patching, antivirus, upgrade, backup, replication, scalability, …)
Few options : database can be moved to Amazon RDS, load balancer can be moved to Amazon ELB, Microsoft AD can be moved to AWS Directory services.
You should turn off/on automatically your non-production and quality servers on night and weekend to get 70% savings easily (12/5 versus 24/7 usage). Even your oldest and fragile production applications that are not used on night or week-ends can now be hibernated. Memory context is stored and application state is fully retrieved after ending the hibernation as if the server has never been stopped.
Widen adoption of FinOps practices
Your application owners could be leveraged after tagging the cloud resources. Give him direct cost visibility and delegate them enough permissions to fix directly spendings’ drifts and optimize costs.
Avoid early commitment
Additional savings could be theoretically achieved with AWS Reserved instances or Google Commited usage instances. However it requires lots of time every week to make sure the reserved bounds cover the running servers (with several combinations of parameters to cross check like region, family, OS). Above all it could block the previous optimisation actions if this path is started too early.
Transform your applications!
We have strong duty to make IT sustainable by using resources when and only when we need them, thus freeing them up for other uses and businesses and benefitting from the best possible energy efficiency across datacenters.
Moving from overconsumption to lean resource usage will generate cost savings. Courage and determination are necessary to tackle application replatforming and rebuilding. In this journey serverless architecture will provide the smallest run costs ever, with 80+% cost decrease.
Auto-scaling is achievable for many legacy applications without throwing all the application code in a trash with some limited re-architecting. After removing the stateful components (all persistent data to the database layer, session data to caching layer, … ), your Java or PHP or .Net app would run smoothly on auto-scaling groups of AWS VM instances. Scaling can be triggered by any metric or scheduled. Autoscaling rules can be completely managed by AWS with new auto scaling feature that is powered by Machine Learning model to use your user data history and forecast the scaling needs.
There is another option to catch 50% to 80% discount : AWS spot instances or Google preemptible instances. Because the cloud provider does not guarantee the capacity of these spare resources, it provides big discount as a trade-off. However the likelihood to lose these AWS servers is really low — once or twice a year. (GCP preemptible instances last for up to 24 hours).
There are common scenarios that could fit well with spot instances
- Legacy applications on non-production environments : any type of Windows or Linux workloads, even stateful applications that could be hibernated if the instance is lost.
- Production environments with fleet of servers that mixes on-demand and spot instances to guarantee minimum capacity if the spot market becomes temporarily short of resources.
Licenses cost may represent 50% or more of your application billing. There are many tools that helps replacing commercial DB (Oracle, SQL Server) by open source DB (MySQL/MariaDB, PostgreSQL) with reduced impact on the application code. You can think about AWS Migration Service that includes DB conversion tool or other free tools like ora2pg. Then database infrastructure of MySQL or PostgreSQL instances could be optimized with Aurora serverless option : CPU and storage are decoupled to allow to scale from 0 CPU to thousands when you use it.
Many other serverless options could be considered for quick wins.
Web Application firewall may not sit on servers as mature serverless options exists like Amazon WAF. It provides custom rules that are built and managed by IT team or rules that are fully managed by security experts (F5, Fortinet, Imperva, TrendMicro, …) on your behalf.
Another illustration are bastion servers that could be replaced by serverless options (like AWS session manager for Windows/Linux instances or Google Identity Aware Proxy with proxy tunneling for managing Linux instances).
Also data warehouses sit on big servers that are always idle or underused. Data project support data lake architecture that ends the abusive waste of resources.
Finally rebuilding the application with serverless services will give the best ROI ratio. 99% of applications will see cost sharp decrease (10 times cheaper or more) except if you have to run Netflix-scaled applications.
Rehosting, replatforming, rebuilding, and replacing applications on Public Cloud will be part of any move to public cloud journey. This journey has great environmental impact for the sake of the common good.