Will you use a gun to kill a fly? The answer is NO. The same thing goes when you want to write a microservice application that is going to be maxim...
For further actions, you may consider blocking this person and/or reporting abuse
It’s indeed an interesting read! Just to offer a different take, I’d say that it really holds about the infrastructure, but that the business rules have to live somewhere. And even considering only one part of the business domain is in each micro service, it still should abide by good code design principles.
Because when it comes the time to “add just that new feature”, you’ll want to have your code flexible enough to sustain it, and not go make another service because, well, things are getting too messy. (I’m not saying that’s what you propose, though) That way you’d be just transferring code complexity to orchestration complexity, and an http mess...
So, if it’s an OO language, I think you should take just enough time to model your domain properly, put the necessary interfaces in place, use the appropriate design patterns, and then go do your next thing. A micromess is still a dangerous mess, and a pretty micro application is probably never going to bite back at you.
Does it make sense to you?
Thanks for the insightful reading!
Yes some parts you wrote surely makes sense. The thing about http level complexity tools like kuberernetes help a lot to handle it. Thanks for your views.
I agree with what you are saying. However, I've run into two issues with this when writing corporate in-house services in the .NET environment.
First, the repository pattern as done with Entity Framework has become so prevalent that any other solution or pattern is immediately regarded as "wrong". This means adding a considerable amount of ORM design and coding overhead where it may not be needed.
Second, you are rarely working with a totally new system. Instead, there's almost always a huge technical debt of legacy systems. Most of them have been built up over many years with feature after feature being added, sometimes in a haphazard fashion. This has led to tight coupling and a resistance to making changes because of what that refactoring would break.
I think you have already made it clear with "corporate in-house services" which are surely not microservices. And if you are not working with totally new systems are they even microservices? :)
Part of our goal is to reduce the current technical debt by moving legacy to a new microservice architecture. However, there is considerable legacy code that has to be kept running while this new work is being done. The challenge is to create the new service structure while keeping the old, which is everything from old VB6 desktop apps to tightly coupled WCF services, running. This creates considerable drag on our development process due to the fragility of these old systems and resistance to making changes. I think this is something anyone working in a environment that's been in production a long time is going to encounter.
Yes. Looks like you need find a new and better place to work may be :).
It's a great place to work. They are making a huge investment in upgrading technology. But there's a lot of work to be done and there are some challenges.
Thank you for the TLRD.
Speaking of the subject, I saw a talk recently
in which gave an example of monolith-services, which had only 1 instance and communicating sync with the other monoliths. It was a horror image, never thought that someone could achieve that :)
Also like the talk said, micro services were created to scale an organization, and less about the code (See Amazon 15yrs ago). If you have less then 100s developers the operational overhead of services will be a big % of your workforce, that if you do not use managed services like AppEngine and such.
There are multiple ways to look at it. In my previous work we were 10 backend devs and 2 devops/SRE people responsible for ~150 microservices running on k8s. At the end it is generally about code ;).
Sounds great, is there an article or talk about it somewhere? Sounds like a good win over a complex problem. Most of the stories I know had 10devs only for operational glue at that scale.
I can write a talk if this topic deserves more attention :) thanks!
Interesting read.
Thanks.
Lol blast radius!