>In fact, that's how most non-web software is still written and done.
I can even add that we only do web software, but we do them exactly that way.
>If anything, it adds more complexity because now we need to do all kinds of data marshaling, error checking, monitoring, have more infrastructure for something that should have been done in shared memory/in-process to begin with.
I couldn't agree more. Martin Fowler warned us a long time ago : "The first rule of distributed objects : don't distribute them".
>There are a few exceptions where its useful to scale out parts of a distributed application
Yes, and very very very few. As I always say : microservices are not an architecture, they are an optimization.
> I can even add that we only do web software, but we do them exactly that way.
I can even add that not only do we do them exactly that way, but it's many times faster and more reliable than microservices, for reasons I have written about before[1].
The reality is that microservices add a whole host of failure modes, for just one benefit over monoliths: They are easier to scale horizontally. If you don't absolutely need horizontal scalability, and not many companies do, then you'd be foolish to pay the large cost.
> The reality is that microservices add a whole host of failure modes, for just one benefit over monoliths: They are easier to scale horizontally. If you don't absolutely need horizontal scalability, and not many companies do, then you'd be foolish to pay the large cost.
If you are writing and deploying standalone applications, I agree. Microservices do have another benefit, though: forcing the application to be modularized. There are better ways to do that, though, like having proper systems engineering lay out the application architecture.
If you are writing applications that need to be integrated with third-party applications or need to be configured with different functionality for different customers, microservices can still make sense. This is what has pushed my company in that direction. We currently have a set of monolithic applications with varying but overlapping functionality, and customers who want feature X from application Y and feature W from application Z, plus feature V that we are developing just for them. Our code has become a mess of curricular dependencies and duplicated code in order to meet these desires.
The microservice (maybe not micro, but definitely service) architecture we are moving to will allow us to compose applications with reusable building blocks more easily than trying to maintain different git branches and library versions. It also allows us to better manage the non-code resources we need to deploy as we have hundreds of gigs of data resources used by various libraries. Furthermore, we will be able to deploy applications with either our in-house GUI and command line tools, as well as provide the APIs necessary for our customers to integrate our applications into their own third-party frameworks.
> The microservice (maybe not micro, but definitely service) architecture we are moving to will allow us to compose applications with reusable building blocks more easily than trying to maintain different git branches and library versions.
Can you elaborate why? Presumably, with microservices, you're always running the latest version, whereas you're mentioning a need for "different branches and versions" in your comment.
Microservices don't force you to modularize, you can still make a mess by not cleanly separating things or by cutting across the wrong boundary. You modularized well because you created a clean, separated, thought-out architecture, not because of any intrinsic property of microservices.
> Can you elaborate why? Presumably, with microservices, you're always running the latest version, whereas you're mentioning a need for "different branches and versions" in your comment.
Not necessarily. Depends on the needs of the customer and what we deploy to them. In general, we try to deploy the most recent version of everything when we make a release for a particular customer.
The issue we have with our builds is dependency management. As a note below, that in itself is something that could be addressed by refactoring our projects[1]. Because of the way we need to deploy our software (shaded uberjars) even a well-structured dependency hierarchy would result in large data updates every time we had to update the monolithic application.
> Microservices don't force you to modularize, you can still make a mess by not cleanly separating things or by cutting across the wrong boundary. You modularized well because you created a clean, separated, thought-out architecture, not because of any intrinsic property of microservices.
They don't force you to modularize well. but they force you to think about how to break your application up. You still need the systems engineering to break it up well.
You're right that services aren't the only way or necessarily the best way to accomplish this. We could get the modularization just by refactoring the organization of out projects. In the absence of the requirements for third-party integration and an actual need for horizontal scalability, that is what I would have done. All-totaled, though, I think the service paradigm was the right way to go for us.
I need to note for context that the software we write and deliver needs to be delivered on physical disks (yes, we still literally ship software) and that deployment size is an issue. We also can't guarantee that we will have access to anything besides a Windows or Linux JVM, so our deployment needs to drag all of its supporting data along with it. being able to simply deploy a new version of a particular service makes updates much less painful.
[1] And actually using versions for our Maven artifacts, but that is a battle I lost a long time ago...
Thanks for the comments! +1 to "APIs necessary for our customers." I think every developer should have a customer-oriented mindset, even if their customers are just other developers in the same organization.
> I couldn't agree more. Martin Fowler warned us a long time ago : "The first rule of distributed objects : don't distribute them".
Funny that now the same person carries the flag with the symbol of microservices, which are seen as a way to "get rid of architects". That's exactly what Thoughtworks believes in - and you will understand more if you read the first chapters of the book "Building Microservices", or if you join their recent conferences. Just my 2 cents.
Not to take anything from Martin Fowler, but the "do not distribute (unless you absolutely have to)" rule originated at Sun much, much earlier. I have a hardcopy of the paper somewhere, it was a conclusion drawn from acknowledging the fallacies of distributed computing.
I can even add that we only do web software, but we do them exactly that way.
>If anything, it adds more complexity because now we need to do all kinds of data marshaling, error checking, monitoring, have more infrastructure for something that should have been done in shared memory/in-process to begin with.
I couldn't agree more. Martin Fowler warned us a long time ago : "The first rule of distributed objects : don't distribute them".
>There are a few exceptions where its useful to scale out parts of a distributed application
Yes, and very very very few. As I always say : microservices are not an architecture, they are an optimization.