Transition into Mashery

OK, you’ve done it. Your web service is working. It is useful, it is getting popular, people like it, and want to integrate with your service. So you create and API and everybody is happy. Nowadays APIs are the glue that allows for different services to benefit from each other, synergistically creating what we call the Internet. Now your business has grown ten or one hundred times, and you realize that you are spending  too much time managing API users, adjusting throttling and authorization settings, supporting several different versions of API. And you have JSON dialect for a VIP partner A while keeping XML for partner B and so on. But what makes you feel bad most of all is that all those tasks are done by engineers. So instead of developing new features, engineers are busy with managerial tasks. Not very efficient, is it? How do you return the control to the managers? Either you can create your own API administration interface (further involving your engineers) or outsource this to a company like Mashery. We chose the second option.

How does this process look in engineering perspective? As we have a lot of APIs, a decision has been made to do the transition step by step:

1. Create services on Mashery, describing APIs we migrated first. We created a separate entry point for Mashery on our side to avoid our own throttling. The new services have been set up to use that entry point.

2. Setting up the Catch-All service. To make the transition smooth and seamless we wanted to eventually cname our to Mashery servers. In order to do so we needed to forward all calls, which did not belong to APIs from step 1, to our servers, like there had been no additional Mashery layer at all. And this is what a special Catch-All service has been designed for. It does not require a user to have a Mashery account, so every API consumer, after the cnaming is done, could use the service like nothing has ever happened.

3. User migration. Mashery users need to have an account to use anything other than Catch-All service. So we took all our active API consumers and used Mashery user management API to create accounts for them As we had our own authentication mechanism (GET parameter, named access_key), we could also migrate users credentials, and Mashery was flexible enough to allow the users to have exactly the same credentials they had had before the migration.

4. CNAME change. In the final stage we changed DNS records for, pointing it to Mashery servers.At that time everything was ready for the transition, so the users did not have to change anything: the same GET requests, with the same access_key, but they were actually accessing Mashery web servers and using Mashery user accounts.

That’s it. We still have a lot of things to do, the migration is not 100% complete, but the clients and the company already can benefit from standardized documentation, real-time stats, forums and other convenient tools provided by Mashery.

Posted in: Implementation and Customization, Learn

All posts