1. 1
  1.  

  2. 3

    I never understand how people suggest microservices for improving the software architecture! To me it seems that the performance argument is all there is to microservices, and in all other aspects it’s a negative trade-off. And it’s a very negative trade-off especially for software architecture!

    You write a series of services that take in one value and output another, ideally this would be done with no outside influence, i.e. you pass in ‘x’ and you will always get ‘y’.

    But these are just pure functions, you don’t need to separate the callee from the caller with your operating system’s network stack and all the hardware and the wiring in order to achieve separation of concerns! Even if you want a multi-lingual architecture, you’re still better off just going through the C FFI. Think about it, if you’re willing to serialize your entire interface (which you must be, since you’re considering microservices), you can just define a generic C function that takes a buffer of bytes and returns another buffer of bytes, then you should be able to hide any function that works on, say, JSON values from any language behind this C function, and you won’t be any worse off (architecturally) compared to microservices. Your architecture is the same, but at least you don’t have to account for network failures down to the FINEST GRANULARITY LEVEL!

    1. 1

      “If we took our previous set of microservices and we were to consider the likes of Go for these microservices, we could cut down the memory footprint for one of these microservices from 1GB per instance of an to something like 64MB. This represents a massive saving and would allow us to achieve the same resiliency that we needed before in 756MB worth of RAM. Less than the total cost of 1 instance of our Java based microservice.”

      1. 4

        Why though? I have no love for Java, but it isn’t inherently memory inefficient. Sounds like they just suck at writing code.