7 ms·

The author is not lying. I've been learning docker and it is certainly nice to pull and docker-compose up for local dev, but there is a lot to learn when you fa

The author is not lying. I've been learning docker and it is certainly nice to pull and docker-compose up for local dev, but there is a lot to learn when you factor in orchestrators. And when I mean learn, I mean actually learning the nuts and bolts of a Dockerfile and not copy/pasting shit from the internet. While it's all helpful, its certainly not needed for the project we have at work, nor the "microservices" that our lead thinks we need even though they aren't even microservices. All we've done is split our application into seperate mini applications that don't talk to eachother at all, essentially 4 web services. Great! Sigh. So why am I learning all this instead of just programming? Programming is what I really want to do all day, just writing code and thinking through software architecture. Because the industry tells me if I don't learn this stuff I will be decommissioned. Fun stuff.

intellix 6y ago
Unfortunately I also had to waste my time learning containers when all I wanted was Heroku without the insane prices for addon services. For delivering just apps I think Cloud Native Buildpacks solve that: https://buildpacks.io/ https://buildpacks.io/
- monsieurbanana 6y ago
  What does "delivering just apps" means? And what's buildpacks? Seems like a more specialized docker.
  - bjt 6y ago
    Buildpacks predate Docker. They're standardized build scripts for popular app runtimes. Heroku created the concept and applied it for their PaaS years before Docker was a thing. They're not a competitor to Docker containers. They are perhaps a competitor to Dockerfiles.
  - intellix 6y ago
    They detect the kind of app and then basically do everything required to build and run that app from pushing a repository. So it'll detect that it's a NodeJS application because there's a package.json file in the root and essentially: install node modules, run the build script and then do npm run start to run it. All you need to know how to do is: supply a build + start script and push your repository and now it's built and running in the Cloud to scale from 0 to unlimited. It's basically Heroku but buildpacks are a standardised way to do it on any Cloud.
- ksajadi 6y ago
  You can also try Cloud 66
  - lvturner 6y ago
    Used them years ago when we moved from AWS to bare-metal (losing Elastic Beanstalk that we were using in AWS in the process) I seem to recall a few minor issues here and there, but I'd totally use them again.
- barhum 6y ago
  Have you tried Dokku? Very similar to Heroku. I run it on a DO server without any issues.
- cpursley 6y ago
  Render.com is like Heroku but cheaper and handles static sites as well as distributed applications (nodes can talk to each other).
cdrini 6y ago
For me, docker is just a superpower that let's me build larger, more complex applications. That's why it's worth learning. It raises the ceiling of what I'm able to create. Creating a site with multiple services that integrate with each other is complicated. You could do it from scratch, but it would take so long that you would likely never be able to manage the actual complexity you care about--the complexity you want to architect and program. You'd be too busy programming solutions to the problems that docker already solves.
- SilverRed 6y ago
  I love docker as a home user as well. Sometimes when I'm bored I'll build an IM bot. Docker makes hosting it super simple. I just start from the ruby docker image, copy my script in and then dump it on gitlab which will build and host the container which lets me pull it from my server. I can then copy a simple systemd config to start it on boot and restart it if it fails. This is all much simpler than managing multiple versions of ruby installed locally. Not to mention the security benefits of keeping it in a container. Perhaps this is all so easy and convenient for me because I learned docker for pro use and now its just mentally free for casual use.
  - vincnetas 6y ago
    Docker has autorestart on failure. I think it also autorestarts after reboot.
    - SilverRed 6y ago
      Yeah I have seen this but for some reason it just wasn't working for me. I think that maybe the docker service just wasn't being started at boot but once I set it up with systemd it all just works now.
      - lostlogin 6y ago
        I find it painfully reliable. I forget about it and then weeks later I find the image when scrounging about trying to work out where my RAM went.
SatvikBeri 6y ago
I started using Docker heavily about 3 years into my current project and that was the right time. There's real overhead to getting things to work on compared to a local dev environment, but there are major benefits, especially once you actually do need to run the same thing on multiple machines. It's a pretty classic example of something with a high constant factor but better scaling properties.
jayd16 6y ago
You're learning this stuff because you're an engineer not a computer scientist. Deploying to prod is the goal, not writing code. >seperate mini applications that don't talk to eachother at all, essentially 4 web services. I mean, that sounds pretty good. If you can do that why couple them? "Microservices" is just SOA without any debate over how small a service can be.
- ZephyrBlu 6y ago
  > I mean, that sounds pretty good. If you can do that why couple them? Because what is the point in separating each one into their own deployed service and having to deal with network issues when they could just be services inside a monolith?
  - jayd16 6y ago
    OP just said they don't talk at all. They sound completely decoupled already. You could put them in the same app and share routes if you want and just separate by package or compilation unit if you really want to. The hard part is already done though. They could be managed and deployed by completely different teams with no overhead now. It really depends what we're tuning for.
    - neuronic 6y ago
      Scaling is another factor that comes to mind, also resilience. If one part in the monolith goes haywire so will the entire application. If you can decouple and split the software into 4 applications with their own concerns, at least you have 3 applications left running (assuming they are decoupled). If app 1 wants 5000% more CPU than app 2, maybe you can have different instance types running and save costs/resources.
      - systematical 6y ago
        A good reason no doubt and if that comes to bear sure. But at least code in a monorepo and split to microservices in your pipeline. Cake and eat.
z3t4 6y ago
> ... the "microservices" that our lead thinks we need even though they aren't even microservices. All we've done is split our application into seperate mini applications that don't talk to eachother at all, Replacing in-app API/libary calls with RPC is an micro-service anti-pattern (1). If the services don't need to communicate you have probably made the correct split - or you could think backwards - why would these services that are independent and don't talk to each need to be merged into a monolith ? 1) There are of course exceptions, there could be a good idea to separate things for performance, eg. create worker processes. Which works if they are like pure functions.
- systematical 6y ago
  As my reply far up this chain says, the services have a ton in common. So much so that the idea was "just copy and paste" code between. Still sound great? I forced his hand on a shared library that houses lots of the code all services need, but not everything can (or should) go in there. Multiple PRs just to complete one task sometimes and we're talking a small 4-6 hour task. If the services were truly independent this wouldn't be needed and the approach wouldn't be a poor developer experience and infrastructure headache. But a change in one often requires a change in another. We don't have a monorepo, because he was too much of a doofus to figure it out and gave up instead of asking for help. 80% of the problems are because the guy doesn't know what he's doing, doesn't know architecture and just said we're doing this. Which means I have to go in and fix his poorly built Dockerfiles that are an expose on what not to do. We're now adding API Gateway. Was this explained as to why we need it? No. Did I ask yes? But I simply get "I've already explained it" Cool. I explained to you why running an update on packages in your build instead of installing from a lock file is some of the dumbest shit I've ever seen yet I just had to go in and clean up your dockerfile again. You want untested packages going into stage / prod? My lead is your guy. I'm sure in a few weeks he'll come to me with "But API Gateway doesn't work and I don't have time can you fix it". Fuck this dude. I just want to write clean code and not fuck with his mistakes. Did I mention we run completely different Dockerfiles between environments (local vs stage/prod). Like, not even the same O.S (ubuntu vs alpine), web server (apache vs nginx) etc... Getting the picture of whats its like to deal with his mistakes day in and day out and slowly fix them.

intellix 6y ago

Unfortunately I also had to waste my time learning containers when all I wanted was Heroku without the insane prices for addon services. For delivering just apps I think Cloud Native Buildpacks solve that: https://buildpacks.io/ https://buildpacks.io/

monsieurbanana 6y ago
What does "delivering just apps" means? And what's buildpacks? Seems like a more specialized docker.
- bjt 6y ago
  Buildpacks predate Docker. They're standardized build scripts for popular app runtimes. Heroku created the concept and applied it for their PaaS years before Docker was a thing. They're not a competitor to Docker containers. They are perhaps a competitor to Dockerfiles.
- intellix 6y ago
  They detect the kind of app and then basically do everything required to build and run that app from pushing a repository. So it'll detect that it's a NodeJS application because there's a package.json file in the root and essentially: install node modules, run the build script and then do npm run start to run it. All you need to know how to do is: supply a build + start script and push your repository and now it's built and running in the Cloud to scale from 0 to unlimited. It's basically Heroku but buildpacks are a standardised way to do it on any Cloud.
ksajadi 6y ago
You can also try Cloud 66
- lvturner 6y ago
  Used them years ago when we moved from AWS to bare-metal (losing Elastic Beanstalk that we were using in AWS in the process) I seem to recall a few minor issues here and there, but I'd totally use them again.
barhum 6y ago
Have you tried Dokku? Very similar to Heroku. I run it on a DO server without any issues.
cpursley 6y ago
Render.com is like Heroku but cheaper and handles static sites as well as distributed applications (nodes can talk to each other).

cdrini 6y ago

For me, docker is just a superpower that let's me build larger, more complex applications. That's why it's worth learning. It raises the ceiling of what I'm able to create. Creating a site with multiple services that integrate with each other is complicated. You could do it from scratch, but it would take so long that you would likely never be able to manage the actual complexity you care about--the complexity you want to architect and program. You'd be too busy programming solutions to the problems that docker already solves.

SilverRed 6y ago
I love docker as a home user as well. Sometimes when I'm bored I'll build an IM bot. Docker makes hosting it super simple. I just start from the ruby docker image, copy my script in and then dump it on gitlab which will build and host the container which lets me pull it from my server. I can then copy a simple systemd config to start it on boot and restart it if it fails. This is all much simpler than managing multiple versions of ruby installed locally. Not to mention the security benefits of keeping it in a container. Perhaps this is all so easy and convenient for me because I learned docker for pro use and now its just mentally free for casual use.
- vincnetas 6y ago
  Docker has autorestart on failure. I think it also autorestarts after reboot.
  - SilverRed 6y ago
    Yeah I have seen this but for some reason it just wasn't working for me. I think that maybe the docker service just wasn't being started at boot but once I set it up with systemd it all just works now.
    - lostlogin 6y ago
      I find it painfully reliable. I forget about it and then weeks later I find the image when scrounging about trying to work out where my RAM went.

SatvikBeri 6y ago

I started using Docker heavily about 3 years into my current project and that was the right time. There's real overhead to getting things to work on compared to a local dev environment, but there are major benefits, especially once you actually do need to run the same thing on multiple machines. It's a pretty classic example of something with a high constant factor but better scaling properties.

jayd16 6y ago

You're learning this stuff because you're an engineer not a computer scientist. Deploying to prod is the goal, not writing code. >seperate mini applications that don't talk to eachother at all, essentially 4 web services. I mean, that sounds pretty good. If you can do that why couple them? "Microservices" is just SOA without any debate over how small a service can be.

ZephyrBlu 6y ago
> I mean, that sounds pretty good. If you can do that why couple them? Because what is the point in separating each one into their own deployed service and having to deal with network issues when they could just be services inside a monolith?
- jayd16 6y ago
  OP just said they don't talk at all. They sound completely decoupled already. You could put them in the same app and share routes if you want and just separate by package or compilation unit if you really want to. The hard part is already done though. They could be managed and deployed by completely different teams with no overhead now. It really depends what we're tuning for.
  - neuronic 6y ago
    Scaling is another factor that comes to mind, also resilience. If one part in the monolith goes haywire so will the entire application. If you can decouple and split the software into 4 applications with their own concerns, at least you have 3 applications left running (assuming they are decoupled). If app 1 wants 5000% more CPU than app 2, maybe you can have different instance types running and save costs/resources.
    - systematical 6y ago
      A good reason no doubt and if that comes to bear sure. But at least code in a monorepo and split to microservices in your pipeline. Cake and eat.

z3t4 6y ago

> ... the "microservices" that our lead thinks we need even though they aren't even microservices. All we've done is split our application into seperate mini applications that don't talk to eachother at all, Replacing in-app API/libary calls with RPC is an micro-service anti-pattern (1). If the services don't need to communicate you have probably made the correct split - or you could think backwards - why would these services that are independent and don't talk to each need to be merged into a monolith ? 1) There are of course exceptions, there could be a good idea to separate things for performance, eg. create worker processes. Which works if they are like pure functions.

systematical 6y ago
As my reply far up this chain says, the services have a ton in common. So much so that the idea was "just copy and paste" code between. Still sound great? I forced his hand on a shared library that houses lots of the code all services need, but not everything can (or should) go in there. Multiple PRs just to complete one task sometimes and we're talking a small 4-6 hour task. If the services were truly independent this wouldn't be needed and the approach wouldn't be a poor developer experience and infrastructure headache. But a change in one often requires a change in another. We don't have a monorepo, because he was too much of a doofus to figure it out and gave up instead of asking for help. 80% of the problems are because the guy doesn't know what he's doing, doesn't know architecture and just said we're doing this. Which means I have to go in and fix his poorly built Dockerfiles that are an expose on what not to do. We're now adding API Gateway. Was this explained as to why we need it? No. Did I ask yes? But I simply get "I've already explained it" Cool. I explained to you why running an update on packages in your build instead of installing from a lock file is some of the dumbest shit I've ever seen yet I just had to go in and clean up your dockerfile again. You want untested packages going into stage / prod? My lead is your guy. I'm sure in a few weeks he'll come to me with "But API Gateway doesn't work and I don't have time can you fix it". Fuck this dude. I just want to write clean code and not fuck with his mistakes. Did I mention we run completely different Dockerfiles between environments (local vs stage/prod). Like, not even the same O.S (ubuntu vs alpine), web server (apache vs nginx) etc... Getting the picture of whats its like to deal with his mistakes day in and day out and slowly fix them.