During CA World 2017 I gave a presentation on the lifecycle of Gateway services and policies. There are two main points I think are important in a migration-less lifecycle:
- Treat policies as code
- Configure Gateways from Scratch
Why migration-less lifecycle
Before I go into some detail on the above two points; Why do we want a migration-less lifecycle? In practice using a lifecycle that involve migrating policies and services from one environment to another has the following issues:
- Merging and mapping issues
- Many have already run into these issues. Moving policies and services from one Gateway to another often involves much preparation, coordination, and maintenance of mapping instructions. These are often brittle and can easily break when there are unexpected updated to either the source or target Gateway.
- Scaling and maintenance issues
- When there are several environments this can be managed but if you have 10s to 100s of different environment (which may be required do to the rise of microservices) it becomes unmanageable.
- No rollback support
- It is very difficult to rollback to a previous version after a migration
Treat policies as code
The Gateway provides a very powerful runtime that can be programmed via the policy language. Because of this, it is really important to treat policy the same way you would treat any other code (Java, C#, etc...). Specifically this implies:
- Using a version control system (GIT, SVN, ...) to store and track policy changes over time
- Use a build system to package your policy into something that the Gateway can load (a RESTMAN Bundle)
- Use an artifact repository to store built packages
We can compare this to how we treat Java applications:
- A Java applications is stored in a version control system. Each file is a different class, and they are organized in some sort of logical package structure. We can do the same sort of thing with Gateway policies and services. Each file could be a different policy or service. They can be organized in the same folder structure that they are located in the policy manager.
- A build system would build a Java application into one or more jar files. Similarly a Gateway build system could build one or more bundle files that could be deployed to a Gateway.
- Jar files are then versioned and added to an artifact repository. The same should be done for built Gateway bundles.
This is simple to say but how it is done in practice can be tricky. I will tackle that in another blog post.
Configure Gateways from Scratch
The other point in a migration-less lifecycle is to deploy to gateways from scratch. When containerized Gateways are available this becomes simpler, however it is possible with appliance (virtual machine) Gateways as well. There are two approaches to doing this:
- Re-deploying the Gateway
- This means starting a new empty Gateway, applying your policies and configuration to it, then shutting down the previous version of the Gateway.
- Cleaning up running Gateways
- Before deploying updates to your Gateway run a cleanup script to remove existing policies and services. This allows you to deploy your policies and configuration as if you are deploying them to a new Gateway.
In future blog posts I will go into details of how to implement this lifecycle. In general, attempt to follow the below 5 steps and avoid migration (moving policies from one environment directly to another.)