Hacker News Reader

Comment by bradleybuda | Hacker News Reader

> We have over 1,000 microservices constantly being built and deployed.

Wait until they find out how much faster in-process function calls are than RPCs.

Nobody said that calls between microservices have to be done via RPCs.

I use a framework at Google that is microservice-based, and allows for composition of microservices into an assembly. Within an assembly, calls between services are done in-process; if you are calling a service in a different assembly, it has to make an RPC.

The mechanics of whether it's a local call or an RPC are all handled at the framework leve. This makes splitting a service into its own assembly a simple task (don't have to update any code, just configuration; this can be managed by SREs).

>I use a framework at Google that is microservice-based, and allows for composition of microservices into an assembly. Within an assembly, calls between services are done in-process; if you are calling a service in a different assembly, it has to make an RPC.

Sounds a lot like OTP.

In Java-land, you could also just have your client and service use the same interface. Just inject different implementations for local and remote.

Right, then you can have some supporting code automatically handle the remoting.

Once you've gone to the trouble of automatically generating the glue between the local interface and the remote object, it becomes simple to interpose further useful things - security checks, transactions if you're using a relational database, and so on. You can even have the glue code lazily instantiate the service components, so you don't need to actually load them until a client makes a call.

You'd want a cool name for it, though. Extreme Java Binding? Enhanced Jet Bus? Excellent Joy Bringer?

Or just IDL/Thrift/Protobuffers?

How about EJB?

Yes, that is the joke.

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.

> 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.

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.

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.

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.

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.

"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.

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.

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.

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.

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 find out how much faster in-process function calls are than RPCs.

2017 will be the year of the return of the monolith: "How We Replaced 946 Microservices With a Statically Linked 10kB Rust Binary and How It Ulimately Did Not Save Us From Our Complete Lack of Anything Resembling a Coherent Business Model".

Faster hardware is usually cheaper than hiring more developers.

That changes very quickly if you create distributed systems that tend to either have underdimensioned external IO (networks) and/or be excessively expensive. It's not unusual for systems to balloon up to several times the original size the moment you have to cross the boundary to communicating over the network. Even if it's a LAN.

>Faster hardware is usually cheaper than hiring more developers.

Now that Moore's law is running out of steam, we can reasonably expect that to become false within the next decade or so. The division between those who can merely write code and those who can properly engineer software systems will become all too apparent then.

Reply on news.ycombinator.com