Reworking Under the Hood
Sentinel Hub has been around for a while, almost two years now. It went through several iterations but nobody outside of the company saw the first two versions. The third version was based on lots of pre-processing and was shelved as soon as we realized it would take tens of servers running all the time just to prepare the data properly. The fourth went public but its performance was not good enough to support an interactive user experience, which is why Sentinel Postcards was created — the only decent use-case we could think of and it only returned on one small image. This was the first stable version, which had weekly updates, where we added features but mostly worked on improving performance.
Once we managed to increase the performance sufficiently so that it was possible for one request to complete in a couple of seconds on one machine, things became interesting and much more usable. Sentinel Playground and EO Browser naturally evolved from these increased capabilities. But with ever increasing capabilities various limitations started becoming problematic and we came to a point where we realized we needed a new major release.
One reason was to clean up the mess created by fast iteration, but the main reason was to address various incorrect assumptions made at the beginning of the project, and design decisions that followed from those assumptions. To give some examples:
- our target group was initially “individual users” with their desktop GIS applications — in reality, the vast majority of our user base today are application developers each with their own demands;
- the limitations of OGC standards, especially the WMS, became obvious (the lack of a POST request option, hassle with lat/lon order in various versions, etc.);
- all the while our users asked for more control over data visualization, and most importantly, for more transparency on what was happening with the data — how did we go from a satellite’s “digital numbers” to “NDVI values” or “atmospherically corrected true color images”.
To be able to proceed further it was necessary to take a step back, tidying up our system and getting rid of various problematic features. Today’s release is an important step towards future stability, ease of use, and transparency. And even better integration with third-party applications. Of course we are not done yet (and don’t expect to be), further improvements are still to come. Check this link to see what is changing.
At the same time, we are fully aware that API changes are not desirable. Even less so when these APIs are used to process more than one million requests per day, many of these directly related to our users’ revenues. We have therefore put a significant effort into making all changes as backward compatible as possible. And we are going to provide a one month transitional period which will ensure that no application will break overnight. That said, many users will actually not need to make any changes at all. The release will follow these steps:
- The new service end-point (services.sentinel-hub.com/ogc/*) will be released tomorrow (November 24, 2017) morning, CET.
- New configuration utility will be released, being simpler to use, and tailored for configuration of the newly released services.
- Old configurations will be migrated to the new system. It will not be possible to change configurations in the old system anymore. All further changes will need to be done on the new system.
- Old services, using existing configurations, will continue running without any changes for a period of one month. This should give all our users enough time to make the necessary transition.
- After the one month, just before Christmas, we will discontinue the old version (services.sentinel-hub.com/v1/*) and automatically forward all requests from the old end-point to the new services. Unless API changes affect our users’ integration, they can actually avoid doing anything as it will auto-magically work. Nevertheless, we strongly advise to move to the new services as soon as possible.
We apologize for any inconvenience that this might have caused, but we are certain that everyone will appreciate the changes long-term. We will try to limit the number of such events to a minimum.