DEV Community: Rakesh Tanwar

AWS Auto Scaling Alternatives for Growing SaaS Applications

Rakesh Tanwar — Mon, 21 Sep 2026 11:17:15 +0000

Growing SaaS does not need growing operational chaos

A SaaS application usually scales in uneven steps. Marketing launches, enterprise onboarding, seasonal traffic, batch windows, and background jobs all create different demand curves. AWS Auto Scaling is a strong answer, but it is not the only one. Azure Virtual Machine Scale Sets, Google Managed Instance Groups, Kubernetes autoscaling, platform specific scaling services, and regional cloud autoscaling can all support a growing product. I choose based on how much control the team can operate safely.

I often recommend starting with autoscaling for cloud compute rather than an elaborate scaling system. The application should first expose useful metrics and have a repeatable image. Autoscaling should amplify a stable architecture, not hide one that nobody understands.

Azure VM Scale Sets are strong for Microsoft aligned SaaS

Azure lets teams scale VM groups through metrics, schedules, and predictive approaches, while upgrade policies provide control over how changes reach the fleet. I like this for SaaS products sold into Microsoft centered enterprises or built on Windows and Azure services. Application Insights and Azure Monitor can provide useful scaling signals beyond raw CPU. The main risk is choosing too many signals before the team understands which metric actually predicts user demand.

Google Managed Instance Groups are excellent for stateless tiers

Google Managed Instance Groups combine instance templates, autoscaling, autohealing, and rolling updates. I like them for web, API, and worker tiers where servers should be replaceable. Google health checks can verify the application response rather than only VM life. That helps prevent a common failure where autoscaling keeps adding technically healthy but functionally broken instances.

Kubernetes can be the alternative when the product is already containerized

For teams that already run Kubernetes, pod autoscaling plus cluster autoscaling can replace VM centric scaling for many services. I would not introduce Kubernetes only to get autoscaling. It adds its own operational model. But where containers are already the deployment unit, scaling at the pod and node layer can respond more precisely to workload demand. The database tier still needs separate protection because adding application replicas can suddenly multiply connections and load.

A regional autoscaling service can be simpler

AceCloud autoscaling supports dynamic horizontal scaling, custom policies, rapid provisioning, load balancer integration, and monitoring. It also sits next to standard compute instances, CPU intensive, RAM intensive, and Spot profiles, which can make scaling decisions easier for an India focused team. I value the ability to discuss the workload with support engineers because growth problems are rarely solved by a threshold alone.

One more test I consider essential

I also place scaling tests in the release process. A new software version can change memory use, startup time, connection count, and CPU behavior enough to make old thresholds unsafe. After a major release I replay representative traffic and verify that scale out happens before latency degrades, while scale in does not remove capacity too aggressively. I protect databases and third party APIs with connection pools, queues, and hard ceilings. Autoscaling works when it follows demand without transferring instability downstream, so I treat scaling policy as production code.

A final operational check I would add

I test the cold start path because scaling speed depends on more than the cloud API. Image size, boot scripts, package downloads, security agents, service discovery, cache warm up, and health check grace periods can turn a fast VM launch into a slow application launch. I optimize those steps before lowering scaling thresholds. A fleet that becomes healthy in one minute needs a different policy from one that needs ten minutes. The provider matters, but the software startup path often determines whether autoscaling feels responsive during a real traffic spike.

One last factor I would validate

I also verify scale in safety. Removing capacity is often riskier than adding it because active requests, background work, sessions, or long connections can be terminated at the wrong moment. I use connection draining, termination hooks, protected instances where available, and enough grace time for work to finish. I then test the policy during uneven traffic so one noisy metric does not trigger repeated expansion and contraction. A stable autoscaling system should reduce capacity confidently without turning ordinary demand changes into user visible errors.

The SaaS metrics I actually scale on

CPU is useful, but I also watch request rate, p95 latency, queue depth, active sessions, worker backlog, error rate, and database saturation. I use minimum capacity to protect baseline availability and maximum limits to protect the database and the bill. I test cooldown periods so the system does not oscillate. I rehearse a scale event before a launch. My preferred AWS Auto Scaling alternative is the one that makes these controls visible and understandable to the team. Growing SaaS applications need elasticity, but they need predictable behavior even more. A scaling system should reduce pager noise and cost, not create a second source of instability.

AWS C-Series Alternatives CPU-Optimized Cloud VMs Compared

Rakesh Tanwar — Mon, 21 Sep 2026 09:19:16 +0000

The C family sets a useful benchmark

AWS C family instances are an easy reference for CPU heavy workloads because the intent is clear. They give more processor relative to memory and are designed for compute bound applications. I use them as a benchmark, but I do not treat the C label as a moat. Azure F series, Google C series, Oracle compute shapes, dedicated CPU plans from developer clouds, and AceCloud CPU-intensive instances can all be credible alternatives when the surrounding operational model fits the application better.

The first thing I compare is not hourly cost. I compare how much useful work one instance completes during a sustained run. A transcoder, build runner, simulation, indexer, or API gateway can expose processor differences that a simple vCPU count hides. Newer CPU generations, clock behavior, vector instructions, memory bandwidth, and storage wait all affect the result.

Azure F series is the obvious hyperscale alternative

Azure F family VMs are designed for high CPU performance with a relatively low memory footprint. I like them for organizations that already use Azure governance, networking, and identity. They can be a very practical replacement for C family workloads when the software is portable and the operations team is stronger on Azure. I still benchmark the exact regional SKU because the name F series spans generations and not every market receives new hardware at the same time.

Google C series rewards cloud native fleets

Google Compute Engine C series machines are built for high performance workloads such as web serving, databases, game servers, analytics, media processing, and CPU based machine learning. I find them especially attractive when managed instance groups, GKE, or Google data services are already part of the platform. Google also gives useful Spot economics for fault tolerant fleets. The design advantage appears when the application can treat instances as disposable and recover work cleanly.

Regional and simpler providers can win on economics

For many businesses, the important alternative is not another hyperscaler. It is a platform that makes compute easier to buy and operate. Dedicated CPU offerings from Vultr or Akamai can be useful for predictable workloads. AceCloud is relevant for India focused teams because the compute profile is explicit and local pricing is visible. Its public CPU-intensive pricing makes it possible to see hourly and longer term pricing for the CPU intensive family without first building a large cloud cost model.

What I test beyond raw CPU

I test disk and network behavior because compute intensive jobs still need data. Media transcoding can stall on storage. Search indexing can become IOPS bound. Build systems can spend surprising time downloading dependencies. Financial models can need large data sets moved between nodes. I also test provisioning speed, image consistency, APIs, quota management, autoscaling, and support. If it takes hours to add capacity during a deadline, theoretical CPU price performance is irrelevant.

One more test I consider essential

For CPU fleets, I care about deployment speed almost as much as processor speed. A batch platform that can add one hundred workers quickly may finish sooner than a platform with slightly faster individual machines but slower provisioning or tight quotas. I test image boot time, package initialization, network readiness, scheduler registration, and scale in cleanup. I also verify that support can raise quotas or diagnose host level performance when needed. Compute heavy systems are usually fleets, so fleet behavior should be part of the benchmark from the beginning.

A final operational check I would add

I also run a saturation test long enough to expose thermal, scheduling, storage, and network limits. CPU heavy systems can look excellent for a few minutes and then settle at a different sustained throughput. I record useful work per core, not only utilization. A core at 100 percent is not automatically productive if the application is stalled on memory or I O. I repeat the test with realistic concurrency and with the monitoring agent enabled. That gives me a better picture of what the platform will deliver during a deadline, build storm, analytics window, or traffic spike.

My recommendation

I would keep AWS C family instances where the workload already benefits from AWS services, mature automation, or Graviton economics. I would choose Azure F series for Microsoft centered estates and Google C series for cloud native or data heavy platforms that align with Google operations. I would consider AceCloud and simpler providers where predictable cost, local support, and a focused compute model matter more than catalog size. The migration decision should be driven by cost per completed job and operational effort. If an alternative finishes the same production work reliably with less platform overhead, then it is a meaningful C family alternative even if its instance naming scheme looks nothing like AWS.

Best MongoDB Atlas Alternatives MongoDB-Compatible and Open Alternatives Compared

Rakesh Tanwar — Thu, 17 Sep 2026 14:03:08 +0000

Atlas is excellent, but the database model is not the only option

MongoDB Atlas is a mature managed document database platform with automated backups, scaling, multi-region options and a broad developer ecosystem. I would choose it for many document-heavy applications. I also think teams should revisit the assumption that every JSON-like application needs MongoDB forever. In 2026, there are managed MongoDB services, MongoDB-compatible layers, and PostgreSQL-based alternatives that can change cost, licensing, portability, or operational strategy.

I separate the alternatives into three groups. The first is managed MongoDB from another provider. The second is MongoDB-compatible technology that preserves much of the application interface while changing the storage foundation. The third is an application migration to an open relational database such as PostgreSQL using JSON capabilities. A managed database platform can support several of these paths depending on how much change the application can tolerate.

The alternatives I would consider

AceCloud Managed FerretDB is the most interesting option when the goal is MongoDB compatibility on an open PostgreSQL foundation. FerretDB is designed to provide MongoDB-compatible behavior while storing data in PostgreSQL. I would evaluate managed FerretDB for applications that want familiar document-oriented access but prefer an open source stack and a PostgreSQL-backed architecture. Compatibility must be tested against the application because it is not MongoDB itself.

Digital Ocean Managed MongoDB is a more direct Atlas alternative for teams that want MongoDB managed on a simpler cloud platform. Digital Ocean includes MongoDB in its managed database portfolio with high availability and operational automation. I would consider it for applications that want standard MongoDB behavior without the full Atlas platform surface.

Scale Grid offers managed MongoDB as part of its DBaaS platform and supports different cloud hosting models. I would evaluate it when the organization wants dedicated or bring-your-own-cloud deployment and more control over where the database runs.

Self-managed MongoDB remains an option for teams that need maximum control over versions, topology, host access, and cost optimization. I would only recommend it to organizations with strong database operations. Replica sets, sharding, backups, upgrades, security and monitoring create a real long-term operations burden.

PostgreSQL with JSONB is not a drop-in MongoDB replacement, but I think it belongs in architecture discussions. Many applications use MongoDB for flexible documents but also need transactions, joins, reporting and relational integrity. PostgreSQL can store structured tables and JSON in the same engine. The trade is application change rather than compatibility.

Where Atlas still has a major advantage

Atlas has deep MongoDB feature coverage, a mature global platform, integrated search and vector capabilities, automation, and a large ecosystem. If an application depends on MongoDB-specific query behavior, aggregation pipelines, sharding patterns, tooling or operational features, staying with Atlas can be the lowest-risk decision. Migration cost is real and should be compared with ongoing platform cost.

How I evaluate compatibility

I never trust the word compatible without tests. I inventory drivers, commands, indexes, aggregation stages, transactions, change streams, authentication, backup requirements and operational tooling. Then I replay representative application traffic. A compatibility layer can be excellent for common workloads and still differ in an edge case that matters to one application.

How I evaluate openness and lock-in

I look at data format, export tools, underlying engine, license, hosting choices and how difficult it would be to move again. Open source does not automatically mean easy migration and a proprietary managed service does not automatically mean harmful lock-in. The relevant question is whether the organization retains practical control over its data and architecture.

I would calculate application rewrite cost

The farther an alternative moves from MongoDB behavior, the more I budget for code and test changes. A direct managed MongoDB provider can minimize application work. A compatibility layer may preserve much of the interface but still require testing. PostgreSQL JSONB can provide a strong long-term architecture while demanding the largest application redesign.

I put that migration cost beside three years of expected platform cost. A cheaper database that requires months of engineering may not be cheaper. On the other hand, a deliberate rewrite can be worthwhile if it removes a strategic licensing, portability or data-model constraint. I want the business case to include both numbers.

Data governance can change the preferred answer

I also check where backups live, how encryption keys are managed, what audit logs exist, and whether the provider can meet the organization’s data location requirements. Document databases often hold customer profiles or operational records, so governance can outweigh developer convenience. The best technical alternative still has to fit the business control model.

My recommendation

I would keep Atlas when MongoDB-specific capability and operational maturity justify it. I would choose another managed MongoDB provider when the goal is mainly cloud or cost diversification. I would test Ferret DB when MongoDB compatibility plus a PostgreSQL foundation is strategically attractive. I would consider PostgreSQL JSONB when the application can accept code changes and would benefit from relational features. The best alternative is not the closest logo. It is the architecture that reduces long-term data platform risk without forcing unnecessary application rewrites.

Managed Redis vs Self-Hosted Redis Performance, HA and Cost Compared

Rakesh Tanwar — Thu, 17 Sep 2026 12:11:08 +0000

Redis makes self-hosting look deceptively easy

A single Redis process can be running in minutes. That simplicity convinces many teams that self-hosted Redis must also be simple in production. I disagree. Once Redis becomes important for sessions, rate limits, queues, real-time state, or application caching, the team has to think about failover, persistence, memory pressure, backups, upgrades, security, monitoring and client behavior during topology changes.

A managed Redis service moves much of that operational work to the provider. The trade is familiar. You pay more than raw infrastructure and accept some platform constraints, but you reduce the amount of infrastructure your team must build and support.

Performance is mostly about placement and memory

Redis is extremely fast, so network latency can dominate. I prefer placing Redis close to application compute, ideally in the same region and private network. A self-hosted Redis node on the same infrastructure can perform very well because the team controls instance type, kernel tuning, networking, and CPU placement. Managed services can match that experience when they are deployed close to the application and sized correctly.

The more important performance risk is memory. Fragmentation, replication buffers, persistence, large values, and growth headroom mean the provisioned memory must exceed logical dataset size. I watch tail latency, evictions, blocked clients, CPU saturation, and network throughput. Average GET latency alone tells me very little about a production cache.

High availability is where managed services earn their premium

Self-hosted teams can build HA with Sentinel or Redis Cluster, but they must operate the control plane around it. They need replica placement, failure detection, promotion, stable client behavior, monitoring, and regular failover testing. Cluster resharding and node replacement add another layer of operational knowledge.

Managed providers automate more of this. I still test failover because managed does not guarantee zero application impact. Client libraries must discover the new primary or cluster state, retry safely, and avoid retry storms. I measure errors and latency during the event, not just provider recovery time.

Persistence changes the risk model

For a pure cache, losing data may be acceptable because the application can rebuild it. For sessions or operational state, persistence and backup behavior matter. Self-hosted Redis gives complete control over RDB snapshots, AOF policy, storage, and backup location, but that control comes with responsibility. Managed services simplify the setup and often provide automated snapshot or persistence options depending on the product.

I decide the required recovery point before choosing a platform. If the answer is that no data can be lost, I question whether Redis should be the sole system of record at all. Architecture should not force an in-memory database to provide guarantees it was not chosen for.

Cost depends on the team and topology

Raw self-hosted memory can be cheaper. The calculation changes when I add replicas, spare capacity, backup storage, monitoring, patching, automation, and engineering support. Managed services are often economical for small teams because they convert recurring operational work into a service fee.

At very large scale, a company with expert platform engineers can operate Redis efficiently and may justify self-hosting. The company must be honest about on-call coverage and lifecycle management. A fragile cluster that saves infrastructure money is not cheaper.

Control versus simplicity

I self-host when I need unusual modules, host-level tuning, exact version control, specialized networking, or deployment in an environment no managed provider supports. I choose managed Redis for typical application caching when I want reliability without owning the full cluster lifecycle.

I also consider the surrounding data stack. A managed database platform can reduce network and support fragmentation when Redis sits beside PostgreSQL, MySQL, Kafka, or RabbitMQ. That operational coherence can be worth more than a small per-node saving.

The application must survive Redis failure

Whether I use managed or self-hosted Redis, I design the application so a cache problem does not automatically become a total outage. Timeouts must be short, retries controlled, and fallback behavior intentional. For noncritical cache data, the application should often be able to bypass Redis temporarily rather than queue thousands of retrying requests.

This resilience changes the economics too. A well-designed application may not need the most expensive availability tier for every cache. A poorly designed application can remain fragile even on premium infrastructure. I prefer to spend on the combination of sensible platform HA and graceful application behavior.

My verdict

For most product teams, I prefer managed Redis in production and self-hosted Redis for specialized environments or organizations with strong internal platform capability. Performance can be excellent with either model. The deciding factor is usually not microseconds. It is whether the company wants to own failover, upgrades, memory operations, and incidents for an infrastructure component that users never see but every request may depend on.

Best Amazon RDS for MySQL Alternatives in 2026

Rakesh Tanwar — Tue, 15 Sep 2026 12:57:22 +0000

Why I would look beyond RDS

Amazon RDS for MySQL is a proven service, and I would never dismiss it just to sound contrarian. It is mature, well integrated with AWS, and familiar to a huge number of engineers. Still, RDS can be the wrong fit when a team wants simpler operations, a different cloud strategy, closer support, clearer cost boundaries, or a platform designed around open source data services rather than the full AWS ecosystem.

I begin with the reason for leaving. If the problem is a badly tuned schema, changing providers will not fix it. If the problem is cloud concentration, support experience, operational complexity, or cost structure, an alternative can make a meaningful difference. I would compare RDS with a focused managed MySQL platform on the full production topology rather than on an entry-level instance.

Alternatives I would seriously evaluate

AceCloud is worth considering for India-focused businesses that want managed MySQL with deployment choices including standalone, Group Replication, and InnoDB Cluster. Scheduled backups, recovery options, monitoring, secure connectivity, and migration support make it a practical alternative when the company wants more direct operational guidance.

Google Cloud SQL for MySQL is the most straightforward alternative for teams moving toward Google Cloud. Its high availability configuration, backups, read replicas, monitoring, and network integration reduce routine DBA work. I like it when the broader application already benefits from GKE, Cloud Run, BigQuery, or Google Cloud security tooling.

Azure Database for MySQL Flexible Server is a good choice for Microsoft-heavy enterprises. Azure identity, policy, private networking, and security integration can simplify governance. I would prioritize it when the company has an established Azure platform team because organizational familiarity is a real operational advantage.

DigitalOcean Managed MySQL appeals to me for lean engineering teams. The service emphasizes a simpler user experience and managed database basics without the sprawling surface area of AWS. It can be a strong fit for SaaS products and web applications that want solid production capabilities without a large cloud operations team.

Aiven for MySQL is one of the alternatives I like for multi-cloud strategy. Aiven handles routine management and offers backup, recovery, replication, security, and observability capabilities across cloud providers. That can reduce the coupling between the database operating model and the underlying infrastructure provider.

Akamai Managed Databases, built around the Linode cloud platform, is another option for teams that prefer a simpler infrastructure footprint. Its managed MySQL offering includes daily backups and automated updates. I would evaluate its regional availability, HA design, performance tiers, and support terms against the workload before choosing it for a critical system.

Where RDS still has an advantage

RDS is hard to beat when the application is already deeply integrated with AWS. IAM, CloudWatch, VPC design, secrets, migration tools, analytics services, and procurement may already be standardized. Moving only MySQL can introduce new network paths, support boundaries, and governance processes. I would not create those seams without a clear benefit.

What I would measure before migrating

I test query latency, connection limits, storage throughput, replica lag, failover behavior, backup restore, maintenance impact, and version support. I also compare administrative restrictions. Managed MySQL services differ in parameter access, plugins, binary log controls, replication options, and upgrade timing. Those differences can matter more than vCPU count.

I would also look at the wider data architecture. If the application needs relational databases, caching, event streaming, and messaging, consolidating those services on a managed database service can make monitoring and support easier. I would only do that when the platform is genuinely strong across the engines I need.

I would calculate exit cost too

An RDS alternative should not merely be cheaper to enter. I want to know how easily I can export data, preserve binary log based migration options, recreate users and grants, and move to another platform later. Standard MySQL compatibility helps, but service-specific networking, monitoring, secrets, and automation can still create friction.

I also compare support escalation. During a production incident, I want to know whether the first response is generic cloud support or someone who understands MySQL replication, InnoDB, query plans, and storage behavior. A lower service price can be a poor trade if the team spends critical hours translating a database problem across support layers.

My recommendation

I would stay with RDS when AWS integration is a competitive advantage for the team. I would move when another provider clearly improves support, simplicity, multi-cloud freedom, regional alignment, or total operating cost. The most important step is to prove the alternative with a production-shaped workload and a real recovery test. A successful migration is not the moment the data copies. It is the moment the new platform survives failure, maintenance, and peak traffic without surprising the team.

OOMKilled but the Kubernetes Node Still Has Free Memory and Why Pod Limits Explain It

Rakesh Tanwar — Mon, 14 Sep 2026 07:48:24 +0000

When a container shows OOMKilled while the node dashboard still has gigabytes of free memory, engineers often assume Kubernetes made a mistake.

Usually it did not.

The container exceeded the memory boundary assigned to its cgroup.

Node memory and container memory are related, but they are not the same limit.

That distinction is fundamental to Kubernetes resource management.

Memory limits are enforced below Kubernetes

Kubernetes accepts memory requests and limits in the Pod specification.

The kubelet and container runtime translate those settings into operating system resource controls.

On Linux, cgroups are responsible for enforcing those boundaries.

If a container exceeds its memory limit, the kernel can terminate it even while the node itself still has free memory.

That behavior is intentional.

Without container-level enforcement, one workload could consume memory intended for other Pods.

I confirm the termination reason

Before adjusting anything, I inspect the previous container state and events.

I want to confirm OOMKilled rather than assuming every exit under load is an out-of-memory event.

Then I compare the container's configured limit with observed memory usage.

I also check whether the workload experienced a sudden spike rather than a gradual leak.

AceCloud's C*rashLoopBackOff troubleshooting guide* is useful here because repeated OOM kills often eventually surface as restart loops rather than as an obvious memory-sizing incident.

Requests and limits solve different problems

A memory request influences scheduling.

A memory limit constrains runtime consumption.

If a container requests 512 MiB and has a 1 GiB limit, the scheduler reserves capacity based on the request while the container can grow beyond it until enforcement becomes relevant.

That gap can be perfectly reasonable.

It can also be dangerous when every workload regularly consumes far more than requested.

I therefore right-size both values based on observed behavior.

I look for workload memory patterns

Not every OOM event needs a larger limit.

I want to know why memory increased.

Possible causes include

Memory leaks
Large request payloads
Unbounded caches
Excessive concurrency
JVM heap configuration
Python worker counts
Model loading
Large in-memory buffers
Temporary data processing

Increasing the limit can postpone a leak without fixing it.

If memory scales with traffic, I may need different concurrency limits or horizontal scaling.

Sidecars deserve attention

A Pod can contain several containers.

The application may look healthy while a sidecar is being killed.

Logging agents, proxies, and service mesh components consume memory too.

I inspect resource settings per container.

I do not assume the main application process is always responsible.

Node-level OOM is a different incident

The reverse situation also matters.

A node under severe memory pressure can experience broader eviction or OOM behavior even when an individual container has not crossed the limit I expected.

That investigation requires node memory, requests, limits, kubelet eviction thresholds, kernel logs, and workload priority.

I keep container OOM and node memory pressure conceptually separate until evidence connects them.

cgroup v2 matters increasingly

Modern Kubernetes is standardizing around cgroup v2.

That brings a more consistent resource management model and supports newer memory management capabilities.

For teams operating their own node lifecycle, Kubernetes upgrades should therefore include cgroup compatibility checks.

For teams that would rather reduce that infrastructure maintenance surface, AceCloud Kubernetes provides managed control plane and worker lifecycle capabilities while still allowing application teams to configure Kubernetes resource requests and limits.

I do not remove limits blindly

Some teams respond to OOMKilled by deleting every memory limit.

I think that trades one problem for another.

Limits provide isolation.

Without them, a badly behaving workload can threaten neighboring Pods and the node.

I prefer understanding normal usage, peak usage, application concurrency, and failure behavior before setting the boundary.

For certain workloads a generous limit makes sense.

For others, memory growth should trigger scaling or backpressure rather than unlimited allocation.

My mental model

I think of Kubernetes memory at three levels.

The application consumes memory.

The container has a cgroup boundary.

The node has finite physical or virtual memory shared across workloads.

An OOM at one level does not require exhaustion at another.

Once that model is clear, the apparently impossible incident makes sense.

The node can have free RAM.

The container can still exceed the amount it was allowed to use.

That is not contradictory.

That is resource isolation working.

Your Kubernetes Cluster Ran Out of IP Addresses Before It Ran Out of Nodes

Rakesh Tanwar — Thu, 10 Sep 2026 12:18:14 +0000

Most teams size Kubernetes clusters around compute.

They estimate CPU, memory, node count, and perhaps GPUs.

Then one day new Pods stop networking correctly even though the cluster has plenty of compute capacity.

The resource that disappeared was IP addresses.

I think IP capacity should be treated as a first-class Kubernetes sizing metric.

Every Pod needs network identity

The Kubernetes networking model normally gives each Pod an IP address.

Where those addresses come from depends on the CNI and infrastructure design.

In some cloud architectures, Pod addressing can consume subnet resources closely tied to the underlying virtual network.

That means adding larger nodes does not automatically solve the problem.

A cluster can have enough CPU to schedule hundreds of additional Pods while the available address pool can support only a fraction of them.

I calculate address capacity before production

I start with the CIDRs used by nodes, Pods, and Services.

They must be understood separately.

Then I ask how the selected CNI allocates Pod addresses.

Does it assign addresses directly from cloud subnets

Does it use an overlay

Does it reserve addresses in blocks

Does it keep warm addresses ready for faster Pod startup

Different answers produce very different capacity limits.

This is why VPC design and Kubernetes design cannot be separated. The AceCloud VPC comparison guide provides useful context around subnet design, address ranges, routing, and private connectivity.

Node density can surprise you

Suppose a team moves from many small nodes to fewer large nodes.

Compute efficiency might improve.

Network density might not.

The maximum number of Pods supported per node may be influenced by the networking implementation and available addresses.

I therefore model both resources.

A node is useful only if it has enough CPU, memory, and networking capacity to host the intended Pods.

Autoscaling can accelerate exhaustion

Node autoscaling makes IP planning even more important.

During a traffic spike, the system may create nodes and Pods rapidly.

If those nodes consume address capacity from an already crowded subnet, autoscaling can hit the network ceiling exactly when the application needs capacity most.

That is a nasty failure mode because the infrastructure appears to be scaling successfully while workloads remain unable to start correctly.

I include remaining IP capacity in cluster alerts for this reason.

I avoid using one subnet for everything

Where the infrastructure supports it, I prefer intentional address planning across environments and workload groups.

Production clusters should not inherit a tiny CIDR simply because it was convenient during initial setup.

I leave room for growth, rolling upgrades, temporary surge capacity, and node replacement.

A rolling node upgrade can temporarily require old and new workers to coexist.

If the address plan supports only normal steady state, maintenance itself can trigger exhaustion.

Dual stack can be strategic but not automatic

IPv6 and dual-stack Kubernetes can significantly change long-term address planning.

I do not view dual stack as an emergency fix for a poorly designed IPv4 network.

It introduces application, observability, security, and operational considerations of its own.

But for organizations building platforms expected to grow substantially, I believe IPv6 readiness belongs in the architecture conversation.

I monitor IP capacity beside CPU and memory

Most cluster dashboards make CPU and memory impossible to ignore.

I want network capacity to be similarly visible.

The exact metric depends on the CNI and cloud environment, but the principle is universal.

I want alerts before address utilization becomes critical.

I also test Pod creation during load exercises.

A cluster that can handle traffic only while no additional Pods need addresses is not genuinely ready for a spike.

Managed Kubernetes does not remove network planning

A managed control plane can eliminate considerable operational work.

It does not repeal network mathematics.

Teams still need suitable subnet sizes, CNI choices, node groups, and private network design.

When evaluating environments such as AceCloud Kubernetes, I would include projected Pod count and network isolation requirements alongside worker CPU and memory sizing.

My main lesson

Kubernetes capacity is multidimensional.

CPU is capacity.

Memory is capacity.

GPU devices are capacity.

Storage attachment is capacity.

IP addresses are capacity too.

If I design only for the first two, I can build a cluster with expensive idle nodes that still cannot create another usable Pod.

That is why I calculate IP headroom before deployment, monitor it during operation, and revisit it before major scaling events.

The best time to discover that a subnet is too small is during architecture review.

The worst time is when the autoscaler is trying to save production.

Cluster Autoscaler Won't Remove a Node and Why I Check PDBs, Storage and Scheduling Constraints

Rakesh Tanwar — Thu, 10 Sep 2026 07:53:05 +0000

When a Kubernetes cluster scales out correctly but refuses to scale back in, people often blame Cluster Autoscaler.

Sometimes the autoscaler is doing exactly what I want.

It has found a node that appears underused, attempted to determine whether its Pods can move elsewhere, and concluded that removing the node would violate a workload constraint.

That distinction matters.

I never troubleshoot failed scale-down by looking only at CPU utilization.

An empty-looking node may not be removable

Node autoscaling is fundamentally a scheduling problem.

Before a node can disappear, workloads running there usually need somewhere safe to go.

That means the autoscaler must consider much more than available CPU and memory.

A Pod may depend on a disruption budget, local storage, node affinity, zone-specific storage, taints, topology rules, or another scheduling condition.

The node can therefore look wasteful on a dashboard while remaining necessary to the scheduler.

I check PodDisruptionBudgets first

PodDisruptionBudgets are one of my first checks.

A PDB can intentionally prevent voluntary eviction when removing a Pod would take the workload below its availability requirement.

That is useful.

The problem appears when the PDB and replica count make voluntary disruption mathematically impossible.

A three replica application with a sensible budget may drain easily.

A single replica application requiring that single replica to remain available cannot.

I inspect the current healthy count, desired healthy count, and allowed disruptions.

I also look for old PDBs whose selectors no longer match the intended workload architecture.

The right fix is rarely to delete the PDB blindly.

I usually fix the availability model.

Local storage changes the equation

Local ephemeral data can also make node removal difficult.

Whenever applications depend on node-local state, I ask what happens when the Pod moves.

Production workloads that require durable data generally belong on storage designed for that lifecycle rather than relying on a specific worker.

Stateful applications deserve particular attention because a volume may also have topology restrictions.

AceCloud's guide to Kubernetes CSI volume snapshots is a useful reminder that storage lifecycle, restore behavior, and application consistency must be designed independently from node lifecycle.

Scheduling rules can create invisible anchors

Next I inspect hard node selectors and node affinity.

A Pod might be allowed on only two nodes in the entire cluster.

If one is being evaluated for removal and the other lacks capacity, scale-down stops.

Taints and tolerations can create similar restrictions.

Topology spread rules and anti-affinity can also require a particular distribution across zones, nodes, or failure domains.

These are often good availability controls.

The problem is not that they exist.

The problem is when teams create them without realizing they also constrain autoscaling.

I compare requests with real usage

Cluster Autoscaler generally reasons about schedulability using requested resources rather than the utilization percentage displayed on a monitoring dashboard.

This difference catches many teams.

A node may show low real CPU usage while the Pods on it request most of the node's allocatable CPU.

From the scheduler's perspective, those requests matter.

I therefore look for over-requested workloads.

Right-sizing requests can make scale-down easier without sacrificing application reliability.

This is also why I like treating node autoscaling as part of the platform rather than as a separate cost script. Managed services such as AceCloud Kubernetes combine node groups and autoscaling with the wider cluster lifecycle, but workload requests and scheduling policy still determine how effectively capacity can be reclaimed.

DaemonSets deserve a separate look

DaemonSet Pods are expected to exist on relevant nodes.

Monitoring agents, security agents, log collectors, CNI components, and GPU components often use DaemonSets.

I distinguish these from normal application Pods during troubleshooting because their scale-down treatment differs.

The important question is whether an ordinary workload is anchoring the node.

I inspect autoscaler events before changing anything

Autoscaler logs usually tell a better story than utilization graphs.

I look for messages showing which Pod prevented removal and why.

That evidence turns an apparently mysterious scale-down failure into a scheduling investigation.

Only after finding the blocker do I change PDBs, requests, affinity, or storage placement.

I design workloads to be removable

My preferred approach is preventive.

For workloads expected to run on elastic worker pools, I ask whether the Pod can survive being moved at any reasonable time.

If the answer is no, I either redesign the workload or place it on a more stable node group.

Autoscaling works best when applications cooperate with infrastructure elasticity.

A node that cannot be drained is not truly elastic capacity.

That is the principle I keep in mind whenever Cluster Autoscaler refuses to remove a machine.

Before blaming the autoscaler, I ask which workload rule is telling Kubernetes that the node still matters.

Migrating Legacy CentOS 7 Production Servers Without Rebuilding the Entire Application

Rakesh Tanwar — Thu, 10 Sep 2026 06:32:48 +0000

CentOS 7 is already a lifecycle problem, but a rushed rewrite is not the only answer

CentOS Linux 7 reached end of life in June 2024. In 2026, any production system still running it deserves an explicit remediation plan. I also understand why some teams hesitate. The server may host an old Java application, a commercial binary, custom native libraries or years of configuration that nobody wants to recreate. I do not think the only choices are to keep an unsupported OS or rewrite the whole application. A staged migration can separate infrastructure modernization from application modernization. The first goal is to move the workload onto a supported operating system with the least behavioral change. The second goal, later, can be to improve the application architecture.

Inventory what is coupled to CentOS 7

I capture installed packages, enabled repositories, kernel modules, services, cron jobs, users, SELinux policy, firewall rules, mounts, environment variables and locally compiled software. I also identify runtime versions such as Java, Python, PHP, Node.js and database clients. AceCloud's IaaS migration guide uses dependency discovery as a core migration step, and that matters even more for legacy Linux. The hidden risk is rarely the RPM list. It is the script under /opt, the vendor daemon with an old library dependency or the certificate path hard-coded six years ago.

Choose a compatible successor before choosing a migration method

If the application expects the RHEL ecosystem, I evaluate supported enterprise Linux distributions that preserve familiar package and filesystem conventions. The exact choice depends on vendor certification, support requirements and organizational standards. I do not force a distribution because it is fashionable. I test the application on the target operating system in a clone or isolated environment, then document every incompatibility. If a dependency exists only on CentOS 7-era libraries, I look for a supported replacement, vendor update or isolated compatibility mechanism rather than copying obsolete system libraries across blindly.

Prefer parallel reconstruction to risky in-place transformation

For critical services, I usually build a fresh target VM and move the application instead of attempting a major in-place conversion on the only production server. The new cloud compute instance can run beside the old one while we install packages, reproduce configuration and test data access. Configuration management or scripts should capture what we learn so the replacement is reproducible. For stateful data, I separate data migration from OS migration. Databases may use replication or dump and restore. File data may use repeated synchronization before cutover. Parallel build preserves rollback and makes troubleshooting far less stressful.

Use containment when one dependency cannot move yet

Sometimes one legacy component blocks the whole server upgrade. I isolate that component instead of allowing it to dictate the future of the entire stack. A compatible container can sometimes preserve an old user-space runtime while the host moves to a supported OS, provided the security implications are understood. A dedicated small VM can isolate a vendor component while the rest of the application modernizes. Reverse proxies and service boundaries can also help split the migration. These are transitional patterns, not excuses to keep unsupported software indefinitely. Every exception should have an owner and an exit plan.

Use the migration to reduce unsupported dependencies

I keep a dependency retirement list alongside the server migration plan. If the target build requires an obsolete Java runtime, unsupported database client or abandoned monitoring agent, I do not hide that fact just because the new operating system boots. I assign a follow-up milestone to remove or upgrade each exception. I also compare the restored application behavior with the old server under representative load, because a compatibility workaround can preserve functionality while changing performance. Security controls are retested as well, including SELinux mode, firewall policy and service accounts. The first migration milestone is supported infrastructure. The second is a cleaner application dependency chain. Separating those milestones keeps the project achievable while ensuring the temporary bridge does not become another decade of technical debt. I keep the old CentOS 7 VM isolated and powered down for a short rollback window rather than deleting it immediately. That gives the team a safety net without allowing both systems to accept writes. After the observation period, I remove the legacy copy and its credentials deliberately so the migration actually closes the risk.

Make the migrated server easier to replace next time

The most valuable outcome is not merely leaving CentOS 7. It is eliminating the conditions that made leaving so difficult. I move configuration into version control, externalize secrets, document package sources, standardize monitoring and create repeatable images. I avoid storing business data inside the root image when it can live on managed storage or a dedicated volume. I also record operating system lifecycle dates in the asset inventory. A legacy migration is expensive because the organization has to rediscover how the server works. The visionary move is to make the replacement transparent enough that the next OS lifecycle event becomes a planned rebuild rather than an archaeological project.

Why Cloud VM Clocks Matter for CERT-In Compliance and Incident Investigation

Rakesh Tanwar — Mon, 07 Sep 2026 14:16:01 +0000

Time is evidence, not a cosmetic server setting

I think clock synchronization is one of the most underestimated controls in cloud operations. A VM can serve traffic perfectly while its clock is wrong by seconds or minutes, yet that small error can damage incident reconstruction, authentication, distributed tracing and legal evidence. In India, CERT-In directions require covered entities to synchronize ICT system clocks with NIC or NPL NTP sources, or with time sources traceable to them. The same directions require specified cyber incidents to be reported within six hours of noticing them. If clocks across firewalls, applications, databases and VMs disagree, answering when an event happened becomes much harder precisely when the organization is under pressure.

Incident timelines fail when systems disagree about time

Imagine a compromised account that logs in to a web server, queries a database and transfers data through a gateway. If the web server is three minutes fast, the database is one minute slow and the gateway uses UTC without clear normalization, investigators can misorder the sequence. That affects root-cause analysis and can delay containment. AceCloud's DRaaS guidance for India also highlights CERT-In log retention and reporting obligations. I treat synchronized time as part of the same evidence chain. Logs are only useful when timestamps can be correlated across systems with confidence.

Use a controlled hierarchy of trusted time sources

I do not want every VM randomly reaching public NTP servers. I prefer a defined time architecture. Infrastructure nodes synchronize against approved upstream sources that meet organizational and regulatory requirements, and internal systems use those trusted sources or a controlled hierarchy. I monitor offset, synchronization state and source changes. For multi-region environments, I keep time in UTC at the system and logging layer, then convert to local time only in presentation. Time zone labels still matter because investigators need to know how timestamps were generated. Consistency is more important than what humans find most readable.

Cloud images and autoscaling must inherit the same time policy

A manually configured production VM may have perfect NTP settings while newly launched autoscaled VMs use defaults from an old image. That is why I bake time configuration into baseline images and validate it during boot. Configuration management should correct drift, and monitoring should alert when synchronization is lost. A standardized cloud compute environment helps teams create repeatable VM templates, but the control is effective only if every instance follows the same policy. I also verify that containers, applications and managed agents use the host clock correctly and that logs include sufficient timestamp precision.

Clock health belongs in security monitoring

I monitor offset and synchronization just as I monitor CPU and disk health on critical systems. A sudden clock jump can break Kerberos, TLS validation, scheduled jobs or distributed databases. It can also create gaps or duplicates in logs. During an incident, I record the synchronization status of key systems so investigators know whether timestamps are trustworthy. For very sensitive environments, I retain evidence of NTP configuration and drift history. This may sound operationally small, but strong incident response depends on dozens of small controls that were functioning before the incident began.

Include time validation in every incident drill

During tabletop and recovery exercises, I ask the security team to build a timeline from several systems without first being told which clock is authoritative. This exposes drift, missing time zones and timestamp formats quickly. I also test what happens when a VM cannot reach its normal NTP source. It should fail visibly rather than drift silently for days. Configuration changes to time sources belong in change control because a seemingly harmless server tweak can affect every forensic event that follows. I keep synchronization configuration in code where possible and include clock offset in baseline health checks. These practices turn time from background plumbing into a measurable security dependency. When an incident occurs, investigators can spend their limited hours analyzing attacker behavior instead of reconciling basic chronology. I include hypervisors, network appliances and centralized logging systems in the same time policy. Synchronizing only application VMs still leaves gaps if the firewall or load balancer records events on a different clock. A forensic timeline is only as consistent as the least disciplined system contributing evidence.

Design logs so a 180-day history is actually usable

CERT-In directions also require covered organizations to enable logs of ICT systems and securely retain them for a rolling period of 180 days within Indian jurisdiction. Retention without reliable time is weak evidence. My view is that clock synchronization, centralized logging, retention and incident reporting should be designed together. The log platform should preserve event time, ingestion time, source identity and time zone context where needed. Teams should be able to search across systems quickly and export evidence without rebuilding timelines by hand. When every system shares a trusted time reference, six hours is still a demanding incident window, but at least the organization is investigating one coherent timeline instead of twenty conflicting clocks.

Why Large Memory VMs Can Get Slower as You Add More RAM and How NUMA Changes the Result

Rakesh Tanwar — Mon, 07 Sep 2026 13:14:01 +0000

More memory can expose a topology problem

I like large-memory VMs because they let databases, analytics engines and in-memory services keep a bigger working set close to the CPU. However, I do not assume that adding RAM always makes those workloads faster. On large physical hosts, memory is often arranged in NUMA nodes. Each processor socket or group of cores has memory that is local to it and can access memory attached to another node at a higher cost. When a workload expands across NUMA boundaries without awareness, some threads spend more time reaching remote memory. The result can be surprising. The VM has more RAM and fewer disk reads, yet latency gets worse because memory access itself has become less local.

NUMA is about distance inside the server

Non-uniform memory access means that not every CPU reaches every byte of RAM with the same latency and bandwidth. The operating system and hypervisor try to keep threads and their memory close together, but large VMs can span multiple NUMA nodes. AceCloud's guidance on RAM-intensive workload optimization calls out remote NUMA access as a pitfall, and I agree with that emphasis. Applications such as databases, JVMs, scientific codes and in-memory analytics can be particularly sensitive because they move large volumes of data through memory. The first step is simply to know whether the VM topology crosses NUMA nodes and whether the application is NUMA-aware.

A bigger VM can make the working set less local

Consider a database that fits comfortably inside one NUMA node at 128 GB. If I resize it to a much larger VM, the virtual CPUs and memory may be distributed across several nodes. If the database has worker threads concentrated on one node while buffers are allocated across another, remote memory traffic grows. The application may also create more worker threads simply because more vCPUs are available, increasing contention on shared structures. Larger pages, garbage collectors and memory allocators can all interact with topology. I therefore compare memory bandwidth, remote access counters, CPU migrations and application latency before and after a resize instead of assuming bigger is automatically better.

Keep compute and memory topology aligned

For NUMA-sensitive workloads, I want vCPU placement and memory allocation to align. On operating systems that expose the topology, tools such as numactl and lscpu help show nodes and CPU mappings. Databases and JVMs may have their own NUMA guidance. I also avoid allocating every last gigabyte to the application because the OS, page cache, agents and filesystem still need headroom. In a cloud compute platform with memory-optimized instance families, I select the smallest shape that comfortably holds the working set and meets concurrency goals. That often produces better locality and lower cost than one enormous VM.

Watch bandwidth, page faults and remote access, not just free RAM

Traditional monitoring often shows used memory, free memory and swap. Those numbers do not tell me whether memory is close to the threads consuming it. For large systems, I care about memory bandwidth, cache misses, major page faults, swap activity, garbage collection time and NUMA locality when the guest exposes it. I also measure business outcomes. A database may show lower disk I/O after adding RAM but still process fewer transactions per second because remote memory and lock contention increased. Performance work fails when we optimize the metric that is easiest to see instead of the one that controls user experience.

Test resize behavior before the production database needs it

NUMA problems are much easier to study in a controlled benchmark than during a memory emergency. I keep a representative dataset and workload that can be replayed on candidate VM sizes. Before resizing production, I compare throughput, p99 latency, garbage collection time, page faults and memory bandwidth on the current and larger shapes. If the application exposes thread pinning or NUMA controls, I test those settings rather than enabling them blindly. I also verify restart time because a much larger memory footprint can lengthen cache warm-up and database recovery. The winning instance is the one that meets the service objective with predictable behavior and reasonable headroom. More RAM is valuable when it reduces real bottlenecks. It is waste when it only increases the size and complexity of the failure domain.

*Scale out when one giant memory domain becomes operationally awkward *

There is a point where continuing to scale one VM vertically becomes less attractive. Very large instances can have bigger failure domains, longer restart times, more complex NUMA behavior and expensive idle headroom. Some databases support replicas or sharding. Analytics platforms can distribute work. Caches can partition keys. I do not recommend scale-out merely because it is fashionable, but I do recommend comparing it with the next vertical resize. The strategic question is whether the application benefits more from one massive memory space or from several smaller and more predictable nodes. Large memory is powerful. It becomes truly useful when the software, topology and operating model are designed to use it deliberately.

CERT-In Log Retention for Databases and What I Would Log Without Creating a New PII Risk

Rakesh Tanwar — Thu, 03 Sep 2026 08:14:17 +0000

Logging is one of the best tools we have for investigating database security incidents.

It can also become a new sensitive-data repository if teams record everything indiscriminately.

India's CERT-In directions require covered entities such as service providers, intermediaries, data centres, body corporates, and government organisations to enable logs of ICT systems and securely maintain them for a rolling period of 180 days within Indian jurisdiction.

I do not interpret that as an instruction to copy every piece of personal data into logs.

Good security logging records enough evidence to reconstruct important activity without turning the logging platform into a second uncontrolled database.

Log the event, not the entire customer record

Suppose an application queries a customer's account.

For security investigation, I may need to know which application identity connected, when it connected, where it connected from, which database it accessed, whether authentication succeeded, and what privileged activity followed.

I usually do not need the customer's complete profile copied into the log line.

This distinction is fundamental.

Logs should describe activity.

They should not duplicate business data unless there is a specific justified reason.

For organisations using a managed database platform, I would define database audit events alongside application and infrastructure events rather than logging without a data model.

Authentication events matter

I want visibility into successful and failed database authentication.

User or service identity.

Timestamp.

Source system or address.

Destination database.

Authentication result.

Relevant privilege context.

Repeated failures can expose brute-force attempts, broken credentials, or misconfigured services.

Successful access from an unusual source can be even more important.

What I avoid is logging passwords, connection secrets, private keys, or complete authentication tokens.

A log that contains secrets becomes an attack surface.

Privileged actions deserve strong visibility

Routine SELECT activity on a busy application can generate enormous log volume.

Privileged operations are different.

Role changes.

Permission grants.

Database creation.

Schema changes.

User creation.

Security configuration updates.

Backup changes.

Logging configuration changes.

Destructive administrative actions.

I want these events clearly attributable to an identity.

If an attacker obtains administrative access, investigators need evidence of what changed.

Query logging needs judgement

Logging every SQL statement can be useful in specific environments.

It can also capture sensitive values embedded directly in SQL.

A query might contain an email address, phone number, personal identifier, access token, or other data.

I therefore prefer parameterised application queries and logging strategies that separate query structure from sensitive parameter values where possible.

Fingerprinting or query identifiers can help with operational analysis without preserving every literal value.

Network metadata connects the story

Database incidents rarely happen entirely inside the database.

An application host is compromised.

Credentials are used.

Connections reach the database.

Data is queried.

Information leaves through another system.

Network records help reconstruct that path.

That is why I consider cloud networking and security controls part of database observability.

Database logs, firewall events, private-network records, authentication events, and application logs become much more useful when timestamps and identities can be correlated.

Time synchronisation is essential

An incident timeline is useless if every system disagrees about time.

Database server says 10.03.

Application says 10.08.

Network logs say 10.05.

Now the incident team has to guess which event happened first.

CERT-In's directions also address system clock synchronisation.

From an engineering perspective, accurate consistent time is basic observability hygiene.

Protect the logs themselves

Retention creates value only if logs remain trustworthy.

Restrict write and deletion permissions.

Encrypt storage.

Control administrator access.

Monitor attempts to change logging configuration.

Consider immutable or append-oriented storage for important audit data.

Separate ordinary application administrators from people who can erase security evidence where practical.

An attacker who compromises a database account should not automatically gain the ability to delete the logs that record the compromise.

Retention should have an end

If an applicable requirement calls for a rolling 180-day period, I would automate that lifecycle.

Keep the required evidence securely for the required period and delete it according to policy when there is no longer another lawful or operational need.

Keeping security logs forever does not automatically improve security.

It can create a larger archive of sensitive metadata waiting to be exposed.

Minimise PII before collection

The cheapest sensitive log to protect is the one you never created.

I ask teams to review every field.

Do we need a full email address or would an internal user identifier work?

Do we need the request body?

Do we need raw card-related data?

Do we need complete SQL parameters?

Do we need authentication tokens?

Usually, the answer to several of those questions is no.

Good logging is selective.

Capture identity, time, action, source, destination, outcome, privilege changes, security-relevant database events, and enough context to investigate incidents.

Do not use regulatory retention as an excuse to collect unnecessary personal data.

That produces better forensic evidence and a smaller privacy risk at the same time.