Microservices are hard
11–20 of 356 posts
Re: Microservices are hard
#12Re: Microservices are hard
#13Or as I like to say "Oh, you have a big ball of mud in your monolith because of poor design and want to move to micro-services?"..."now you have n^n big balls of mud" Poor design is poor design, adding more complexity just makes it a more complicated poor design.
All these design pattern and methodology fads are attempts to get around the simple truth you stated, and one other: No design pattern or methodology will make bad programmers write good code. The only solution for poor skills is practice, education, and experience.
Re: Microservices are hard
#14Microservices - 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?
Re: Microservices are hard
#15Microservices 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…
Re: Microservices are hard
#16I 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, while they alone have achieved perfection. Which they will detail how they do in a later blogpost.
Re: Microservices are hard
#17Microservices - 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.
Re: Microservices are hard
#18Microservices 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…
So using your definition what is the difference between a module, a service, and a microservice ?
Re: Microservices are hard
#19No need to run a microservice just to make some function call.
Re: Microservices are hard
#20I'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…
The problem with standardizing these things is, that it makes them hard to change. A breaking change in the way you deploy must also work for all other solutions - otherwise you immediately loose your standardization. And this will happen eventually. For all this different kind of problems it is near impossible to avoid inconsistency and force rules on them. So, imo you either have a (very) large organization with in…
If the repo builds a container and the service provides a health endpoint, we are good.
My company has 10 - 15 developers and we are at about 10 macro/microservices.
One should definitely not create a new service for every function call but some seperation works quite well on our side.