3 ms·

> The biggest problem I have with microservice is that they lock you into a particular data flow up front. You say that as if that's an unalterable fact. > No

> The biggest problem I have with microservice is that they lock you into a particular data flow up front. You say that as if that's an unalterable fact. > No battle plan survives contact with the enemy, and microservices are making decisions early on that are difficult to change later. Because you've picked one decomposition and then erected fences around the parts. If you know about that problem, then don't do that! :P In my experience, if you slice your microservice boundaries with the philosophy that each of them should be able to be sold as a white label product (or more realistically be reused for a completely different product internally), microservices can survive pretty large pivots of the startup/project with little changes.

ojosilva 9y ago
I agree. Microservices enable startups to pivot very easily, or to implement or diverge into new sales channels quicker than with monolithic solutions. The same applies to larger business. With microservices, ie. large banks can easily offer API services, enabling new revenue streams that were nearly impossible to offer before. Microservices are an excellent way to deal with future changes. The unknown unknowns like some would put it.
- JamesBarney 9y ago
  What size start-up do you think is benefited by a microservices architecture?
  - hobofan 9y ago
    If you have people that are experienced with microservices I think it can even benefit a 2 person team. The anecdote that comes with that: I joined a startup as the second developer. The first developer built everything in a microservices architecture with the background that we were supposed to grow as a devteam significantly in the next 6 months. One of my first tasks was setting up CI/CD for the microservices so we can launch the product, which is a pretty routine setup for me since I've done the same thing ~5 times before. Then startup things happened and we stayed a 2 person team for a long long time. In the beginning, I was skeptical if the microservice architecture was really the right choice there, but overall I think we came out ahead. There were a lot of instances where we needed to upgrade libraries to fix some bugs or get some newer features and only had to upgrade very little of the whole codebase, allowing us to iterate faster. This would not have been possible in a monolith. We also experienced some of the microservices downsides, like slower refactoring and network connections being less reliable than in-process function calls, but with the right approach and tools, they were not much of a problem. Microservices are not a free lunch, but they can be a cheap and tasty one.
lmm 9y ago
> In my experience, if you slice your microservice boundaries with the philosophy that each of them should be able to be sold as a white label product (or more realistically be reused for a completely different product internally), microservices can survive pretty large pivots of the startup/project with little changes. Once you're at the point of having multiple products you've already made it past the valley of death. In my experience you only understand the system well enough to be able to decompose it correctly if it's already working end-to-end.
JamesBarney 9y ago
Split into what you imagine your different white label products to be? Or split into what the market has proven your white label products will be?

ojosilva 9y ago

I agree. Microservices enable startups to pivot very easily, or to implement or diverge into new sales channels quicker than with monolithic solutions. The same applies to larger business. With microservices, ie. large banks can easily offer API services, enabling new revenue streams that were nearly impossible to offer before. Microservices are an excellent way to deal with future changes. The unknown unknowns like some would put it.

JamesBarney 9y ago
What size start-up do you think is benefited by a microservices architecture?
- hobofan 9y ago
  If you have people that are experienced with microservices I think it can even benefit a 2 person team. The anecdote that comes with that: I joined a startup as the second developer. The first developer built everything in a microservices architecture with the background that we were supposed to grow as a devteam significantly in the next 6 months. One of my first tasks was setting up CI/CD for the microservices so we can launch the product, which is a pretty routine setup for me since I've done the same thing ~5 times before. Then startup things happened and we stayed a 2 person team for a long long time. In the beginning, I was skeptical if the microservice architecture was really the right choice there, but overall I think we came out ahead. There were a lot of instances where we needed to upgrade libraries to fix some bugs or get some newer features and only had to upgrade very little of the whole codebase, allowing us to iterate faster. This would not have been possible in a monolith. We also experienced some of the microservices downsides, like slower refactoring and network connections being less reliable than in-process function calls, but with the right approach and tools, they were not much of a problem. Microservices are not a free lunch, but they can be a cheap and tasty one.

lmm 9y ago

> In my experience, if you slice your microservice boundaries with the philosophy that each of them should be able to be sold as a white label product (or more realistically be reused for a completely different product internally), microservices can survive pretty large pivots of the startup/project with little changes. Once you're at the point of having multiple products you've already made it past the valley of death. In my experience you only understand the system well enough to be able to decompose it correctly if it's already working end-to-end.

JamesBarney 9y ago

Split into what you imagine your different white label products to be? Or split into what the market has proven your white label products will be?