Engineering includes Economy
One of the travel vloggers I occasionally watch recently started a new venture - an E-commerce service for unique traditional products from rural areas. In one of the videos, he mentioned that his website had crashed on launch day. He claimed the crash was due to the high load.
It was interesting to watch a few comments from software development professionals. A couple of them suggested using Microservices Architecture - which is no surprise to me. Very likely, the folks who gave this suggestion are developing applications for some large corporations. Based on my observation, "Microservices" definitely tops the list of most misunderstood jargons.
While I appreciate these engineers' willingness to offer some free advice, to be honest, their advice was not professional after all.
"If your application crashes under load, then use microservices" - is a very dangerous conclusion to arrive at.
First, they failed to assess this entrepreneur's needs and constraints. Let us start with economic viability. Since this is a new venture, the possibility of this enterprise surviving and winning is low to start with. Hence, it is not wise to invest too much right up front. This means we need software that requires minimal upfront investment. This, in turn, rules out a completely custom-built software.
If we start with a particular architecture in mind and look for available applications (say Microservices), we would be less likely to find many. Hence, it might be better to start with what popular SaaS (Software as a Service)/ COTS (Commercial Off-the-Shelf) options are available in the market and ask if they suit our needs. Hence, the assumption that this enterprise built everything from scratch is baseless (A quick look at the front end was enough to prove it).
Unlike this situation, when engineers worked on their jobs, they were already working on a problem faced by several people over the globe and required a solution on a large scale, which should evolve quickly, too. Hence, the organisations that develop software will have enough money to invest in solutions that use Microservices architecture.
Coming to Microservices, they incur more cost per transaction compared to a monolithic architecture. However, they can evolve quickly as the changes are limited to a smaller number of services. However, for the services to have this quickly evolving quality, the engineers need to ensure the coupling between services is low, which costs money upfront.
To summarise from the entrepreneur's view:
- They need software with a smaller upfront investment to start with. A software subscription works better than buying one.
- The software system has a lower cost of maintenance.
- or to put together a lower cost of ownership.
- they don't need any of the extra benefits the Microservices offer.
- If they were to exit the business, they should incur less loss (the software shouldn't add too much to the loss)
They are better off starting with a subscription to Shopify or a similar ecosystem and making the necessary customisations with a custom storefront (or white labelled) to reflect their brand.
What an engineer at a large enterprise needs to learn:
- Understand that software costs money, and not every customer can afford every feature some software offers. Hence, economic viability should be kept in mind when engineering.
- Keep in mind the context. Start with understanding the context of your current project/ product. Start by asking why your current project makes use of Microservices architecture. How does it justify the extra cost that this architecture demands?
- Justify the cost to the user with the value the software (including architecture) offers if it doesn't change the architecture and features.
- Be willing to learn and adapt. (don't just adopt something because it works for someone).