Cloud That Delivers: Senior Developer's Insights on Performance, Maintainability, and the Human Factor For Iaroslav Molochkov, true leadership is measured not by how much your colleagues need you, but by how well they perform without you.

The cloud has become the engine of the modern digital economy. In the second quarter of 2025, global enterprise spending on cloud infrastructure soared to $99 billion — a jump of more than $20 billion compared with the same period a year earlier. No longer just a hosting solution, the cloud now powers everything from AI applications to global financial systems. For companies, it is both an opportunity and a test: it offers limitless flexibility, but also demands precise architectural choices to balance speed, resilience and cost.

Few engineers grasp these trade-offs as deeply as Iaroslav Molochkov, a Senior Software Developer with expertise in distributed systems, performance optimization, and cloud technologies. Over the years, he has built a track record of solving complex challenges where technology and teamwork intersect — from steering open-source release cycles to reshaping enterprise architectures. Now, Molochkov shares insights on how organizations can unlock the full value of cloud platforms, finding the right balance between short-term gains and long-term maintainability.

From Release Cycles to Microservices

Molochkov's career illustrates how technical expertise and organizational skills go hand in hand. While working as a Principal IT Engineer at SberTech, the IT division of Sberbank, he was entrusted with overseeing the release of a new version of Apache Ignite, an in-memory data grid. Coordinating contributors across a distributed open-source community, untangling blockers, and ensuring the system passed demanding tests were all part of the job. Under Molochkov's leadership, the release not only shipped on time but also delivered measurable performance gains and was adopted by hundreds of organizations worldwide.

At the time, releases were relatively infrequent, hindered by the product's complexity. By taking initiative, Molochkov significantly contributed to efforts of shifting towards an agile development rhythm. "One of the goals was to shorten release cycles," Molochkov recalls. "Delivering features and fixes more quickly helps users see that the product is active, improving, and well-supported." This initiative marked an important step in building a more responsive culture at SberTech, where large systems could evolve continuously.

Iaroslav Molochkov's successful project also set a precedent and inspired others to take on similar ownership. Beyond the technical execution, Molochkov mentored colleagues through the process and shared his experience with the team to strengthen internal expertise and raise the overall level of engineering maturity.

Later, as a Lead Java Developer at EPAM Systems, he focused on system architecture for a major European retail client. The company's legacy monolith was straining under modern demands, and his team was tasked with building a microservice capable of handling high volumes of concurrent client requests, each involving database or external API calls. "We couldn't just throw more servers at the problem," Iaroslav Molochkov explains. "The solution had to scale efficiently and still be cost-conscious. Performance mattered, but so did every dollar spent on cloud resources."

The final design used Spring WebFlux for its reactive model, Kafka for event streaming, Schema Registry for safe schema evolution, Avro for efficient serialization, and MongoDB for unstructured data and text indexing. The result was a microservice that was highly scalable, maintaining low latency and high throughput in production. It was rigorously tested and rolled out through a CI/CD pipeline, ensuring controlled and reliable deployment. Molochkov's work became an integral part of the retailer's digital ecosystem, underpinning key production services.

Yet the design came with a trade-off. While it met the demanding performance targets, the reactive model introduced additional complexity and required developers to adapt to a steeper learning curve.

"The architecture delivered the performance we aimed for," says Molochkov, "but it also raised the technical bar for the whole team. High-performance systems are rarely simple, and part of the challenge is making sure people are ready to develop and maintain them long term." For him, these experiences underscored that innovation is never just about technology. It also depends on how teams adapt, communicate, and share responsibility.

Building Bridges in the Cloud

Today, Iaroslav Molochkov works as a Senior Software Developer at JetBrains — a global software provider whose products are used by millions of developers and companies worldwide — where he focuses on cloud integrations. His work plays an important role in ensuring that the company's tools remain fast, stable, and efficient even under the intense demands of enterprise users. In one recent project, he has improved AWS integrations to better support high-concurrency workloads — changes that translated into notable improvements in speed and resource usage for enterprises.

He points out that every cloud platform has its own strengths and limitations. AWS, for example, stands out for the sheer variety of services it offers, giving developers components for nearly any use case. At the same time, that breadth can create traps. "The flexibility is powerful, but if you don't understand how the pieces interact, costs can spiral quickly," Molochkov cautions.

GCP has carved out a leadership position in data and machine learning, which makes it attractive for companies that want analytics-first architectures. Azure, meanwhile, appeals to enterprises invested in Microsoft ecosystems, thanks to its strong hybrid cloud capabilities and seamless compatibility with tools like Active Directory and SQL Server. And Nebius, though a newer entrant, is gaining traction with an emphasis on high-performance, top-tier GPU clusters, low-latency storage and EU data residency. Still, its relatively young ecosystem requires extra scrutiny.

"To design well for the cloud, you can't just read the API docs," Molochkov says. "You have to understand what each platform is optimized for, where it performs best, and where the trade-offs are."

On the debate over single-cloud versus multi-cloud, he is pragmatic. "If you don't have a strong reason to split workloads, sticking with one provider gives you more focus and leverage," he says. However, in situations where regulation, latency requirements, or vendor risk justify it, he recommends designing portability at the interface level.

AWS Insights: Finding the Right Balance

When architecting solutions on AWS, the leading cloud infrastructure service provider on the global market, Iaroslav Molochkov emphasizes finding the right balance between performance gains and long-term maintainability.

He begins by defining clear service-level objectives. "Once you know the exact targets you need to hit, performance decisions stop being subjective," he explains. "It's no longer about whether something feels fast, but whether it meets the standard the business relies on."

When it comes to compute options, Molochkov believes the workload should dictate the model. Bursty traffic is often best served by serverless, steady usage typically fits containers, and specialized hardware or legacy requirements may still call for virtual machines. "What matters most," he stresses, "is modeling cost and performance under realistic load conditions, not just on paper."

He also cautions against overusing AWS's enormous catalog of services. With so many overlapping options, it's easy to overcomplicate the stack. He favors defining reference architectures and templates, leaning on managed services where they fit, and pruning components that don't clearly add value.

Managed services like DynamoDB, for example, can reduce time-to-market and operational risk. However, in situations where particular guarantees or cost models don't align, custom setups may still make sense. "In those cases, you need to design an exit strategy upfront," Molochkov advises. "That means thinking through data portability and migration steps before you even start."

He sums up the principle this way: "Every service you add comes with a maintenance cost that isn't always obvious. You have to be sure it's delivering enough value to justify that burden — and document the reasoning, not just the decision itself. This way, future teams understand why a choice was made and can build on it."

At scale, subtle bottlenecks almost always appear. Observability is a key consideration. Molochkov suggests tracking four key signals: latency, errors, saturation and traffic. To make troubleshooting easier, he recommends standardizing logs and metrics with correlation IDs so issues can be traced across different parts of the system.

The Human Side of Engineering

Technical choices alone don't guarantee success — long-term resilience also depends on the teams behind them. On this front, Iaroslav stresses that good mentorship starts with empathy. "No one starts as an expert," he says. "If you forget that, you create a culture where people are afraid to ask questions." He makes it clear to juniors and interns that there are no "stupid" questions, only missed opportunities to learn.

Molochkov also expects them to propose an initial approach before asking for guidance, so discussions focus on refining their ideas rather than solving the problem for them. "It accelerates learning and gives people confidence in their own judgment," he explains. That openness has helped Iaroslav create an environment where younger engineers feel comfortable exploring ideas early in their careers — an essential condition for building strong, independent teams.

The expert encourages initiative, supporting ambitious tasks when deadlines allow time to learn and grow. "That's how I progressed," he says. "By saying yes to challenges that seemed slightly out of reach, and then figuring them out."

For Iaroslav Molochkov, true leadership is measured not by how much your colleagues need you, but by how well they perform without you. "If your absence causes everything to stall, then you haven't built a resilient team," he reflects. "The real goal is to grow people who can carry the work forward — and even surpass you." It's a philosophy that mirrors his technical work: building systems that remain stable under pressure, and teams that remain capable when the challenges evolve. In both cases, sustainability is the real measure of success.