You need some logic that depends on whether you're running the software yourself as SaaS or whether the software is run by a customer, but both more monolithic and more service-oriented approaches can satisfy this.
It makes good architectural sense to have different modules for these two cases, instead of having if/else branches throughout your entire code base. But how you implement this modularization is up to you.
In a microservice architecture, you might have different services that provide the same interface, and you configure your software via some orchestration tool (e.g. Kubernetes, or simply an environment variable) to tell it which service to connect to.
In a more monolithic architecture, you might have two classes or plugins that implement the same interface, and select the appropriate implementation at startup (e.g. via an environment variable, or by providing a plugin file with a particular name, or by selecting the appropriate behaviour at compile-time).
All of the code-level architectural advantages you can get from microservices, you can also get in a monolithic architecture by using modularization and OOP techniques. You only really need microservices if you (a) want to develop services independently, such as by different teams in a large organization, or if different services use incompatible technologies, or (b) if you want to deploy and scale the different services independently, such as having 1 instance of service A but 143 servers running service B.
This also means that going full monolith or full microservice is not necessary – they are extreme ends on a gradient of architectures. You can have a mostly monolithic application that just extracts one part as a service that you want to scale separately. You can have services that are not “micro”. A monolith will still have some internal architecture and sub-components, they are just part of the same process and are not spread across a distributed system. In many cases, a bit of multithreading and some OOP techniques achieves many of the same benefits that microservices would bring.
It usually makes sense to start out with clear component boundaries within your code, but to deploy the software as a monolith. This is typically much easier and more efficient than jumping straight into microservices, because microservices mean distributed systems and distributed systems are complicated. Suddenly you have to think about issues like eventual consistency, and that's not fun (at least for me). Martin Fowler mentions the concept of a Microservice Premium that you have to “pay” for using that architecture – while they provide a way to structure very complex systems, they introduce unnecessary baggage for less-complex systems. You should absolutely read Fowler's article (it's very short) if you're considering to use Microservices without a clear pressing need for them.
if (runningInCloud) { startCloudBusinessLogic(); } else { log("Running on-premise, not starting cloud business logic"); }. For (2), monolith and microservices are two ends of a sliding scale, not the only possibilities. For the whole thing, there's a world of difference between "can" and "should". And for "should", it depends on your requirements, none of which you've really told us here.