DEV Community: Andrey Nikishaev

SQL Is Easy... And That’s The Problem

Andrey Nikishaev — Wed, 04 Jun 2025 13:44:16 +0000

🗄️ Almost every software project needs a database to store information, which is why most developers start with SQL or object-based databases. These tools are familiar, flexible, and easy to use out of the box.

But that flexibility comes at a hidden cost.

SQL and object databases allow developers to store data in virtually any structure—even poorly designed ones. Without enforced planning or schema constraints, it’s tempting to skip modeling relationships or typing queries properly. This often leads to messy, unscalable data layers that later cause serious issues: slow queries, painful sharding and replication, unclear data ownership, and access control chaos.

I love PostgreSQL as much as anyone, but in my 25+ years of engineering, I’ve rarely seen teams treat data modeling with the care it deserves. In most cases, schema design happens reactively, not proactively.

That’s why in many of my recent projects, I’ve leaned toward less traditional databases—like Cassandra or AWS DynamoDB. These systems force you to think ahead. You can’t skip modeling. You must define access patterns and data structures upfront. Otherwise, the system simply won’t work.

And that’s a good thing.

Great systems aren’t about enforcing rules manually—they’re about creating environments where the right architecture becomes the path of least resistance.

Watch full video: https://youtu.be/kORcLmvS5OE

Did you plan your retirement?

Andrey Nikishaev — Wed, 04 Jun 2025 13:42:28 +0000

🧓 Any software engineer can experience a kind of "early retirement" - sometimes chosen, sometimes forced. And i want to emphasize how important its to prepare for the end of an engineering career - and how to navigate it.

For many, its hard to imagine what stepping away from engineering feels like. So let me try to explain it from a different angle.

Imagine you're 40 or 45. From today, you’re not allowed to write code anymore. No more building products, fixing bugs, reviewing PRs, or discussing system architecture. You can’t touch your favorite editor. You're left with an empty GitHub graph, no standups, and no more income. You can't return to what you've been mastering for 15-20 years. It's over. Finite.

That's a reality many engineers eventually face - whether due to burnout, layoffs, AI disruption, or just life. And it's one most of us are not prepared for.

That's why I believe you need to start building a parallel path while you’re still active. A new occupation, a different income stream, or simply a life outside the code. My strongest recommendation: start now, not later.

💰 First, long-term financial planning is essential. Not everyone wants to think about it, but everyone needs it. Talk to professionals. Find someone with real financial knowledge and the integrity to match. The right advice early on makes a world of difference.

💡 Second, finding a new passion after engineering isn’t simple. Writing code gives many of us a deep sense of flow and purpose. Losing that can be devastating. So start experimenting now. Try things - whether it's teaching, writing, mentoring, creating tools, starting a company, or working in a completely different field.

One thing I know for sure: engineers love to solve problems. We crave challenges, not idleness. We need something to sink our teeth into. Doing nothing isn't an option for most of us.

🎯 This isn't just for those at the end of their careers. It’s a valuable exercise for every engineer: sit down and ask yourself - if coding disappeared from my life tomorrow, what would I do next?

As for me, I'm grateful I've started to find new challenges that give me meaning outside of my IDE. It's not the same - but it's something real.

Tutorial: Unlocking the Power of Sidecars in Kubernetes

Andrey Nikishaev — Mon, 02 Jun 2025 17:27:33 +0000

I recently built a small demo that illustrates how sidecar containers can transform observability and control in any Kubernetes‐based service. Instead of embedding metrics, logging, and networking logic directly into your app, you simply “bolt on” three dedicated sidecars:

Prometheus – Collects application and infrastructure metrics out of the box.
Promtail → Grafana Loki – Streams logs in real time without changing your app code.
Envoy Proxy – Handles TLS termination, request filtering, and even simulates network failures.

✅ Why this Matters

Separation of Concerns: All observability (metrics + logs) and networking (TLS, filters, chaos testing) live outside the main container. Your app stays lightweight and focused solely on business logic.
Consistency Across Services: You can reuse the exact same Prometheus/Promtail/Envoy configuration for every microservice. No more “one‐off” instrumentation code in each repo.
Faster Development & Onboarding: Developers don’t need to spend time wiring in monitoring libraries or custom proxy code—sidecars handle it for you automatically.
Easier Upgrades and Troubleshooting: When you need to tweak logging formats or experiment with TLS settings, you update the sidecar image, not dozens of disparate applications.

⚠️ Considerations

Resource Overhead: Each sidecar adds CPU/memory usage. In lightweight deployments, be mindful of your node capacity and pod limits.
Operational Complexity: More containers per Pod means more YAML to manage and additional network hops. You’ll need to ensure your CI/CD and Helm charts stay up to date.
Sidecar Lifecycle: When you roll out a new version of your app, the sidecar versions may need to stay in sync (e.g., Promtail pipelines). Establish clear versioning and testing practices.

Ultimately, moving observability and networking logic into reusable sidecars makes your main application image lighter, speeds up developer onboarding, and enforces a consistent control plane across all services. If you’re evaluating how to standardize monitoring, logging, and network policies at scale, consider a sidecar‐centric approach. It’s a small shift in architecture that can pay big dividends in maintainability and speed.

Repo: https://github.com/creotiv/sidecar-demo

Making tutorials and guides as tests, so they always work

Andrey Nikishaev — Tue, 08 Apr 2025 18:20:02 +0000

In my previous post https://lnkd.in/eJbfM6xR I discussed how important it is to synchronize all the data in a project. I also mentioned that doing it manually is a pain in the ass and basically never works.

In this post, I want to show an example of how this problem should be solved—and its elegance.

Our task is to write tutorials and guides for the documentation, but in such a way that they are always tied to a specific version of the code and are always executable.

To solve this problem, we present the guides as test cases, which are executed along with all others during the build process. Based on their results, an MD-format file with the article is generated. And if something doesn't work, we immediately fix it and accordingly update the test/guide.

As you can see from the code, even a junior developer could write the tool that does this, or you can simply ask ChatGPT.

This approach will save you from pain, problems, and thousands of bug reports about something not working.