Converged Infrastructure Management & BSS/OSS

You may possibly have been watching the emergence of Converged Infrastructure (CI) offerings from the major equipment vendors. In this entry I’ll attempt to examine the relevance of these products and their management layers to the OSS/BSS domain. This may be a near impossible job for a single blog entry, but here goes!

Significant product offerings in the CI space include:

(VCE is a joint venture between VMWare, Cisco & EMC).

Background

‘Converged Infrastructure’ (CI) products provide pre-assembled compute, storage and network fabric configurations relevant mainly for virtualisation workloads, in a range of capacity options. (Some of the above vendors also support pre-packaged configurations specifically for application and data workloads).

CI products are supplied with an integrated management layer enabling a range of hardware monitoring and management services, and also virtualisation configuration capabilities. It appears that some offerings also support workflow driven service activation for complex multi-layer virtualised services – it was this item that really caught my attention due to it’s relevance to BSS/OSS, prompting me to do some further investigation.

Good material I thought for another blog entry!

 

Benefits of CI

  • Software Defined Networking – CI products arrive pre-cabled and enable dynamic configuration of complex virtual resources in specific network topologies and security partitions, without requiring physical cabling changes.
  • Rapid implementation – CI products arrive pre-integrated and can be production ready shortly after delivery.
  • Validated Configurations – CI vendors provide validated combinations of equipment items in terms of software release levels, and ensure that ongoing upgrades are provided as tested packages.
  • Single Source – From the executive layer perspective, these products represent platform building blocks that are simple to acquire, implement and manage, and have single-source vendor commitment.

The story regarding the customer needs that drove creation of the VCE product set are described in this blog: VCE and Vblock –3 years in

 

Relationship to SDN

CI is a key platform via which Software Defined Networking is being introduced to Enterprise customers, saving customers from having to architect and implement their own SDN and associated management environments – CI appears to solve this problem in one move. Network Functions Virtualisation (NFV) is in the mix also, although I won’t try and address this here.

 

Management Layer functions

I haven’t had the opportunity to see the management layers for these products in real life yet, but I have had a quick dive into some of the documentation available online.

After a little investigation it became clearer that each of the associated management suites are focussed on supporting similar areas, as follows (assumptions are indicated!):

  • Discovery/Identification – probes for and catalogues resource item presence and configuration against manufacturer expected configurations,
  • Health monitoring – alarm capture & notification (& I assume contextual interpretation),
  • Event Logging – capture of items such as configuration change tracking, management tool access events etc,
  • Usage data collection / Billing support – it seems the tools allow definition of projects & would presumably therefore associate capacity/usage events produced to the Project level,
  • Environment validation – scheduled examination of component software release levels against manufacturer supported configurations,
  • Environment Upgrade – managed firmware/software upgrade processes,
  • VMware vCenter integration – CI vendors are highlighting their integration with vCentre as a key feature (some of their respective architectures for this appear to be different).
  • Complex virtualised resource configuration – this area has been harder to get a very clear view of. It’s not easily possible to determine exactly how much ‘service orchestration workflow’ occurs directly within the CI management toolsets, or in associated products such as VMware vCentre, EMC UIM etc.
  • API Support – supports external management system access for orchestration of above capabilities/access to management information.

Of course, the capabilities listed above are normally provided by distinct virtualisation, FCAPS, SNMP and AAA device management & configuration tools. Some vendor supplied product marketing material I’ve seen describes these ‘previous generation’ products as being disjointed and difficult to work with – including presumably their own well-established product offerings. CI is clearly therefore a very strategically important product category.

 

Relationship with the OSS world

My first reaction upon seeing these products originally was ‘uh-oh what does this mean for OSS..!’

It seems clear that the world of  integrated CI management tools is heading generally towards the OSS/BSS space. Of course OSS/BSS actually encompasses all of these areas – I’m using the term to loosely differentiate higher order/layer capabilities.

Whilst it’s not completely clear yet how fully embedded or integrated the configuration and orchestrated activation of full-stack virtualisation capabilities is within CI products, the general approach is obviously heading towards total unified management support.

So what role does OSS/BSS have to play in this scenario?

My view of CI management tools is that they are evolving towards higher layer management functions, from the equipment layer upwards.

Conversely it is clear also that numerous OSS/BSS tools are reaching downwards towards the virtualisation layer from the Service Management viewpoint.

Taking a step back, the capabilities supported in OSS management models such as the TMForum Shared Information and Data (SID) model were added originally based on the real-world needs of many service providers globally. It could be said that the modern ICT division of a large Enterprise class organisation is a service provider – services are contracted and recharged externally and internally, and strategy, planning /design is done from the viewpoint of the wider integrated system landscape, etc.

It will be interesting to watch which CI management toolsets evolve towards becoming more comprehensive in terms of OSS/BSS capabilities, and which ones stop at the API layer.

Data modelling decisions made early in the design of these products will make this evolution easier or harder. (Some vendors have made large OSS acquisitions that should make significant OSS domain knowledge & components readily available: Oracle/Metasolv, IBM/Intelliden, NEC/NetCracker).

OSS/BSS products are usually generalised for operation in a multi-vendor context across physical and virtual equipment / network resources . They may be used for workforce management, have understanding of application integration architecture, be capable of working in conjunction with ICT supplier partners, and deliver/support Product Catalog management, Billing, Revenue Assurance or Security capabilities (this is only a partially complete list!)

Regardless, it will certainly be very interesting to watch how CI management tools and the OSS/BSS domain evolve with respect to each other. There are numerous other major software and hardware based advances that are occurring separately from the pure CI domain – OSS/BSS must ultimately encompass all of these. I’ll save discussion of these for future blog entries.

This is really only a quick look across what is really quite a large subject area. I’m not an expert on CI products – perhaps you might have some comments, insights or corrections? If so I’d love to hear from you!

 

Thanks Ralph

In each blog entry I’m attempting to include some interesting reference material, which may either be on topic or completely off topic, depending on how you look at it 😉

Given that this entry is in the hardware domain, and because CI products reminded me initially of large mainframe implementations (visually), I’m including a link to the personal site of Ralph Klimek who tells the story of: A brief history of the Burroughs mainframe at monash university and my part in its maintenance. I should warn that it’s definitely not brief, and also quite technical – but anyone with an interest in technical things may find Ralph’s storytelling humorous and the nature of what he was doing ‘just a little bit out there’ by modern standards.

Possibly the description of what life was like in those days highlights the strong quality control benefits of modern CI products.

I was lucky enough as a pimply fifteen year old to be taken through the ANZ Bank data centre on Toorak Road in Melbourne, where they had a large amount of Burroughs equipment similar to that shown in the photos at the bottom of Ralph’s page. At the time it looked like something out of a sci-fi movie – Ralph has done a very good job of explaining the reality of it all!

 

 

2 replies
  1. Ryan Jeffery
    Ryan Jeffery says:

    HI Evan,

    Great summary!

    The things that I find fascinating amongst all these CI discussions is:
    1) At this stage, each CI only manages a sub-set of devices. Until SDN / NFV / etc are able to virtualise “legacy” domains like transmission (SDH, DWDM, etc), then there will always need to be a higher-order management suite (eg B/OSS) and the CI’s remain equivalent to an EMS / NMS
    2) A CI may be able to control all aspects within a jurisdiction (eg a data centre) but when expanding into a carrier environment, there is a need for federating control into other jurisdictions (eg creation of a service that traverses carriers in separate countries)
    3) It seems that many a CI implementation takes longer than customers expect and getting automations to work has many of the same (or similar) issues as getting automation established in traditional OSS.

    Rgds
    Ryan

    Reply
  2. Evan Linwood
    Evan Linwood says:

    Hi Ryan,
    Thanks very much for your comments! You’ve made some very good points and extended into the service provider world – always a good reference point including for Enterprise. Your comment re jurisdictions is a topical one as I’ve managed to find myself with two Apple accounts on the same device (one from outside Australia, the other is an earlier account type). Purchases are spread across both, iTunes is confused – it’s a mess. I’ve got the details of where to call within Apple, I’m just not sure I’m ready to go there yet! In terms of what you’re saying, the underlying practicalities must be quite complex.
    Regards Evan

    Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *