6
Managing Multiple ServiceNow Instances
Typically, ServiceNow customers will have multiple ServiceNow environments, also known as instances, which are independent copies of the ServiceNow application. In most cases, an order form for ServiceNow will include one production instance and one or more sub-production instances. The number of instances granted in an order is typically dependent on the size of the order with ServiceNow and, often, ranges from two to five total instances (although higher numbers are not uncommon among the largest customers).
As your ServiceNow implementation goes from vision to execution, one of the very first things the administration or development team will need to do is to set up your instances. Setting up these instances properly at the start will help improve the velocity of your project. Unfortunately, for many teams, this critical stage comes before the team has had enough hands-on experience with the platform and before they can be expected to design an optional environment plan. The goal of this chapter is to help you understand and plan for the setup of your instances, including the following:
- What are ServiceNow instances?
- Instance administration operations
- Code promotion and data clone flow
- Designing your ServiceNow landscape
What are ServiceNow instances?
Understanding the most effective way to buy, deploy, and manage your ServiceNow instances starts with a clear understanding of exactly what a ServiceNow instance is, which requires a little bit of knowledge of the component parts. In general, web applications consist of infrastructure running one or more web servers, application servers, and a database with more advanced applications having additional services or variations on this theme. Part of the value of a SaaS cloud offering is that the details of the servers and component parts aren’t important to the customers, but it is still useful to think of a ServiceNow instance as Core Application Code + Data running on ServiceNow’s cloud infrastructure (in the ServiceNow data centers). Note that we say Core application code because ServiceNow stores a lot of the JavaScript code that defines the business logic and even UI in the database.
An instance of ServiceNow can be seen from a few perspectives. Looking at it from a contract or infrastructure perspective, the instance you license is the space in the cloud needed to run a copy of the ServiceNow application. In this sense, you can say, “We bought three ServiceNow instances,” which means, in this context, you are entitled to three environments according to your contract. This is important as different ServiceNow entitlements provide you with different underlying infrastructures; for example, production instances are often assigned more resources and might also be more isolated than development or test instances.
Typically, a ServiceNow instance has a specified role defined such as Production, Development, or one of the other roles we’ll cover later in this chapter. In this sense, when you refer to your production instance, you would be referring to the cloud application and its associated database that your users and administrators can access. ServiceNow instances are often suffixed with their names, so a company named Fake Example Company Ltd. might have instances with the fakeexampleco.service-now.com URL for their production instance and the fakeexamplecotest.service-now.com URL for the test instance. This leads to the common convention where teams call their production instance prod, production, or by its full name, while other instances are called just by their suffix, that is, test in the preceding example. Typically, the major difference between instances is the content and use of the associated database with the production instance holding both the stable configuration and the actual day-to-day data used by your company, while a test instance might hold the latest prerelease configuration, a subset of production data, and any records that have been created/modified to validate functionality.
Finally, you might hear folks referring to the application version of ServiceNow as an instance and might say, “I need to try that in a Rome instance” or “I’m getting a Utah Dev instance,” where Rome and Utah are the names of specific ServiceNow family releases.
If you bring these three views together, you’ll understand that you can look at one of your instances and understand the infrastructure allotment, the instance role with the associated database, and the release of ServiceNow that is running. For the purpose of this book, we’ll refer to the set of all instances your company uses as the landscape, although you might also hear people refer to it as an environment (which we avoid because an individual instance is also often called an environment in some contexts). With this foundation, we’re ready to understand the basic administrative operations you can take within a ServiceNow instance.
Instance administration operations
ServiceNow provides multiple tools for its customers to use in managing their instances. This section will introduce two of these tools and their uses to set the stage for the workflows that you’ll ultimately use to manage your landscape. First, we’ll cover the zBoot operation followed by the system clone.
zBoot – a full reset of your instance
The most basic operation you can do to a ServiceNow instance is a zBoot (pronounced Zee-Boot), which allows you to reset your instance to the out-of-the-box configuration. A zBoot is a destructive operation in the sense that any work in the selected instance will be lost, whether that work is in the form of ticket data or configuration/code.
Uses of a zBoot
A zBoot is most commonly used in the restoration of a sandbox or development instance to an out-of-the-box state in preparation for some exploration or development activity. Note that once your company has active production instances, zBoots will become very rare, as you will more likely want your development instances to mirror production, a goal that can be achieved using the system clone operation, which we will cover in the following subsection.
Accessing the Now Support Automation Store
Like many administrative operations, you request a zBoot from the Now Support Automation Store. Now Support is the ServiceNow customer support portal found at https://support.servicenow.com and offers a broad catalog of request types, such as admin password resets, upgrade requests, and more. Your company’s primary and secondary technical contacts will be provisioned with access to the Now Support portal, and they can add trusted administrators as additional contacts if needed:
Figure 6.1 – The Now Support menu
The Now Support Automation Store can be accessed from the Now Support header menu.
Requesting a zBoot
The zBoot option can be found on the second page of the Instance Management category, which can be accessed from the left-hand menu in All automations | Service catalog | Instance Management:
Figure 6.2 – The location of the zBoot catalog item in Now Support
Additionally, you can get to the zBoot catalog item and access numerous knowledge articles related to zBoots by searching for zBoot in the header menu search.
Selecting the zBoot options
When requesting a zBoot, the only parameters you need to specify are the instance name, the time for the zBoot to occur, and whether you’d like the instance to be populated with demo data. Note that due to the destructive nature of the zBoot operation, you cannot request a zBoot for a production instance online but will have to contact ServiceNow directly.
If you choose to include demo data but later want it to be removed, there is another instance management request item that is available to remove it. For this reason, demo data is often enabled in development and demo instances to avoid time-consuming data staging when showing the system’s out-of-the-box functionality. Demo data should not be selected if you are preparing a production instance, as it can cause confusion during the setup process if you rely on records present in the demo data.
zBoot process
Once a zBoot request has been placed, a change record will be created, which you can use to monitor the process of the zBoot operation. Additionally, the change record permits the rescheduling or cancellation of the request, but you should be careful to only request a zBoot when you are ready for that instance to be fully wiped.
You can expect the process to kick off at the scheduled time and to take approximately 5 hours (although the actual time will vary). A zBoot operation clears all passwords and user profiles, so a new password for the system administrator (admin) user will be emailed once the operation is complete, after which you can use the instance.
System clone – copying the configuration and data from another instance
A system clone is likely the most frequent operation that you’ll need to request, and it forms an essential component of the maintenance of a multi-instance landscape. Simply put, a system clone takes a copy of the source instance and duplicates it in the target instance, erasing any configuration and data in the target (with some exceptions that we’ll cover later).
Uses of the system clone
System clones, or clones as they are often known, are used for three main purposes in the ServiceNow ecosystem. We’ll cover them in order of their appearance in a customer’s life cycle:
- System clone go-live (optional)
- Clones to synchronize non-production environments
- Creating a production-like sandbox for upgrades, plugin activations, and more
System clone go-live
A go-live via the system clone is one of the options to update your production environment to match the development environment configuration. For many customers, it maximizes the certainty that your production instance will behave just like your test or development instances (depending on which you cloned from). Most critically, the cloning process will ensure that no configurations are missed. Additionally, it prevents common challenges due to system identifier mismatches, which occur when two records that look alike in different instances have different unique identifiers, a situation that can cause bugs in the configuration of ServiceNow. A clone go-live is also easy to execute as it is a mostly automated process once the necessary requests have been made and the change has been scheduled. This approach does have some drawbacks that should be considered as well.
A go-live with a system clone is straightforward, but in the simplicity of the approach, you do lose a degree of control and introduce some risks that alternative strategies can mitigate. The most compelling reason to take a different approach (for example the update set or application repository approaches) is the ability to leave behind unwanted configurations in the development instance and to more precisely control the configurations promoted to production.
Clones to synchronize non-production environments
Regardless of the go-live approach, you will eventually be faced with the task of using your sub-production instances to build, test, and deploy updates to your ServiceNow environment. This process is made exceptionally easy in the ServiceNow world using system clones, as you can replicate the production data and configuration exactly in your sub-production instance with special provisions to exclude or preserve data if needed. System clones are the best way to periodically refresh test and development environments and should be scheduled as an operational activity. Typically, a clone from production is appropriate after a major release of functionality, an upgrade to your ServiceNow instance, or when significant unplanned drift is observed between the production and sub-production data or configuration.
Synchronization clones can be scheduled on a reoccurring basis or manually. As a new customer, manual clones are preferred to avoid any surprises for developers, but with maturity and experience, a scheduled pattern helps to enforce good development practices and reduces the overall risk of deploying to production. Often, new ServiceNow customers find clones to be disruptive until they have appropriately tuned the process with data preservers and exclusion policies. We’ll cover the function of these two important tools after addressing the final regular use case for system clones: the creation of a sandbox environment.
Creating a production-like sandbox for upgrades, plugin activations, and more
In the ServiceNow ecosystem, you will occasionally be faced with an attractive new piece of functionality such as a new and improved version of ServiceNow or an application or plugin that you would like to explore. In this situation, you will often wish to verify the functionality’s compatibility and value alongside your existing configurations and data without incorporating it into your test or dev environments (which could impact test and development processes).
Cloning the production to an unused instance (or temporarily repurposing a non-essential instance) will allow you to explore the new functionality without disrupting regular operations. If you choose to take this approach on an instance normally used for a sandbox, training instance, or another designated role, you should plan to return it to the production configuration via a second clone once your investigation is complete.
Requesting a system clone
Unlike a zBoot, a system clone is requested and managed from within the source instance. You will find the system clone in the menu under System Clone | Request Clone:
Figure 6.3 – The System Clone menu contains the tools for the management of clones
To schedule a clone, you can use the Clone Targets menu item to first specify a destination or target instance for the clone. Remember, you are requesting the clone in the source instance, so you will need to specify a target instance. When configuring a new target instance, you will need the full instance URL and an administrative username and password. This requirement helps to ensure that a third party cannot overwrite your instances. An additional step is required if the target instance is a production instance and involves setting the value of the system property: glide.db.clone.allow_clone_target. This property is a failsafe against the accidental overwrite of a production instance, so if you feel this is needed, consult the ServiceNow documentation and your ServiceNow support team. Typically this property is only modified if you are completing a clone for your initial go-live.
When scheduling a clone, you will need to select a clone profile, a target instance (from among those you’ve configured), a time, and one or more contact persons who will receive status updates via email. Additionally, there are several additional options available in the Options section of the form. These settings can be set in your clone profile and overridden on a per-clone basis. In general, it is good for your clone process to be as repeatable as possible. So, rather than choosing the settings for each clone, you should set these properties in a clone profile, which is then reused for each subsequent clone. If you are unsure about a specific setting, each label provides a link to the documentation explaining its function.
Clone profiles can also contain data preservers, exclusions, and cleanup scripts, which allow you to fine-tune the behavior of the clone. Typical use cases for these features include the preservation of user data, single sign-on parameters, and integration-related properties. The Default System Clone Profile is a great starting point for tuning your own clone profile and includes common exclusions, preservers, and scripts. Remember that your goal is for clones to be as non-disruptive as possible so that they can be run regularly. Time invested in a robust clone profile will be repaid with every successful clone, and when clone issues are observed, you should consider it a priority to update your clone profile to avoid the reoccurrence of the issue.
Now that you understand the basic operations used in establishing a ServiceNow landscape, we’ll look at how configuration and code flows are promoted from your development instance to ultimately take effect in production.
Code promotion and data flow
The power of the ServiceNow platform comes not only from its out-of-the-box configuration but also from the ability to rapidly configure new business applications and processes. Remember that after your initial go-live, it is not possible to clone your configuration to production, as it would overwrite your data, so a different approach is required. ServiceNow provides multiple options for developers of these new capabilities, which allow them to move code from the development environment to testing and, later, production. There are two primary methods for the promotion of code between environments: update sets and the application repository (also known as app repo). In this section, we’ll cover both and help you decide which is the most appropriate for your deployment.
Update sets
Update sets were the original mechanism for moving configurations between ServiceNow instances and remain the most popular and well-supported even today. The full use of update sets and their application is a subject addressed in the ServiceNow training and documentation and would consume multiple full chapters on their own. For our present goal of defining and managing a ServiceNow landscape, it is sufficient to understand them at a high level.
Essentially, an update set is a record of configurations made in one instance that can be loaded into another instance and then applied while checking for conflicts. Update sets are incremental and do not typically capture a full application configuration (although there can be some exceptions to this). The easiest way to think of update sets is as a recording of the work that happened in development, which is timestamped so that it can’t accidentally overwrite a more recent update in another instance.
Working with update sets requires developers to pay attention to which update set they are using because all configurations made while an update set is active for a developer will be moved when that update set is loaded in another instance. As a developer, it’s recommended that you keep a close eye on all the records in your update sets to ensure you don’t accidentally bring along configurations unintentionally.
Update sets can be moved between instances as XML files or via an integration that ServiceNow provides and are reviewed for conflicts and issues before they are applied in a target instance. Some examples of conflicts can include a business rule that references a user group that does not exist in the target instance or an update to a record that has more recently been changed in your target instance. In both cases, you’ll be notified of these situations when you are reviewing the update sets in your instance.
Update sets have many advantages and are uniquely well-suited for the promotion of small, modular updates of functionality to an existing production environment. Their size and the fact that they can contain as little as one single update make their behavior predictable when tested on similar instances. As you will appreciate, this also means that it is essential that your testing environments reflect the production instance because only the modified code is moved. This is okay in most situations, but in other cases—such as managing multiple production instances—it becomes very difficult to be sure your changes will have the intended effect. The alternative is the use of the ServiceNow application construct, which we’ll cover next.
Scoped (and global) applications
ServiceNow has long had the ability to develop applications in contained scopes that help ensure that configurations are sandboxed in a way that they can be deployed with more predictable results in any ServiceNow instance. A scoped application, unlike a normal update set, captures the full current state of that application with the expectation that when it is applied, the entire application is updated to match the current code base. In this way, a scoped application deployment has a monotonically increasing version number, and when a new version is installed, it is expected to fully replace the old version.
The drawback of scoped applications is that you are constrained to a more limited set of APIs than a global application and that a particular application scope cannot contain edits to records from other applications. ServiceNow does allow the use of globally scoped applications through the use of the sn_g_app_creator.allow_global system property, but this is disabled by default in new instances, as scoped applications are much safer and less likely to cause challenges in deployment and maintenance.
When a scoped application is ready for deployment, it can be published to your company’s application repository, which makes it available to install in other instances, such as your test and production instance. Also, you can export a complete update set, containing every record in your scoped application, which can be useful for moving configurations between different customer accounts, such as from one company to another.
Knowing both of these deployment options for the ServiceNow configurations and code along with the instance operations has set the foundation for us to start looking at practical advice for designing your ServiceNow landscape.
Designing your ServiceNow landscape
Both the most and least useful thing you can learn about designing a ServiceNow landscape is that the correct design depends on many factors, including your team’s level of experience, the number of instances at your disposal, and the types of applications and configurations you’ll be building. Fortunately, we’ll look at more practical advice in this section, including the most common scenarios and principles you can use to inform your own design.
Two-instance landscapes
The easiest scenarios are when you have two or three instances with two instances being rare in all but the smallest deployments. In the case of two instances, you’ll use one production instance as production, and the remaining instance will act as both your development and testing instance:
Figure 6.4 – Two-instance landscape design (using update sets)
Customers using only two instances almost always use update sets for code promotion rather than scoped applications, but there are advantages to using scoped applications too, such as the ability to work on those applications in a separate personal developer instance (a free instance that ServiceNow temporarily assigns to developers). We’ll cover the considerations in more detail in the discussion on three-instance landscapes.
Three-instance landscapes
Most customers will have at least three instances, which provide the extra step of security because configurations from development can be tested in a more production-like test instance, which is free from other work-in-progress code. If you have three instances, you’ll certainly want to set up a Dev -> Test , Dev -> Production code promotion flow while periodically refreshing your test and development instances with clones from production:
Figure 6.5 – Three-instance landscape design (using update sets)
A three-instance landscape can benefit a great deal from the use of scoped applications and the application repository because it allows you to easily compare the versions of code and configuration in development, testing, and production. If most of your configuration work can be completed in scoped applications, which is usually the case, then the use of the application repository will give you faster and more reliable deployments:
Figure 6.6 – Three-instance landscape design (using the application repository)
Additionally, it is possible to adopt a hybrid approach where a majority of configurations are promoted in the scoped applications but any minor updates that are required in the global scope are migrated either by enabling and installing globally scoped applications or by update sets.
Utilizing four or more instances
The natural next question is this: what about larger deployments of four or more instances? Let’s look at each case and provide common uses for additional instances.
Additional quality assurance
Many companies, particularly those with strong internal control or regulatory oversight, require a separation of the instance where the development team conducts their testing from a user acceptance testing or quality assurance instance, where a separate team or group of users confirm the production-readiness of a deployment package. This creates a four-instance promotion chain that is identical to the preceding three-instance patterns except for the presence of an additional testing instance, often called QA or UAT.
Training
Where companies require frequent training in a production-like environment, a training instance might be used to reflect the current production functionality but with the freedom for users to create testing or dummy data during training classes. In most cases, training instances are only ever refreshed by clones from production and will rarely have code deployed directly to them.
Additional development instances
In some cases, multiple development teams need to operate in a single company but with some contradictory requirements. For example, an operational development team might be working on workflows for the current release, while a parallel team might be creating an entirely redone portal using a newer preview version of ServiceNow’s next upgrade. In these cases, having two development instances at the same time can present a significant advantage in allowing work to proceed in parallel on different timescales.
Sandbox instances
Finally, a ServiceNow team might need to occasionally test things in an instance that is not otherwise used for operational activities. This might include an early preview of an upgrade, a new store application installation, or a development activity that is too risky to conduct in your development instances.
The composition of your ServiceNow landscape is determined by your business needs and obligations. Using these building blocks, you should be able to allocate the scarce resources of your instances to meet those needs and obligations.
Summary
With what you’ve learned in this chapter, you should be equipped to complete the basics of understanding, designing, and operating a ServiceNow landscape of two to five instances or more. You now understand the operations that are commonly used to synchronize and configure ServiceNow instances, along with the ways in which these operations can be used to create a deployment pipeline that takes code from development through to production.
For more detailed information on the management of scoped applications and update sets, you might also want to refer to the ServiceNow documentation and the system administrator and application developer courses. Additionally, it is a great idea to request a Personal Developer Instance (PDI) from the ServiceNow developer site (https://developer.servicenow.com) in order to get some hands-on experience with ServiceNow environments and the concepts of this chapter in practice.
In the next chapter, we’ll look at how the processes you develop within these landscapes can be designed to deliver scalable value.