6 ms·

Developments around Microservices, API Gateways, Kubernetes and Service Mesh

91 points by sickeythecat 8y ago

hmexx 8y ago
I’ve never read an article with as many words (brands / technologies) that I have not heard of.. I must be losing touch with tech!
- ui-explorer12 8y ago
  Or maybe you've just decided that it's both pointless and impossible stay on top of every latest project, even if you live in a particular ecosystem. Hold true to the course of solid fundamentals and learn what you need, when you need it; not a moment sooner!
- jbigelow76 8y ago
  Javascript Community: "Angular, React, Vue, TS, webpack, PWAs, yarn, NPM... nobody can keep up with all this change!" DevOps Community: "Hold my beer."
  - barbecue_sauce 8y ago
    DevOps, SecOps, DevSecOps, DataOps, GitOps...
ivan_ah 8y ago
In case you're wondering what a service mesh is, this seems to be one explainer: https://istio.io/docs/concepts/what-is-istio/ https://istio.io/docs/concepts/what-is-istio/ Things that this seems to do are application level end-to-end authorization / authentication, load balancing, monitoring, etc. Not sure if it does service discovery or you'll still need something else for that.
- labrabbit 8y ago
  Full disclosure: I work for Glasnostic. Service mesh encapsulates the complexities of distributed service-to-service communication so you don't have to deal with them. There are a few options (not just Istio) and all approach the problem in a different way. I have written about this here: https://glasnostic.com/blog/what-is-a-service-mesh-istio-linkerd-envoy-consul https://glasnostic.com/blog/what-is-a-service-mesh-istio-lin... and here: https://glasnostic.com/blog/should-i-use-a-service-mesh https://glasnostic.com/blog/should-i-use-a-service-mesh
  - mycall 8y ago
    Great articles, thanks. I'm curious if, say in an IT environment, where both custom services and third-party services live, either on-prem or cloud, is it common to have both Organic architectures and microservice-based applications operating and working side-by-side? If so, what are good concepts to make this work with least effort? btw: the font on https://glasnostic.com https://glasnostic.com is thin and hard to read :)
    - labrabbit 8y ago
      We'll fix that font, thanks! In most cases, organic architecture would include microservice-based applications. At a very high level, organic architecture is a style that IT adopts when the multitude of business needs make the organization itself "organic". An outward sign of this transformation is the emergence of parallel teams and independent release cycles. When this happens, applications take on the role of digital capabilities that can be recombined to support new products and services and the difference between an "application" and a "service" fades away. So, in the IT environment you describe, microservice-based applications would be part of the organic architecture. The key issue in composing capabilities in such a way is the emergence of complex behaviors. For instance, composed fan-out patterns tend to be non-linear, large-scale and highly dynamic. To fully realize the potential of organic architecture, you'll need a way to control these behaviors. This is what we do.
  - wereHamster 8y ago
    What advantages does Istio give you over orchestrating the services using k8s "Service" resources? To me it seems that k8s already provides mechanisms to proxy requests to the correct backends (pods). Why would I use Istio?
potrei 8y ago
Apart from the specific technology used, it's important to change the way applications are designed and implemented. I saw many projects in trouble because they merely split a monolithic application into small pieces, without applying a new model of design and thinking. If you approach micro-services development without changing your mind first, you will fail.
- rasteau 8y ago
  Amen! My last three companies were moving from a monolith to microservices. In every case, the rationale for the move was little more than "monolith development is slow, therefore microservices". Unfortunately for all of them, the true reasons for the slow development was poor separation of concerns, insufficient and brittle tests, and years of accumulated hacky shortcuts to ship new features "faster". The folks pushing the microservice panacea were "proven right" in that development was much faster... initially. Without years of cruft in their way, devs were able to churn out new stuff (after a significant time spent ramping up on infrastructure code). Eventually, and in every case, the fundamental flaws resurfaced, this time increasing in severity now that changing the system often required multiple service changes. As well, a host of new kinds of problems emerged: distributed transactions, network failures, client/server versioning, debugging across services, etc. I'm now a microservice skeptic. Whatever your solution, it should be at the same "level" as the problem. A massive change in technical architecture will not solve the accumulated cost of your poor engineering quality choices.
  - potrei 8y ago
    Yes, I agree. That's why I said that it's necessary to change the way application are designed. And, of course, there's no silver bullet. Sometimes micro-services architecture is not the way to go.
pritambarhate 8y ago
It will be amazing if someone knowledgeable here can share their experience with Linked 2.0, Istio and Envoy.
- boudin 8y ago
  Envoy, if I'm not mistaken, is a sidecar proxy that is used by Istio. The equivalent for Linkerd 2 is Conduit (that was its own app before and now is entirely part of Linkerd 2). From what I've seen, Linkerd 2 doesn't feature as much features as Istio or Linkerd 1 for now (no circuit breaker for example). From the few issues I've seen on Github, it seems a bit immature to be used in a production environment. Between the fact that I've just started looking into that last month and that it changes at a rate that is really hard to follow, I'm might be wrong...
snupples 8y ago
I feel that service mesh integration in k8s is still very immature. Be aware that running any sidecar model service mesh requires setting elevated permissions on the entire pod. Your pod security policy will need to allow NET_ADMIN at the very least, since service meshes mostly operate by manipulating iptables rules in the pod. Often there are other elevated permissions required. Usually this means people are setting elevated permissions globally on the default svc account, which is scary.
germainelong 8y ago
Sadly Kubernetes is still vendor locked in - although you have a selection of them. Average Joe cannot install Kubernetes on their pool of commodity dedicated servers or VPS servers because there is no ingress that works with already assigned IP addresses. If you buy a dedicated server you get a block if IPs and there is no way to assign them to ingress. If such thing was developed, people could ditch expensive cloud providers in favour of order of magnitude cheaper dedicated servers.
- ccmcarey 8y ago
  What? This makes no sense. You absolutely can bootstrap your own cluster of servers running K8s.

91 points by sickeythecat 8y ago

I’ve never read an article with as many words (brands / technologies) that I have not heard of.. I must be losing touch with tech!

ui-explorer12 8y ago
Or maybe you've just decided that it's both pointless and impossible stay on top of every latest project, even if you live in a particular ecosystem. Hold true to the course of solid fundamentals and learn what you need, when you need it; not a moment sooner!
jbigelow76 8y ago
Javascript Community: "Angular, React, Vue, TS, webpack, PWAs, yarn, NPM... nobody can keep up with all this change!" DevOps Community: "Hold my beer."
- barbecue_sauce 8y ago
  DevOps, SecOps, DevSecOps, DataOps, GitOps...

ivan_ah 8y ago

In case you're wondering what a service mesh is, this seems to be one explainer: https://istio.io/docs/concepts/what-is-istio/ https://istio.io/docs/concepts/what-is-istio/ Things that this seems to do are application level end-to-end authorization / authentication, load balancing, monitoring, etc. Not sure if it does service discovery or you'll still need something else for that.

labrabbit 8y ago
Full disclosure: I work for Glasnostic. Service mesh encapsulates the complexities of distributed service-to-service communication so you don't have to deal with them. There are a few options (not just Istio) and all approach the problem in a different way. I have written about this here: https://glasnostic.com/blog/what-is-a-service-mesh-istio-linkerd-envoy-consul https://glasnostic.com/blog/what-is-a-service-mesh-istio-lin... and here: https://glasnostic.com/blog/should-i-use-a-service-mesh https://glasnostic.com/blog/should-i-use-a-service-mesh
- mycall 8y ago
  Great articles, thanks. I'm curious if, say in an IT environment, where both custom services and third-party services live, either on-prem or cloud, is it common to have both Organic architectures and microservice-based applications operating and working side-by-side? If so, what are good concepts to make this work with least effort? btw: the font on https://glasnostic.com https://glasnostic.com is thin and hard to read :)
  - labrabbit 8y ago
    We'll fix that font, thanks! In most cases, organic architecture would include microservice-based applications. At a very high level, organic architecture is a style that IT adopts when the multitude of business needs make the organization itself "organic". An outward sign of this transformation is the emergence of parallel teams and independent release cycles. When this happens, applications take on the role of digital capabilities that can be recombined to support new products and services and the difference between an "application" and a "service" fades away. So, in the IT environment you describe, microservice-based applications would be part of the organic architecture. The key issue in composing capabilities in such a way is the emergence of complex behaviors. For instance, composed fan-out patterns tend to be non-linear, large-scale and highly dynamic. To fully realize the potential of organic architecture, you'll need a way to control these behaviors. This is what we do.
- wereHamster 8y ago
  What advantages does Istio give you over orchestrating the services using k8s "Service" resources? To me it seems that k8s already provides mechanisms to proxy requests to the correct backends (pods). Why would I use Istio?

potrei 8y ago

Apart from the specific technology used, it's important to change the way applications are designed and implemented. I saw many projects in trouble because they merely split a monolithic application into small pieces, without applying a new model of design and thinking. If you approach micro-services development without changing your mind first, you will fail.

rasteau 8y ago
Amen! My last three companies were moving from a monolith to microservices. In every case, the rationale for the move was little more than "monolith development is slow, therefore microservices". Unfortunately for all of them, the true reasons for the slow development was poor separation of concerns, insufficient and brittle tests, and years of accumulated hacky shortcuts to ship new features "faster". The folks pushing the microservice panacea were "proven right" in that development was much faster... initially. Without years of cruft in their way, devs were able to churn out new stuff (after a significant time spent ramping up on infrastructure code). Eventually, and in every case, the fundamental flaws resurfaced, this time increasing in severity now that changing the system often required multiple service changes. As well, a host of new kinds of problems emerged: distributed transactions, network failures, client/server versioning, debugging across services, etc. I'm now a microservice skeptic. Whatever your solution, it should be at the same "level" as the problem. A massive change in technical architecture will not solve the accumulated cost of your poor engineering quality choices.
- potrei 8y ago
  Yes, I agree. That's why I said that it's necessary to change the way application are designed. And, of course, there's no silver bullet. Sometimes micro-services architecture is not the way to go.

pritambarhate 8y ago

It will be amazing if someone knowledgeable here can share their experience with Linked 2.0, Istio and Envoy.

boudin 8y ago
Envoy, if I'm not mistaken, is a sidecar proxy that is used by Istio. The equivalent for Linkerd 2 is Conduit (that was its own app before and now is entirely part of Linkerd 2). From what I've seen, Linkerd 2 doesn't feature as much features as Istio or Linkerd 1 for now (no circuit breaker for example). From the few issues I've seen on Github, it seems a bit immature to be used in a production environment. Between the fact that I've just started looking into that last month and that it changes at a rate that is really hard to follow, I'm might be wrong...

snupples 8y ago

I feel that service mesh integration in k8s is still very immature. Be aware that running any sidecar model service mesh requires setting elevated permissions on the entire pod. Your pod security policy will need to allow NET_ADMIN at the very least, since service meshes mostly operate by manipulating iptables rules in the pod. Often there are other elevated permissions required. Usually this means people are setting elevated permissions globally on the default svc account, which is scary.

germainelong 8y ago

Sadly Kubernetes is still vendor locked in - although you have a selection of them. Average Joe cannot install Kubernetes on their pool of commodity dedicated servers or VPS servers because there is no ingress that works with already assigned IP addresses. If you buy a dedicated server you get a block if IPs and there is no way to assign them to ingress. If such thing was developed, people could ditch expensive cloud providers in favour of order of magnitude cheaper dedicated servers.

ccmcarey 8y ago
What? This makes no sense. You absolutely can bootstrap your own cluster of servers running K8s.