You’ve gone full-blown DevOps, drank the Agile Kool-Aid, cloudified everything, and turned your monolith to microservices — so why have all of your old monolith costs turned into even bigger microservices costs? There are a few common reasons this happens, and some straightforward first steps to get microservices cost control in place.
Why Monolith to Microservices Drives Costs Up
As companies and departments adapt to modern software development processes and utilize the latest technologies, they assume they’re saving money – or forget to think about it altogether. Smaller applications and services should come with more savings opportunities, but complexity and rapidly-evolving environments can actually make the costs skyrocket. Sometimes, it’s happening right under your nose, but the costs are so hard to compile that you don’t even know it’s happening until it’s too late.
The same thing that makes microservices attractive — smaller pieces of infrastructure that can work independently from each other — can also be the main reason that costs spiral out of control. Isolated systems, with their own costs, maintenance, upgrades, and underlying architecture, can each look cheaper than the monolithic system you were running before, but can skyrocket in cost when aggregated.
How to Control Microservices Costs
If your microservices costs are already out of control, there are a few easy first steps to reining them in.
Keep It Simple
As with many new trends, there is a tendency to jump right in and switch everything to the new hotness. Having a drastic cutover, while scrapping all of your old code, can be refreshing and damaging all at the same time. It makes it hard to keep track of everything, so costs can run rampant while you and your team are struggling just to comprehend what pieces are where. By keeping some of what you already have, but slowly creating new functionality in a microservices model, you can maintain a baseline while focusing on costs and infrastructure of your new code.
The other way to keep it simple is to keep each microservice extremely limited in scope. If a microservice does just one thing, without a bunch of bells and whistles, it’s much easier to see if costs are rising and make the infrastructure match the use case. Additional opportunities for using PaaS or picking a cloud provider that fits your needs can really help maximize utilization.
Scalability and Bursting
Microservices architectures, by the very nature of their design, allow you to optimize individual pieces to minimize bottlenecks. This optimization can also include cost optimization of individual components, even to the point of having idle pieces turned completely off until they are needed. Other pieces might be on, but scaled down to the bare minimum, then rapidly scale out when demand runs high. A fluctuating architecture sounds complex, but can really help keep costs down when load is low.
User Governance
Along with a microservices architecture, you may start having certain users and departments be responsible for just a piece of the system. With that in mind, cloud providers and platform tools can help you separate users to only access the systems and infrastructure they are working on so they can focus on the operation (and costs) of that piece. This allows you to give individual users the role that is necessary for minimal access controls, while still allowing them to get their jobs done.
Ordered Start/Stop and Automation with ParkMyCloud
ParkMyCloud is all about cost control, so we’ve started putting together a cost-savings plan for our customers who are moving from monolith to microservices.
First, they should use ParkMyCloud’s Logical Groups to put multiple instances and databases into a single entity with an ordered list. This way, your users do not have to remember multiple servers to start for their application – instead, they can start one group with a single click. This can help eliminate the support tickets that are due to parts of the system not running.
Additionally, use Logical Groups to set start delays and stop delays between nodes of the group. With delays, ParkMyCloud will know to start database A, then wait 10 minutes before starting instance B, to ensure the database is up and ready to accept connections. Similarly, you can make sure other microservices are shut down before finally shutting down the database.
Everything you can do in the ParkMyCloud user interface can also be done through the ParkMyCloud REST API. This means that you can temporarily override schedules, toggle instances to turn off or on, or change team memberships programmatically. In a microservices setup, you might have certain pieces that are idle for large portions of the day. With the ParkMyCloud API, you could have those nodes turned off on a schedule to save money, then have a separate microservice call the API to turn the node on when it’s needed.
The Goal: Continuous Cost Control
Moving from monolith to microservices can be a huge factor in a successful software development practice. Don’t let cost be a limiting factor – practice continuous cost control, no matter what architecture you choose.