Diving into the infrastructure
An instance is several things. It could be part of a URL (something like https://<instance>.service-now.com/), software running in the cloud, or your copy of the ServiceNow platform.
ServiceNow provides a platform and suite of applications as a service. They worry about the hardware, Internet connectivity, and operating system security, and provide you with the URL. All you need to get going is a modern web browser.
To follow the examples in this book, you need admin access to an instance. It'll be better if you have your own, dedicated instance rather than one being used by many people. It allows you to make system-wide configuration changes, and you won't affect anyone else.
Note
It is especially important not to use the production instance assigned to your company. This book uses the examples to teach you about ServiceNow, and you will not want all of these experiments being used by your whole company.
ServiceNow runs a developer program, through which you can obtain your own instance. It is lower powered and restricted in capabilities compared to normal instances, but it is an excellent resource to test out ideas. Be sure to read the FAQ to understand the limitations.
You can access the developer program at https://developer.servicenow.com.
Keeping up with the examples
All the examples in the book have been recorded as Update Sets, which we discuss in detail in Chapter 10, Packaging with Applications, Update Sets, and Upgrades. The hotels application is also in a public Git repository. You can apply them to short-cut the examples. Even if you you wish to work through all the examples, I recommend applying the first one, so your scope identifier is the same as the book. It'll make copying and pasting code much easier!
You can download the Update Sets at http://www.gardiner-hotels.com. Alternatively, you can fork the Git repository available at https://github.com/gardinerhotels/hotel. More instructions are at the website.
Being in charge
An instance is an independent implementation of ServiceNow. It is isolated and autonomous, meaning your code and data is not shared with other customers. ServiceNow uses a single-tenancy architecture, which means your instance is yours: you can do what you want with it, such as changing logic, updating the UI, and adding fields.
Tip
ServiceNow's greatest advantage is also its biggest disadvantage. The power and flexibility can be intoxicating! Just because you can do what you want, doesn't mean you should it! This is discussed in detail throughout the book.
Every customer has several instances-again, each isolated and independent. One instance is usually marked out for developing on, another for testing, and yet another for production. And because each instance is independent, each one can be running a different release of ServiceNow. The production instance differs by having more powerful hardware.
Note
Chapter 9, Diagnosing ServiceNow – Knowing What is Going On, discusses how you can use your instances for tasks such as building functionality, testing it, and then making it live.
Changing your instance
A new instance starts with a few ServiceNow applications, some demo configuration, and example data. This is often called the out-of-the-box state. One of the example data elements is the System Administrator user. You are able to log in and get going, getting full control immediately.
Everyone makes changes to their instance. Unless the people who will be using the system are called Beth Anglin or David Dan (some of the default example users), you'll need to load some users at the very least. Some ServiceNow customers configure a lot, and some do the bare minimum. You can choose how much you wish to do. Because it is single-tenant, you can alter the configuration and data in almost any way you see fit-now, it might not always be smart to do that, but you can!
My favorite analogy, if you haven't guessed it yet, is a building. ServiceNow gives you an office that is yours. It starts off identical, built to the standard plans, but you can redecorate or remodel as you see fit-perhaps even knock down a wall! (Let's hope it's not load bearing.) This is the benefit of single tenancy.
Multitenancy is like an apartment in a block. It is generally more efficient to pack lots of people together in a single building, and you can build it pretty high. However, you don't have the flexibility that being in control gives you. The landlords of the block won't let you knock down a wall!
The vast majority of customers have their instance hosted by ServiceNow. This means that the people who built the house will also look after it, on their land. You get great economies of scale and the benefit of tools and automation design to perform maintenance and give support fast. All the gardeners and janitors are on site, ready to work-they don't need to travel to help out.
Knowing the platform
The heart of ServiceNow is the platform. This is a series of data, logic, and user interface layers, combined to provide a high-level environment that makes it really easy to build workflow and forms-based business applications. If you like, the platform takes raw materials and develops them into building blocks. You then plug them together to create what you need.
ServiceNow has already done a lot of building work. Prebuilt applications are available to perform service management, such as IT, HR, and facilities. Managing IT infrastructure is made easier with the ServiceWatch suite, while the needs of the business are helped with demand, project, and vendor management.
When you know how the platform works, you can more quickly use and support the applications built upon it. And, of course, you can build your own. Understanding the platform will help you in all respects-which is the focus of this book.
Choosing functionalities with plugins
All ServiceNow functionalities are delivered as plugins. When an instance is turned on, one of its first tasks is to load all the plugins that are turned on out of the box. There are quite a few of those: over 200 in the Helsinki version of ServiceNow. And there are several hundred more that you can turn on if you want. A plugin may provide an app, such as HR Service Management, or provide new platform functionality, such as domain separation.
Note
Chapter 9, Diagnosing ServiceNow – Knowing What is Going On, talks about plugins and upgrading ServiceNow in more detail.
When a plugin is turned on, all the data and configuration that the application needs is loaded into the database, meaning that it is ready for work in just a few moments. Many also contain demo data, giving you examples of how it could work.
Running the latest version
Each new version of ServiceNow brings new and improved applications and enhancements to the platform. These are packaged as updates to plugins.
ServiceNow tends to release twice a year, meaning it can be quite a task to keep up with the latest version! This book is written for the Helsinki version of ServiceNow, though most of the information is relevant for newer and older versions.
Aside from improved functionality and bug fixes, ServiceNow often creates improvements to the user interface. An instance provisioned with the Helsinki version of ServiceNow uses UI16 by default. The screenshots in this book show UI16, so if you use a different interface (perhaps for browser compatibility reasons or because of a different version), things may look slightly different, and all of the features may not work the same.
Tip
The product documentation lists the different interfaces available: https://docs.servicenow.com/administer/navigation_and_ui /concept/c_NavigationAndTheUserInterface.html.
Digging into the hosting
A typical ServiceNow-hosted instance is split over two physical datacenters, forming a high-availability pair. Each location runs independently of the other, creating a semi-clustered environment. In the event of a catastrophic disaster with one location being completely unavailable, the other nodes will just pick up the load, with almost no downtime. In fact, the process of switching between locations is used for maintenance procedures, enabling your instance to be well protected against hardware and other failures.
Note
The free developer instances are not replicated, and run only on a single node. A customer's production instance has many more resources!
When you visit your instance, you are directed through several layers:
- By looking up DNS records, you are directed to the currently active datacenter for your instance.
- The load balancer, by reading a cookie, directs you to the application server you have your session with.
- If you aren't logged in, you get directed to the least busy application server.
- Your application server then uses the database currently determined as active.
Knowing the nodes
From an architectural perspective, a ServiceNow instance is made up of several application and database servers or nodes. These generally run on shared hardware, meaning although your instance is logically separate and independent, it is physically hosted alongside another customer. At each location, there are generally at least two application nodes, each running a copy of the ServiceNow platform and working together to share load. Additionally, there may be worker nodes installed to process the noninteractive jobs, such as sending out e-mails or dealing with integrations. Even though you'll never directly log in to these worker nodes, they perform some background processing, allowing the interactive application servers to respond more quickly to user requests. While there are generally lots of application nodes, there is only one active database server, running on a separate physical server. It does have a redundant pair hosted in the remote datacenter.
Tip
Chapter 5, Getting Things Done with Tasks, explores the concept of event queues in more detail.
