201–210 of 272 posts
Microservice architecture is a deployment strategy.
If you have a problem with deployments (eg large numbers of teams, perhaps some external suppliers running at different cadences, or with different tech stacks) the microservices are a fine solution to this.
Earlier quoted context omitted.
This is also why app backends don't really need statically typed languages, no matter how big the company is. You have a well-defined API on the front, and you have a well-defined DB schema on the back, that's good enough. The static typing makes even less sense at finer code scopes, like I don't need to keep asserting that a for-loop counter is an int.
Statically typed languages, when used correctly, save engineering time both as you extend your service and when thing go wrong as the compiler helps you check that the code you've written, to some degree, meets your specification of the problem domain. With a weak type system you can't specify much of the problem domain without increased labour but with a more expressive type system (and a team that understands how t…
Indeed "any" breaks type checking all around it, but it can be contained more easily in a helper func with a simple return type. Most common case is your helper does a SQL query, and it's tedious and redundant to specify the type of rows returned when the SQL is already doing that.
Earlier quoted context omitted.
> Every situation should be evaluated on merits. This came across that there is also an assumption that we didn't try other solutions first - we absolutely did. I completely agree. But this a little bit contradicts with your original comment that caught my eye: > In my experience, a good rule of thumb[0] is if there are actual benefits from being a standalone service. A rule of thumb is, by nature, a generalization —…
>I completely agree. But this a little bit contradicts with your original comment that caught my eye: Its a good rule of thumb that you may want to evaluate if a microservice is appropriate. Thats the point in context[0]. If you think it might be a relevant solution, that is a pretty good heuristic that evaluating it may be worth the time. What I seem to be coming up against when discussing this is people conflate wo…
For example you may be forced to split out some components into separate services because they require a different technology stack to the monolith, but that doesn't strictly require a separate source code repository.
Earlier quoted context omitted.
> Every situation should be evaluated on merits. This came across that there is also an assumption that we didn't try other solutions first - we absolutely did. I completely agree. But this a little bit contradicts with your original comment that caught my eye: > In my experience, a good rule of thumb[0] is if there are actual benefits from being a standalone service. A rule of thumb is, by nature, a generalization —…
>I completely agree. But this a little bit contradicts with your original comment that caught my eye: Its a good rule of thumb that you may want to evaluate if a microservice is appropriate. Thats the point in context[0]. If you think it might be a relevant solution, that is a pretty good heuristic that evaluating it may be worth the time. What I seem to be coming up against when discussing this is people conflate wo…
> What I seem to be coming up against when discussing this is people conflate worthwhile evaluation with worthwhile solution.
> It doesn't equate to saying microservice is the solution if it meets that one criteria, only don't rule it out.
I read the article, it's not against microservice architecture itself, but points out that you shouldn't treat them as a starting point or a best practice.
There is even a section named "When Microservices Do Make Sense". It also highlights examples where microservices make sense ("Their post is a good example of how microservices can work when you have the organizational maturity and operational overhead to support them."), so I really do not see where does anyone rule out, dismiss, come up against anything.
I somewhat understand and agree what you are trying to argue against, but that's definitely not in this article.
> Its a good rule of thumb that you may want to evaluate if a microservice is appropriate.
This is too general to be practically useful — it applies to almost everything in life.
Earlier quoted context omitted.
Statically typed languages, when used correctly, save engineering time both as you extend your service and when thing go wrong as the compiler helps you check that the code you've written, to some degree, meets your specification of the problem domain. With a weak type system you can't specify much of the problem domain without increased labour but with a more expressive type system (and a team that understands how t…
The type system almost never catches a bug that proper testing would miss. And if the code has such nasty untested edge cases that you don't even notice a wrong type going somewhere, it'd probably behave wrongly even with the right types. Indeed "any" breaks type checking all around it, but it can be contained more easily in a helper func with a simple return type. Most common case is your helper does a SQL query, an…
Earlier quoted context omitted.
Some resume driven developers will choose microservices for startups as a way to LARP a future megacorp job. Startup may fail, but they at least got some distributed system experience. It takes extremely savvy technical leadership to prevent this.
Hiring will need to change to stop resume-driven development (can't eliminate it completely though), because you're likely to only get monolith roles if you only work on monoliths. Only being able to speak about microservices puts you in the "talk the talk, not walk the walk" category. It would also nice to have less fear-driven career advice like "your skills go out of date" which drives people to try adopting the l…
Earlier quoted context omitted.
> If it is possible for that other team to merge a broken build, you are doing it wrong. This assertion is unrealistic and fails to address the problem. The fact that builds can and do break is a very mundane fact of life. There are whole job classes dedicated to mitigate the problems caused by broken builds, and here you are accusing others of doing things wrong. You cannot hide this away by trying to shame software…
I haven't seen a broken build in at least nine years, not since I left the company with a merge process built out of bash scripts that took three hours and required manual hand-holding. I am genuinely curious what situations you are seeing where builds are making it through CI and then don't compile. It isn't always worth investing in quality, but when it is it is entirely possible to write essentially bug-free softw…
You lost what little credibility you had left.
Earlier quoted context omitted.
Btw, do any good, modern CI tools support incremental rollout of multiple in-flight changes on monoliths? As in patch A is live, team B wants to rollout A+B and team C wants to rollout A+C. Ideally, A+B+C will eventually go live. Do cloud/paas providers deeply support this flow anymore? Every dashboard would need to compare across multiple live versions and I haven't tried that in a while.
Wouldn't these just be different branches?