My company built from the ground up with micro-architecture and it is an unmitigated disaster. Totally unnecessary, mind-numbing problems unrelated to end-user features, unpredictability at every step, huge coordination tax, overly-complex deployments, borderline impossible to re-create, >50% energy devoted to "infrastructure", dozens of repos, etc.
The whole thing could be trivially built as a monolith on Rails/Django/Express. But that's not exciting.
Interestingly, the Sam Newman book about Microservices specifically says it's easier to succeed by starting with a monolith that you then break up. That advice does seem to be ignored by people who want a microservice architecture because it looks good on their CV, or because they think it will magically solve a bunch of hard problems they don't know how to solve.
The best place to place a module boundary - and the best format for communication across that boundary - is rarely completely transparent from the outset. With a monolith it's relatively easy (if not actually easy) to fiddle with those details until you get them right. With a service it can be very difficult to iterate on this stuff, so unless you're very confident you'll get it right on the first try, it's best to get a bit of experience in the problem domain first.
I think microservices can work well, but also agree that it's easier to start with a monolith. It's hard to go out and create perfect microservices. In my experience they emerge from the problem much like how an amoeba gets big and breaks off at natural points.
We were also built from the ground up with microservices and had the exact opposite experience. Faster shipping (more value to end users), more predictability (APIs designed/behaved similarly across functions despite polyglot tech), much less coordination overhead (deployed dozens of times per day with a < 10 dev team, pre-release backends well in advance of the user-facing parts), etc. We had to invest a lot in infrastructure, but that was worth it for many other reasons as well. Dozens of repos is annoying, but not for a technical reason (a lot of SaaS like Bugsnag and GitHub used to charge by project).
The biggest downside is it makes shipping an on-prem version nearly impossible. The infrastructure and the software are so inextricably linked that it is not portable in the least bit.
We ship a microservices-based product on-premises. You can do it, but it's a heck of a lot of work. Plus you don't get any of the benefits microservices might bring in a CD scenario: you can't do CD over an airgap.
One of the ways we managed to get a microservices system on prem (vSphere or Openstack) is to configure it with a system that can handle the whole provision/build/configure/deploy as a single unit: http://bosh.io .. though the learning curve was steep.
What was the system? Was this at or involving Pivotal? If not, this would be the first non-Pivotal use of BOSH I've heard of, which would be very exciting!
Tell me about it. Exactly same situation here. You forgot the fact that they're paying 1k+ for AWS for all these services where if it was a normal application it would've cost around 100 bucks.
I suppose there's a difference between the "from the ground up micro-architecture" and "using a micro service or two" that should really differentiate the various "should we use microservices?" discussions.
Several sites I'm aware of have an Facebook-style chat service, which is basically an off the shelf node app on its own. This makes far more sense than trying to build such a thing into their legacy app. It also perfectly describes a very useful micro service, in a very different environment to yours.
The whole thing could be trivially built as a monolith on Rails/Django/Express. But that's not exciting.