71–80 of 139 posts
My thoughts on microservices... They're fine. But what's NOT fine are nano services. I did security on a project once where it seemed that every function was its own microservice. User registration, user login, and password resetting were each a separate microservice. It was an utter nightmare.
user-registration.api.dev.my-company.com
user-login.api.dev.my-company.com
password-reset.api.dev.my-company.com
or paths by some huge k8s nginx ingress?
Microservices are not a solution, they're a capability. It's powerful for a team to be able to deploy a tiny service with the absolute minimum amount of explicit plumbing to meet operational requirements. Whether they should break their system up this way is a case by case judgment. Every place I've been, the costs of microservices get overlooked in favor of the illusion of decoupling. Microservices will absolutely m…
Your first question in a job interview should be: "do you use microservices?" If the answer is yes, you can save yourself a lot of time.
Earlier quoted context omitted.
Fails because the function is unreachable. The second half of the sentence you quoted says exactly that, why did you cut it out?
If execution of your binary is stopped some time between the call and return (with following restart), dealing with it is no simpler than dealing with network partitioning.
One should probably not even think of microservices if one employs fewer than 100 programmers. In many cases microservices are introduced because of fashion and/or resume driven design not because it actually makes sense. I prefer refactoring a poorly structured monolith to refactoring poorly structured microservices in every case.
Having to push back on that over and over was frustrating.
We didn’t even have a real devops guy, or a vpc with properly partitioned CIDR blocks to segregate our databases from the public web and we’re going to start adding the complexity of a microservice architecture?
For what! We didn’t even have _users_ yet.
But try to get folk to dogfood our application since we had no actual users besides the founder and it was like pulling teeth.
Totally backwards to me.
Fundamentally, I don't really see much difference between monoliths and microservices. In a monolith, you just call another function/class, but in microservices that function is a http call. I guess the benefit of microservices is the ability to independently scale different microservices, being able to choose different languages for different microservices and less conflicts in the repo as more people work on it, bu…
There’s a huge difference between http and function calls. When I call a function there is no chance it fails because the function ‘cannot be reached’. With services there are endless reasons why one service is unable to communicate with another. It’s a huge amount of overhead to build a system to handle inter-service communication and failure that doesn’t exist when only calling a function in the same binary.
Run time DI configured from XML.
With enough Java anything is possible!
My thoughts on microservices... They're fine. But what's NOT fine are nano services. I did security on a project once where it seemed that every function was its own microservice. User registration, user login, and password resetting were each a separate microservice. It was an utter nightmare.
My thoughts on microservices... They're fine. But what's NOT fine are nano services. I did security on a project once where it seemed that every function was its own microservice. User registration, user login, and password resetting were each a separate microservice. It was an utter nightmare.
Did they do this? user-registration.api.dev.my-company.com user-login.api.dev.my-company.com password-reset.api.dev.my-company.com or paths by some huge k8s nginx ingress?
An interesting list, but is this specific to Microservices, or just Service Oriented Architecture in general? For me, other than the obvious size difference, the difference between microservices and "large" (?) services is that a single team breaks down their domain into sensible layers, abstractions etc.
A single team can break down their domain into sensible layers and abstractions within a monolith. Similarly, A microservices/SOA architecture can fail to break down their domain into good boundaries and abstractions. I've seen this happen a lot. It's a lot harder to fix bad microservices than to fix a bad monolith
I think certain things are easier to change in a monolith, where as other things are easier to change in a service based design. Depends what mistakes you've made along the way or how the spec/environment changes.
Earlier quoted context omitted.
I like them for modularity, message queues and asynchronous events. But you are correct, esp. last one.
Plenty of languages offer modularity, message queues and asynchronous events within a monolith. They are quite idiomatic in go, rust and elixir
I mean yes, I know that each of these problems can be solved, sometimes in a relatively straightforward manner. But who really has all these aspects covered and doesn't run some services that started to smell weirdly a couple of months ago?