Live data from Hacker News

“It's The Future”

circleci.com

81–90 of 536 posts

Re: “It's The Future”

#81

Earlier quoted context omitted.

That's 1 request per minute, you could slap that into a raspberry pi on a 3G connection, and do the same for your next 400 apps that has 1 request per minute. People seem to underestimate just how powerful modern machines really are. And I don't get why people seem to think it's hard to deploy simple web applications. Just write a 4-line shell script that rsync's, runs whatever DB migrations you may have and restarts…

40k visitors per month isn't one per minute. It's anywhere from one per minute to 40k per second. Division of requests by time is the worst possible mistake in calculating load.

Thank you for the correction, but that was not the point I was trying to make. I was referring to his statement:

> [...] before switching to Docker (even though I do love Docker).

This seems like a very drastic solution to problems he does not yet have. I've been responsible for similar thoughts before, but shortly after realized just how damn stupid I was.

Re: “It's The Future”

#82

"-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do. That seems excessive" A 100 times yes. We tried to split our monolithic Rails app into micro-services built in Go. 2 years and many fires later, we decided to abandon the project. It was mostly because the monitoring and alerting were now split in…

Microservices is a technology. IMO, like any other tech, it should be used when there are clear benefits expected in the near future, not as a blanket "always microservices" policies.

Although I personally had to deal with some monolithic monsters that I wished were split into smaller services.

Re: “It's The Future”

#83
post #60

There are 2 major issues with this: 1) Small teams (~1-5 people) trying to seem "big" by working at Google's scale. 2) Heroku's prices. We are currently (successfully so far) migrating a small Django project from bare Amazon EC2 instances to ECS with Docker. Even using 3 EC2 micro instances (1 vCPU, 1 GB RAM) for the Docker cluster we would spend ~8 USD/month/instance. With Heroku the minimum would be 25 USD/month/dy…

wait. you're comparing $25 with $75. it is 3x but it's still accounting noise by any standard imaginable unless you're running a charity server for an open source project.

What about the standard of "I'm young and this is a side project I'm doing in a couple of hours at the weekends"? Of course once you have a real company with more than two customers $75 is nothing. But version 0.1 is often a tool that's only useful to you.

Re: “It's The Future”

#85

"-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do. That seems excessive" A 100 times yes. We tried to split our monolithic Rails app into micro-services built in Go. 2 years and many fires later, we decided to abandon the project. It was mostly because the monitoring and alerting were now split in…

Wait a minute, this sounds familiar. looks at username Oh.

Re: “It's The Future”

#87

"-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do. That seems excessive" A 100 times yes. We tried to split our monolithic Rails app into micro-services built in Go. 2 years and many fires later, we decided to abandon the project. It was mostly because the monitoring and alerting were now split in…

The problem with microservices is that your state is spread over multiple systems. You completely lose the concept of transactional integrity, so you will have to work around that from the start.

The advantage though is that APIs (system boundaries) are usually better defined.

Perhaps one should use the best of both worlds, and run microservices on a common database, and somehow allow to pass transactions between services (so multiple services can act within the same transaction).

Re: “It's The Future”

#88
post #21

https://www.gitignore.io runs on Heroku and it gets 40k+ visitors a month on a free Dyno. I use Heroku because I don't want an IAAS solution, I want a PAAS solution. If I wasn't using Heroku, I would probably find another PAAS, before switching to Docker (even though I do love Docker).

Thanks for providing that - I just notices that your shell instructions don't include completion. I use the following in zsh: https://gist.github.com/lorenzhs/ad6c009f5748d333b73376e07ae... With that, I can do "gi " to get a list of all possibilities.

Re: “It's The Future”

#90

Look, if you're a one man shop doing a small project — do LAMP. Do perl. Do cgi. Do whatever you're comfortable with; if you try to switch to the latest silver bullet tech, you'll just get disappointed. But if you're a CTO with a startup with 10+ server-side developers and plan to hire at least as much in near future, suddenly all these dockers and microservices actually make sense. So, unless you'll start conversati…

> if you're a CTO with a startup with 10+ server-side developers and plan to hire at least as much in near future, suddenly all these dockers and microservices actually make sense

As a consultant, I often get asked those kinds of questions: "Should we use X?"

Whether it's programming languages, databases, operating systems, whether it's Chef vs Puppet vs Ansible vs Docker vs Whatever, it's a question that comes up a lot.

I generally answer it with "What are your team good at? What have they used, what do they know well?"

There are always exceptions to the rule, but in general I encourage people to play to the strengths of their team, rather than recommending Technology X because it's shiny and bang on-trend.

Post reply on HN