41–50 of 187 posts
Fully agree with the article. > "Best practices, not required practices" Is a thing mentioned from the article that I think many people forget. It also not only applies to programming or coding but rather to most things in life. Just because someone says it is best doesnt mean it is for you in your situation.
Earlier quoted context omitted.
It’s also a strategy to isolate failures and to use resources efficiently. I’ve had a very positive experience working on a team that deployed a collection of microservices. That said, it was large scale, and most of the “micro” services were only conceptually micro; they were large in terms of resource usage. We also had excellent tooling.
There are strategies other than microservices to break a problem up into small pieces, manage resources and isolate failures. I've consistently heard good things about Erlang/OTP.
If you have a monolith, you have less control over the service’s shape—the CPU, RAM, IO footprints. If you break it up into smaller microservices, the footprints are smaller and you have more options for how you schedule them.
There is a tradeoff here—services that are too small have high overhead. Services that are too large are inefficiently scheduled. Services that are way too large force you to spend money buying the massive machines needed to run them.
Earlier quoted context omitted.
> The point of the SO post is that, given a limited development time, they chose to focus on performance and sacrifice testability. I used to think that this was necessarily a choice for a long time, in fact I only very recently started writing almost TDD (not completely, there's things that I will still write code first, but no longer do I leave it untested, and I also don't see a problem in writing contained parts…
Something people rarely mention with tests is that their value has a Pareto distribution. Most of the value of a test suite will be captured by a small number of tests. (And inversely, most of your tests will never discover any bugs). The upshot of this is that you will get disproportionate value from the first few tests you add to a project. I think its very rare to have a long lived project in which the first 10 te…
I think the important question is what to be tested. I have written, even not that long ago, unit tests for a function that all passed in isolation and actually forgot to write a simple test with the context it would be called (which was very simple as well, but I just didn't), all isolated tests were good but the actual functionality was still broken.
I haven't been doing it extensively for a long time but for instance, if you have an user action that should update a record, write a job to be executed, then this should be tested. It's easy and does very small assumptions. You don't need to test how the record is updated or the job inserted, just that it happens. You might want to test that all failures provide correct error messages, but that is not as important as at least having the baseline of, if this action that is central happens both these things happen as well.
The argument against Tests sounds like a tooling problem to me. Why shouldn't a compiler be able to optimize the modular approach to the same code that a monolithic approach yields?
Why is that relevant? The fact is that it doesn't (there are good reasons for it, but that is another matter). You can't work with the ideal tools, you can only work with the tools that actually exist. So, with the actual tools, this sacrifice must be made. And now do answer your actual question, the reason is that the languages we use are just not expressive enough, and the compiler doesn't have enough time. If you…
Somewhere down the line, developers will start to realize that single applications running in the same server memory and CPU cache will run much faster than Micro services applications that makes api calls over the network. Depending on your organization scale of course, but for many smaller shops, there is a significant performance overhead of going over the network. Ie a Single binary running Rust/Go/Java/NodeJs vs…
Microservices can be advantageous but I don't think I've ever cited speed, unless I was talking about deployments and build times (which are definitely part of the conversation since architecture affects the entire SDLC). Usually my strongest points about microservices are about maintainability from the team perspective, reliability (if done right), and earlier parts of the SDLC like testing and build times. The cons are that you are usually having to maintain (and test against) very strong external contracts, inner-service knowledge is strong due to a smaller codebase but often times developers have very little intra-service knowledge (they don't understand the big picture, which is important), and many times codesharing is tricky or just not possible.
Earlier quoted context omitted.
It’s also a strategy to isolate failures and to use resources efficiently. I’ve had a very positive experience working on a team that deployed a collection of microservices. That said, it was large scale, and most of the “micro” services were only conceptually micro; they were large in terms of resource usage. We also had excellent tooling.
There are strategies other than microservices to break a problem up into small pieces, manage resources and isolate failures. I've consistently heard good things about Erlang/OTP.
Somewhere down the line, developers will start to realize that single applications running in the same server memory and CPU cache will run much faster than Micro services applications that makes api calls over the network. Depending on your organization scale of course, but for many smaller shops, there is a significant performance overhead of going over the network. Ie a Single binary running Rust/Go/Java/NodeJs vs…
https://colin-scott.github.io/personal_website/research/inte...
It can be faster to read over the network than to read from a hard drive.
Somewhere down the line, developers will start to realize that single applications running in the same server memory and CPU cache will run much faster than Micro services applications that makes api calls over the network. Depending on your organization scale of course, but for many smaller shops, there is a significant performance overhead of going over the network. Ie a Single binary running Rust/Go/Java/NodeJs vs…
Architectures and scalability, although related, are two different conversations. You could build a monolith with an internal messaging queue, this obviously limits scaling possibilities horizontally but may be able to scale vertically. If you externalize the queue and use something like Rabbit, Redis, or NATS then you have more options but you also have more/new problems. Not all things need to scale, and not all th…
Let me guess. Vertically, bigger computer, horizontally, more computers?
These cloud business speaks is getting to my head.
Earlier quoted context omitted.
Architectures and scalability, although related, are two different conversations. You could build a monolith with an internal messaging queue, this obviously limits scaling possibilities horizontally but may be able to scale vertically. If you externalize the queue and use something like Rabbit, Redis, or NATS then you have more options but you also have more/new problems. Not all things need to scale, and not all th…
> scaling possibilities horizontally but may be able to scale vertically Let me guess. Vertically, bigger computer, horizontally, more computers? These cloud business speaks is getting to my head.
But these terms are way older than any cloud-computing and go back many many years.