4 ms·

> A micro-services architecture does force you to be more conscientious about following best practices and automating workflows. This 100x. With a monolith, yo

> A micro-services architecture does force you to be more conscientious about following best practices and automating workflows. This 100x. With a monolith, you can get away with SSH'ing into boxes once in a while to fix or debug stuff. Micro-services must be automated.

majormajor 11y ago
But if ssh'ing into boxes every once in a while is all you need to fix or debug stuff, why is it "best practice" to build out a lot of infrastructure to replace that?
- tehbeard 11y ago
  SSH'ing into a box doesn't tend to lend itself to the fix going through source control, automated tests etc. That's not to say Microservices are the answer. The answer is a dev environment and proper debug/bug fix procedures.
- gedrap 11y ago
  I don't think that this is what he/she meant. If you ssh into the box, check some logs or something, find wrong configuration option and then roll out the new configuration in an automated way then that's all good. The problem comes when you change the configs manually over ssh and call it a day. A few fixes and a few months later, no one really knows how to set up some service because of those undocumented fixes (infrastructure automation serves as documentation). Now image that you have a dozen of services, some people quit, some people join, a year or two of manual fixes passes... And you have an awful mess where no one knows how to set up the services and just hope that you won't need to setup any new servers or migrate to different ones.
  - nathancahill 11y ago
    Nailed it. Micro-services are not necessarily always the answer (good devops is), but they encourage doing the "right thing".
- jdblair 11y ago
  Because that will bite you in the ass. Someday the person who knows how to ssh in to fix stuff will be on vacation, or at another job. Or someday you'll decide you would really like to put the service in an autoscale group and now you have to sort out a bunch of tribal knowledge into a real deployment.
gedrap 11y ago
Absolutely. If you can't prepare a new server (install system dependencies, sync system configuration, etc) and deploy the latest version with one or two commands, you will have bad bad time.
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
manigandham 11y ago
This is more about automation vs manual control and having a strong deployment and integration process. Microservices just demand it more, but it's just as useful and necessary with monoliths. By the way, monoliths describe both the architecture and deployment package. You can have microservices that are deployed as a monolith (like a single binary for example).

majormajor 11y ago

But if ssh'ing into boxes every once in a while is all you need to fix or debug stuff, why is it "best practice" to build out a lot of infrastructure to replace that?

tehbeard 11y ago
SSH'ing into a box doesn't tend to lend itself to the fix going through source control, automated tests etc. That's not to say Microservices are the answer. The answer is a dev environment and proper debug/bug fix procedures.
gedrap 11y ago
I don't think that this is what he/she meant. If you ssh into the box, check some logs or something, find wrong configuration option and then roll out the new configuration in an automated way then that's all good. The problem comes when you change the configs manually over ssh and call it a day. A few fixes and a few months later, no one really knows how to set up some service because of those undocumented fixes (infrastructure automation serves as documentation). Now image that you have a dozen of services, some people quit, some people join, a year or two of manual fixes passes... And you have an awful mess where no one knows how to set up the services and just hope that you won't need to setup any new servers or migrate to different ones.
- nathancahill 11y ago
  Nailed it. Micro-services are not necessarily always the answer (good devops is), but they encourage doing the "right thing".
jdblair 11y ago
Because that will bite you in the ass. Someday the person who knows how to ssh in to fix stuff will be on vacation, or at another job. Or someday you'll decide you would really like to put the service in an autoscale group and now you have to sort out a bunch of tribal knowledge into a real deployment.

gedrap 11y ago

Absolutely. If you can't prepare a new server (install system dependencies, sync system configuration, etc) and deploy the latest version with one or two commands, you will have bad bad time.

deleted 11y ago

[deleted]

deleted 11y ago

[deleted]

manigandham 11y ago

This is more about automation vs manual control and having a strong deployment and integration process. Microservices just demand it more, but it's just as useful and necessary with monoliths. By the way, monoliths describe both the architecture and deployment package. You can have microservices that are deployed as a monolith (like a single binary for example).