DevAssistant

13/10/2026

Infrastructure down? Let’s get it running again.

Data center failures can take services offline, limit access to critical data, and interrupt business processes. When this happens, restoring normal operations as soon as possible is a priority.

Our team can help you assess the situation and bring your infrastructure back online. After services are restored, we’ll evaluate the risks together and consider whether migrating to a different hosting environment would be beneficial.

We can assist with both recovery and migration, helping you restore operations and find a hosting environment that better fits your needs.

Experiencing infrastructure issues? Contact us to discuss your situation and possible next steps.

09/10/2026

How do you know when a standard HR system is no longer enough for your company? Our colleagues explore this question through Evrone’s projects, share their experience building an in-house ERP, and discuss the role AI can play in the future of HR Tech.

We started with an ERP to solve our own business needs – and ended up in HR Tech.

Sounds a little unexpected, right? But when a company spends years accumulating data on employees, projects, levels, workload, and processes, it quickly becomes clear that an HR system is about much more than employee records and time-off requests.

It starts to connect with almost everything: resource planning, finance, projects, and performance reviews. And that’s when questions come up that an off-the-shelf HRM can’t always answer in a way that works for a particular business.

We went through this ourselves first, and then faced the same challenges in projects for our clients. So in the article, we decided to share not a theory of the “perfect HR platform,” but what we’ve actually learned along the way: what’s worth automating, when custom development really makes sense, and where AI can already be applied in HR.

Here’s the full story: https://evrone.com/blog/from-evrone-erp-to-hr-tech-expertise

18/09/2026

Notion isn’t always seen as a tool for managing a team’s day-to-day operations. But a lot depends on how it’s built into the workflow.

In this case, the team didn’t switch to a new, complex system. Instead, they built a custom operational workflow on top of the Notion environment they were already familiar with.

Here’s how it works in practice – from handling incoming tasks to planning team capacity.

How do you manage a DevOps team when tasks come from everywhere?

From chats, clients, and colleagues. Some tasks need to be handled right away, others are planned for the week ahead, and some are part of larger projects. At the same time, one specialist may be working across several projects at once.

It’s a familiar situation for a growing team. At some point, it becomes difficult to see what’s really happening with workloads, where work is getting delayed, and how resources should be allocated across projects.

That’s where the approach we developed for one of our DevOps clients comes in.

Instead of introducing yet another complex system that would take time to implement and then require everyone to adapt their workflow around it, we built a custom system on top of Notion, tailored to the team’s actual way of working.

Now, a request from a chat, a meeting, or a client conversation becomes part of a single operational workflow, with a project, an owner, a priority, and a status. At the same time, the team can keep its familiar working rhythm: urgent tasks can still be picked up throughout the day, while more predictable work can be planned for the week and beyond.

As a result, daily syncs were reduced from two hours to 30 minutes, while the number of reported client complaints dropped by 87% in the first three weeks after implementation.

But the most interesting part is how the system actually works, why Notion was chosen, and how it helps not only manage tasks but also plan team capacity.

We’ve broken down the entire process in our case study: https://evrone.com/cases/devops-task-management

27/08/2026

We were happy to be part of this project and help tackle a complex logistics challenge – from enterprise integration to shipment tracking.

Together with our partners, we worked on building a solution that connects systems, streamlines data processing, and supports the company’s growing logistics operations.

Take a look at the full case below 👇

How do you digitalize logistics when you have dozens of offices, warehouses, and thousands of shipments?

Our client is a large logistics company with 40 offices and more than 100,000 m² of warehouse space.

The project involved several key challenges: reducing the load on the database, integrating a new B2B client, and enabling users to track shipments by tracking number.

We built an enterprise data bus based on Apache NiFi and Kafka. It receives messages from different systems, processes them, and passes them on without creating peak loads on the database.

For the new client integration, we developed data mapping, and used the same data bus to build a public shipment tracking service.
As a result, we brought integration, data processing, and tracking together in a single solution – exactly the kind of complex challenge we love solving at Evrone.

The result is a unified infrastructure that connects different systems and helps the company manage shipment data.

Read the full case: https://evrone.com/cases/edi-for-logistics

14/08/2026

A month, dozens of services, and zero downtime allowed. A tough challenge, but a fascinating engineering one. Here's how it all came together.

You have one month, dozens of services, and a strict no-downtime policy. What do you do first?

This was exactly the situation when we helped an international ride-hailing service migrate to a new infrastructure.

Within four weeks, we had to move all services from an old Kubernetes cluster to a new one and get them up and running on an updated engineering platform – all while keeping the user-facing application fully operational with zero interruptions.

The biggest challenge? The sheer scale of the system and the web of dependencies. Databases, Redis and other storage systems, message brokers, internal microservices, external APIs – some of these connections weren’t even documented in the configs and only came to light during deep analysis.

In the end, within those four weeks, we successfully migrated every planned service to the new cloud environment and decommissioned the old platform – all while users continued using the service 24/7 without even noticing a thing.

We’ve detailed the entire migration process and the key strategies that helped us meet such a tight deadline with zero application downtime in our case study:
https://evrone.com/cases/wayo

And you – where would you start with a migration like this?

16/07/2026

When we take on a project, we put not only our expertise into it but also our heart. This one was no exception.

It was truly great working on this task — a lively process, tough decisions, and genuine involvement from everyone. We're glad our experience came in handy and truly appreciate the trust placed in us.

We're moving forward in high spirits with new plans!

The most expensive mistake in infrastructure projects is starting to choose tools too early.

We have an interesting case. The client is a top-tier research laboratory – we can't disclose the name due to NDA. Their pain point: despite having a powerful pool of professional GPUs, engineers were wasting time waiting. Graphics cards were being reserved entirely even for small tasks, resource allocation between teams was done manually, and expensive equipment sat idle.

We didn't jump straight into designing the future platform's architecture. Instead, we started with experiments: we tested different GPU scheduling approaches on the client's real workloads. This helped us understand which solution would actually fit their infrastructure.

Based on the data we gathered, we built a unified MLOps platform that automated compute resource allocation, pooled existing GPUs, and made their usage transparent for the entire team.

As a result, engineers could run tasks in parallel without waiting for access to compute resources, and management got full visibility into infrastructure utilization.

Good architecture doesn't start with tool selection. It starts with understanding the problem.

Read more about the project on Evrone's website: https://evrone.com/cases/relab

25/06/2026

A solid read for anyone considering a move to Rust. The authors honestly lay out where it delivers (memory, speed, legacy code) and where it only creates more problems. Worth reading before making a decision.

Something interesting has happened with Rust.

Just a few years ago, people were mostly arguing about it. Some said it was the future of development, others thought it was just another overhyped trend.

Now there's less arguing. But there are a lot more practical questions. For example, whether it's worth migrating an existing product to Rust.

And this is usually where it turns out that the question isn't really about the language at all.

Because there's a golden rule: if it ain't broke, don't fix it. If the system is well-tuned, the team is happy, and business goals are being met – migration can end up being an expensive endeavor with little noticeable return. But if you've accumulated issues with performance, security, or maintaining legacy code – that's a whole different conversation.

In an article with Evrone's DevRel Grigory Petrov, we broke down the situations where switching to Rust might actually be justified. And a few cases where it's better not to redo something that's already working just fine.

https://evrone.com/blog/migrating-to-rust-in-2025

18/06/2026

On the surface — a clean and intuitive interface; underneath — serious work on architecture and business logic. That was exactly the approach taken in modernizing the Mindbox platform. We were able to join this stage and contribute to reworking the user scenarios. The results speak for themselves: the product became more convenient without becoming internally more complex.

Redesign isn't always about a new look. Often, as a product grows, there comes a point where updating the interface alone is no longer enough.

That's exactly what Mindbox ran into during their platform modernization. It's a cloud service for marketing automation – email campaigns, personalization, loyalty programs, plus customer data management without overloading the client's internal IT systems. The product is complex, and its frontend had become a bottleneck for further development.

Together with the client's team, Evrone developers took part in updating the frontend architecture and reworking key user scenarios. As a result, reports became much more convenient, working with data became clearer, and setting up recommendations became simpler.

At the same time, the most important changes weren't happening on the screen. Behind an interface that looks simple and intuitive to the user, there's usually a significant amount of work on architecture, product logic, and internal processes. It's these kinds of changes that allow a product to keep growing without constantly becoming more complicated.

More about the project:
https://evrone.com/cases/mindbox

28/05/2026

Go has a solid standard library, so why even bother with frameworks? And if you do bother – which one actually makes sense for highload, microservices, or MVP? This article answers both questions.

14/05/2026

When should you migrate from Ruby to Go, and when is it better to stick with your familiar stack? Our colleagues have published a piece that breaks down all the arguments for and against. No extremes, just to the point. The link is in the post.

Migrating from Ruby to Go: when it makes sense and when it's a mistake

A Ruby project worked steadily for years, but then the load grew, response time increased, new features became a struggle, and everyone around started saying: "Switch to Go."

Is it worth abandoning your familiar stack? Let's explore this together with Alexander Kirillov, a DevOps expert and mentor in the Evrone DevOps internship program.

Go is faster under load because it compiles to machine code. Built-in goroutines simplify parallel computing. Static typing catches errors at compile time. The final binary is easy to deploy.

But there are trade-offs. The Ruby ecosystem is richer – many things in Go would have to be written from scratch. The language has strict rules: even an unused variable will prevent compilation. There are no classes or inheritance – only structs and interfaces.
Migrating a large project takes months, plus retraining the team.

To make the right decision, assess your actual problems. If current performance is no longer satisfactory – Go might help. If everything runs fine, the switch may not be worth the effort. Start by rewriting one microservice in Go, not the entire project.

And if you want to try Go but find it daunting, we can help with migration – from a test prototype to a full project rewrite.

All the details – which approach to choose, how to test, and whether to start at all – are in the article.
https://evrone.com/blog/from-ruby-to-go