Migrating for scalability? No, this time it’s for faster feature implementation. Does it work? No pain, no gain, right? But what if there’s much pain and so little gain? Is this paying off technical debt, an investment for the future, or just hopping on the hype train?
TL;DR: What feature? You knew it!
We have a project that integrates with other systems. These integrations involve numerous business rules that change constantly. No one remembers these business rules. A developer needs to read the documentation, coordinate meetings, implement a new feature, and fix new bugs. It’s a trial-and-error process every time. Let’s create a microservice and assign responsibility to a new team. A microservice for a team — what a great idea! Let’s implement the microservices architecture first, and we’ll build teams later. We must sacrifice the current team for the greater good of the new teams!
Let the meetings begin! Everyone has ideas about the design of the new microservices architecture. Everyone is excited and wants to talk. Developers who have worked with microservices architecture before are our knights — they are on the front lines, fighting the monster! Monster? Microservices are a monster? Come on, that can’t be true!
We needed some mediator microservices, workers, queue infrastructure, and some state machines. We converted some libraries to NuGet packages. So much extra work for migration. But what about features?
“Network. What? I’m a software developer,” said nobody. “Network? Not a problem, bro, bring it on.” And the monster is hunting us. Connectivity problems are the new bugs. Increased latency is another story.
Log aggregation. Oh, correlation, my new friend. There’s a new bug. Where? It’s somewhere in the logs, if it’s logged. And if it’s logged correctly. And with enough data. It should be there. Oh my God, please help me! Oh, I found it. No, it’s another thing. Is this really it? This one. Hmm. Let’s see where it starts, goes, and stops. You found it. Good. Is it different from your assumption? Good. You need to suffer more. Breakpoint. You can’t hit the breakpoint.
You fixed it. Built it. Deployed it. Deployed the new version? Oh, let’s check it. We have a cool CI/CD. Don’t worry. What? A deployment error?
Deployment to production, adding a new microservice, staging a new environment, and simulating production locally are all fun. Just saying. Deploying to different cloud services is even more fun.
Test it? You can’t give your local machine to testers. They can sense if you’re weak. Stay strong! Let’s build a container and deploy it to the test stage. The test stage is running, right? If not, testers will bury you alive.
Have you ever heard of different databases? Yes, bro, it sounds cool. Okay. What about different data sources? Do you mean different databases? No. Think about configuration file and other folder paths. If you survive that, think about different event sources. What triggers what? What if a microservice retries something again and again? What if a microservice is in panic mode and another microservice tries to kill others? Who will survive? I wish for data or states. The flow of code is complicated. No matter how clean your code is.
Technology stack diversity. It’s a good thing. Right? I’m sure you hired all team members for the unknown new stacks. Learning a new programming language is fun, but in production, it’s hell.
Security vulnerabilities. New attack vectors or something like that. I’m not a security expert. Our security team opened many tickets for new vulnerabilities. I don’t understand most of them. Kidding! All I think about is features. What about features?
Cultural shift? We don’t have time for it. There is a bug in production! Not kidding!
You get the point. It is hard to deal with it. We have learned a lot, and we are still learning. All you need is to be prepared for what is coming for you. Features? They are accustomed to waiting.
Top comments (0)