Is database software licensing driving your architecture?
In a perfect world software licensing wouldn’t top your list of considerations when building and delivering the IT solutions your customers need. Architects and developers would collaborate to find the best tools for the job, use agile processes and flexible, elastic cloud architectures, and deliver solutions that meet business needs in a timely, cost-effective fashion.
Unfortunately, all too often, that idealistic approach flounders when it encounters the cold realities of software licensing. The terms of your existing licenses may limit your options for deployment, development, and consumption of your solutions, or, as noted DevOps practitioner Gene Kim recently tweeted, even where and how you hire staff.
OH: “The licensing for XYZ is so expensive, but to critical for QA, they moved some roles offshore — so that multiple people can use the same licenses, just at different times.”
— Gene Kim (@RealGeneKim) May 23, 2018
As customers migrate to cloud-based models, they may need to navigate the terms of years-old license agreements to continue their journey. The good news is there are paths around some of these obstacles, but you need to first know the issues exist and make sure your architects, consultants, developers, and other technologists know what they are and how to deal with them.
While these issues affect many classes of software – development and test tools, QA tools, and more –many of the biggest cost issues seem to center around databases.
Keep your database, optimize your CPUs
Amazon recently rolled out Optimized CPU, a new feature for EC2 virtual machines that lets you deploy an instance and disable some of the cores, or hyperthreading, while preserving the other characteristics of the instance. What’s interesting about this is that you pay the original price for the instance, meaning you get fewer virtual CPUs than you pay for … and organizations find this is attractive.
Why? Because the key metric for many software products, including large database engines such as Oracle and SQL Server, is the number of CPU cores available to the software. If your database needs large amounts of RAM for caching but doesn’t need a matching amount of processor power, it makes sense to avoid paying for licensing you don’t need.
Amazon illustrated this point in a recent blog post using the example of an Oracle Database requiring about 1TB of RAM and 16 vCPUs. The closest AWS RDS instance today is a db.x1e.8xlarge – that brings 976GB of RAM, but 32 vCPUs. If you don’t need the extra 16 processors in that instance, you don’t want to pay for them, since they can double the license costs. It makes financial sense for you to use the large instance, but disable those extra processors, even though you’re paying for vCPUs you’re not using.
Migrate the database to open source
Many customers are working to minimize the impact of database licensing on their applications by moving to an open source database platform like MySQL, Maria DB, or Postgres. These databases don’t have the same vCPU-driven costs, other than the costs of the processors themselves, and provide portability across cloud platforms.
Microsoft, Google, and AWS all have Platform as a Service (PaaS) offerings that provide MySQL and PostgreSQL compatible engines to the market. In many cases, customers can leverage these to avoid licensing concerns and take advantage of features that help them address cloud-scale use cases.
Part-time databases for Dev/Test
One trap many shops fall into is thinking they need to run their Dev/Test environment databases 24×7. When these databases were on-premises, there was little to be saved by running them only some of the time. After all, if you were running on bare metal in your data center the machines generally needed to exist, be dedicated to their workloads, and be appropriately licensed.
Today, development teams often don’t need databases running all the time. PaaS offerings give you the option of stopping the instances and using a schedule to orchestrate it. If you are using licenses provided by the cloud provider, and paying for them by the hour, you can save a significant amount of money by running those databases only when the team needs them.
For example, if you assume your development team may need a database server five days a week for 12 hours a day (to allow for varying work schedules), you only need to pay for the processor and included licensing 35 percent of the time. Of course if someone needs the environment off schedule, you can still spin it up, but the default case can save you large amounts of money.
At re:Invent 2017, AWS announced a Serverless version of the Aurora database platform for MySQL and PostgreSQL. This platform ups the ante on part-time databases by provisioning the capacity you need for your database on demand. When no one is hitting it, it spins down, and you pay for storage. As load hits it, Amazon Aurora Serverless allocates database server capacity and automatically scales the computing capacity needed to run the database for you.
When load goes away, it shrinks the capacity until it shuts down and is needed again. You’ll pay for the capacity you use but you won’t pay for processing power or RAM during periods the database isn’t running.
Don’t be limited by software licensing
Licensing can throw obstacles in the path of cloud-based models. But by following these methods of navigating around the roadblocks, you can take advantage of the best tools for the job with significant cost savings.