shoes too big for feet
Microservices Custom Software Business Success Scalability
June 19th, 2020 - Derek H.

Why We Don’t Build Software to Support Millions of Users

As custom software developers, it is our job at Entrision to deliver a product that is designed and built to perfectly address our clients unique needs. So when a customer asks us to build their software so that it can support millions of future customers, it often comes as a surprise--or even an offense--when we say no.

Let me explain (hint: it’s in your interest).

What Happens When You Jump the Gun

It may seem intuitive that, rather than having to worry about it down the line, you can simply build a software infrastructure now that can accommodate your many, many future customers. To some extent, that’s a logical way of thinking. Custom software should be built to scale up, so that two years down the line you won’t need to scrap the whole thing and start over again. Luckily, it can do that.

But over-compensating is its own danger. Building something too big, too early, can directly impact the success of a business.

Here’s the big point: Over-engineering a system for needs you don’t yet have adds unneeded complexity and costs now that can actually limit your future growth.

A recent podcast from Wix--the custom website company--offers one example of how “presumptive” scaling can wreak havoc on a growing business. In the episode, Yuval Perry, an engineer of 25 years, describes working for a growing e-learning company. The success of the company prompted a change: they’d graduate from their existing software, into one that was based in microservices. This is a common step for large companies that employ hundreds of developers spread around the world.

In just a few years, we had more than 60 micro services in production. We were very proud [of] each and every one of them because we built a sophisticated CICD environment and everything was deployed behind a feature toggle and it was super eventual consistent.

So we thought back then that we did everything by the book.

The problem, in this case, was that the company wasn’t yet big enough to where this change in digital architecture was necessary. Instead, they were upgrading in anticipation of needing to in the future. The consequences of jumping the gun like that manifested very clearly, very quickly.

As we grew a little bit more, [. . .] each person that breaks the build or breaks the ongoing development would have affected and impacted every other person in the team and eventually every time something would break, it stopped the development of all of the company. [. . .] We started to feel the load of the management. I mean things started to fail – to break more than often and it got into a point where I couldn’t imagine adding 10 more.

The bigger, more diverse microservices architecture was supposed to help the company work more efficiently. Instead, it had the opposite effect. Why? Because they hadn’t considered how their legacy systems would affect their shiny, new one. Their integration environment--where developers test new code to make sure it works--couldn’t be squared with the new microservices infrastructure. Every problem microservices were supposed to solve, instead, became exacerbated.

In the end, the company chose to delete their integration environment entirely. This was a very bold move--akin to shutting off the spelling and grammar check in your Word processor, forever. The company survived, but Yuval and his colleagues learned a valuable lesson in why scaling should be handled with deftness and patience.

The Bottom Line

Buying software is like buying anything else. Would you buy adult-sized shoes for your child, in anticipation of them becoming an adult? It wouldn’t be advisable. The shoes won’t fit for years to come, and by the time your child does reach adulthood, they may require a different size than you’d expected. Your money would be better-spent on shoes that fit them now.

Your business may very well turn out to be the next unicorn. If you went so far as to seek out a software solution that didn’t come pre-packaged off a shelf, you’re already ahead of the competition. If you then took that extra step of reading an article like this--doing your homework, to gain as much information as you can before making a decision--then you’re the kind of business owner I certainly wouldn’t bet against. But just because your business might have millions of customers one day doesn’t mean it’s time to accommodate those millions of people...yet.


may also like
Aug 22nd, 2019 - By Carlos G.

Benefits of Custom Software

may also like
Apr 3rd, 2020 - By Derek H.

Why Software Projects Fail

Contact Us

Have questions? Reach out. We're happy to chat about who we are, what we do, and how we can partner with your organization to better utilize custom software in achieving your business goals. Drop us a line and let's chat.