The following are two deployment models:
Shared Deployment Model (Multi-tenant Model) – In the shared deployment model, the database server and instances are shared by multiple applications. The applications is given access to the databaseschema and the scope of the access is limited to the application databases alone. The instance is owned and governed by IT teams. The shared multi-tenant model is cost efficient, allows central governance of resources. The shared deployment model can lack isolation and is vulnerable to noisy neighbor issues which can lead to sporadic performance issues. This makes it more suitable for tier 2 and 3 applications in the enterprise environment. For instance – A visitor checkin application can just reside in shared instances since the concurrency requirement is generally not too high. To achieve predictable performance, resource governance in SQL MI can be implemented to avoid runaway queries or single application hogging the database resources.
Dedicated Deployment Model (Single-tenant Model) – In the dedicated deployment model, the database server and instance are dedicated for the application. The application enjoys the full access of the dedicated resources and can thereby expect predictable performance provided other variables in the system remains unchanged. The DBAs still control the ownership and can set up role-based access (RBAC). The dedicated deployment provides predictable performance, easier ownership, internal billing chargeback, independent failover and combined with the elasticity of cloud allowing scale up and down as needed. This dedicated model is suited for Tier 1 and some tier 2 workloads. For small workloads, it can lead to inefficient utilization of server resources and may not be cost efficient.
If you are going with the Shared Deployment model, try to balance write-intensive databases and read-intensive databases. Do not add to the mix those databases that are affected by deadlocks/blocking.
To avoid CPU spikes make you eradicate missing indexes and establish index and statistics maintenance plans. Managed instances are always consuming all RAM as the max memory setting is not available.
Very important, before migrating databases is to do the experiment explained here on your current SQL Server instance(s) to check what are the instance log limits that the current workload have and determine if that workload can run on the Managed Instance with the same performance.