Our Move to Google
In this blog post, I’ll explain the rationale and implications of moving our technology from IBM to Google.
This is not a decision that’s taken lightly, but as I’ll explain, is one that is right for the long term success of the company.
Background
A few months ago now, we started realise that the solution we had developed had some significant limitations, which if we didn’t address, would restrict our ability to scale the solution.
It was like a plane, taxiing down the runway getting ready for takeoff, suddenly realising there’s a critical operational decision to be made.
Should we stop and address the issue, or take a risk and continue on regardless?
Decision
We took the bold decision and decided to switch from IBM to Google
This is serious decision because it meant that we need to rewrite most of the code we had already developed.
There was nothing technically wrong with the solution, but rolling it out across more and more customers manual management, which would make it much harder to bring on new customers and write new integrations.
It was a bold decision to move, but i believe it was the right one, and I will explain why.
Rationale
Google is very easy to work with as a startup company, and their technology is enterprise grade, leading edge.
In fact, the key piece of infrastructure technology we use – Kubenetes – was developed by Google before being made open source.
Most importantly though, we decided to change our programming language from Python – which is great for general purpose development – to Swift, which is much more suited to high volume analytics.
As a low level, compiled language, it is much easier to introduce concurrent processing, which is what we need to scale our solution effectively.
Benefit
So without getting too technical, let me give you a simplified example.
In rough terms, we can say that one hour of heavy duty processing on IBM WatsonX using Python will cost about $5.00.
The same workload, when implemented as a Google Cloud function rewritten on Swift, cost a fraction of that.
It’s not so much the cost, it’s the time that matters. Particularly when you’re developing something very complex it’s extremely important to be able to iterate quickly, and we were finding that the WatsonX solution wasn’t up to the job.
Outcome
The good news is that we have moved most of the Infrastructure over to Google.
It’s too simplistic to say it was a lift and shift because the code needed to be rewritten. However the infrastructure component is now done, and we plan to be completely out of IBM by the end of 2024.
Apart from better and faster technology, this move allows the team to specialise in certain technologies, while still delivering a standard, scaleable solution.
Ashley Peak, our CTO, has responsibility for the Google infrastructure, and manages the delivery to customers.
Joshua Lane, our front-end developer, heads up the Desktop team, which focuses on the platform and the end user experience, including KIRAA our virtual assistant.
My role focuses on the back-end, generating the content required to populate the large models, and building the tools that we use internally to keep everything running smoothly.
Implications
We are believe this was the right decision overall, there are some important implications. The first, obvious one, is that it has delayed the rollout of the advanced integrations.
In some way this was a good thing because it allowed us to focus on the core knowledge management product, which we still believe is highly valuable, but it’s a much harder sell.
Many customers, rightly or wrongly, still think of AI as some kind of silver bullet solution to eliminates people, whereas we see AI as technology component which contributes to making the overall solution more effective.
Of course our foundation customers are very keen to see the advanced integrations running, so it’s been important to communicate these changes with our foundation customers, and continue to demonstrate value with our core product.
This is a significant upgrade to our technology stack, and a full cyber review will again be required. But the technology now allows us to scale with simplicity.
This is now the third time we’ve rewritten some of this code, and every time we do, we learn how to make it more scaleble and more reusable.
The technology we are now using opens up the door to many new possibilities, both on the desktop and the device.
Conclusion
So in conclusion, the Generation 3 architecture was a wise, long term decision that has been incredibly painful in the short term. The entire team has been working feverishly over the last few months to and will continue to for a little longer yet.
Although there’s still a lot more work to go, we can now see a path forward that will allow us to onboard new customers and service existing ones much more easily.
I would not say that starting with IBM Python was a mistake, but it would be a mistake to continue for convenience. It had to be done now.