Don’t Build Microservices but if you must, then Build Services.

Due to the nature of being a platform and SRE engineer, I deal with these problems first hand, and as my consulting client base increases I am faced with the same problem with every startup who has established some market presence but still in its infancy.

The Problem

Startups want to build the most scalable solutions from the get go, they have high hopes and always dream that their software will reach millions of people. For this to happen you need to be agile enough to ship new features and have enough speed to make adjustments without breaking things on a regular basis. As with my previous article regarding Kubernetes, they try to solve the problem they are facing the enterprise way.

Instead of making their code base more readable or refactoring the obscure parts, people starts throwing every piece of code in its own repo and spin what is called a microservice with it. We now have multiplied the problem made it a lot harder to debug, deploy and reason with.

Why Microservices

A micro services architecture has a lot of benefits to be honest but it comes with a steep cost that small and medium sized startups are not ready for, I will list some of the reasons of why microservices solves some of the current software challenges

1. Scaling just the parts you need to scale; imagine having a huge monolith where 3 endpoints are getting more than half the traffic while their internal code size represents 10% of the code base to scale your application when you have a monolith means to deploy 2 or 3 more monoliths just to scale that 10% of your code base, moving the code to its own microservice is a good solution here, see we had a good motive here.
2. Reducing the tricky errors; I believe all of us has faced this one before, you make change to a function it works fine but something totally unrelated breaks, because well this function was being used and its signature changed someway or another.
3. Totally unrelated technical skills; a good example for this is image you are building a video streaming platform, the range of technical skills range from required to build that platform is huge ranging from usual web development skills for features like authentication and authorization, to video encoding and decoding skills, to fintech and payment gateway skills. For big organizations there is likely a dedicated team for each of these function so it makes sense to split them into microservices.
4. A huge number of engineers; in enterprises it is normal to find a thousand or 2 engineers working on the same project, the number of collisions and rebases needed to reconcile all these team members working on the same repository is insane so breaking these off to its own smaller microservices where related functional resides and team members will have easier times getting those PRs approved.

What is going wrong then?

Smaller to mid size business rarely face the previous problems and microservices becomes one of those trends they must follow to become trendy or secure a fund with some tech VC, I’ve seen a team of 6 engineers handling 20 microservices where they start to face problems they were not ready for like distributed log tracing and dependency metrics.

How hard can it be?

To have a real microservice architecture will mean a lot of things that you don’t really expect to handle and I will try to list a few here:

1. Managing Deployment and Versions
   • To deploy microservices you will probably need something to handle deploying all these moving parts for you, make sure they are up and making sures they are compatible, this leads us to platforms such as Kubernetes and the technical challenges that comes with it from engineering costs to dedicated resources and security problems.
2. A New Class of Infrastructure Services
   • You will now need to handle stuff like services discovery now between services, internal load balancing and distributed session management.
3. Logging and Metrics
   • You will need to enter the world of distributed tracing and how can you collect and tag related logs and how to handle connections between these logs.
4. Debugging
   • You will have to take into considerations to debug the messaging systems between various microservices you will need to consider a whole new class of network problems to be the factor and that your code might actually not be the problem
5. Slower Feature Release Cycle
   • Features will probably span multiple microservices making it harder to implement and involving a lot more engineering resources to get done.

A Question

Well someone would come up and say well I am a small business but I need some separation of concerns. I would advise you in that case to start building services rather than microservices.

How do I organize my services

Well you can decide on a lot of ways to split your monolith into services without going extreme and falling into the microservices trap:

1. Related functionality; to achieve the best code reusability so that you avoid duplicating code across repositories.
2. Traffic analysis and load balancing; so that you can get some of the benefits of microservices scaling
3. Teams; making it easier for teams for have the code changes reviewed within the same team.
4. Internal and external services; some parts of the code maybe refactored into its own internal helper services for example a data-compression services.
5. By defining data owner-ship; to avoid waiting on data locks you can split your services by which parts of the data they operate on so you can organize internal locks or mutex rather wait on a database and network I/O to organize this as networked locks are extremely costly in performance.

The Conclusion

For small organizations, the operational benefits from a microservice architecture may not be worth the increase in complexity. Additionally, microservices will often require dedicated engineering resources to support them, which may not be financially feasible for early stage startups or could be lower on their list of priorities.

Directing you engineering resources to build features and sustain a simpler architecture is the way to go in the cases of small to mid sized startups where the engineering resource is somewhat limited and the business value of building microservices is still hazy.