8 ms·

I can’t wait until the Kubernetes/container/Microservice beasts we are building today become legacy in 20 years. Fixing a COBOL application will probably look s

I can’t wait until the Kubernetes/container/Microservice beasts we are building today become legacy in 20 years. Fixing a COBOL application will probably look simple in comparison.

musicale 6y ago
Even more than the efficiency penalties, it's the drastic increase in complexity that makes me want to stay far, far away from microservice architectures.
- gonzo41 6y ago
  Like all legacy tech. Wrap it in a box of tests don't touch it and just manage the risk down over 20 years. Just like migrating away from a mainframe.
- yaml-ops-guy 6y ago
  Am I doing myself a disservice by actively avoiding shops that want to go down the k8s road? Asking in interviews questions like “how many namespaces are you managing or expecting to manage” and often times teams are talking about a single microservice and bringing in k8s “just in case” To which I’ve oft said “good luck in your endeavors”
  - goodoldneon 6y ago
    K8s solves a specific set of problems that mid- to large-sized companies face. If the company is big enough to have multiple K8s experts then it can be successful
  - jjav 6y ago
    > Am I doing myself a disservice by actively avoiding shops that want to go down the k8s road? From the resume-driven-development angle, probably. I do the same though. If you prefer to work in a sane environment though, wise choice.
- mathgladiator 6y ago
  k8s sits on a list of things that I hope to avoid long enough before I can retire.
  - kbenson 6y ago
    I felt largely the same way, but now our company has enough microservices that without something like k8s it's hard to actually sufficiently test anything well. Sure, we have test setups for any one service, and tests for that service with some other services mocked, but there's really no way to spin up a real full dev or QA environment with all the services interacting without herculean effort, and keeping it up to date would be non-trivial. I still haven't done anything with k8s, but I suspect it's the solution to this problem, even if it would take that same herculean effort to finally get everything moved to using it (we don't even run containers, we run our own application delivery system that has some similarities without the process isolation, because we've been doing so since before Docker existed).
    - jjav 6y ago
      > I felt largely the same way, but now our company has enough microservices that without something like k8s it's hard to actually sufficiently test anything well. That feels like a self-inflicted wound that will now only get worse with k8s.
      - kbenson 6y ago
        > That feels like a self-inflicted wound What's the alternative? It's not like we're some web property with an application, it's an ISP, and we sell internet services, and we've been around long enough that we still offer traditional ISP services (many for free) such as email, hosting, VPN service, etc, as well as telecom services. These often need to communicate with each other in some way, as well as many back-end services we've written to serve our staff. Microservices come with problems, but honestly I can't see a large monolithic app (or even a few of them) being much better development wise, even if it might have been easier to test and set up a development environment.
  - 6y ago
- nostrebored 6y ago
  Well designed microservices drastically reduce complexity and mental overhead of working with a system. The problem is companies with poorly designed monoliths hit complexity problems more quickly and often. If software architecture is not a core competency, solutions architecture is probably not either, and poorly designed microservices are a completely different beast. A distributed monolith is inherently more difficult to maintain and operate.
  - bildung 6y ago
    But why would the same people that poorly designed the monolith be able to design the intrinsically more complex microservice architecture better?
    - mkoubaa 6y ago
      +1 We have to keep in mind that not all software systems are designed by savants, and even ones that are might be constrained by business needs from rearchitecting them when they need it
    - nostrebored 6y ago
      That's what I was trying to articulate in the end. Microservices are generally less complex.They can appear more complicated because companies who are choosing to transition usually do so after a problem. These problems are often due to poor monolith design. Teams that design poor monoliths typically have neither a software or solutions architecture proficiency
    - spaetzleesser 6y ago
      My simple rule is: if you can’t write a decent library you won’t be able to write a well designed microservice. Microservices have all the challenges of library design plus quite a few more.
  - jjav 6y ago
    > microservices drastically reduce complexity and mental overhead of working with a system If you only need to understand and maintain one of them, sure. That would be extremely rare though. You have to understand the entire system and all the interaction between all the parts. At which point the 10x complexity of excessive microservices will kill you.
closeparen 6y ago
As long as the network protocols stay in the mainstream, the implementation tech stacks of remote services will become “ancient” and “icky” without callers really noticing. I suspect they will stay around much longer as people program around them without comprehending what horrors lay inside.
- snth 6y ago
  I wish we could treat services as black boxes like this, but who can run services these days without keeping on top of dependency, security, and platform updates? The inevitable deprecation of some of these means surgery will soon be required to keep a service running and secure.
mathattack 6y ago
I’m not on either side of the k8s debate, but I suspect it will be a lot less than 20 years as the ecosystem is moving faster now.
- abakker 6y ago
  I'd predict 3 years. Mesos looked promising 5 years ago, today its going to the Attic.
hinkley 6y ago
I get the impression some of these things are going into the Linux kernel, one way or the other. When we hit 20% someone will do a Lite version.
Cthulhu_ 6y ago
This is why I'm mainly focusing on the application side of things; container technology is 'just' the runtime. I'm making sure my stuff is sane, that it runs on anything. Others can worry about containerization / the runtime. But I'm getting the feeling that a lot of people worry a lot about the runtime. They break up their applications into microservices not to solve a problem, but because they believe it's the best thing to do because $reason. But you shouldn't do that until you're actually running into an issue and have exhausted the other, simpler options. I mean I wouldn't mind having or experiencing an actual scaling problem directly, but so far I've never seen it. I've seen a LOT more organizational and technical problems stemming from intentionally building a microservices architecture though. But building just the one codebase is dull.
- nnamtr 6y ago
  $reason = Make the microservices independent of each other, so you can rewrite and replace them without much trouble when they're getting old.
  - tovej 6y ago
    This is just modularisation though. You can modularise without microservices. Microservices solve a scaling problem, not a design flexibility problem.
    - iampims 6y ago
      Micro services often solve _an organizational scaling_ problem, and are less frequently deployed for _performance scaling_.
      - beaconstudios 6y ago
        a monorepo also solves that same organisational scaling problem, but without introducing the artificial problem of basic function calls having to traverse the network, and having to keep tons of different services online and talking to each other.
ideamotor 6y ago
It’s completely insane and unfortunately many are wasting time trying to fix it instead of focusing on real problems that weren’t created for the hell of it.
KptMarchewa 6y ago
Strongly disagree - COBOL apps are strongly tied to their obsolete hardware. On the other hand, containerized applications are "portable" - can run on everything that runs Linux.
- adamcstephens 6y ago
  COBOL can and does run on x86 Linux. I suppose you could probably even put it in a container.
  - toomanybeersies 6y ago
    From Big Blue itself, COBOL on a Kubernetes cluster! https://github.com/IBM/kubernetes-cobol https://github.com/IBM/kubernetes-cobol
    - mrweasel 6y ago
      That fantastic and terrifying at the same time. The complexity of Kubernetes and when you open the container: Bam, Cobol.
  - KptMarchewa 6y ago
    It can, but do you really believe is this what those apps are working on, or even that they could work without major rewrite? They are strongly tied to their mainframe environments.
- webreac 6y ago
  As someone who has worked on migration project from redhat 6 to redhat 7, I strongly disagree.
- mrweasel 6y ago
  The article speculates that the hardware is “no more” than 16 years old. Obsolete, but newer than the original code, meaning that it not that strongly tied to the hardware.
toomanybeersies 6y ago
I've had to deal with the opposite problem, where we had a monolithic application running on infrastructure that hadn't changed in half a decade (except to keep increasing the size of the EC2 instances because the OOM killer kept sniping processes) Too much monolith ends with abstraction inversion, which is a Bad Thing.
otabdeveloper4 6y ago
> ...in 20 years Refactor that estimate by an order of magnitude. Most are already legacy next year. (Sadly I'm in that situation too, migrating off an expensive AWS cluster to a single Jenkins machine...)
CRConrad 6y ago
I mag au Schpätzlä!

I can’t wait until the Kubernetes/container/Microservice beasts we are building today become legacy in 20 years. Fixing a COBOL application will probably look simple in comparison.

musicale 6y ago

Even more than the efficiency penalties, it's the drastic increase in complexity that makes me want to stay far, far away from microservice architectures.

gonzo41 6y ago
Like all legacy tech. Wrap it in a box of tests don't touch it and just manage the risk down over 20 years. Just like migrating away from a mainframe.
yaml-ops-guy 6y ago
Am I doing myself a disservice by actively avoiding shops that want to go down the k8s road? Asking in interviews questions like “how many namespaces are you managing or expecting to manage” and often times teams are talking about a single microservice and bringing in k8s “just in case” To which I’ve oft said “good luck in your endeavors”
- goodoldneon 6y ago
  K8s solves a specific set of problems that mid- to large-sized companies face. If the company is big enough to have multiple K8s experts then it can be successful
- jjav 6y ago
  > Am I doing myself a disservice by actively avoiding shops that want to go down the k8s road? From the resume-driven-development angle, probably. I do the same though. If you prefer to work in a sane environment though, wise choice.
mathgladiator 6y ago
k8s sits on a list of things that I hope to avoid long enough before I can retire.
- kbenson 6y ago
  I felt largely the same way, but now our company has enough microservices that without something like k8s it's hard to actually sufficiently test anything well. Sure, we have test setups for any one service, and tests for that service with some other services mocked, but there's really no way to spin up a real full dev or QA environment with all the services interacting without herculean effort, and keeping it up to date would be non-trivial. I still haven't done anything with k8s, but I suspect it's the solution to this problem, even if it would take that same herculean effort to finally get everything moved to using it (we don't even run containers, we run our own application delivery system that has some similarities without the process isolation, because we've been doing so since before Docker existed).
  - jjav 6y ago
    > I felt largely the same way, but now our company has enough microservices that without something like k8s it's hard to actually sufficiently test anything well. That feels like a self-inflicted wound that will now only get worse with k8s.
    - kbenson 6y ago
      > That feels like a self-inflicted wound What's the alternative? It's not like we're some web property with an application, it's an ISP, and we sell internet services, and we've been around long enough that we still offer traditional ISP services (many for free) such as email, hosting, VPN service, etc, as well as telecom services. These often need to communicate with each other in some way, as well as many back-end services we've written to serve our staff. Microservices come with problems, but honestly I can't see a large monolithic app (or even a few of them) being much better development wise, even if it might have been easier to test and set up a development environment.
- 6y ago
nostrebored 6y ago
Well designed microservices drastically reduce complexity and mental overhead of working with a system. The problem is companies with poorly designed monoliths hit complexity problems more quickly and often. If software architecture is not a core competency, solutions architecture is probably not either, and poorly designed microservices are a completely different beast. A distributed monolith is inherently more difficult to maintain and operate.
- bildung 6y ago
  But why would the same people that poorly designed the monolith be able to design the intrinsically more complex microservice architecture better?
  - mkoubaa 6y ago
    +1 We have to keep in mind that not all software systems are designed by savants, and even ones that are might be constrained by business needs from rearchitecting them when they need it
  - nostrebored 6y ago
    That's what I was trying to articulate in the end. Microservices are generally less complex.They can appear more complicated because companies who are choosing to transition usually do so after a problem. These problems are often due to poor monolith design. Teams that design poor monoliths typically have neither a software or solutions architecture proficiency
  - spaetzleesser 6y ago
    My simple rule is: if you can’t write a decent library you won’t be able to write a well designed microservice. Microservices have all the challenges of library design plus quite a few more.
- jjav 6y ago
  > microservices drastically reduce complexity and mental overhead of working with a system If you only need to understand and maintain one of them, sure. That would be extremely rare though. You have to understand the entire system and all the interaction between all the parts. At which point the 10x complexity of excessive microservices will kill you.

closeparen 6y ago

As long as the network protocols stay in the mainstream, the implementation tech stacks of remote services will become “ancient” and “icky” without callers really noticing. I suspect they will stay around much longer as people program around them without comprehending what horrors lay inside.

snth 6y ago
I wish we could treat services as black boxes like this, but who can run services these days without keeping on top of dependency, security, and platform updates? The inevitable deprecation of some of these means surgery will soon be required to keep a service running and secure.

mathattack 6y ago

I’m not on either side of the k8s debate, but I suspect it will be a lot less than 20 years as the ecosystem is moving faster now.

abakker 6y ago
I'd predict 3 years. Mesos looked promising 5 years ago, today its going to the Attic.

hinkley 6y ago

I get the impression some of these things are going into the Linux kernel, one way or the other. When we hit 20% someone will do a Lite version.

Cthulhu_ 6y ago

This is why I'm mainly focusing on the application side of things; container technology is 'just' the runtime. I'm making sure my stuff is sane, that it runs on anything. Others can worry about containerization / the runtime. But I'm getting the feeling that a lot of people worry a lot about the runtime. They break up their applications into microservices not to solve a problem, but because they believe it's the best thing to do because $reason. But you shouldn't do that until you're actually running into an issue and have exhausted the other, simpler options. I mean I wouldn't mind having or experiencing an actual scaling problem directly, but so far I've never seen it. I've seen a LOT more organizational and technical problems stemming from intentionally building a microservices architecture though. But building just the one codebase is dull.

nnamtr 6y ago
$reason = Make the microservices independent of each other, so you can rewrite and replace them without much trouble when they're getting old.
- tovej 6y ago
  This is just modularisation though. You can modularise without microservices. Microservices solve a scaling problem, not a design flexibility problem.
  - iampims 6y ago
    Micro services often solve _an organizational scaling_ problem, and are less frequently deployed for _performance scaling_.
    - beaconstudios 6y ago
      a monorepo also solves that same organisational scaling problem, but without introducing the artificial problem of basic function calls having to traverse the network, and having to keep tons of different services online and talking to each other.

ideamotor 6y ago

It’s completely insane and unfortunately many are wasting time trying to fix it instead of focusing on real problems that weren’t created for the hell of it.

KptMarchewa 6y ago

Strongly disagree - COBOL apps are strongly tied to their obsolete hardware. On the other hand, containerized applications are "portable" - can run on everything that runs Linux.

adamcstephens 6y ago
COBOL can and does run on x86 Linux. I suppose you could probably even put it in a container.
- toomanybeersies 6y ago
  From Big Blue itself, COBOL on a Kubernetes cluster! https://github.com/IBM/kubernetes-cobol https://github.com/IBM/kubernetes-cobol
  - mrweasel 6y ago
    That fantastic and terrifying at the same time. The complexity of Kubernetes and when you open the container: Bam, Cobol.
- KptMarchewa 6y ago
  It can, but do you really believe is this what those apps are working on, or even that they could work without major rewrite? They are strongly tied to their mainframe environments.
webreac 6y ago
As someone who has worked on migration project from redhat 6 to redhat 7, I strongly disagree.
mrweasel 6y ago
The article speculates that the hardware is “no more” than 16 years old. Obsolete, but newer than the original code, meaning that it not that strongly tied to the hardware.

toomanybeersies 6y ago

I've had to deal with the opposite problem, where we had a monolithic application running on infrastructure that hadn't changed in half a decade (except to keep increasing the size of the EC2 instances because the OOM killer kept sniping processes) Too much monolith ends with abstraction inversion, which is a Bad Thing.

otabdeveloper4 6y ago

> ...in 20 years Refactor that estimate by an order of magnitude. Most are already legacy next year. (Sadly I'm in that situation too, migrating off an expensive AWS cluster to a single Jenkins machine...)

CRConrad 6y ago

I mag au Schpätzlä!