41–50 of 356 posts
Earlier quoted context omitted.
Scalability and stability. You need to process more requests? Launch more virtual machines, easy. Your microservice is a shit and it crashes every second? Don't care, it will be relaunched automatically.
We learned in the 90s to not distribute the objects and instead just spin up more copied of the whole application. And if only scalability is the point this is still valid.
Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer. Why call a function when you can wrap that function in an entire application and call it via API? Why have a single database when we can silo our data across 200 mini databases? Why have a single repo when we can have 200 tiny repos?
Don’t you find it weird that everybody else is either over or underengineering, but you , you engineer things exactly the right amount? I bet when you’re driving, you also tend to notice that everyone else is either an idiot driving way too slow in the middle lane or a maniac speeding past you. Nobody else drives as well as you do. It must be exhausting for these people to live in a world surrounded by strawmen, whil…
Don’t you find it weird that everybody else is either over or underengineering, but you , you engineer things exactly the right amount? I bet when you’re driving, you also tend to notice that everyone else is either an idiot driving way too slow in the middle lane or a maniac speeding past you. Nobody else drives as well as you do. It must be exhausting for these people to live in a world surrounded by strawmen, whil…
Microservices is a team organization technique, whereby disparate teams only communicate by well defined APIs. Any technology choices that come out of that are merely the result of Conway's Law. Any time you lean on code in a random GitHub repository, where you never speak to the author and just use the API you're given, you're doing microservices. This works well enough so long as the product does what you need of i…
> Any time you lean on code in a random GitHub repository, where you never speak to the author and just use the API you're given, you're doing microservices. So a library is a microservice now?
Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer. Why call a function when you can wrap that function in an entire application and call it via API? Why have a single database when we can silo our data across 200 mini databases? Why have a single repo when we can have 200 tiny repos?
Everyone already has a service based architecture whether they want to admit it or not. The question is the efficiency and granularity of it.
If you interface with any external systems that have data records (ERP, CRM, etc), your database is already spread out. You need to deal with it and be sure you understand the data efficiency and reliability of it.
I don't know what a monolith is that people talk about. Please show me one that doesn't talk to anything else.
Earlier quoted context omitted.
> Any time you lean on code in a random GitHub repository, where you never speak to the author and just use the API you're given, you're doing microservices. So a library is a microservice now?
Microservices is a collection of independent teams who only communicate using well defined APIs. Those teams may produce libraries, perhaps. That's up to Conway.
Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer. Why call a function when you can wrap that function in an entire application and call it via API? Why have a single database when we can silo our data across 200 mini databases? Why have a single repo when we can have 200 tiny repos?
Scalability and stability. You need to process more requests? Launch more virtual machines, easy. Your microservice is a shit and it crashes every second? Don't care, it will be relaunched automatically.
Companies that repeatedly fail to detect and solve this type of problem using automated testing and QA are exactly the companies that lack the sophistication to do distributed microservice architecture.
Learn to do proper CI/CD, end-to-end testing, and logging/metrics on your monolith before you decide to transition to microservices.