Service Lifescyle Support Scenario - NEXOF-RA - BT
From FutureInternetWiki
Contents |
[edit] Service Lifecycle Support
NEXOF aims to ensure low barriers to entry so that service innovation can come from a very wide range of parties, companies, communities or even individuals. As a consequence, no assumptions are made about the nature of the service or service provider. Some of the steps described in this scenario may not be explicit in all cases but it is believed it represents a generally applicable pattern.
This scenario begins when a potential service provider identifies an opportunity for a new service. This is the result of activities that may include observing some unmet customer requirements, carrying out market research, determining that providing the service is within the capabilities of the provider (given available resources, including services already accessible that could be included) and that service provision is likely to be economically sustainable for its anticipated lifetime.
A service developer (or integrator) then designs the system required to deliver the service, according to the needs of the service provider. This includes identifying existing components and designing any additional software required. It is essential at this stage that the system is functionally correct (i.e. it does what the provider intends it to do) and also that facilities for monitoring and managing a running service are incorporated. (Typically this will require support for the usual FCAPS aspects – Fault, Configuration, Accounting, Performance and Security). This design may be, at least in-part, abstract, particularly where external third-party provided services are concerned. It is anticipated that these will be specified in terms of required properties, which are matched to real services at deployment time rather than having specific service instances built into the new service.
With a system design in place and novel components developed, the provider then determines resource requirements to support anticipated demand patterns. This also needs to include strategies for deployment and scaling of the service. Resources owned and controlled by the provider are out of scope for NEXOF, so the main concern here is to define dependencies on external functionality, including infrastructure resources (computing, storage, network etc) as well as application-level functionality.
The next step is for the provider to consider in detail how to expose the functionality of the service to his customers. This involves developing templates for Service Level Agreements (SLAs) and service descriptions. The SLA templates must clearly define the parameters by which service behaviour is measured and the provider needs to understand feasible limits on these parameters. This defines what levels of service can be offered.
In parallel with addressing service exposure, and still in the phase before launching the service, the provider defines operational management policies. These should use the management and monitoring features of the service implementation to define the desired behaviour in response to any anticipated service conditions. As far as possible these policies should be amenable to automation.
At this point, the service is ready to be offered to customers. It has a clear description; relevant functional and non-functional properties have been defined. Policies for operational management are in place and deployment procedures are established.
Customers must be made aware of the service, in terms of what it can do for them, how it can be used and what to expect for a given price. The provider achieves this by advertising the service in appropriate locations. This may include the use of public or restricted directories. From an architectural point of view, information models and protocols should be independent of any policy decisions made by the provider with regard to service visibility or accessibility.
On discovering a new service, interested customers obtain SLA templates and make appropriate selections within the parametric boundaries defined by the provider. The resulting bid (completed template) is sent to the provider who then assesses the ability to deliver against the proposed SLA, taking into account the resources available, all existing commitments for the same service (or others contending for the same resources) and any other business policy decisions. Following this assessment, the provider decides whether or not to accept the bid. If accepted, the SLA is concluded and enters into force. The provider communicates access information (e.g. endpoint details) to the customer and then waits to receive service requests from the customer.
Either in response to or in anticipation of service requests from the new customer, the provider may provision the service. This may involve, for example, new or increased resource deployment (or alternatively no change). There is then a phase in which the service runs to support the demands of its customers. During this phase, the provider monitors the behaviour of the service, takes management actions to maintain it at levels aligned to whatever set of SLAs is current, and carries out appropriate accounting, billing and customer support actions.
While the service is running, the provider may assess usage patterns, performance levels achieved in practice and maybe improvements (in quality or cost) that could be obtained by replacing some third-party components with others. As a result, SLA templates may be modified for future customers, typically offering more control or higher levels of assurance to the customer. When the service becomes obsolete or no longer in the interests of the provider to offer, there will be a need to withdraw and decommission it. It is straightforward to stop advertising a service and publishing SLA templates to new customers. However, existing customers and users must be dealt with.
In an open service environment, a particular service may be involved in complex relationships with others so the impact of withdrawing it may not be obvious. This needs to be recognised in the architecture. In simple cases the provider may offer a migration path to affected customers. In general the provider does not know in detail how the service is used so it may be necessary to announce its withdrawal and leave the service consumers to make their own decisions. There must be clear recognition by service consumers that services cannot necessarily be relied on in the long term. This should influence the design of NEXOF applications and services.
The rationale for this scenario is the following: the concerns of a service provider are not solely associated with running an existing service. A full service lifecycle view must be taken, and supported by the NESSI Open Framework. This starts from defining a service concept and then goes right through to ultimate withdrawal and decommissioning. As services in the ecosystem envisaged by NESSI may have complex relationships with each other, which are not under the sole control of a single party, it is important that the Reference Architecture ensures that services are manageable throughout their whole life.
This scenario applies to
- Any service consumer: Many service consumers will not be satisfied with best-effort services. Consumers need to have an awareness of the existence of services and providers through advertising. Needs a clear understanding of the characteristics of the services he uses including full lifecycle aspects, not just properties of the running phase.
- Any service provider:
-It is assumed that a provider may provide a range of different services to many different customers. Needs to be able to introduce new services into a complex service ecosystem in a systematic way. Needs to integrate with generic support systems and services (e.g. management, accounting/billing, CRM)
-Needs to make sure SLAs are based on realistic capabilities and customer needs (and price accordingly).
-Needs to have automated management for operational efficiency. Not all requests for service will be accepted.
-Needs an understanding of the service ecosystem and all relevant relationships to facilitate deployment and decommissioning.
- Any service integrator/developer. (Service integrator/developer role may
be combined with the service provider role in practice). Every service must meet functional requirements and provide adequate functionality for monitoring and management. In the environment of the NESSI Open Framework, dependencies should be expressed in abstract form so that specific supporting components can be mapped in at deployment time (and replaced later as necessary).
The problems or challenges of this scenario are:
- Understanding in detail the requirements on a service to make it
manageable.
- Representation of low-level resource requirements in service terms
(Infrastructure as a Service)
- Uniform deployment strategies applicable to a shared infrastructure.
Different approaches to scaling will be appropriate for different services. It is important that those required to make management decisions know what to do.
- Management of service (including infrastructure resource) dependencies.
The architectural constraints of this scenario include:
- Consistent and uniform approach to monitoring and control.
- Service description including functional and non-functional characteristics.
- Commonly understood (between provider and consumers of a service)
representation and semantics for SLAs
- Flexible and dynamic deployment of services into the service ecosystem.
- Ability to decommission and remove services with predictable
consequences for all actors.
