Service Owners
In NetOrca we define the follow key role:
Service Owner -> Any team within the organisation that offers a Service
The Services offered could range from basic requests such as adding a user to a group, through to infrastructure requests like creating a VM and finally encompassing very complex requests such as a deployment patterns spread across multiple teams.
Declare what you offer
Services in NetOrca are created solely through the creation and declaration of a JSON Schema object which represents the minimum required configuration a consumer needs to be provide in order for that Service to be created.
NetOrca's customised implementation of JSON Schema allows for explicit definition of the fields a customer is required to input to raise a Service
NetOrca uses the defined Schema to validate all incoming customer requests. This allows for errors to be caught even before the Service Owner team is involved.
The JSON schemas can also be used directly within the customers IDE providing even more guidance on how to request a service.
Service Owners are encouraged to put their schema definitions into GIT. Giving them the full audit and collaboration functionality that GIT provides whilst still allowing quick modifications
NetOrca has versioning of Service Schemas by default.
This means Service Owner teams always have the option to improve their Service definitions and validations.
It also allows for slow depreciation of existing schemas, giving consumers of these Services direction on what to change to be compatible for the new Service Schema
NetOrca's Service definitions allow you to create relations/dependancies on other Services.
This allows for more complex services, such as a Load-balancer that needs to refer directly to a VM. Or a microservice that requires a DNS Record.
NetOrca's validation ensures these dependancies are met before a customer can request a Service.
Other teams can be tagged in the creation of a Service you own.
This allows for a single service request and a single customer configuration to potentially create multiple changes for different teams. This is especially useful for more complex requests.
Serivces in NetOrca have the option for changes to be auto-approved if they meet the strict validation criteria.
Service Owner teams also have the option to require approval for each change to a requested Service.
Once you Service schema is made live on NetOrca, it immediatley becomes part of a Service Catalogue that is available to Consumers.
The Service catalogue can produce an example of how to consume this Service directly from the examples that Service Owners have defined in their schema.
Service schemas have the ability to reference globally defined variables at a Team or Application level. No duplication of values is required by the Consumer
{
"metadata": {
"servicename": "VM",
"schemaversion": "1.0.1",
"owningteam": "networkautomation",
"service_dependancies": [
],
"requires": {
"application": [
"name",
"application_ci"
],
"team": [
"name",
"budget_code",
]
},
},
"cpu": {
"$id": "#/properties/value",
"type": "integer",
"title": "cpu cores",
"description": "Number of cpu cores",
"default": "2",
"examples": [
"2"
],
},
"memory": {
"$id": "#/properties/value",
"type": "integer",
"title": "Memory",
"description": "Memory in GB",
"default": "8",
"examples": [
"8",
"16",
"24"
],
},
}
Change and Lifecycle management
As a Service Owner NetOrca keeps track of all of the Service Items that have been requested against your Service.
Customers can create a declaration for a Service Item based on your JSON Schema definition. It will be automatically validated and then submitted to the NetOrca platform.
Once it is there NetOrca can determine if it is a:
- New Service
- Modification
- Deletion
The appropriate Change Instance with all the required details then gets raised for the owning team.
Consumer declaration
Consumer uses the provided example to create a declaration for a new Service Item
Validation
Consumer declaration is validated against schema and change type determined.
Changes Created
Create, Modify, Delete changes created ready for processing
Changes Approved
The Service Owners have the option to approve changes here
Change completion
Service Owners are free to use any automated or manual process they wish to perform the changes. Change completion is reported back to the consumer.
The basic process described above is non-blocking and consumer can continue to stack changes before others are completed. Allowing them to get on with what they need to do and not be concerned with the speed of another teams change process.
Flexible Implementation
With NetOrca your team builds how the changes are implemented.
This means that you can use any automation system that is currently deployed within the team, or that the team has the skills for to implement changes. NetOrca simple offers the change management and orchestaration which would otherwise be a large component of your deployment.
In addition NetOrca supports changes to still be processed manually.
Define first automate later
By allowing manual change support, NetOrca encourages teams to put effort into properly defining their services so they can be consumed from a simple request.
This encourages Service Owner teams to remove unecessary components of their normal service requests and reduce it down to a simple configuration file.
Once that exercise has been done, the automation of the change itself becomes much more trivial as you process is now being feed with well defined validated data from it’s Consumers.
Automated Modules
NetOrca has a suite of pre-defined modules to interact with the change process. These include ansible and python implementations.
Service Owners can utilise these modules to handle the communication and updating to the NetOrca platform and these modules can be easily connected to csutomer or vendor provided automation solutions.