81–90 of 356 posts
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 - 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?
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.
>Your X is a shit and it crashes every second? 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.
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…
The most dangerous thing about microservices is that many people squee when they hear "You can write 45 different microservices in 35 different languages". Writing a new microservice? What a great opportunity to learn a new language!
Now it is true that by decoupling the address spaces microservices do let you take advantage of different runtime systems: you might really want access to scikit-learn in Python, for instance, certain libraries available in Java, but also like the speed of Go. That's alright, to a point.
If a microservice system is going to be maintainable you need to minimize the excessive complexity of using different libraries and frameworks for build, configuration, serialization, logging, database access, and other cross cutting concern. To the extent that that stuff is standardized the programmer who works on service Q can do some work on service B and be focused on the application instead of having to do a research project on where to put a configuration variable or log a message.
It's hard to do because in the microservice environment people seem to get a lot of joy out of not being disciplined, will make endless excuses why they can't update the version of the language they are using, etc. It's the kind of freedom that Orwell warned you about.
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?
The move to microservices is often more about scaling change management when an organization grows from tens to hundreds of engineers. Change management becomes the bottleneck when organizations exceed Dunbar's Number, and a "reverse Conway maneuver" is needed to counter excessive cost of coordination. https://cloud.google.com/architecture/devops/devops-tech-arc...
My question then is: is this type of growth the norm, or is it exceptional? If I am, say, Tesla... do I need 1 order of magnitude more sw engineers when I start selling 10 times the cars I was selling 2 years ago?
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?
So you embed S3 into your app? Do you embed your ERP system? How about your marketing e-mail system? Your CRM? Do you use an in-process database? 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…
Earlier quoted context omitted.
Monoliths can also scale horizontally and be restarted automatically when they fail. No need for microservices for that.
> Monoliths can also scale horizontally At a (potentially much) bigger cost.
I'd say it doesn't have to be. There is a certain kind of "freedom" that is really slavery, but people feel so free when they hear about it is they often squee and hurt themselves with uncontrolled movements. Microservices can be that way. Now that you have 25 different services in 25 different address spaces you can write them in 11 different languages and even use 4 versions of Python and 3 versions of Java. (I got…
You don’t have to standardize build or deployment or configuration. For serialization, you can use something like GraphQL which will enforce types. For logging, you need distributed tracing which services like Sentry have good support of.
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…
I get the feeling he really misses the point. The most dangerous thing about microservices is that many people squee when they hear "You can write 45 different microservices in 35 different languages". Writing a new microservice? What a great opportunity to learn a new language! Now it is true that by decoupling the address spaces microservices do let you take advantage of different runtime systems: you might really…
Being able to use different stacks where appropriate is also great (but needs care). E.g. if you are a Java shop but you want to deploy an ML pipeline you should at least consider carving out a pathway for deploying python microservices.