281–290 of 356 posts
Earlier quoted context omitted.
Why yes, I have. It is essentially impossible without the (sadly rare) design pattern that I gave at https://news.ycombinator.com/item?id=26016854 .
You might be interested in OpenTracing/OpenTelemetry, in case you’re not aware of it: https://opentracing.io/
If I am ever unfortunate enough to work on a microservices architecture again, I'll see if I can get it used.
Earlier quoted context omitted.
When the same practices used to sell microservices get applied to modules, packages and libraries, there is no need to put a network in the middle to do the linker's job. But too many are eager to jump into distributed computing without understanding what they are bring into their development workflow and debugging scenarios.
I've been trying to get buy-in from colleagues to have stricter boundaries between modules but without much success, mainly because I don't fully understand how to do it myself. Let's say we have 3 different modules, all domains: sales, work, and materials. A customer places an order, someone on the factory floor needs to process it, and they need materials to do it. Materials know what work they are for, and work kn…
If I understand your example, the usual solution is to separate your business objects from your business logic, and add a data access layer between them.
In terms of dependencies, you would want the data access layer module to depend on the business object modules. And your business logic modules would depend on both the data access layer and business object modules. You may find that it is ok to group business objects from multiple domains into a single module.
Note that this somewhat mirrors the structure you might expect to see in a microservices architecture.
Earlier quoted context omitted.
As someone who is new to Go and learning actively, do you have an example of how this would look?
Sure. First you'll need to familiarize yourself with interfaces in go. This link explains them well. https://gobyexample.com/interfaces So a struct satisfies an interface if it implements all of the methods of the interface. The example you see in the above link is a monolithic design. Everything only exists in one place and will be deployed together. So if the functions for circle were getting hit really hard and we…
Earlier quoted context omitted.
Sounds like you're saying "Don't do distributed work" if possible (considering tradeoffs of course, but I guess people just don't even consider this option is your contention). And secondly, if you do end up with q distributed systems, remember how many independently failing components there are because thag directly translates to complexity. On both these counts I agree. Microservices is no silver bullet. Network pa…
I'm not reading this as "Don't do distributed work". It's "distributed systems have nontrivial hidden costs". Sure, monoliths are often synonymous with single points of failure. In theory, distributed systems are built to mitigate this. But unfortunately, in reality, distributed systems often introduce many additional single points of failure, because building resilient systems takes extra effort, effort that oftenti…
You'll also likely use multiple databases (caching in e. g. Redis) and a job queue for longer tasks.
You'll also probably already have multiple instances talking to the databases, as well as multiple workers processing jobs.
Pretending that the monolith is a single thing is sneakily misleading. It's already a distributed system
Earlier quoted context omitted.
Monoliths are also distributed systems and will run on multiple hosts, most probably co-ordinating on some sort of state (and that state management will need to take care of concurrency, consistency). Some hosts will go down. Service traffic will increase. I understand your point. You are using distributed in the sense of "how is one big work distributed", you probably also hate overly "Object Oriented code" for simi…
Different kinds of distributed systems have wildly different complexity in possible fun that the distributed nature can cause. If you have a replicated set of monoliths, you typically have fewer exciting modes of behaviour and failures. Consider how many unique communciation graph edges and multi hop causal chains of effects you have you have in a typical microservice system vs having replicated copies of the monolit…
If you've done your work correctly you get almost no distributed system problems. For example, you might be pinning your users to a particular app server or maybe you use Kafka and it is Kafka broker that decides which backend node gets which topic partition to process.
The only thing you need then is to properly talk to your database (app server talking to database is still distributed system!), use database transactions or maybe use optimistic locking.
The fun starts when you have your transaction spread over multiple services and sometimes more than one hop from the root of the transaction.
Earlier quoted context omitted.
This! Service boundaries are vital and almost intractable to design up front as you won’t be sure of your systems’ use cases. I’ve worked on numerous micro services systems and all of them were designed in such a way that data loss and unknown error states were mandatory. Micro services seem simpler, but are actually harder than my methodology “as few services as necessary” + bounded contexts within them. Using netwo…
This is why Domain Driven Design should be mandatory reading for all anyone making decisions on Software Architecture.
As pervasive and helpful and as easy to understand what Clean Code is, it is still very rare to find someone who understands it and applies it in the field.
Earlier quoted context omitted.
This. One million times this. I’ve been developing for more years than dime if you have lived, and the best thing I’ve heard in years was that Google interviews were requiring developers to understand the overhead of requests. In addition, they should require understanding of design complexity of asynchronous queues, needing and suffering from management overhead of dead letter, scaling by sharding queues if it makes…
I mean, you can always deploy your microsevices on the same host, it would just be a service mesh. Adding network is not a limitation. And frankly, I don't understand why you say things like understanding network. Like reliability is taken care of, routing is taken care of. The remaining problems of unboundedness and causal ordering are taken care of (by various frameworks and protocols). For dlq management, you can…
I keep saying this every time this topic comes up, have a look at elixir/erlang. The OTP library gives some great reusable patterns (and elixir project is adding new ones[1]) out of the box. You're basically developing a single codebase microservice project which feels like a monolith. You can spread out on multiple machines easily if you need to, the introspection tooling is better than anything you can buy right no…
And Erlang runtime) is used in massive telephone switches, famously AXD301 which is claimed to have uptime percentage of 99.9999999% over 20 years.
- from Erlang Programming by Simon Thompson, Chapter 1
Earlier quoted context omitted.
Does each microservice/module have its own db?
Nope. Everything lives in one big DB, but services are not allowed to touch each others tables directly - communication must be done through service API endpoints.