One of the big ones: For a small startup, granular microservices are often very premature, and will slow you down rather than speed you up.
To my mind, services like Lambda are perfect for startups. In addition to scaling down, costing nothing when unused and allowing rapid iteration with zero operational concerns, they largely scale up and, in the unlikely event that the startup is wildly successful, they'll handle almost any load you throw at them until you've had time to re-engineer the backend to be more economical for the increased load.
Microservices do require more overhead. Additionally, they require you to be familiar enough with you business logic to know where you boundaries lie - changing abstraction boundaries is much harder with microservices than with a monolith.
I think that while they are great for scaling, they are a lot harder to use to successfully get off the ground (though I'm betting that there are places that have successfully done so)
you can scale the base app by giving it more hardware, but when you have to batch process lots of stuff then think of services (most of the time you can just split that to another server).
Yeah. A starting monolith, some cronnish way to run batches, and some way to listen to queues goes a long way.
There's a new alternative: write it in Elixir/Phoenix. You'll get the same productivity benefits with none of the performance trade-offs. Elixir apps are reliable and concurrent by default, and the Phoenix framework has none of the "magic" that Rails has, making it very developer-friendly. :)
This isn't to say that Elixir/Phoenix are perfect. The ecosystem isn't as mature as that of Ruby/Rails, so finding answers to questions can take a bit longer. But that is changing quite quickly.
Fwiw, I've been pretty intrigued by the idea of dotnet on linux lately (integrates with postgresql and everything). dotnet isn't exactly hip, but C# is fast and it's mature (and has some pretty dope functionalish features. You can run F# if you want to, too). Planning to try how well this works in practice soon.
There are things I like a lot about Elixir, but also plenty that I'm not quite a fan of.
There is a case to made to switch ruby/rail for php/laravel. Just as rapid for development and easier scaling plus bigger ecosystem. There is also a case to be made for switching Django for vue or even simple jquery in some cases.
This growth journey makes more sense than starting out the door working on your microservices before business logic as this is like putting the cart before the horse.
Instead, people should start splitting up the monolith into sensible modules and libraries. Instead of a "user accounts microservice", start with a "user accounts library" with a well-documented API that stays in the main codebase and is deployed as part of the rest of the app.
Microservices sound ideal at first because it's easy to not see that the brunt of the effort is not writing the first version but monitoring, maintaining, and handling when some go down. By using microservices one introduces additional edge cases that don't exist in a "monolith". Quotations around monolith because I believe startups use it with some exaggeration. For example, a Django project of ~10k LoC might be composed of 15 separate Django apps behind one API and I don't see this as monolithic.
If you're switching languages/stacks just for funsies, you're going to make services more difficult to maintain over time (and just generally slow down development)
As far as languages go, pick one. When you hit a problem that absolutely cannot be reasonably solved under the specifications you care about, consider a different one for that service. Apart from that, there's little value, and lots of overhead, in moving. Getting to write that one Haskell microservice is sure a romantic idea, until that employee leaves and nobody knows Haskell anymore, and suddenly the service is dysfunctional because dependencies have changed. (For non-mission-critical funsies, sure, use whatever, though non-mission-critical apps tend to have a knack for becoming very important for workflows, hah)
Having nice hard boundaries that you can't just penetrate can aid and abet you in debugging.
It also probably helps you with respect to managing security.
As in most things, good judgement is key.