On-Premise to Cloud Migration

[parna]

More and more enterprises are moving beyond “Cloud adoption” to “Cloud first” strategy. As a result, several of them are migrating their on-premise workloads into the cloud to take advantage of the scale, reliability & operational excellence of the leading cloud providers. The benefits of using “SaaS over On-premise” or “Public Cloud over Private Cloud” is gaining a lot of attention.

Moving from on-premise to cloud requires detailed planning & coordination across multiple teams and stakeholders each with distinct and diverse areas of concern. Stakeholders must consider the impact on processes, technology, data, talent pool, security, support, etc.

Several major global brands have successfully taken this route; along the way valuable lessons have been learned. Some of the key considerations for moving from on-premise to cloud on the Apigee platform are listed below; most of these are applicable for other applications as well:

Security:

A move to cloud first & foremost raises questions with the security teams - operations & architecture. It’s critical to bring them on-board early on & ensure their understanding of the various security controls available in the product addresses their queries and concerns. In many cases, they are variants of challenges that have already been faced and addressed. A good starting point is knowledge transfer followed by profiling threats and a sober risk assessment.

Traffic from the cloud must cross multiple trust boundaries on its journey from a request to a response. Each time the trust zone is crossed, the ingress and egress points represent an attack surface.

A well established best practice is to encrypt traffic in motion using TLS (HTTPS). In addition to encryption, TLS also establishes the authenticity of the server. Enterprises typically want to ensure that the client itself is authentic. A less well known capability is mutual authentication, or 2-way TLS. In this scenario both the client and the server are identified by mutually trusted X.509 certificates.

Laying down security best practices & guidelines for the API development team at this stage would ensure following “secure by default” practice. For example - Setting data encryption rules.

Apigee supports PCI & HIPAA compliance on the cloud - which can be considered as add-ons to the platform if required.

Apigee platform has several out of the box features like - granular Role based access controls, OAuth 2.0, SAML assertions, threat protection, multi-factor authentication etc to ensure strong security controls.

Further details on Platform capabilities can be found here.

Process :

Every organization has processes, some which are designed and documented while others that have evolved by chance and circumstance. Moving to the cloud would require a relook identifying processes important to the company and leveraging the best practices around the same.

Operations Management:

Apigee operations would be responsible for regular Platform upgrades, infrastructure maintenance, back-up etc

Monitoring : Infrastructure components would be monitored by Apigee.

The API monitoring on the other hand needs to be taken care by the customer operations team.

Logging: Access to infrastructure log would be restricted in the cloud setup. But API logs can be generated and integrated with in-house syslog serves.

Auditing: Audit log APIs are available to extract information on key platform events like deploying/updating/deleting APIs. This can be used by operations team to integrate with internal tools or processes if required.

Firewall burns between the cloud platform & internal systems would be required for new backends & would be the responsibility of the operations team.

Release & Change Management:

The speed of deployment should be faster with the operations team focusing on reduced time to market. Deployment checklists should be optimised keeping in mind that the maintenance & uptime of the platform lies with the cloud team and several sections of the release process like Networks, infrastructure needs to be removed. Additional tasks like notifying Apigee support of an upcoming release needs to be added.

Support:

The platform & infrastructure support and maintenance lies with Apigee team (no more worries around Cassandra tuning, adding new message processors etc) . It’s important to understand the platform SLAs and the process around raising support requests.

https://community.apigee.com/content/apigee-customer-support

With this the in-house support teams can focus on understanding the solution built on top of the API platform and improve the consumer experience for the API users.

Technology

Logical Architecture

Design the Orgs, Environments & Virtual hosts.

If the orgs & environment mapping between on-premise and cloud are similar its straightforward to map them.

Often it has been observed that a redesign of the orgs: environments have been made during the cloud migration: based on learning over the years in the on-premise setup; security considerations, federated API program, governance etc Also note the pricing model in cloud & on-premise are different which might trigger a consolidation of the orgs.

APIs

The biggest consideration to make during re-deployment of the APIs would be the version compatibility. If the on-premise version of the platform is less than a year old this should be straightforward. Older versions might need some remediations in the proxy.

An easy way to test this is to set up a free org in the cloud & point the Continuous deployment tool to the cloud org for re-deploying the proxies.

NOTE: If you don’t have a CI/CD setup this would be a great time to design and build the same.

Data

One of the key considerations during the migration is to minimise the impact on the end-users of the APIs & apps; this would be achieved by migrating the data used in the current platform to the new one here’s a list of types of data to be considered:

Key management system:

Consists of : Developer details - name, email etc, App details - keys, secrets, name, custom attributes etc, API products

There is an open source tool to help migrate this data - which might have to be customized based on the on-prem version.

https://github.com/apigeecs/apigee-migrate-tool

Note: access tokens should not be migrated - since they should ideally have limited validity. In edge cases where access tokens have infinite lifetime migration is tricky & covered in a separate post here.

Analytics :

Many organizations might want to start the cloud journey in a clean slate. But if required the analytics data can be moved to the cloud. Contact Apigee support team for the same.

Resources :

Key Value Maps, Caches - There are APIs to export & import these data. Also the tool above would help with these.

Developer Portal

Developer portal migration involves content, theme & MySQL data migration.

This can be accomplished using drupal plug-ins.

Testing

The key to a successful migration would be thorough testing:

Ideally there should be automated test cases for the existing APIs in the on-prem platform - which when executed against the cloud platform should have the same test result.

Incase there are no test suites - it would be critical to use this opportunity to build one - this might delay the launch but well worth the time; this can be used continually to validate the health of the APIs & the platform.

Performance testing of the key APIs before the platform launch is recommended.

Talent

The biggest consideration of the cloud move is to ensure the impacted teams feel included in the decision and execution process; understands their new roles and responsibilities. Views this as a positive change for them to focus on things that would have much higher business value and impact

Conclusion

Though there is no single click way to migrate from on-premise to the cloud platform; the benefits are worth taking the leap. My recommendation would be to be “Biased towards action” & getting started!

[ssudhindra]

Nice summary of topics to be addressed during migration.

Another topic to address would be URL migration. Here DNS switch can be done during migration window to switch traffic from on-prem installation to public cloud instance. DNS switch takes careful planning with security and network team and should be initiated at least a couple of weeks in advance. See docs for more details on DNS changes needed.