The service facade is the way to go -- it will make it much easier to managed and test in the long term. You can build the service facade as an entirely separate library in fact so you can use the facade in other apps without much to do.
Insofar as were to drop it, keep in mind that MVC is really a UI pattern, what happens below the waterline is really beyond it's concern. So have your controllers reference the service facade and pull out models to send to the UI and don't get hung up on what is a model vs what is a controller.
Model: Fields that belong to the object, methods that help to get/set data from the object (a fullname accessor that returns first + last name)
Service: Methods to perform operations with one or more models, see 'unit of work', transactions, etc...
Employee::create should just take a set of data, perform model validation if necessary, and return an Employee Object.
EmployeeService::hireEmployee might create the employee, send them a welcome email, create a mailbox, make them a sandwich, etc... it may return the set of data, or a result code, etc...
This can also affect validation:
Model Validation: Employee must have a id, first and last name, and birthday
Service Validation: Employees for the bartender position must be 21 or over, and approved by a manager.
Best Answer
All your business rules (and application) should be in the model layer of your application. The controller should just be collecting (from models to views) and sending (from URL requests to models) the data.
Your models can be composed in two layers, the business logic (and application) and your data access layer. Your data access layer execute queries (SQL, NoSQL, Web Service or even text files).
Your models should not be "aware" of the type of storage you are using. This way, you can change and combine different data access mecanism (your users are in a database and the rest of the data comes from a web service for example).
To cleanly integrate your data access layer in your models you should rely on dependency injection