It kind of depends. With microservices and the
patterns and support for them being relatively new, not all teams are able to "think in microservices" very effectively. For such a team to attack an app as a microservices-based app might result in a misapplication of the technologies and patterns and be worse than a monolithic implementation. It *might* be better for such a team to start with a monolith and then later peel off microservices.
That said, the benefits of microservices (there are many, but focused scalability and continuous delivery are the two that come immediately to mind) are great enough that it might be worthwhile to get up to speed with microservices and what is required before starting a new project and then deciding whether or not to go with microservices or a monolith.
I guess I can't say what the right approach is for a new project. It's not a one size fits all kind of thing. It depends on the team and the goals of the project. Personally, I lean toward microservices but that's more of a symptom of what I do day-to-day than it is a dogmatic application of microservices. I'd say that if the team does not have a good grasp on what is expected to develop microservices and doesn't have the time nor interest to get up to speed, then they should definitely go with a monolith. But if they feel that they have a grasp on it and if the project's goals justify it, then go for microservices.
The good news is that regardless of what you decide, Spring Boot is a fit for either.
