5 ms·

The need for microservices has little to do with company size, they have to be the right tool for the job. People mistakenly use them for scalability, or to par

The need for microservices has little to do with company size, they have to be the right tool for the job. People mistakenly use them for scalability, or to partition work between teams. I'm in a small engineering org, and I split out a bunch of security critical code from an unsecure monolith and moved that into a microservice, running in a very tightly controlled and audited environment. A tiny part of my runtime needed different security from the rest of it, and a microservice was the easiest way to accomplish it. Now, I've traded a security problem for a latency problem, as everything that used to be handled internally is now an RPC - though this is an easy problem to solve.

bayonetz 8y ago
Ha! A close cousin to what I call "Resume Driven Development". Most engineers don't want to add to or maintain something someone else built prior. Since most people are working on and inheriting monoliths at small to midsize companies, the "micro services are what successes like Google do" era has been a real boon to RDD because you've got this great ready made justification for a rebuild. It would be a much harder sell to rebuild a better 2.0 of your monolith. In most cases, you don't need to do either for business value. But we pretend it is needed so that we can get a chance to do something blue sky for a change. I'm pretty conscious of when I'm RDDing but I've seen a lot of folks really delude themselves into thinking there is an urgent need to rebuild. It's very amusing watching RDD theater play out.
alrs 8y ago
Scalability is what microservices give you, at the expense of nearly everything else.
- edejong 8y ago
  Independant deployment Multiple languages A/B testing at deployment fir small services Less dependency to software specific stack Security compartmentalizations Strict programming by interface Failure isolation
  - remify 8y ago
    And the reason some developers don't understand micro-services is because they don't do any of those things. They just stick to MVC and their preferred language.
  - krainboltgreene 8y ago
    Independent deployment: Rarely needed. Multiple languages: No shared infrastructure. A/B testing at deployment for small services: Feature flags. Less dependency to software specific stack: More dependency to homegrown immature solutions. Security compartmentalizations: Isolated half-assed solutions with few people responsible. Strict programming by interface: Not unique to microservices, some people call this "static typing". Failure isolation: No shared infrastructure, blindsides, definitely not unique to microservices.
    - edejong 8y ago
      Independent deployment: having deployed hundreds of microservices, I can tell you it is a godsend. Quickly iterating on a specific microservice without running risk of down-time is useful right from the start. We would sometimes deploy the same microservice multiple times a day to improve performance or fix a critical bug. Apart from scaling, this is my number one reason to stay with microservices. Multiple languages: the shared infra in this case is your Kubernetes yaml files and Docker build files, both of which can be shared easily. The rest is either RESTful or Kafka consume/produce. Python/R/Scala/Java/C#/Haskell/OCaml can all interface with that. Feature flags are a possible solution. I worked with them in the past and, applied correctly, they can offer a similar experience. However, one often needs more than just a boolean filter: you need to have the logic in your application to route the requests to, say, two different implementations of the same interface. Do this on the micro-service scale, and you get a nice SoC at the proxy level. It moves A/B testing to be part of the infra, not the application logic. More dependency to homegrown immature solutions: care to elaborate? Isolated half-assed solutions with few people responsible: care to elaborate? My little micro-service component needs the bare minimum of access, which I can precisely provide to it. No memory is shared, no storage is shared... Often it is much easier to prove that the system stays within confidentiality and availability limits. Networking allows me to transparently monitor all data flowing through my services. Strict programming by interface vs. static typing. Oh yes, I totally agree with static typing! Such a big advantage over dynamic typing, read my other comments on HN. However, there is no static typing across versions of your same software. Forward compatibility is hard to achieve when all components need to be upgraded at the same time. I still dread the days when we would upgrade 'a major version' and all kinds of database tables had to be changed, causing chicken-and-eggs problems. Not saying that this problem is completely eliminated with a micro-service architecture, but it forces developers to think what can be reasonable isolated, causing a higher SoC. It also prevents the humongous unmaintainable 300+ tables large RDBMSs, which are often the primary cause of stagnated development. Failure isolation: I don't understand your reasoning, sorry.
plasma 8y ago
I think JWT are supposed to help here, allowing other services to self validate signed credentials instead of always reaching out to the external service.
detaro 8y ago
There's quite a difference between splitting out a few components for a specific purpose, and going full-on "microservice architecture" IMHO

bayonetz 8y ago

Ha! A close cousin to what I call "Resume Driven Development". Most engineers don't want to add to or maintain something someone else built prior. Since most people are working on and inheriting monoliths at small to midsize companies, the "micro services are what successes like Google do" era has been a real boon to RDD because you've got this great ready made justification for a rebuild. It would be a much harder sell to rebuild a better 2.0 of your monolith. In most cases, you don't need to do either for business value. But we pretend it is needed so that we can get a chance to do something blue sky for a change. I'm pretty conscious of when I'm RDDing but I've seen a lot of folks really delude themselves into thinking there is an urgent need to rebuild. It's very amusing watching RDD theater play out.

alrs 8y ago

Scalability is what microservices give you, at the expense of nearly everything else.

edejong 8y ago
Independant deployment Multiple languages A/B testing at deployment fir small services Less dependency to software specific stack Security compartmentalizations Strict programming by interface Failure isolation
- remify 8y ago
  And the reason some developers don't understand micro-services is because they don't do any of those things. They just stick to MVC and their preferred language.
- krainboltgreene 8y ago
  Independent deployment: Rarely needed. Multiple languages: No shared infrastructure. A/B testing at deployment for small services: Feature flags. Less dependency to software specific stack: More dependency to homegrown immature solutions. Security compartmentalizations: Isolated half-assed solutions with few people responsible. Strict programming by interface: Not unique to microservices, some people call this "static typing". Failure isolation: No shared infrastructure, blindsides, definitely not unique to microservices.
  - edejong 8y ago
    Independent deployment: having deployed hundreds of microservices, I can tell you it is a godsend. Quickly iterating on a specific microservice without running risk of down-time is useful right from the start. We would sometimes deploy the same microservice multiple times a day to improve performance or fix a critical bug. Apart from scaling, this is my number one reason to stay with microservices. Multiple languages: the shared infra in this case is your Kubernetes yaml files and Docker build files, both of which can be shared easily. The rest is either RESTful or Kafka consume/produce. Python/R/Scala/Java/C#/Haskell/OCaml can all interface with that. Feature flags are a possible solution. I worked with them in the past and, applied correctly, they can offer a similar experience. However, one often needs more than just a boolean filter: you need to have the logic in your application to route the requests to, say, two different implementations of the same interface. Do this on the micro-service scale, and you get a nice SoC at the proxy level. It moves A/B testing to be part of the infra, not the application logic. More dependency to homegrown immature solutions: care to elaborate? Isolated half-assed solutions with few people responsible: care to elaborate? My little micro-service component needs the bare minimum of access, which I can precisely provide to it. No memory is shared, no storage is shared... Often it is much easier to prove that the system stays within confidentiality and availability limits. Networking allows me to transparently monitor all data flowing through my services. Strict programming by interface vs. static typing. Oh yes, I totally agree with static typing! Such a big advantage over dynamic typing, read my other comments on HN. However, there is no static typing across versions of your same software. Forward compatibility is hard to achieve when all components need to be upgraded at the same time. I still dread the days when we would upgrade 'a major version' and all kinds of database tables had to be changed, causing chicken-and-eggs problems. Not saying that this problem is completely eliminated with a micro-service architecture, but it forces developers to think what can be reasonable isolated, causing a higher SoC. It also prevents the humongous unmaintainable 300+ tables large RDBMSs, which are often the primary cause of stagnated development. Failure isolation: I don't understand your reasoning, sorry.

plasma 8y ago

I think JWT are supposed to help here, allowing other services to self validate signed credentials instead of always reaching out to the external service.

detaro 8y ago

There's quite a difference between splitting out a few components for a specific purpose, and going full-on "microservice architecture" IMHO