the size does not impact if you can maintain microservices or not. Microservices are about just breaking code apart in reasonable packages.
agree, let me say that there always be exceptions. some team would be fine with doing microservices and maintaining them even with 1-2 people. Some team will be suffer with devops and 10 devs.
Setting up basic setups in time of cloud and hosted Kubernetes Clusters or hosted Microservice services is achievable by every developer.
achievable definitely yes, but it could take weeks of work without knowledge of how to do so and what does it even mean. With Kubernetes developer without a proper background will have pain on each step because he will need to configure cert manager, he will need to learn yaml syntax required for Kubernetes configuration, terminology, architecture of Kubernetes, then the simple tasks he get used become a problem as well such as - ssl certificates renewal, persistent storage, self hosted or cloud docker registry, configuration of ci/cd services. From perspective of project delivery, it's definitely not the best time thing to spend time on.
this argument is placed by someone who basically misinterpred microservices. You can start your microservice architecture with just having 2 services and as soon as you get to the point that it gets overcomplex you split it apart.
Microservices suppose to have a small as possible isolated parts of your application. I can't imagine that any real product even on the MVP stage could just have 2 microservice. It will be mostly Monolith + maybe 1 microservices, but definitely not a microservices architecture.
can't see the point of the used framework here? you can create microservices that run laravel ruby etc. microservices are about splitting complexity and business logic and making systems reliable and self sustaining from each other.
Microservices on laravel? I don't think someone will be build microservices on laravel framework, there are a lot of alternatives for PHP to make microservices smaller and better than grab all stuff laravel could get to you
what?
that's advice could be addressed for everything development related. Don't go ahead with technology for production usage if you the only one reason you chose it is "it's cool"
Someone has to do the hosting even of your monolith and it comes down to either a developer or a devops. and i think we can agree that is way more pain hosting a LAMP or whatever sytem and maintaining it than to have docke swarms or kubernetes clusters. especially when you start a new project.
Instagram clone, one services handeling accounts one service distributing images without extracting the database handling logic out of it. Yes you can split it further by one for rendering images and so on. But here you have the point. You start with a small microservice layout. and as soon as you se it gets to complex you split a service again. this is the point of having an evolving microservice architecture. You cannot possible all the services that you will end up with.
Laravel even have a microservice addition: lumen.laravel.com/ :D
There is no this now not a microservice, for example you have an onlineshop and you are using laraval for model creation in each of the services.
An important point is: "There is nothing inherently “micro” about microservices per se. While they tend to be smaller than the average monolith, they do not have to be tiny. Some are, but size is relative and there’s no standard of unit of measure across organizations."
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
agree, let me say that there always be exceptions. some team would be fine with doing microservices and maintaining them even with 1-2 people. Some team will be suffer with devops and 10 devs.
achievable definitely yes, but it could take weeks of work without knowledge of how to do so and what does it even mean. With Kubernetes developer without a proper background will have pain on each step because he will need to configure cert manager, he will need to learn yaml syntax required for Kubernetes configuration, terminology, architecture of Kubernetes, then the simple tasks he get used become a problem as well such as - ssl certificates renewal, persistent storage, self hosted or cloud docker registry, configuration of ci/cd services. From perspective of project delivery, it's definitely not the best time thing to spend time on.
Microservices suppose to have a small as possible isolated parts of your application. I can't imagine that any real product even on the MVP stage could just have 2 microservice. It will be mostly Monolith + maybe 1 microservices, but definitely not a microservices architecture.
Microservices on laravel? I don't think someone will be build microservices on laravel framework, there are a lot of alternatives for PHP to make microservices smaller and better than grab all stuff laravel could get to you
that's advice could be addressed for everything development related. Don't go ahead with technology for production usage if you the only one reason you chose it is "it's cool"
Someone has to do the hosting even of your monolith and it comes down to either a developer or a devops. and i think we can agree that is way more pain hosting a LAMP or whatever sytem and maintaining it than to have docke swarms or kubernetes clusters. especially when you start a new project.
Instagram clone, one services handeling accounts one service distributing images without extracting the database handling logic out of it. Yes you can split it further by one for rendering images and so on. But here you have the point. You start with a small microservice layout. and as soon as you se it gets to complex you split a service again. this is the point of having an evolving microservice architecture. You cannot possible all the services that you will end up with.
Laravel even have a microservice addition: lumen.laravel.com/ :D
There is no this now not a microservice, for example you have an onlineshop and you are using laraval for model creation in each of the services.
An important point is: "There is nothing inherently “micro” about microservices per se. While they tend to be smaller than the average monolith, they do not have to be tiny. Some are, but size is relative and there’s no standard of unit of measure across organizations."