I can’t speak for most programmers, but I started my career by taking courses online. That’s right, the courses I learned from my undergraduate degree are too theoretical for anything in the real world, so I took upon myself to learn about web/app development. It didn’t take long as there are very good resources out there on websites like Udemy, Coursera, Pluralsight, edX and more. Pretty soon, I reached the point where all web developers would reach at some point of their career, learning micro-service. It’s all about Docker, container, Kubernetes and orchestration. Feel lost yet? Well I did. Not because all of these terms are overwhelming because the courses that teach these things are pretty reasonably paced, but, as soon as you finish the course, you forget how to do micro-service. I have figured out the reason why.

The Domain Problem

In micro-service, you divide a large piece of backend code into different services that only take care of its own domain, hence, micro-service. The problem is, the courses you take are designed with teaching you this concept in mind, so the course project would be something that can be perfectly divided into several services that just work together and be able to show you the benefit of using micro-service. However, when you practice on you own personal project, there are usually issues with turning it into a micro-service based project because of various of reasons. It could be that your project is too simple to benefit from micro-service, or it could be that eventual consistency is not something your application’s data model can tolerate. The point is, it’s hard enough to come up with something to work with micro-service architecture, let alone making sense of how to divide up the original application into multiple domains. Even when you do find something that can work, being someone who just started learning micro-service, you probably don’t know if what you did was the best practice. This is because, truth to be told, no one really knows what is the best practice in micro-service. It varies from product to product, and the only way to truly validate it is by using large scale tests either with real users or a chaos engine of some sort. As a developer who just trying to learn something on the side, this is too costly.

You Are Your Biggest Enemy

Ok then, if small practice projects can’t cut it for learning micro-service, let’s just do something big. Let’s build the app that we always wanted to build and start with a micro-service architecture. Well that wouldn’t work either. Let me explain.

Building something in micro-service instead of a monolithic code base takes significantly more time. It’s not only harder to do proper full scale testing, but also debugging is much more challenging all of a sudden. You likely will see a lot of repeated code in each service. Then you decided that you are going to abstract that layer and reuse some common library. Or maybe you decided to fully embrace eventual consistency, but then you would need a solid messaging service to aggregate all the events. How would you deal with the database of each service? They cannot live in the container because once it goes down, the data go with it (unless you do something to keep the volume which is super hacky and unreliable in real world large scale products). Suddenly you have to make a lot more decisions and implement a lot more just to get the skeleton of the app.

I’m saying all of this because it’s not like these things are undoable, but it’s because you are just one developer. You are not building the next Netflix that needs to scale to the whole world with huge bandwidth. You are just building a hobby project or trying to learn. Micro-service is not a skill like React you can just pick up and practice. Micro-service is a complicated way to solve complicated problems. You can’t solve a problem without having it first. That’s why learning micro-service always feels hard.

Create The Problem First

Go ahead and build your dream app you always wanted to build, but do so with a monolithic code base. Try to focus on what matters, the business logic and user engagement. When you can actually release the product, iterate it with more features, you can probably look at it and see if you are hitting any scalability issues. Is the server holding up? Is there any performance bottleneck that forces you to scale up everything just for making few lines of code run faster. If you can find one or two area that can be scaled up in an isolated way, just add one or two services to you app with the existing code base. You can orchestrate the services if you want, but if it’s small enough and doesn’t scale beyond multiple regions, you can just do direct communication between the services. The point here is, if you don’t need something complicated, like discoverable services, don’t used it. KISS (keep it simple stupid) is the key here.

By “creating the problem”, you get the chance to “fix” it. That is the true learning here. Micro-service, like a lot other complicated solutions, is without its meaning if the problem didn’t come first. You can now put on your resume that you increased the performance of you website by 80% by adopting micro-service architecture.