Overview
Moving Instana from one environment to another can have various facets:
-
Migration from onPrem to Saas (less likely the opposite),
-
Migration from Lower (i.e: Dev) to Higher (i.e: Prod),
-
Migration form Docker to K8s (Idea: INSTANA-I-1379),
-
Migration from other APM to Instana,
-
Moving from lower to a higher version of Instana is known as Upgrade (process is always covered in our docs)
In this document, we are presenting one aspect of migration:
Moving Instana from onPrem to Saas, this migration involves two main activities on Backend and Agents.
1.Backend
1.1.Provisioning
When you are switching from onPrem to SaaS, it is important to know that data cannot be carried over.
No infrastructure and configuration are done by Customer (except filling a form torequest environment(s)).
Instana Architecture is based on a concept of tenants and units (aka environments).
IBM will provision SaaS backend environment to host your data and config: This environment is a combination of tenants and units.
Tenant: You can see as your domain, the tenant name should contain a reference to the customer / company that uses Instana. (e.g. mycompany).
Unit: as subdomain should reflect the area where Instana is used (e.g. prod, nonprod, for simplicity units are also called "environments")
The URL structure of Instana Backend is http://<<UNIT>>-<<TENANT>>.instant.io ( This will give you access to monitoring interface)
Every user in a tenant “mycompany” can access all the environments (dev, test & prod)
Monitoring UI URL will be:
A tenant can have multiple units (environments) and setup on region EU or US , on AWS or GCP
Depending of use cases (i.e : users access restricted to an env), you can request multiple tenants.
1.2. Access control: Users/Groups migration
There is no ready-made script, Users, Groups and API Tokens should be recreated.
Access to new environments can be created manually via UI (if there is not a lot of users), alternatively API can be used to create Users / Groups (new API tokens should be created in the SaaS env).
Migration can be an opportunity to optimise access to new environments using identity providers, i.e:
-
Google SSO, SAML, OpenID Connect
-
Mapping identity group providers and Instana group
1.3.Applications
There is no ready-made script, Application Perspective can be recreated manually or via API calls.
1.4.Configuration: Website / Mobile
There is no ready-made script, also there is no auto-injection for website monitoring.
Can be done manually or automated with APIs
(Search Key and Reporting URL for onPrem and replace with SaaS values)
Some improvement considerations: replace Tracking Script with a link to a central location.
It is easy to get Key and Reporting URL from SaaS instance, provided above in section 1 Backend Provisioning
1.5.Events, Alerts, Alerts channels, Maintenance Windows, Custom Payload
There is no ready-made script.
Moving to SaaS can be opportunity to remove unnecessary alerts, tune alerts
1.6.Custom Dashboards
As above there is no ready-made script,
On Saas create new Dashboard and paste the json
2.Agents
Instana agents that monitor your technology stacks is the same for onPrem and SaaS, therefore there is no need to reinstall the agent, but the configuration should be updated to communicate to SaaS.
2.1.Update agent/download key
The agent key is used to create a relationship between the monitoring agent and the environment that it belongs to.
The agent key can be found by clicking Deploy Agent within the Instana user interfaces' landing page.
Download key: On Saas, download key will be save value as agent key
Update agent key in config file: <instana-agent-dir>/etc/instana/com.instana.agent.main.sender.Backend.cfg
2.2.Update connection to Backend
Agents should be able to communicate over HTTPS to SaaS endpoint provided by IBM in section above (Backend Provisioning)
The ingress endpoint for monitoring technologies depends on the type of data that is ingested, and where the installation is located.
When you have doubts, go to your Instana installation, click ... More > Agents > Installing Instana Agents, and choose the type of installation you want to use.
To recap : Update config files <instana-agent-dir>/etc/instana/com.instana.agent.main.sender.Backend.cfg as shown below:
Although data migration is not possible, Instana can report to multiple backends (onPrem and SaaS).
It is recommended before switching completely to SaaS, to have a transition period with a dual reporting (onPrem and SaaS) ,
This will not only help to build historical data when you are on SaaS but also will help during the transition period to make sure everything is setup and working properly on SaaS -
Dual reporting (onPrem and SaaS) configuration can be done following steps below:
Backend-1.cfg and Backend-2.cfg can even contain different proxy settings.
|
|
|
|
|
|
|
|
Manual updates done by customer
|
Automated scaling of components
|
Manual scaling by customer operations team
|
Continuous monitoring of SaaS Tenant Units
|
Self-monitoring done by customer
|
Hardware/Infra costs as part of license price
|
Hardware/Infra costs not covered in license price
|
Support for Google SSO/SAML/IdP authentication
|
Support for Google SSO/SAML/IdP + LDAP authentication
|
Best-in-class SaaS architecture evolving continuously
|
Variety of deployment options: Docker-based and Kubernetes Operator for Kubernetes and OpenShift, fitting customer needs
|
Latest architectural changes and newest product capabilities (and faster access to beta features)
|
Delayed architectural changes based on SaaS experiences, potentially additional efforts for customers to implement (depending on deployment)
|
SOC2, GDPR and other security validations in place
|
Can be adjusted/implemented to comply with internal security needs
|
Easy support options for IBM support staff by accessing SaaS Tenant Units
|
No direct access by IBM support staff, logs etc. need to be shared by customer operations team
Synthetics and logging only available in Kubernetes Operator, not Docker-based.
Active directory integration, VPN and data retention manipulation
|