And then when they need help fixing the mess they can call in a consultant wielding Fowlers latest book, or go to a bunch of new monolithichitecture conferences where people put up slides full of memes mocking microservices.
Truly we are blessed to live in an era of such efficient job creation.
Personally, I would start sooner than that. I think new technologies make service creation easier. But the right moment for me depends a lot on product, team, and tech.
So I guess I would say that any place not working like that might not be ready for a microservices approach.
I think Containers are somewhat pushing Microservices a bit too early for some organizations because of Docker's focus on single entry point (sans supervisor, etc). They are useful for other reasons, but containers solve people problems, containers solve technical deployment problems.
You don't want N kinds of things if you can have 2 kinds of things (say, web tier, job workers for long running stuff, db layer), until you start having problems working out of the same codebases/repos/etc.
Microservices make things harder to debug and most likely there is still coordination that needs to happen, and it's likely going to be less efficient versus developing libraries -- so if you're a small company, you can probably ignore these for a while.
If yes, please, create a library.
Microservices share data, if you'll need part of the data in other projects, yes, they are the way to go. If you just need behavior, or need to decentralize CPU usage, there are plenty of easier ways to achieve those.
Assuming you want to force everyone to use the same technology stack. And redeploy every application every time the internals of the library change.
That may well be OK for what you are doing. Or not.
Also, a library does not force people into the same technology stack. It makes it easier to work with the same programing language, but it's still possible to not do so. Microservices also often have complex data structures that only work well when created and parsed by the same set of tools. There is some difference, but much less than you are claiming.
We've also all met that developer that decided that Foo (library, framework, pattern, language - pick your poison) is SO MUCH BETTER than Bar (which is what you use now), and frantically sets out to replace all things Bar with Foo (and gives up halfway, so now you've got the maintain both Foo and Bar bit of your code, all intertwined).
The problem isn't with Foo and it's merits, it's actually very useful, the problem is that that developer is, frankly, shit.
Microservices is a perfectly useful pattern to achieve a number of ends, but it's not the answer to all questions. Know what you're trying to achieve, evaluate options on their actual merits (not what's buzzwordy this month) and make decisions consciously.
EDIT to add:
> can I see parts of this project being used in another project?
That's not the only benefit from microservices. Smaller units are easier to reason about (and test!), and they allow you to experiment: A monolithical app needs to maintain some sort of consistency. Most of the time it will be written in the same language, using the same general patterns and libraries supporting these patterns (eg. dependency injection using Guice or Spring). Most of the time, none of this will be cutting edge, some of the time it will be decidedly out of date, but changing it is hard and risky, and, well, it works.
With microservices your can use the languages, patterns and libraries that suit your isolated use case best. Need to support complex web forms? You might want to run Node.js so you can use the same JS code for validation on the front end and back end. Need lots of boring CRUD in your admin app? Ruby on Rails is your friend. Number-crunching? You might want to use Clojure or F#. Interfacing with some proprietary system (e.g. Sharepoint)? Use the best supported library you can find (.NET webservices client), and build a service up around that, on the platform that best supports that library (ASP.NET on IIS on Windows).
First, you need to issue pull requests for multiple projects and keep mental track of the status of those pull requests.
Second, [in a large organization] you might find out that changing the microservice on the server side breaks some client down the road because of new/unexpected parameters introduced, and the client handling it poorly.
Third, if the services [in a large organization] are distributed across multiple teams, you need to work around their schedules and their deploy calendars to orchestrate those changes.
And if you're having a tough time deploying changes, it sounds like you're not practicing continuous delivery, which as Fowler said is a prerequisite.
Patient: "Doctor, when I bend my arm backward, it hurts!"
Doctor: "Stop doing that."
- don't issue pull requests for multiple projects
- don't keep mental track of the status of those pull requests.
- don't worry about breaking clients
- don't worry about the logistical/scheduling issues of multiple teams
?
That said, I heard a dev want to break up a low traffic app that had to take in a message, encrypt it, then put it on a queue want to break that into microservices. My first reaction is "what the fuck?". My second reaction is that an encryption service might not be a terrible idea, though I doubt ensuring folks don't roll broken encryption is why the dev proposed it.
No, it's not appropriate for your blog. But it IS appropriate for many applications out there and it's an incredibly beneficial way to scale a set of services and build a complex application in a cost effective manner.
I don't quite agree with the notion of being "stuck maintaining five apps, five APIs, etc." because it's not. It's really one app. You're doing something wrong if you feel that you have five different apps and APIs. In fact, your testing and debugging should become easier under such an architecture. Maintenance should be much better if done properly. Of course regardless of your software architecture, you can end up in "maintenance hell" so that's really an invalid argument against SoA. I certainly wouldn't let the fear of bad programming prevent me from using a specific design pattern or architecture.
There's also the question about project complexity.. does the marketing website really need to be part of the application's project?
It's a matter of separating things out where it makes the most sense.
To reduce complexity and centralize common functionalities API Gateways such as KONG (https://github.com/mashape/kong) are the base of microservice architectures.
I think the idea is to use microservices when they will be owned by separate teams. If your application is small enough that a single team can meaningfully work on it, then you probably don't need to break it up.
If it worked "perfectly fine", and the team is productive, then they should have spent their time on more important things :).
Experienced engineers know that technology that has stood the test of time is boring. But we are not in the business of designing "fun" ways of working constantly, we are here to ship software on schedule and produce something that is easily understood and maintanable by next generation of engineers, instead of getting bamboozled by a new buzzwords invented by empty suits (agile, tdd, xp, microservice, mvc up your browshizzle), regardless, if not an engineer, than some "manager" who can't code reads some article on HN, and decides that's the way to do it.