I am a cloud application architect with 10 years' experience in software development in several languages, including Perl, Java and C#. I'm an Irishman living in Calgary, Canada. GitHub on @cubikca.
Location
Calgary, Canada
Education
BSc. Computing and Info Systems, Athabasca University
I think there's both logical and techincal reasons to take on the additional work at the beginning.
From a DDD perspective, domains often align nicely with the expected complexity of a microservice. The ability to containerize the entire service including storage and infrastructure allows you to make new atoms and manage complexity better. From a security perspective, different services have different security requirements. If you package a service's identity with the deployment, it is very easy to provide cloud role permissions. From an application code perspective, aligning to the DDD provides traceability to the high-level design, reducing defects in the long run. From a management perspective, different services can be owned and developed by different teams.
I agree that a monolith is easier to develop. But in my experience, it is not so easy to maintain, or to bring in new people on such projects. If you have any or all of the requirements I mentioned above (traceability, DDD, management), I believe that microservices are an appropriate solution. If these requirements aren't there, a monolith is by far easier to manage in the short-term.
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 think there's both logical and techincal reasons to take on the additional work at the beginning.
From a DDD perspective, domains often align nicely with the expected complexity of a microservice. The ability to containerize the entire service including storage and infrastructure allows you to make new atoms and manage complexity better. From a security perspective, different services have different security requirements. If you package a service's identity with the deployment, it is very easy to provide cloud role permissions. From an application code perspective, aligning to the DDD provides traceability to the high-level design, reducing defects in the long run. From a management perspective, different services can be owned and developed by different teams.
I agree that a monolith is easier to develop. But in my experience, it is not so easy to maintain, or to bring in new people on such projects. If you have any or all of the requirements I mentioned above (traceability, DDD, management), I believe that microservices are an appropriate solution. If these requirements aren't there, a monolith is by far easier to manage in the short-term.