2 Item Types
Seiso's purpose is to help your organization manage the sort of data that commonly appears in devops automation contexts. In Seiso we call refer to the individually managed entities as items.
This section describes the various items that Seiso manages, as well as the relationships between them. It sets a foundation for understanding how to use the UI and CLI.
Service management is a central activity in technology organizations. Accordingly, services occupy a central role in Seiso. In this section we explore services and their associated notions, such as environments, services instances and nodes.
Before diving in, let's address an important issue regarding terminology.
In technology, service is a heavily overloaded term. To process people it might mean IT services in the ITSM sense. Network engineers might think of it as software processes listening on a port for requests. Developers might think "web service". Windows administrators might say it's software that runs in the background. There are probably several other senses that enjoy regular use.
Indeed there are many other examples of overloaded terms: applications, nodes, instances, farms, clusters, endpoints, resources, etc. To be sure sometimes people simply misuse terms. (For example, I think that it's wrong to use clustering to refer to simple load balancing.) Usually, though, such terms have multiple legitimate meanings.
But we're trying to explain how to use Seiso here, and it won't do for our purpose to be completely loose. So in what follows we'll explain our way of using the terminology, without suggesting that this is the only or even the best way of doing so. We're simply fixing terminology to facilitate communication.
In Seiso, services are the software that technology organizations deploy to accomplish business and market goals. In many cases it's a judgment call, but for us, services are applications, web services, databases (especially when shared by multiple apps), message brokers, agents, batch processes and the like.
We don't intend services to cover non-software IT offerings, like security training or technical support. Nor do we mean fine-grained things like code libraries (Hibernate, Nokogiri, log4j, AngularJS). Generally we mean software that either responds to client requests (whether human or machine), or else takes action on its own. Something that you might ask your NOC to manage.
We noted that sometimes it's a judgment call. One kind of ambiguous case is a dedicated database: does it make sense to call it out as a service separate from the app it supports? Another fuzzy case is the so-called microservice architecture —is it a single service, or many?
As a general rule, we recommend the conservative and simpler approach of treating such instances as cases of a single service, and then breaking them apart if and when you determine that you have use cases that would benefit from such a treatment.
You can get to the Seiso services view via Services → Services. See Figure 2.1 below.
Seiso allows you to classify your services by type. The types are up to you, but we intend these to be technology-related classifications like application, web service, database, batch job and so on, as opposed to business or product domain classifications. If it makes sense for your team, you can use even more refined categories like SOAP web service, REST web service, relational database, NoSQL database, etc. Again, up to you.
A service can have at most one type.
Go to Services → Types to see the Seiso types view. See Figure 2.2.
Besides types, Seiso has service groups, which allow you to categorize services by business or product domain. This could be very general categories like marketing, sales, support, administrative and so forth. Or they could be more specific, like lead generation or lead qualification. The categories might be industry-specific; at Expedia, we have groups for categories like flight and lodging inventory systems.
As with service types, choose the categories and granularity that make sense for your organization.
A service can have at most one group.
Figure 2.3 shows a list of service groups as it appears on the Seiso home page.
Though services are Seiso's foundational concept, in practice it's service instances that we really care about. Before we can get to those, though, we have to cover environments.
Technology organizations typically create a number of environments dedicated to specific stages in the development and deployment process. Orgs that do their own service development will usually have development and functional test environments. Other common environments are integration testing, performance/stress testing, production and disaster recovery. Sometimes there will be one overall functional testing environment and other times different development teams will have their own functional testing environments.
Because different organizations have different needs here, Seiso doesn't prescribe any particular set of environments. Instead we provide a way to create the environments you need.
Figure 2.4 shows the Seiso environments view.
Service instances, as their name suggests, individual instances of a given service. They bind services to environments. Load balancing, if used, generally happens at the service instance level.
Suppose for example that we have a service called Hotel Inventory. We might have several service instances, such as hotel-inventory-dev, hotel-inventory-test, hotel-inventory-prod and hotel-inventory-dr.
It's possible to have multiple instances of a given service in a given environment. Say for example that Hotel Inventory uses a sharded architecture where one instance manages one set of hotels and another instance manages another set.
Deciding how to model your services and service instances obviously involves some level of subjectivity and judgment. But there are a couple of points of confusion that come up often enough that we can address them here.
Another confusion that sometimes arises is distinguishing service instances from deployment groups. One kind of zero-downtime service instance deployment strategy is to deploy one group of nodes at a time until the entire instance has been deployed. The individual groups are deployment groups, not service instances; the entire set of nodes is a service instance.
Seiso doesn't currently have an explicit way to model deployment groups. We plan to support this in the future via a node tagging mechanism.
Service instances have some dependent item types, including nodes, IP address roles and ports. We'll treat nodes in its own major section below, but let's cover IP addresses and ports here.