Microservices using Laravel

@gitwithravish You wouldn’t use a batteries-included web framework like Laravel for micro services. It defeats the point of micro services if every service is 60MB+.

Monzo, a challenger bank here in the UK, is another company that adopted a micro services approach. But these companies all have one thing in common: a massive engineering team. Micro services just increases development time and complexity, so adopting a micro service architecture doesn’t magically make your application easier to develop or reason about. It in fact does the opposite, as now you have to maintain multiple codebases, orchestrate deploying multiple applications, and so on.

Don’t adopt micro services just because that’s what Uber does. Adopt micro services if you’ve researched them and came to the conclusion that the approach will definitely be better than a “traditional”, “monolith” approach. Because 99% of the time, a monolith will still be the best approach. Even Facebook is still a monolithic codebase and they’ll probably have one of the largest and most complicated codebases in the world.

I think this post is not going to be short, but once and forever I want to clarify micro-services architecture.

A "micro-service" is an application outside the context of your website with which your website communicates. Most of the time, this communication is done by the help of a REST API.

Your client side application can send requests to an API and get the proper response using Javascript's built-in Fetch or a third party library like Axios (Extremely popular in Laravel's community). Moreover, your backend side can send and retrieve information too. For instance, Laravel has a facade called Http, which is used to send different types of requests to any where you wish to.

There are other complicated options for micro-services intercommunication, for example message brokers like Kafka and RabbitMQ but if your are beginning to learn about micro-services you don't need them. They are probably useful for enterprise applications.

To summarize, building a micro-service can be simple as sending an HTTP request, if you are following a valid structure. There are numerous shared characteristics that define a micro-service, like the very fact that each micro-service has a separate database or each of 'em is independently deployable. But at the end of the day the process of creating an application which uses micro-services is NOT complicated.

In conclusion, building micro-services is not as hard as it seems, if you completely understand the underlying dynamics. I'm constantly thinking about creating a follow-along course on Youtube to explain everything is needed to create a micro-service, probably using Laravel, 'cause that is my main choice for building web-based applications. and after starting the course I will post the associated link in this thread.

Hope this helps.

Below comes from my experience with microservices. Kindly take it as notes.

My Experience with Microservices

• We have successfully implemented microservices by keeping some characteristics of it. We divided our project into 15 different backend projects including APIs and worker environments.
• The services that needed database has its own data store. (mysql, mongo and redis)
• Most of the services are based on laravel PHP, but a couple of those uses python for its AI ML libraries.
• Every service , its logic, its data is only exposed by one and only one way which is an API gateway in front of each service.
• This way we could very easily divide developer teams and provided them one or two microservices to work on. They independently work and they do not require to even coordinate back to back with other teams because the standard of the API are maintained regardless of the logical implementations within it.
• We use message broker service to communicate between microservices so that each service has high availability.

Role of database

• If a microservice is a worker environment whose job is to perform some tasks / calculations only, then it may not be require for it to have its own data store. You can pass data to it as @snapey suggested
• Sometimes microservices are require to be very small otherwise it defeats the purpose as @martinbean suggested.
• A big application can be divided into multiple modules and in that case a microservice may have its own data store. In this case the services are loosely coupled because the database, source code and the infrastructure can be modified, maintained and scaled separately without requiring much knowledge and communication to the other teams and microservices maintainers as far as the API of microservice is keeping its standards as it is.
• In many cases, having multiple databases might seem very challenging and therefore it could be completely normal and acceptable to have a single database (in some cases). However it introduces coupling for sure, but its just with the database layer. If anything changes in the database and schema design, then every microservice has to make those changes and redeploy.

Monolith vs Microservices

• Before even diving into microservices, you should first understand the characteristics of it and study a few applications that are built on microservices. Study does not mean you look at an diagram on google which says Order Service, Restaurant Service, Kitchen Service, Accounting Service etc interconnected with adapters and message brokers. We must understand a lot more than that such as what sort of logic is written inside microservice, how they communicate (synchronous / through message broker), what happens if one microservice fails and much much more. You must do good amount of case studies before thinking about monolith vs microservices. If you do not know microservice well, then the default answer is Monolith for you. Because there is nothing worse than building a microservice with half knowledge.

Wrong decision can bite you

I have seen a couple of project that failed because of inaccurate decisions regarding "Monolith vs Microservices".

1. Monolith was a wrong choice. My first startup company had a typical management who needed a STAR PRODUCT within no time. They forced they saw developers just as "manpower" and therefore the dev team created a big monolith mess. Now, the application worked just fine and we got investment as well and business started off ! The problem arrived while scaling the app. The developers took literally months to launch small feature. And every time a feature was launch, some or the other part of the code was broken. Since the app was so big, new developers took a month to two, just to get a grip on the project. Dividing this application in microservices, just like 2 3 partitions, would have made everyone's life a lot better.
2. Microservice was a wrong choice. Project from a friend of mine was built with microservice concepts. The project failed because they implemented the architecture in a very wrong way. So wrong that maintaining the architecture become a financial burden and they barely find good teach people who can handle such a mess.

Clarifications

• There is no mechanical way to design microservices.
• "Micro' does not necessarily mean a microservice should be small in size. It DEPENDS. There might be projects where the microservice MUST be lightweight and there are projects where the SIZE does not matter, the characteristics that this division of monolith brings matters.
• People on community platforms speak with different vocabulary and with different contexts, therefore its best that you study the concepts first before opening thread with such vague question on laracast like me.
• Some people debate that microservice can have a common db as well as shared db. Where as some communities divide both the concept as SOA and Microservices respectively. Some dive deeper and debates SOA can have multiple db as well and this goes on. So never try to learn such big concepts with people's opinions. You need to spend great amount of time learning and experiencing these concepts.

With microservices, what I have learnt is, what matters is the idea of it. The characteristics that it brings and the advantages it brings. Now in order to retain those characteristics, there is no mechanical way. You gotta figure out how you can implement it in the right way.

I was also searching implementation of "Micro-service using Laravel ". But in the answers everyone is explaining micro-service. Hope this link will help if you want to learn micro-service implementation. https://www.youtube.com/watch?v=SzsPe_QX__c&t=1261s