Controlling cost in the cloudAdoption of Cloud computing is continually growing and so are the costs to the enterprise but without good guidance, controlling cost is difficult or impossible for more organizations. In a recent survey by Flexera, controlling cost was the number one challenge identified by nearly everyone using the cloud. I am going to give you some places to identify where you might be spending too much, some ways of improving your efficiency today, and some ideas of what you might want to be doing in the future.
Cloud adoption is on the rise for all enterprises with all cloud vendorsGartner reports that worldwide cloud services grew over 37% in 2019. AWS is the largest cloud vendor with around 45% of the total market and Azure is second at nearly 18% but steadily gaining market share (over 57% growth from 2018 to 2019). Alibaba is third with about 1/2 the market share of Azure, then Google capturing a little over 5% but both are seeing impressive growth between 2018 to 2019. There are many other players, but they start to fall into niche categories. And adoption of cloud resource may be accelerated by Covid-19 with respondents to the Flexera survey saying that 60% of their usage was higher than expected.
Most enterprises have a hybrid approach to the cloud. A mix of public and private cloud is common with most companies maintaining some resources on-premises or in a data center while migrating some workloads to the cloud. Many companies try several cloud vendors when starting their journey but very few companies adopt a multiple public cloud approach in the end (> 5%).
The challengeMany organizations see their spend on public cloud infrastructure rising over the next 12 months with some estimates see this growth as much as 47% from the previous year. Yet often the budget for cloud resources exceeds expectations. On average this spend can be 25% or more over budget. And respondents to a recent survey say close to 1/3rd of this is identified as wasted spend. How does an enterprise then migrate more workloads to the cloud while staying with budget and minimizing waste?
First, it’s ok to have these problems, it is hard to know the full cost of cloud adoption up front. And while each vendor has tools for cost planning, these tools are hard to understand and hard to use. Microsoft has a whole course and certification on how to use their cost planning tool. And post-spend cost analysis tools from each vendor can tell you where you are spending your money but not often why. And without proper planning these cost analysis tools don’t help you trace the spend back to the deployments that initiated the problems.
Keep in mind that what is often the simplest path to adoption is not the cheapest. Moving VMs to the cloud is one of the most attractive and easy ways of migration but is one of the most expensive ways to run a workload in the cloud. Migrating your data to the cloud can eat up budget without proper curation because we all know that your data size only grows over time and some enterprises end up being data hoarders. Also, the cost of networking can be opaque and end up with unintentional spend. Some simple and easily overlooked configurations can end up bleeding costs over the long term.
Everyone is responsible for controlling cost in the cloud. Managers own the budget, Architects own the design, and developers own the implementation. These three groups need to work together so no one is surprised. And this is not a one-time event, it is a process that should be refined over time.
There are things you can do to address these problems:
- Make sure your spend on compute resources are right sized and using the right technology
- Take advantage of the different storage options for your data
- Ensure you understand your network topology
- Stop deploying your workloads by hand
- A little planning up front by dividend over the long term
Using Compute more effectivelyMigrating VMs to the cloud is made simple by every vendor but this is often the most expensive proposition.
There are a few easy things everyone will tell you to do like right sizing your machines, AWS and Azure both have reserved instance pricing which is a good cost savings if you know you will run your VMs for a long time. Turning off virtual machines when not in use is a good practice, if you can remember to do it or if you can schedule it. Did you know that your Microsoft licenses for your Windows Server and some applications extend to workloads run in the cloud? Did you know you might be paying twice for your Windows licensees? These virtual machine optimizations take little effort, and you might not need to engage a smart system’s integrator like MILL5 to start seeing benefit.
Containers are the new VMs (but they are not VMs)Consider moving to higher density compute resources like containers to further reduce your spend. Migration from server VMs to containers take some effort from your developers and will change your deployment but this can pay dividend over time. Linux containers are inexpensive and scale very well but not every server workload runs on Linux and even the ones that can, might introduce subtle bugs if you don’t know what to look for during migration. Windows containers can fill a gap in your containerization journey, but they introduce other issues, complexity, and don’t offer the same cost benefit as Linux based containers. And containers are not little VMs and treating them as such is missing the point of containerization, so some education is required.
Take advantage of your vendor’s PaaSIdeally Platform-as-a-Service (PaaS) can be very efficient but take significant design and development effort. Offerings like on-demand containers for tasks that run to completion then turn off are useful and can further optimize your containerization efforts. Server-less compute services of AWS Lambda, Azure Functions or Google Cloud Functions are scalable pay-as-you-go services to run your code with zero server management. Service buses, event grids, and streaming analytics are available for these cloud vendors that can further reduce your VM infrastructure. There is often no lift and shift into these technologies so will have to design and plan to use these services, but this investment can be the most efficient use of your vendors cloud resources.
Consuming Storage smartlyData has gravity and your compute needs to be close to your data but choosing the right data storage and access can make the difference between efficient spend and uncontrolled waste. Considering data always grows over time managing your cloud data and access technology is a pillar of a good cloud adoption plan. The first place to optimize is to move from your VM hosted SQL Database to Cloud hosted instances of your SQL Databases. Sometimes these hosted versions don’t have the same feature parity as your on-premises instances, but you should weigh the cost of migration against the cost of the feature you are using. Migrating to an open-source database such as PostgreSQL from SQL Server or Oracle can provide better cost effectiveness but will require investment in training and development.
There are many NoSQL/non-relational storage options that provide cost effective solutions for accessing large datasets. Storage in the cloud is cheaper than compute and by removing the SQL engine, data access becomes cheaper. These NoSQL options will require architecture and development effort to adopt so they are often not simple ports. But you can use these NoSQL/non-relational options in conjunction with relational databases and migrate over time.
Efficient Networking is not an accidentCloud networking is often overlooked and can be a hidden cost in cloud deployments. In a hybrid scenario where your compute is in the cloud and your data is on-premises, the cost of network access could skew any cost efficiency if you are not careful. VPNs and public networking are metered services so monitoring and optimizing your network is key to a good cloud deployment. You should also be aware of the cost of networking between different regions and availability zones. You are not charged for traffic between machines/services in the same region, but you will be when it crosses these regions. Understanding to cost of networking can shape different deployment scenarios. And if you are not careful, traffic between regions even inside of the same vendor might end up routed over the public internet rather than the vendors networking backplane, costing you double.
Adopting DevOpsIf you are deploying your workloads or creating your services though a cloud vendors portal, please stop. This might be convenient when doing a proof of concept but is an awful practice to continue. Having a DevOps practice might have been a luxury before, but it is key to a successful cloud adoption now. DevOps allows you to quickly deploy, re-deploy, or delete cloud services. Treating your deployments as code means you have repeatability process that you can optimize over time. DevOps is also the easiest way of adding metadata to your deployments. This metadata is useful in decoding where you spend your money. Tagging each application and each deployment with appropriate metadata can make it easy to trace back unexpected expenses. Without this traceability, you might be guessing at where the money went.
Cloud Architecture is differentIf you are born in the cloud, this is not new to you. But for those who have had the cloud thrust upon them this could seem daunting. Designing your applications for the cloud is different. There are lots of options not available to you on-premises. New technologies and techniques can change your lift-and-shift application to cost less and scale better. Consuming the Platform-as-a-Service offerings from your cloud vendor is where you can save the most since these are shared resources but are pay-as-you-use services. Engaging a great cloud architect from the start can save money and improve performance.
To sum it all upMake sure you are using your compute, storage and networking efficiently.
Investing in redesigning your applications to take advantage of the cloud can pay dividends.
Leveraging DevOps and Cloud architecture can be the difference between good and great cloud adoption.