Application Communication – Preferred Way of Communicating Between Applications on the Same System

Consolidating authentication into a single service is called Single Sign-On and it's been a thing, even a best practice, for like thirty years.

His suggestion is that we either write the authentication into the individual applications or we should provide some sort of redundant auth system for if the primary system fails.

You already have your ASP.net authentication in the individual applications, so, to be fair, “write the authentication into the individual applications” (with a lot of cut and paste, or shared libraries, or whatever) is probably the least amount of work.

The redundant auth system suggestion is a security problem as well as a maintenance problem and is clearly bananas. It's not a serious suggestion.

It looks to me like you have a people problem, not a programming problem. Your people problem is that you need to figure out your colleague's real reason for objecting. It probably isn't anything he's actually said.

Some possibilities:

1. he feels that rewriting the whole auth stack for each application will be too much work.
2. he feels that rewriting the whole auth stack for each application is too risky, in terms of possibly breaking the existing credentials authentication.
3. he doesn't understand the IdentityServer solution and because of that isn't comfortable with it.
4. he didn't come up with the IdentityServer solution himself and because of that isn't comfortable with it.
5. he feels like taking on 2FA is enough new technology to deal with and enough new complexity to add to the apps, without taking on OpenID/OAuth/etc., etc.
6. something else I haven't thought of

You need to find that underlying objection and evaluate it fairly. (He might even be right!)

One approach would be to step back from the specific solutions you've each advocated and try to at least agree on the criteria that should be used to choose a solution, taking into account each of your preferences regarding technical risk, short-term vs. long-term workload, etc. (In negotiation school, they call this distinguishing interests from positions.)

If, in the end, he's still convinced that he's right and you're wrong, and you're still convinced that you're right and he's wrong, you need to kick it up a level to where you can each present your preferred options to someone empowered to make the call. And then you both need to accept the decision.

Microservices are generally undesirable because they turn your software into a distributed system – and distributed systems make everything a lot more difficult. But a service-oriented architecture has some important benefits:

• different services can be developed and deployed independently by different teams
• different services can be scaled independently

As you will be the sole developer, you do not need the flexibility to develop the services independently.

But you note that some parts may be CPU-bound. So it might be desirable to scale those independently from the rest of the application. If that is the case, that doesn't mean that you have to turn the whole project into a microservice-architecture. You only need to move that CPU-intensive part into its own service, and can keep the rest in a convenient monolith. Along which lines the system should be split up is difficult to tell, but in general the DDD idea of “bounded contexts” is a good guideline.

Note that monoliths are not bad. Monoliths do not equal a huge messy unmaintainable project. Where you could split the system into different microservices, you can also split the system into different components within a monolith. The separation between these components is just more visible and more clearly enforced in a service-oriented architecture. This also means that for a well-designed system, it should be fairly easy to turn a component into a service at some later point. So you don't have to decide right now, you can move to microservices if and when a monolith has proven itself unsuitable.

Consider also Martin Fowler's concept of the Microservice Premium (2015): microservices introduce substantial complexity of their own, in addition to the base complexity of your system. You have to pay this “premium” in terms of reduced productivity. This means that for simple projects, microservices make you less productive. This changes for more complex projects: whereas a monolithic solution might become increasingly difficult to work with, a microservice architecture scales much better and requires roughly constant effort. You have to know whether the extra initial effort of microservices is worth it given your software system. Since you are asking this question, the answer is probably “no”. Fowler continues:

So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don't try to separate it into separate services.