5 ms·

Take away the word micro from micro services. Its just a buzzword. Now you have just services. You can have just one service that handles email, chat, payroll,

by z3t4 6y ago

Take away the word micro from micro services. Its just a buzzword. Now you have just services. You can have just one service that handles email, chat, payroll, website - or you can break them up into independent services. Ask yourself: Does it make sense to have two different services to handle x and y. Just don't break something up because of some buzzword mantra. Maybe the public website is the bottleneck in your monolith, then it might be a good idea to put it on its own server and scaling strategy so that it doesn't bog down the other parts of the system.

ismayilzadan 6y ago
Agreed. I was going to add my own separate comment but noticed yours. I think the main issue is, most companies nowadays end up creating "nano" services. A normal "service" should be built and then if functionality/team gets too big, then you break it down into another 2-3 smaller services. Again, service code already should have been written in a clean, modular code style so it can be broken down easily too without rearchitecting whole stack.
- ShellfishMeme 6y ago
  But is it really true that so many companies create too small services? I admit I haven’t seen too many architectures from the inside but from my experience the problem is usually the opposite: adding more and more things to a monolith that already has serious complexity and scalability issues because it’s the convenient place and is faster to develop. Most of the times I heard about the nano services problem was from articles warning of using services and encouraging monoliths instead.
  - ismayilzadan 6y ago
    It is true for companies that recently trying to adopt this "microservices" catchphrase. Just because it is a trend and somebody sold kubernetes/cf/some-other-cloud-solution to the company, they end up overusing it and creating a new microservice for something that could just be a separate package in already existing microservice. I am definitely not encouraging monolith architecture, they are horrible to work with, but I am also not suggesting 1500+ microservices for a company like Monzo (just considering their lack of functionalities compared to other new banks, 1500+ microservices sound like nanoservices instead to me)
eldelshell 6y ago
Yeah, something in between a monolith and microservices, and I'm going to name it: services architecture. Hmmm... I think I can do better: Service Oriented Architecture... Yeah I like this name. SOA. Are you telling me I just invented something that's 30 years old? Bollocks!
- Bnshsysjab 6y ago
  Can you articulate SOA without using buzzwords? I assume it’s concepts like a dedicated TLS terminator, Single Sign on, centralised logging, etc?
  - m463 6y ago
    programs communicating with remote programs. People will try to quibble that all this is new stuff, but really it is just new names for old ideas. https://en.wikipedia.org/wiki/Remote_procedure_call https://en.wikipedia.org/wiki/Remote_procedure_call
jayd16 6y ago
Yeah, I think this is an important point. Micro is supposed to imply that you should feel free (not obligated) to make small services. People ended up treating it like every library project should be separated by a network call.

by z3t4 6y ago

ismayilzadan 6y ago

Agreed. I was going to add my own separate comment but noticed yours. I think the main issue is, most companies nowadays end up creating "nano" services. A normal "service" should be built and then if functionality/team gets too big, then you break it down into another 2-3 smaller services. Again, service code already should have been written in a clean, modular code style so it can be broken down easily too without rearchitecting whole stack.

ShellfishMeme 6y ago
But is it really true that so many companies create too small services? I admit I haven’t seen too many architectures from the inside but from my experience the problem is usually the opposite: adding more and more things to a monolith that already has serious complexity and scalability issues because it’s the convenient place and is faster to develop. Most of the times I heard about the nano services problem was from articles warning of using services and encouraging monoliths instead.
- ismayilzadan 6y ago
  It is true for companies that recently trying to adopt this "microservices" catchphrase. Just because it is a trend and somebody sold kubernetes/cf/some-other-cloud-solution to the company, they end up overusing it and creating a new microservice for something that could just be a separate package in already existing microservice. I am definitely not encouraging monolith architecture, they are horrible to work with, but I am also not suggesting 1500+ microservices for a company like Monzo (just considering their lack of functionalities compared to other new banks, 1500+ microservices sound like nanoservices instead to me)

eldelshell 6y ago

Yeah, something in between a monolith and microservices, and I'm going to name it: services architecture. Hmmm... I think I can do better: Service Oriented Architecture... Yeah I like this name. SOA. Are you telling me I just invented something that's 30 years old? Bollocks!

Bnshsysjab 6y ago
Can you articulate SOA without using buzzwords? I assume it’s concepts like a dedicated TLS terminator, Single Sign on, centralised logging, etc?
- m463 6y ago
  programs communicating with remote programs. People will try to quibble that all this is new stuff, but really it is just new names for old ideas. https://en.wikipedia.org/wiki/Remote_procedure_call https://en.wikipedia.org/wiki/Remote_procedure_call

jayd16 6y ago

Yeah, I think this is an important point. Micro is supposed to imply that you should feel free (not obligated) to make small services. People ended up treating it like every library project should be separated by a network call.