Hello fellas!

I've started learning about microservice architecture a few months ago,and I've noticed that despite the drive in some quarters to make microservice architectures the default approach for software, I feel that because of the numerous challenges (e.g low coupling and high cohesion between microservices), adopting them still requires careful thought.

Given the importance of defining stable service boundaries,we might consider that microservice architectures are often a bad choice for brand-new products or startups.the domain that we are working with is typically undergoing significant change as we iterate on the fundamentals of what we are trying to build. This shift in domain models will, in turn, result in more changes being made to service boundaries, and coordinating changes across service boundaries is an expensive undertaking.
In general,it is more appropriate to wait until enough of the domain model has stabilized before looking to define service boundaries but the question is :

"if we're really successful and we're in the right path,we'll need to scale so why not building a scalable architecture from the begining?"

The problem is that we don't necessarily know if anyone is even going to want to use our new product. And even if we do become successful enough to require a highly scalable architecture, the thing we end up delivering to our users might be very different from what we started building in the first place. Uber initially focused on limos, and Flickr spun out of attempts to create a multiplayer online game.

The process of finding product market fit means that we might end up with a very different product at the end than the one we thought we'd build when we started. The challenge of microservices for startups is compounded by the fact that normally the biggest constraint is people. For a small team (1-5 startup), a microservice architecture can be difficult to justify because there is work required just to handle the deployment and management of the microservices themselves. When that investment benefits lots of people, it's easier to justify. But if one person out of your five-person team is spending their time on these issues, that's a lot of valuable time not being spent building your product. It's much easier to move to microservices later, after we understand where the constraints are in our architecture and what our pain points are—then we can focus our energy on using microservices in the most sensible places.

Finally,I think that a five-person startup is likely to find a microservice architecture a drag.A hundred-person scale-up that is growing rapidly is likely to find that its growth is much easier to accommodate with a microservice architecture properly aligned around its product development efforts.
What do you think about it ?any suggestions about architectures that suits (works) well with startups ?