How to Minimize Costs in Cloud-based Microservices

If your enterprise has decided to invest in microservices, it is important to do your homework diligently. You should have an idea about the real costs as some of them may be hidden and will reveal themselves at the most inopportune moment. 

Handling microservices’ distributed architecture and scaling issues are best handled by cloud-based systems. It is also true that businesses and their development teams want to quickly deploy their products and the latest versions. For this, you would need the best QA and automation processes. However, for this to happen, products must be deployed in steps in each environment, while simultaneously maintaining the highest quality and effectiveness.

The end customers generate profits as the microservices architecture is designed for them. Because of their performance and low impact of possible failures on the system, microservices function best when they are cloud-based. When the number of services must grow, the expenses will also grow. The cloud and microservices can swallow large amounts of money, and it is difficult to save. In this blog, we attempt to highlight commonly missed aspects that can help you save hundreds of dollars when operating cloud-based microservices.

Read our blog “Microservices Architecture – Getting started with Amazon ECS”.

AWS charges on a “pay-as-you-use” basis, and you can pay only for what you use. If the development department uses 2 temporary environments at least, these costs are already known to us. However, it would be worth the while if we can cut these costs down further. AWS allows a few ways to manage costs.

Microservices costs on AWS

Optimizing costs in the production environment vary by sector and technology. Therefore this will not be discussed. However, costs can be optimized in the development and staging environments in a few ways.

One Machine Per Service

Though this is one of the first choices, it may not be right every time. At the beginning of the microservices journey and you have still not completely sure about the infrastructure yet, it is easy to get trapped. The costs can go very high and sink the entire project. In case you chose this option, you should get to know about other ways that you can implement to cut costs.

Multicontainer Environments

Beginner DevOps users are familiar with this tool. This is often discussed when launching new projects. The use of containerisation already reduces our costs by a reasonable amount. However, this solution does not guarantee the best possible outcome when it is simple. Using this option, all the services are executed in containers on an EC2 machine.

Read our blog Why have big companies like Amazon and Netflix adopted Microservices?

If all the resources of a single EC2 instance are not being used fully, this unused power of the first instance can be used to scale only a select number of services. However, this cannot be achieved using Beanstalk. Imagine having to run only a selected number of microservices, such as when running performance tests of one service. In this scenario, you will need to create another EC2 instance to run all apps using the requisite proportions. This is not cost-efficient. 

However, this function is available in Elastic Container Service (ECS). This operates like Beanstalk in a multi-container configuration, but you can achieve more. You can utilize all your leased EC2 resources by scaling each service separately and configuring auto-scaling. This will help you considerably reduce the costs to run the microservices.

Elastic Container Service

ECS is an orchestrator for Docker containers in which the services are executed. It is good for scaling and it is free and easy to use. It can be controlled using the AWS console, dedicated API, or CLI.

Download the ebook for FREE: "How to choose the best microservices vendor and trim the costs".

ECS helps us control containers, which are also called ‘Tasks’ in this context. The Tasks are a part of a ‘Service’ that manages the number of Tasks used by the service at any given moment. Each Task is defined by the resources it requires and the Docker image to be used. A ‘Cluster’ that gives us access to the machines should also be defined. ECS decides the EC2 cluster instance on which the Tasks will be launched. It does this in the best possible manner so that the resources are allocated most efficiently.

Read our blog: Microservices Authorization 8 Best Practices

Lightweight CI/CD

Many organizations migrate to microservices but may not remember to refactor the release process. The release process from the monolithic system can lead to inflated integration environments. The teams may overdo the ‘too few testing environments in the data center’ by provisioning too many environments. The ease with which testing can be done in the cloud may make the situation even worse.

Unfortunately, a large number of non-production environments do not help to increase the speed to market. Instead, the release process can become lengthy and brittle even with complete automation. 

Read our blog How Microservices will help you develop a better web application

If non-production infrastructure costs are increasing, you can reduce your total cloud costs by implementing a lightweight CD process. Given below are some suggestions:

• Shift testing to the individual service’s level or applications in isolation. A majority of defects can be spotted at service-level testing. Proper implementation of stubs and test data can ensure high test coverage.
• It is vital to reduce the number of integration testing environments, including performance integration, functional integration, staging and user acceptance.
• You should implement service mesh and smart routing between applications and microservices. The service mesh allows multiple logical “environments” to coexist safely inside the perimeter of production environments.
• You can onboard modern CD tooling such as Harness.io to streamline the CICD pipeline, enable controlled and monitored canary releases, and implement safe dark launches in the production environment.

Application Modernization

Only some companies choose to modernize their application deeply and migrate their workloads to containers or serverless computing. For some applications that include many stateful components, deploying applications directly on VMs is the only reliable choice. However, VM-based deployment brings infrastructure overheads.

Read our blog:Building Microservices Application Using Spring Boot & Cloud

Containers are used to improve resource (memory, CPU) utilization when compared to VM-based workloads (because of denser packing and larger machines). Asynchronous jobs contribute to improved efficiency by scavenging unused capacity.

Are you thinking of shifting to microservices to help your business grow? Call SayOne today!

Most cloud providers support container platforms such as Kubernetes as a service with Google GKE, Amazon EKS, and Azure AKS. The Kubernetes-based platform can support most application workloads (with only rare exceptions) and also satisfy a majority of enterprise requirements.

Even if you were to choose or not choose to host stateful components such as caches, databases, and message queues in containers, even migrating stateless applications will serve to reduce infrastructure costs. If you are not hosting stateful components in container platforms, cloud services such as Amazon DynamoDB, Amazon RDS, Amazon Kinesis, Google Spanner, Google Cloud SQL, Google Pub/Sub, Azure CosmosDB, Azure SQL, and many others may be used. 

Read our blog How to Build a Microservices Application

Advanced modernization techniques can include migration to serverless deployments using Amazon Lambdas, Azure Functions, or Google Cloud Functions. Modern cloud container runtimes such as Google Cloud Run/AWS Fargate can offer a middle ground between serverless platforms and regular Kubernetes infrastructure. Based on the use case, they may also contribute to infrastructure cost savings. The usage of cloud services, however, reduces the human costs that come with provisioning, configuration, and maintenance.

Reactive and Proactive Scalability

Reactive auto-scaling and predictive AI-based scaling are two scalability types that companies can implement to reduce cloud costs and also improve the utilization of cloud resources. Reactive autoscaling is easier to implement; however, it works for stateless applications that don’t require long start-up and warm-up times. Applications configured for auto-scaling should be designed and implemented to start and warm up quickly for the best performance.

Predictive scaling works for any application including stateful components like databases and applications that take a long time to warm up. It relies on AI and machine learning and works on the results of analysis of performance, past traffic, and utilization. It provides predictions on the infrastructure footprint required to handle upcoming surges or traffic slow-downs.

Download and read our eBook “MICROSERVICES- A Short Guide”.

A word of caution regarding scalability is that whether you choose auto-scaling or predictive scaling, a majority of cloud providers provide discounts for continuous and stable usage of CPU capacity and other cloud resources. In your case, if scalability cannot provide better savings than cloud discounts, you do not have to implement this.

On-Demand and Low-Priority Workloads

If a company can implement on-demand provisioning of low-priority workloads such as in-depth testing, reporting, batch analytics, etc., you can take advantage of both dynamic scalability and cloud discounts for continued usage of resources.

To perform service-level testing/integration testing with lightweight CICD, the CICD process can be designed to work in a way so that heavy testing will be aligned with the low production traffic. For customer-facing applications, this would mean testing in the nighttime. A majority of cloud providers allow discounts for continued usage. even when a VM is taken down and then reprovisioned with a different workload, so a company would not need to sacrifice flexibility in deployments and reusing existing provisioning and deployment automation.

Read our blog “How to Handle Failed Transactions in Microservices”.

Environments provisioned on demand can be deleted as soon as they are not needed. This shutdown can be implemented as part of a CD pipeline and implement an environment leasing system to avoid reliance on people. Each newly created on-demand environment will get a lease only when there is an explicit lease renewal from the owner. It is vital to separate the monitoring processes and set up garbage collection of cloud resources to ensure that any unused resource will get destroyed.

You can additionally save costs is to using deeply discounted cloud resources with limited SLA guarantees. Examples are spot (AWS) or preemptible (GCP) VM instances. They represent unused capacity and are much cheaper than regular VM instances. These instances can be used in jobs such as build-test automation and other batch jobs that do not respond to restarts.

All round Monitoring

To monitor cloud infrastructure, it is best to use cloud tools. To take advantage of cost monitoring, cloud resources have to be organized properly so that costs can be measured by the department, team, environment, application/microservice, etc. However, some areas require additional input which is beyond the scope of this article. 

Conclusion

Cloud migration is a challenging step for an organization. It is important to estimate cloud infrastructure costs in advance and should not feel discouraged when you get higher invoices than what you expected. The priority should be to get the applications running and avoid disruption to the business. You can then use the above strategies to optimize the cloud infrastructure footprint and reduce cloud costs.

If you want to transition from legacy software into microservices architecture, speak to our expert developers today! 

How SayOne can help in Microservices Development

At SayOne, we offer independent and stable services that have separate development aspects as well as maintenance advantages. We build microservices especially suited for individuals' businesses in different industry verticals. In the longer term, this would allow your organization/business to enjoy a sizeable increase in both growth and efficiency. We create microservices as APIs with security and the application built in. We provide SDKs that allow for the automatic creation of microservices.

Our comprehensive services in microservices development for start-ups, SMBs, and enterprises start with extensive microservices feasibility analysis to provide our clients with the best services. We use powerful frameworks for our custom-built microservices for different organizations. Our APIs are designed to enable fast iteration, easy deployment, and significantly less time to market. In short, our microservices are dexterous and resilient and deliver the security and reliability required for the different functions.