Can an IT DevOps approach speed up CSP Innovation?

Source – vanillaplus.com

Copy your fiercest competitor

We believe that a new mentality and way of working, a far more collaborative, flexible and lean way of working is needed in CSP organisations. This is easier said than done as CSPs have inherited a legacy infrastructure. But a change in mindset, more transparency, collaboration and efficient processes will become necessary if the competitive level is to be increased or even maintained. One way of achieving this it to introduce a DevOps culture that could bring in improved results in many areas if well mastered.

Application providers made their mark decades ago and internet technology companies have enjoyed enormous success, all which has contributed to the highly competitive environment that CSPs find themselves in. Today’s CSPs have a lot to learn from the best players in the field, in particular those organisations that have adopted a true DevOps culture. While it may not be possible to fully adopt the principles and best practices from the most innovative Internet players, even by implementing just a few of their methodologies and tools, short term improvements in both services development and operations could be achieved.

The future CSP organisation

In their quest to become fully digitalised service providers, CSPs are essentially becoming software developers, with all the advantages and disadvantages this entails. This is not only because the future will bring us more virtualisation, network functions and software defined networks – frankly speaking this still has to take off among CSPs, at least in Europe. It is also caused by the transition to all-IP networks and it is tightly related to the embracement of the cloud, the possibility of performing advanced analytics in real-time and thus to respond quicker and more effectively to market demands.

Turning into a software developer also has cost implications. The traditional way of organising work in separate departments and projects is rigid and costly and more importantly these structures do not invite to collaboration and sharing across departments, functions or projects.

Thus these structures will not be sustainable in the long run. We believe the future CSP organisation will not have the same clear divisions of work and responsibilities that is common today, with neatly delimited processes, from design to development, testing, launch, operations and maintenance. In fact, in some cases there might not even be dedicated labs, as setting up and running these is costly.

But more importantly, we might be seeing many of todays’ processes and functions merge and transform into a whole new production chain. In this new production chain the developer is as responsible for the functioning of a service as the operations people are. Ideally there is trust, a desire to get things working and launched fast. Roles are flexible and developers might be asked to assist or participate in the operations of software or services they themselves have created, which increases the sense of shared responsibility.

The origin of DevOps

DevOps stands for ”software DEVelopment” and “information technology OPerationS” and was born as a response to the agile culture and its many different methods. It takes a holistic view of software system production and delivery and is as much a culture as a way of creating and deploying code by incorporating iteration and continuous feedback.

Exactly what a modern mobile operator needs? We think so and are happy to share some recommendations on how to start understanding the need for this process reengineering by embracing the DevOps approach. We think testing automation could actually be a smart place to start and then expand the transformation.

Some tips to get a head start

Ideally CSPs would implement a test orchestration tool for their labs where they can map the lab topology, including both physical and virtual resources and assets, such as nodes, testing equipment, virtual network functions (VNFs), connections and testers. We consider there are three key aspects to take into account before embarking on an automation project:

1 – Automate everything

The first step is to adopt the DevOps approach through procedure automation. Manual intervention means human errors and dead time waiting for human input. There should be no room for unnecessary manual steps in a modern test environment setup.

Everything begins with the environment installation and its setup. Tests are often intrusive and can even damage the setup leaving it unusable for subsequent tests. This means frequent reinstallations from scratch are required in order to ensure clean environments for new tests. Thus this should be one of the first items to check off.

In customer projects, and for reasonably complex laboratory deployments, we’ve seen installation time go down from one week to just five hours. That’s an impressive 97% reduction.

Additionally, migration from manual steps to automation in installations will benefit not only the laboratory environments but can also provide customer live deployments with a simpler, more elegant and robust experience. This becomes especially relevant in cloud environments in which not only the traditional software layer is included in the process but also the definition and deployment of the software defined infrastructure.

2 – Centralised recording permits focusing on value adding tasks

The migration of existing manual testing procedures is achieved by capturing and recording logs generated by each individual step which, once within the automation tool, can then be incorporated into a centralised log server.

When test automation processes are taken to the cloud, additional benefits will be easy recovery of test data, which is important due to test infrastructure being even more volatile in this environment. In a traditional test scenario failures would wipe out the whole test environment or make it inaccessible.

Having all relevant information stored in a server means test teams won’t usually need to perform log analysis in situ. This enables them to carry out work of a higher value, which in itself improves productivity as it shifts the focus from repetitive to more challenging tasks like validation of the outcomes of tests and others.

In an automated test setting, as tests are executed each step is captured and therefore automatically provides a complete audit trail to help with diagnosis and optimisation. This can be configured to be made available to team members, who might be working from different locations, allowing testers to focus on team collaboration and share their best practices in an efficient way, all in line with the DevOps culture.

3 – Know your exact strengths and limitations

Later in the test automation process, this initial centralisation of information allows performing algorithmic log analysis. This will not only allow for automation of the analysis of the test results but also open for root cause analysis driven by advanced analytics based on machine learning. Finally, it will also provide valuable statistical information on diverse issues such as common points of failure, resource usage or time consumption of test channels.

A deep understanding of the level of intrusiveness and resource requirements for each of the test channels allows for further optimising the use of test facilities on a 24/7 basis.

Innovate and launch faster

The work with implementing an automated test environment will very quickly give important time and cost savings. This is because testing can be done at far earlier stages of the product development process, such as launches of minimum viable products and also on a more continuous basis, of smaller upgrades. Any CSP that introduces the DevOps culture and process in the testing department will not only see a rise in productivity in this area but also speed up the innovation process itself. This will lead to improved time to market and a real capacity of responding to the fast changing market demands.

New releases of existing services could be based 95% on the current service, and with only minor upgrades, but much more frequent and gradual. This is necessary if CSPs are to effectively respond to the demands of the digital, always connected lifestyle.

The test teams could then go on to teach other departments how to introduce automation and the DevOps approach successfully, and help the organisation as a whole to transform.