Okta, an enterprise identity management platform provider, has acquired Stormpath, a startup that provides an API for implementing user management capabilities in websites and applications. Stormpath co-founders Alex Salazar and Les Hazlewood along with the Stormpath team are joining Okta to help accelerate the development of its identity platform for developers. This is not a complete acquisition of Stormpath as Okta is licensing Stormpath's technology. Stormpath APIs and SDKs will be shut down on 8/17/2017.
While Okta and Stormpath both include some of the same capabilities, there are some differences (view the compatibility matrix) that developers must consider when migrating applications to the Okta platform. Stormpath has provided a migration path to help developers with the transition to the Okta platform. The company plans on releasing export tools by the end of April so that users can export their data. After 8/17/2017 Stormpath data will not be accessible and will be deleted.
Stormpath has been around since 2011, and the startup has released several APIs since the company was founded. Most recently, Stormpath released the Client API for frontend registration and authentication. Now developers that have applications using Stormpath APIs must decide whether they want to follow Stormpath and move to the Okta platform or weigh their options, and there are quite a few options. Companies offering user management platforms similar to Okta and Stormpath include AWS, IBM, Inversoft, Microsoft, Ping Identity, and Salesforce.
Migrating to another platform, whether it's Okta or one of the other identity management platforms available, is going to be a difficult and time-consuming process. There are a lot of identity management platforms available today, and many of them have similar features; however, many also have significant differences. All identity management platforms don't work the same way, and they all aren't implemented in the same way. Developers have about five months to do their research, weigh their options, and migrate their applications from Stormpath to Otka or another identity management platform. Developers are going to have to rewrite portions of their applications and will have to transfer Stormpath data to the new platform. The bottom line is that migration to another identity management platform is going to be a real hassle for developers.
The acquisition of Stormpath by Okta exemplifies the dangers of using startup APIs or any third-party APIs for that matter. When businesses build applications that use even one third-party API, especially if it's an API from a startup, are taking a significant risk. When businesses use a startup API, they are taking the risk that the startup may radically change access to the API (many developers still remember the Twitter API fiasco of 2012), shut down the API, or the startup itself will go out of business or be acquired.
Businesses take a little less of a risk using APIs from major, well-established technology companies like Amazon, Google, Microsoft, and IBM. Odds are these companies are going to be around for a long time to come. However, if a business decides to use an API from a well-established technology company, it still runs the risk that the API will eventually be shut down, become more expensive to use, or be redesigned. Many technology companies have an API deprecation policy that helps make it a little easier on developers when APIs are going to be sunsetted. Having to switch from one API to another is still a hassle though.
We're not suggesting that developers should only use APIs from well-established technology companies. All well-established technology companies were once startups. If you choose to build an application that depends on one startup API or multiple startup APIs, keep tabs on the startups providing those APIs; make sure the startup(s) is doing well (annual revenue, new funding, etc.) and doesn't appear to be struggling. There's always a chance that a technology startup could be acquired, but in the meantime, make sure the startup seems to be on the right track for long-term success. Also, be aware of APIs that could be alternatives to the ones currently being used. Check out the API documentation to see how much of a hassle it would be to switch to an alternative API and if the API includes the same functionality as the API currently in use.
Always be prepared for the possibility that a third-party API may be shut down with or without proper notice or access to the API may eventually be severely restricted. There's always a risk when using a startup API or any third-party API; however, preparation is the key to successfully handling that risk.