4 ms·

Wait until they realized microservices can be deployed independently and have strict APIs without people using classes they shouldn't or creating spaghetti code

Wait until they realized microservices can be deployed independently and have strict APIs without people using classes they shouldn't or creating spaghetti code because they have 800k LOC.

msbarnett 10y ago
> without people using classes they shouldn't or creating spaghetti code because they have 800k LOC. Honestly, if you can't trust your devs not to make a mess in a monolith, you can't trust them not to make a distributed mess with microservices. Both architectural patterns have their uses. Neither will save you from bad developers.
- heartsucker 10y ago
  I think monoliths lend themselves to hacks more often than microservices do. It's too easy to just import something you shouldn't, where as breaking the rest API is a lot harder. You can't just do a bad database access because there's usually a network firewall that will keep you from doing your tomfoolery on the DB. I also could be wrong about this, but I like the microservice after projects reach a certain size.
  - eropple 10y ago
    "Microservices" often lead to the degenerate fragmentary case (look at people bragging about how many microservices they have--that's a weird mindset to have). I am a big fan of a well-designed SOA, but that's not properly bloggable here in 2016.
  - sievebrain 10y ago
    That's what module systems and access modifiers are for. Now, OK, the JVM ecosystem lacks a good module system at the moment. But Java 9 will fix that. There is also OSGi though I don't know much about it.
  - takeda 10y ago
    The problem with API is that is not an easy to create a good one. It's so easy to do it wrong, and once you do, it's very hard to change it later. API should be created pretty much by a committee where everyone from the company can have an input how it will affect them. It's not a panacea, it looks like you're just pushing the complexity into another place.
    - heartsucker 10y ago
      At least with an API, people seem to care more about consensus and seem to agree that it should be planned out. "Just make it work" seems to happen to the guts. And no, not panacea, just a way of thinking that I think is useful.
  - jacques_chester 10y ago
    I refer to this as "design backpressure". In a microservice world you need to consciously decide to cross the network boundary. With a single memory space it's easy to simply go around whatever architecture you "should" be following. Microservices don't solve balls of mud, but they can make it harder to form and easier to spot forming.
aleyan 10y ago
Wait until they realized that solving their spaghetti problem with microservices resulted in them operating an Italian restaurant. Pushing complexity onto interprocess/machine communication will just result in higher levels of spaghetti. Do you really think that same people who would construct a monolith poorly would do a better job building a distributed system instead? I don't mean to be too dogmatic; there are legit use cases for services. I am just highly skeptical of microservices as a solution for complexity.
- heartsucker 10y ago
  I'm not dogmatic about either. 1000 microservices sounds... excessive. I was countering the point that optimizing for speed might lead to less maintainable infrastructure.
lmm 10y ago
You don't need microservices for that. This is Java, we have working dependency management and multi-module projects via maven, and the system can actually enforce things like separation of interface and implementation.

Wait until they realized microservices can be deployed independently and have strict APIs without people using classes they shouldn't or creating spaghetti code because they have 800k LOC.

msbarnett 10y ago

> without people using classes they shouldn't or creating spaghetti code because they have 800k LOC. Honestly, if you can't trust your devs not to make a mess in a monolith, you can't trust them not to make a distributed mess with microservices. Both architectural patterns have their uses. Neither will save you from bad developers.

heartsucker 10y ago
I think monoliths lend themselves to hacks more often than microservices do. It's too easy to just import something you shouldn't, where as breaking the rest API is a lot harder. You can't just do a bad database access because there's usually a network firewall that will keep you from doing your tomfoolery on the DB. I also could be wrong about this, but I like the microservice after projects reach a certain size.
- eropple 10y ago
  "Microservices" often lead to the degenerate fragmentary case (look at people bragging about how many microservices they have--that's a weird mindset to have). I am a big fan of a well-designed SOA, but that's not properly bloggable here in 2016.
- sievebrain 10y ago
  That's what module systems and access modifiers are for. Now, OK, the JVM ecosystem lacks a good module system at the moment. But Java 9 will fix that. There is also OSGi though I don't know much about it.
- takeda 10y ago
  The problem with API is that is not an easy to create a good one. It's so easy to do it wrong, and once you do, it's very hard to change it later. API should be created pretty much by a committee where everyone from the company can have an input how it will affect them. It's not a panacea, it looks like you're just pushing the complexity into another place.
  - heartsucker 10y ago
    At least with an API, people seem to care more about consensus and seem to agree that it should be planned out. "Just make it work" seems to happen to the guts. And no, not panacea, just a way of thinking that I think is useful.
- jacques_chester 10y ago
  I refer to this as "design backpressure". In a microservice world you need to consciously decide to cross the network boundary. With a single memory space it's easy to simply go around whatever architecture you "should" be following. Microservices don't solve balls of mud, but they can make it harder to form and easier to spot forming.

aleyan 10y ago

Wait until they realized that solving their spaghetti problem with microservices resulted in them operating an Italian restaurant. Pushing complexity onto interprocess/machine communication will just result in higher levels of spaghetti. Do you really think that same people who would construct a monolith poorly would do a better job building a distributed system instead? I don't mean to be too dogmatic; there are legit use cases for services. I am just highly skeptical of microservices as a solution for complexity.

heartsucker 10y ago
I'm not dogmatic about either. 1000 microservices sounds... excessive. I was countering the point that optimizing for speed might lead to less maintainable infrastructure.

lmm 10y ago

You don't need microservices for that. This is Java, we have working dependency management and multi-module projects via maven, and the system can actually enforce things like separation of interface and implementation.