Messaging network software using DevOps delivery
What is DevOps?
– Simon Burbridge, VP of Engineering
DevOps is an approach to software development and IT operations that emphasizes collaboration and communication between teams, as well as automation through the use of tools and technologies. It promotes an iterative and collaborative approach to software delivery through regular and frequent release of the latest software, thereby enabling a feedback loop which enhances the quality of the end product.
This movement began around 2007 when it was recognized that there was a need to bridge the gap between developers, who create code, and operations, who deploy and maintain it, and the customers who use it. The name DevOps is a portmanteau of ‘development’ and ‘operations’, which reflects the core idea of integrating these two disciplines into one continuous, streamlined process. Through this approach, teams are empowered, collaboration is encouraged, and automation is utilized to promote efficiency and effectiveness.
Openmind overview
Openmind Networks is an independent technology company focused on mobile messaging software and services for the telecoms industry. Openmind messaging solutions allow telecoms firms to consolidate their core messaging, protect their network and unlock the potential in business messaging and 5G.
Boasting a highly experienced team of engineers, Openmind has consistently led the way in bringing new innovations to the mobile messaging market.
We are responsible for delivering over 1 billion messages a day with our global customer base which includes some of the world’s largest Mobile Operators, Wholesale Intercarriers, Aggregators and Social Media providers.
Openmind’s main platform is called Traffic Control with two versions still live Traffic Control 5000 and it’s successor Traffic Control 6000.
The problems inherent in on-premises and release-patch solution
Prior to adopting a DevOps approach to software delivery we cut a release of our Traffic Control product once a quarter. This release was then branched to provide a static snapshot of the code at this point in time. Therefore, any changes required to this version of the code base, e.g. a bug fix or a new feature, would have to be provided as a patch specific to this release of the software. Some challenges that this model throws up are:
- A large number of different branches of the code base need to be maintained – effectively as many branches as there are live deployments.
- A critical bug found on one release has to be propagated to all other branches.
- A new feature written for a specific customer on one branch needs to be written at least twice, once on the branch and once on the head of development.
- New features written in this way are not automatically available to all customers as they are all potentially on different branches.
- Code written low down in the code base (e.g. in a library shared by many modules) needs to be propagated upwards potentially leading to patches which need to deliver multiple binaries, hence making the patch delivery unwieldy.
- The method of delivering a patch is cumbersome, requiring a Virtual Private Network (VPN) to each customer site.
Customers get a complete upgrade every 3 months
The beauty of the DevOps framework is that you move from the paradigm of branching to the CI/CD model of software delivery, i.e. you only maintain the head of development and publish a deployable release at regular intervals, in our case daily.
Customers do not get patches anymore, but instead perform a complete upgrade each time they move from one release to the next. This created some interesting challenges which we embraced and overcame successfully:
- Each published nightly build has to be ‘production grade’. We achieved this by creating a suite a unit tests (tests run during the compiling and building of each software module of Traffic Control), QA tests (another substantial suite of tests that are run on the released Traffic Control image to test all functional areas) and Staging 1 tests (a further substantial suite of tests to test messaging scenarios).
- We created a new software component called Kudos which is our DevOps pipeline. This allows us to automate the running of all test modules, the publishing of the build once it passes all tests, the pushing of that build to customer sites and finally the running of a suite of Staging 2 tests within the customers’ test environment to further ensure the publish release is production quality.
- Enhancements to our coding practices to ensure forward and backward compatibility of all our software modules. This allows different releases of Traffic Control to be able to run simultaneously within the same cluster.
- The development of a Rolling Upgrade Procedure (RUP) which allows us to seamlessly upgrade from one version of Traffic Control to another without any traffic interruption. Because Traffic Control is elastic and containerised, we can introduce components of the new release before we remove any of the old release, thereby allowing us to service messaging traffic without any disruption during the upgrade procedure.
All of these enhancements to our product and delivery paradigm means that we can fully upgrade our customer sites regularly within hours. No more lengthy, costly upgrade projects.
If you would like to discuss upgrading to TC6000 or would like to talk about messaging systems with us then reach out to us today.
