Fast vs Complex
Recently I've been reflecting on some of the services I've built and run at the enterprise level. In particular, I've been thinking about how the performance to the end-user hasn't really changed in the last 20 years (yes, I'm old).
This all stems from a conversation I had with a colleague about 15 years ago after we had delivered a new underwriting platform for the London Market. The system had been delayed. This was in part down to performance issues that emerged late on in testing due to adding third party integrations and complex searches on new fields as part of new functionality. And so I was curious to see how the performance had improved over time in the context of his delivering technology in the Lloyds market.
For context, my colleague was at the end of his career, and often talked about the days of mainframes and manually inputting all data. So I was genuinely surprised when he said that the performance was about the same when running queries and looking up clients between when he started and the new system we had just delivered. The difference he said, was in the complexity. Speed had stayed the same but the complexity behind the searches, queries, and general functionality had increased exponentially.
That has stayed with me ever since… and is never more relevant than now.
I’ve helped lots of clients build and run all sorts of different architectures and services. While Microservices are extremely flexible and rapid to deploy, there is a hidden cost to these services, especially as they scale. As services mature, we frequently see more integrations (and data) start to emerge which drives complexity behind the scenes.
Complexity can come in many forms. Here are a few that come to mind in the context of this post:
In the old days of data centres and client server architecture (gather round children 😉), there was an inverse relationship between spend and application performance. Spend (hardware) was more or less fixed** and – generally speaking – performance was tuned at the app level. This involved lots of performance test cycles where you’d also try to tune the environment. All this took a long time and careful coordination while involving lots of people with all sorts of different skill sets, all while the business tapped its foot impatiently and finance watched the project's budget increase hour by hour.
Now, with Cloud, it’s completely flipped. One person can build and deploy an app (or series of microservices) and can tune the environment to make the service work quickly, and in quite a cost-effective manner. This is a stunning turnabout and the reason why so many tech companies are successful (thank you Captain Obvious) but it can also be a catastrophe for an enterprise organisation. One such example is the story of someone who was experimenting on a bank’s Cloud account. They built and deployed an app on AWS but didn’t really understand the operational side, and the firm received a $1m invoice from AWS in a month for services that weren’t designed properly and kept autoscaling uncapped.
Carefully designing platforms and integration services is now something I seem to be spending a lot of my time talking to clients about and it’s refreshing that people like to hear about our experiences running platforms so they can learn how to prevent operational costs from being too high from the start. In fact, nearly all the conversations now start with that angle, which is great to hear!
If you’re running enterprise-like services, what you will likely see these days, is while the speed of your services will likely stay the same, the cost of doing so behind the scenes will probably climb fairly steeply as complexity drives increased processing, storage requirements, networking... the list goes on. You need to design for that and make sure any changes are visible and understood.
** yes you could play around with VMs or add more memory but that involved lots of people and was generally very visible, time-consuming, and lots of people got in trouble messy for all involved!
The latest insights
Get the inside scoop — delivered straight to your inbox.