I do recommend going into this one service at a time as you split up your large monolith. Also picking and sticking to one general architecture and way of doing things allows developers to more easily move between projects built on different services.
Funny enough and having done both I would actually say it makes the application as a whole more complicated and sometimes slower then an equivalently well designed monolith because a monolith can be internally segmented as well without the internal communication overhead. The main advantage is that it forces well defined interfaces between services and it is clear that you can upgrade one at a time.
An example of things being slow in a micro service architecture is realizing you need to collect data from multiple services due to a new requirement. Since making many calls can be slower we tend to need to create purpose built interfaces. In the end the amount of implementation time seems to be higher then it was for the monolith and also because of communication between teams that had to work together on the interfaces but could be protective of their respective services.
People keep saying a monolith can't scale but I think it depends on the application design, we just deploy a whole copy of the main code base on a bunch of servers at the same time.
Currently we still have a large main application but have been able to split a bunch of it off into smaller services, I just thought I would share some of our issues along he way.
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.
I do recommend going into this one service at a time as you split up your large monolith. Also picking and sticking to one general architecture and way of doing things allows developers to more easily move between projects built on different services.
Funny enough and having done both I would actually say it makes the application as a whole more complicated and sometimes slower then an equivalently well designed monolith because a monolith can be internally segmented as well without the internal communication overhead. The main advantage is that it forces well defined interfaces between services and it is clear that you can upgrade one at a time.
An example of things being slow in a micro service architecture is realizing you need to collect data from multiple services due to a new requirement. Since making many calls can be slower we tend to need to create purpose built interfaces. In the end the amount of implementation time seems to be higher then it was for the monolith and also because of communication between teams that had to work together on the interfaces but could be protective of their respective services.
People keep saying a monolith can't scale but I think it depends on the application design, we just deploy a whole copy of the main code base on a bunch of servers at the same time.
Currently we still have a large main application but have been able to split a bunch of it off into smaller services, I just thought I would share some of our issues along he way.