Whether decoupling into microservices or making them part of a monolith is a good idea or not, to me, had a lot more to do with the teams and company organization behind these services than the product itself.
So I'd say without knowing how big, and how many teams are dealing with this we cannot say one approach is better than the other.
I've been in companies where several hundreds of engineers where working on a "core" monolith and it was a real pain, almost impossible to track where problems where coming from, some times deploys blocked for weeks due to some team having problems with their tests or just spending months to agree how to do something.
I've also been at companies where being about 10 devs the "architect" went totally crazy into microservices, microfraneworks, cqrs, event sourcing, etc etc... And it was a total mess where each developer had to deal with 10 services and keep it's dependencies up to date and coordinate deploys of 3 things at the same time and nobody knew where and why things were failing.
So, as always, right tool for the job.
What I've seen works the best, is to adapt the services you run to the teams structure you have.
Because there is a bunch of shared code behavior and data between the services and his idea was "just copy and paste". We devised a library that gets shared as a dependency, but managing that dependency is PITA and not everything can go into the shared library still. Which means we still copy/paste some code, which is okay with this bozo somehow. I can stomach splitting things into microservices that don't actually talk to each other, though I don't see the need day one, but why not run it as a monorepo and split it out in the CD pipeline so I don't have to open four PRs for one fucking task?
Because the goof couldn't figure it out and just gave up and said here you go. This is before I knew the guy was completely useless. I had to do a whole presentation and get the favor of every single developer just for him to succumb to FACTS about moving to a monorepo that then splits the code out to his beloved CV fuel on build. Trust me, there is a lot more wrong here if you are getting any of this. As for team size we are small. Six warm bodies, three actually moving.
Personally I say go monolith (for most small/medium projects) but design it with an eye towards splitting it into services down the line, that is unless something is smacking you in the face to go all in on micro. For monolithic that means a logical separation today, that can easily be split out in a single sprint tomorrow. That means less pain and more features today and a path towards some dudes wet dream in the future.
> I mean, that sounds pretty good. If you can do that why couple them?
Because what is the point in separating each one into their own deployed service and having to deal with network issues when they could just be services inside a monolith?
OP just said they don't talk at all. They sound completely decoupled already. You could put them in the same app and share routes if you want and just separate by package or compilation unit if you really want to. The hard part is already done though.
They could be managed and deployed by completely different teams with no overhead now. It really depends what we're tuning for.
Scaling is another factor that comes to mind, also resilience.
If one part in the monolith goes haywire so will the entire application. If you can decouple and split the software into 4 applications with their own concerns, at least you have 3 applications left running (assuming they are decoupled).
If app 1 wants 5000% more CPU than app 2, maybe you can have different instance types running and save costs/resources.
Read my reply further up, they have a lot in common. We had to build a shared library that goes in as a dependency and even with that we have to still copy/paste code between services. Because a data structure change in one must often be reflected in another HELLO multiple PRs for one task.
Developing with docker is not necessary a micro service, it's just a way of packaging, distributing and deploying your application in a clean way. And docker is not a virtual machine, there's not much overhead, you don't need kubernetes if it's just a simple app, but you can just take advantage of managed service like ECS, you get auto scaling right away, and you don't have manage your node and deal with the stupid thing like systemD
Every time I see someone say something like this, or better yet use the word "magic", what I hear is that they don't understand how or why their system does the things it does. Nothing is free; nothing is magic; nothing "just works". You understand it or you don't, and nothing has contributed more to the plague of developers thinking they understand it when they don't than cloud-based containers (and the absurd associated costs!).
> Every time I see someone say something like this, or better yet use the word "magic", what I hear is that they don't understand how or why their system does the things it does.
There is nothing magic about configuring a deployment to autoscale. You set resource limits, you configure your deployment to scale up if an upper limit is reached and you didn't maxed out, and you configure your deployment to scale down if a lower limit is reached and you didn't min out. What do you find hard to understand?
> Nothing is free; nothing is magic; nothing "just works". You understand it or you don't,
You're the only one claiming it's magic.
The rest of the world doesn't seem to have a problem after having read a couple of pages into the tutorial on how to configure autoscale on whatever service/cloud provider.
> and nothing has contributed more to the plague of developers thinking they understand it when they don't than cloud-based containers (and the absurd associated costs!).
You're the only one posting a baseless assertion that other developers somehow don't understand autoscaling, as if everyone around you struggles with it.
Having separate services does add additional overhead and maintenance, but it does provide the benefit of 1) Reducing the blast radius if issues occur, allowing for a degraded service instead of being totally down, and 2) Better scaling/ optimizations. For example, one service could need to support more TPS, or need more memory, CPU, etc.
if they don't talk to each other, then you can run multiple instances of them without paying the price of intercommunications latency. It's a dream for scaling. In this example their teamlead is right.
Looks good to who? When i see all this kind of froth on a CV, that's a red flag to me, or at best, effectively empty space, where another candidate might be telling me about experience and skills that are actually valuable.
Devops is a practice not a role. Essentially it’s bringing good software engineering practice to operations and eliminating the silos. In practice, though, this does usually mean programmers fannying around with docker.
Some organisations just rebranded the ops team to the devops team, but that’s kinda missing the point.
I'm actually perplexed why the people in our ops team have the title DevOps Engineer, when they don't do any dev work, just handle all aws related stuff.
I asked one of them this question, but couldn't get any answer that satisfied my curiousity.
EDIT: For what it's worth I don't view myself as a software developer or operations or systems administrator or frontend or backend or fullstack. I like to think of myself as a Problem Solver. It just so happens that I'm currently paid to solve software engineering problems.
I want to know everything from Dockerfiles to bash scripting to assembly to functional programming to DDD, etc.
I have asked this question myself, and after failing to get an appropriate answer, I started using "DevOps Administrator" instead of "Engineer" in my email signature. It feels more appropriate since I definitely do not write production code.
In my experience, developers then still have to implement a lot of behaviour to deal with docker's limitations around networking. (in my case it was trying to connect multiple BEAMs in a docker network)
>seperate mini applications that don't talk to eachother at all, essentially 4 web services.
I mean, that sounds pretty good. If you can do that why couple them? "Microservices" is just SOA without any debate over how small a service can be.