Headforwards have worked with NTT for around 13 years, helping them develop a cloud hosting product, a Single sign-on (SSO) portal and ticketing systems. Headforwards were also involved in several iterations of NTT’s shared data centre service management system, Colocation, or “Colo,” for about a decade. This time saw Colo evolve from one part of a vast, monolithic architecture to its own series of 80+ microservices.
Initially Headforwards had provided a team to work with NTT to develop and maintain Colo within the monolith, while another Headforwards team worked with them to develop, from scratch, a cloud services dashboard that employed a microservices architecture.
This meant that when the decision was made to migrate Colo away from the monolith, not only did Headforwards have the experience, as well as base architecture, tooling, and microservice templates that could be adopted, but NTT had confidence in the work we can do with microservices.
Colo was to be modularised into microservices in the same way as the cloud services dashboard, but in the case of Colo it meant migrating from the existing monolith. Thus, the existing system had to be maintained during the transition, and its services migrated feature by feature, while minimising the impact on the user.
Headforwards implemented data synchronisation between the old and new systems during this migration process until the old system was eventually decommissioned.
It was decided to use Golang as the language for the Colo microservices, given the positive experience that Headforwards had with it for developing the cloud services dashboard microservices and due to the efficient use of resources that makes it well suited to cloud-native development. It also creates lightweight and portable applications that are ideal for containerisation.
Also building on the cloud services dashboard experience, the base microservices that Headforwards had developed for that project were adopted by the Colo team to handle customer and user data, authentication, and authorisation in Colo.
NTT delegated the task of modularising Colo to different internal teams, initially in Europe and later in Japan.
Headforwards were able to adapt to these client changes and support each team, providing code, quality assurance and user documentation, with experienced developers who had worked on each Colo iteration, until finally ownership of the Colo microservices passed entirely to the NTT team in Japan.
As a result of the shift to microservices releases of new code occur much quicker, more regularly, and with little or no interruption to services.
Colo release cycles were reduced from several weeks for a change to the monolithic architecture to just a few days for an update to a microservice. This is possible because the team has its own CI/CD (Continuous Integration/Continuous Delivery) pipeline and is no longer dependant on a central platform team to coordinate large releases of work from different teams.
The reduced dependencies between different microservices mean that releases can be small, frequent, require minimal manual testing, and are less likely to negatively impact existing functionality. A hot fix can be implemented confidently within hours, with no dependency or impact on other teams.
On-boarding developers is also much quicker with microservices. New developers become productive within, perhaps, a couple of weeks, without having to learn the framework, language, and platform for a vast monolith, which in the case of NTT had a database of around two thousand tables and took several months for a developer to get up to speed with.
With the various microservices having their own repos, less time is spent resolving merge conflicts that were common with the monolith where different teams could be making changes at the same time. Similarly, each microservice has its own database, so unexpected impact is less likely from a schema change, and these are easy to roll back where required.
Microservice teams decide their own technology stacks and implement services using those chosen technologies. This gives a team flexibility, but it can create complexity where resources are more limited, and people are required to move between teams.
Therefore, it tends to be the larger organisations, especially those distributed across various locations, and that can scale by creating new teams and microservices, that benefit most from the advantages that microservice architecture brings.
Smaller organisations that see less benefit in moving from a monolith to microservices may find alternative ways to modularise, such as by refactoring the code to create a distributed monolith with reduced dependencies.
For a broader discussion of the pros and cons of microservices, see our article and webinar Navigating Complexity in Microservices and Distributed Architectures.
IT infrastructure and service provider, Softcat have been working on expanding and maturing their Cloud service portfolio. As their technology partner, Headforwards helped Softcat reimagine the interaction they have with their clients by delivering a Cloud Management Portal.
The route to streamlining an organisation and boosting productivity often lies in the integration of software to digitise manual processes or enhance systems. But how do you make sure you select the right solution for your organisation? Headforwards’ Product Manager Owen Hodge shares five things you should consider when deciding between fully custom or customised off-the-shelf software solution.
Our work with several departments within Cornwall Council involved unifying multiple datasets and presenting insights in digestible formats for both internal and external stakeholders.
Headforwards™ is a Registered Trade Mark of Headforwards Solutions Ltd.
Registered Address: FibreHub, Trevenson Lane, Pool, Redruth, Cornwall, TR15 3GF, UK
Registered in England and Wales: 07576641 | VAT Registration Number: GB111315770