0

Backstory: My new employer has Dynamics CRM on-prem and it is used by all office staff and other colleagues that are consultants. All other employees are a working force out on various construction objects, they do not have access to the CRM. There's a couple of business processes that have to be exposed to that workforce, like time reporting, safety routines, internal equipment orders and such. For that purpose my predecessor created a system from scratch which I now get to inherit :).

This system is a monolithic ASP.Net 4 web app, hosted on Azure and it uses CRM SDK to communicate with the CRM and practically use some of it as a back-end. A number of custom solutions also exist in the CRM, some are used through this ASP.Net web app.

This system is getting increasingly hard to maintain, I have recommended a complete redesign. Folks at the top are kind of aware of the issue and have given me a green light to present a concept This company is evolving fast and new features will constantly be desired.

So, I'm primarily a developer, but I have been involved in projects where I worked closely with architects so I have picked up a thing or two. With that said I am by no means an architect, although I am a quick study and I do find the topic fascinating. After giving this a great deal of thought I've decided not to reinvent the wheel and settle for more or less standard approach.

The plan: My first and most obvious step is to get rid of on-prem CRM and migrate to the cloud to Dynamics Sales. I must remove all on-prem vulnerabilities, and also add Power Apps, although I have no use for that yet.

Further (and this is where I'm uncertain of my choices) I will need to retire the monolithic web app and move towards modular design. I will split the new solution in two parts. For the CRM processes I've honed on microservice based API as a business logic container and on the client side - React GUI for tablets, laptops and phones which consumes that API. Microservice application will expose OpenAPI towards the React GUI and use gRPC for communication between services. Everything must be hosted on Azure, so React GUI will of course be deployed as a web app, but I am unsure about how to host microservices.

My understanding of microservice-based applications is not very deep. I feel that while I'm grasping the overall principles of this architecture, i may be missing some intricacies, so I would love to get some feedback on my thoughts here and maybe some pointers, existing designs / concepts to draw inspiration from.

Should be mentioned that I am sole developer/architect and future maintainer of this project. I have complete control of all decisions regarding design, structure, priorities and code, which means all the benefits of correct design and architecture are mine to enjoy :) I am also big fan of Robert Martin, Clean Code and TDD.

Thanks

2
  • 1
    "Monolith" and "Modular Design" are not mutually exclusive. A well-designed monolith should also be modular; protected by strong automated test coverage - this should ensure the monolith is maintainable in the long-run. Microservices are often tipped as a way of making code more maintainable for large projects run by large teams, but that isn't the case here. It seems you'd be better keeping as much of the existing code as possible (moving to newer frameworks of course); otherwise I'd suggest focusing your efforts on writing automated tests and refactoring for testability. Oct 8, 2021 at 17:51
  • I am exploring my options, so I am flexible and you do point out a viable route. I will certainly rethink my approach. Thank you !
    – MrDim
    Oct 11, 2021 at 6:57

1 Answer 1

1

Microservices are a response to Conway's law: "organizations design systems that mirror their own communication structure". Microservices developed as a way of increasing the productivity of large organisations by breaking down monoliths into units that could be worked on by smaller teams ("two pizza team"), without being blocked on each other's co-dependencies.

Should be mentioned that I am sole developer/architect and future maintainer of this project

You have a team of one? You're going to have trouble eating two pizzas by yourself, and you're also going to have trouble producing more than 50kloc of backend code a year, so you might as well just have one service. A single chunk of (ASP.NET Core maybe?) code that serves all your REST API routes.

1
  • Although I do not necessarily agree that the number of developers on a team is a deciding factor for application architecture, I do definitely see your point. Thank you :)
    – MrDim
    Oct 11, 2021 at 6:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.