6 minute read
Photo by Metassus, licensed CC BY 2.0
The Developer Program has grown steadily since it was announced at Knowledge15, and along with that growth has been a corresponding increase in developer instance usage. The ability to give these away for free use for the community of ServiceNow developers is a great benefit and has reaped benefits for the entire ecosystem. However, it does come at a cost. The program was granted a dedicated chunk of infrastructure, and then another chunk later. Those of you who have been around for a while remember the Great Instance Crunch of late 2015/early 2016. We’ve done a lot with this gift of infrastructure, but at this point we can no longer keep going back to that well.
In order to be able to provide more instances to more developers, hibernation was recently introduced to the program. Roughly 2⁄3 of instances are not actually used on any given day. Hibernation allows the same hardware to serve a larger number of instances, which means we can keep handing them out without having to shorten the inactivity timeout (which we really do not want to do.) Hibernation is not ideal, but we are not in a situation to decide whether to hibernate or not. The choice is whether to have hibernation or no more instances to distribute.
In this post, I want to clarify a few misconceptions and set some expectations around this situation. Some of these are in the FAQ but they bear repeating:
Wake your Instance from the Developer Portal
If your instance is hibernating, you should get a notice to that effect when you attempt to access it via HTTP. The hibernation page will have a link to the part of the portal you need to load to wake it up. Alternately, if you just load your Manage -> Instance page in the Developer Portal, that will automatically wake your instance if it was hibernating.
Hibernation and Reclamation are Different
We see these in feedback and in instance help frequently, messages that conflate the two things. These are entirely separate. When hibernation was originally introduced, a number of developers were confused the first time they received a timeout warning. I personally answered a number of messages of the form “You said you would reclaim my instance in two days, but it was already inactive.” A hibernating instance by definition has not been reclaimed. If it was reclaimed, you wouldn’t have it around to wake up. You can always still extend your instance with the button on your management console at Manage -> Instance even without waking it up, or by the standard development activity that resets the time.
Waking Up Needs an Active Session
Another common pattern is that people report having to wake up hibernating instances multiple times. If you wake it up and do not log in, it will go back to sleep in around 30 minutes. If you log in and then don’t actually keep the session around for very long (log out in less than 15 minutes) it might also go back to sleep in around 30 minutes. If you are continuing to use it actively through the day, you should have around 6 hours of inactivity before hibernation begins. That should be more than enough for anyone using it on a normal workday. If you come back to it in your evening, it might require waking up again but in most cases a single waking should last through the entire day unless you do it early and then don’t touch it all day.
It is also worth noting that developer instances are reclaimed based on developer activity, AKA script changes, configuration changes or anything that would show up in an update set. Hibernation is based on any activity in an interactive session. In other words, creating records or changing data does not reset your activity time for your 10 day timeout. It absolutely does reset your hibernation timer. Any activity through the web interface will keep the instance from hibernating.
Hibernation Affects Your Code
One aspect to note about hibernation is that it does affect the scheduled jobs and other aspects of your development instance. If you have scheduled jobs or other deferred executions on your instance and it is hibernated, those will not execute on the set schedule and possibly not at all. It now makes sense as you configure those jobs on your developer instances to do it for business hours. Although standard in production to push those types of code to the overnight hours, for a developer instance you want to do the opposite if there are jobs you want to maximize the possibility that they run.
Waking Will Get Faster and Easier
At this time, it takes around three minutes to wake a developer instance from hibernation. Over time that will get faster. The development team behind it is shooting to get that down closer to one minute. Additionally, they hope to make the timeouts a little more permissive with a net effect of fewer hibernations in a day with a shorter time to get back to work when it happens.
There are Alternatives to Developer Instances
In the case where you just cannot handle the hibernation as a concept, there are alternatives. If you have the inclination and resources to join the Technology Partner Program, you will receive an instance with the program that does not hibernate nor expire from inactivity. This also has some advantages if the ultimate goal is to develop apps that will be published in the ServiceNow Store. The cost (currently $5k/year) is prohibitive for most individuals but if your developer instance is in use for a consultancy and you find hibernation in your way, this is a possibility.
A frequent question asked is some variation of “Can I pay $X/month and get an instance that does not (hibernate | expire)?” We do appreciate the sentiment and willingness of developers to want to pay some freight of the program in exchange for removing these aspects. For the moment, that is enough outside our model that it is not in our roadmap. We aren’t currently set up to take small retail amounts from a large number of users. This may change at some point in the future but at this time, it is not in the plan.
Conclusion
Hibernation, while not ideal, is now a part of life for users of the developer instances. It does add a little bit of inconvenience for developers. Although we would love a situation where we did not have it, the reality of our program is that we need it to continue to provide more developer instances to an ever larger pool of developers. Every effort is being made to reduce that impact but this is a side effect of the success of the ServiceNow developer program. We thank you for your interest in the program and use of these instances, and will strive to make the program ever better.
Let’s build something great!
Share this post
Twitter
Facebook
Reddit
LinkedIn
Email