Or microservices are strongly indicated if you are in a SaaS industry as we are (HR software), where individual customers want choice over the components making up their own stack.
Yes, if the customer was happy to buy everything from a single vendor that would work perfectly fine. But as per sibling comments, that's not the way that the enterprise HR software market works. There are many, many very specialised vendors that do just one thing.
This is perhaps off-topic but why would you let your SaaS customers dictate the composition of the stack? This seems to obviate one of the major benefits for customers, namely that they don't sweat the details.
It depends on your market. If you are "SaaS for the masses" (i.e. you've got 50,000+ customers) then you're right - any customization is limited to "pick a color from our predefined palette". But if your customers are Fortune 500 -- they can and will demand special consideration.
The nature of software for managing humans is that it's very fuzzy, fashion/tend driven, diverse.
E.g a recent trend is for companies to try and reduce the number of undesirable applicants they get for jobs (since in a big e.g retailer, saying no to a candidate is likely also saying no to a customer).
So customer now needs to inject an e.g culture fit quiz into the candidate experience, which only unlocks the apply button once the candidate has "passed".
This kind of tweaking and evolvement is not possible within a monolith, so good APIs allowing vendors of the customer's choice to inject functionality are essential.
That functionality can then be injected in the form of a small app that does one thing and does it well, has it's own database, i.e has many of the characteristics of what people think of as microservices.
I don't think it's helpful to conflate "microservices" with "dynamically-loaded code". Many, many programs have a plugin system that can completely alter their behavior while having all the characteristics of a monolith - single process, function calls rather than a message bus, central control of flow rather than decentralized, etc.
Well, this can be a fruitless discussion without a shared understanding of what a microservice is.
To Martin Fowler:
> In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
Assembling HR ecosystems from separate apps certainly meets all of the points above.
Ah, this is more what I might call 'macroservices' - API-centric full applications which can be used standalone with their own client interfaces or API-assembled into bigger solutions. I think this should be the default architectural approach and was what Yegge wrote about Bezos mandating at Amazon.
From what I'm seeing, the microservices style is commonly being used for much smaller services a la Unix, typically for reuse across an org. Introduces too many issues around SPOF, orchestration and queuing, versioning, discoverability. I think Lambda is the correct evolution for making that work (if nothing else let AWS figure out stuff like failover, deployment, and the standards for fabric between functions).
You talk as if the customer already has the quiz content in their mind, and just needs a few web pages to present it.
That's not the way the industry works.
Some exciting, specialised startup develops some kind of cool UI blended with some psych validated content, and manages to get it installed at a couple of large reference clients, and then finally manages to draw a link between the quiz results that candidates achieve, and their ultimate chances of successful employment (maybe just getting hired - maybe their on the job performance after X months).
The customer is buying into this package of leading edge stuff. They don't want their existing vendor to have some junior developer hack something up and put it behind a feature flag. They want the new shiny stuff, and they want it from the new shiny vendor.
We did that without microservices, just dynamically-loaded modules on a monolith base. A custom configuration for each client selected which modules to load at runtime.
Typically in the enterprise HR software space, the customer does not want to buy all their components from a single vendor. If they want a culture fit quiz, they do not go to their ATS (applicant tracking system) vendor for it. They go to an organization that has specific skills in this particular area, and has onboard psychologist(s) who can demonstrate the validity of said quiz.
The code behind such a quiz is usually trivial - the intellectual property not so much.
