4 ms·

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 AP

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.

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.