Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“It's The Future”

circleci.com

Post reply on HN
Print view View original

91–100 of 536 posts

Re: “It's The Future”

#91

Post by CrLf »

xchaotic wrote: post #37

I think I will be fine, thanks. I'll stick to my shell scripts, so far they've outlived any other devops fad.

I worry when I can't tell if a comment like this is based on fact or just trying to be funny.

Because I've seen my share of nasty "legacy" automation but, surprisingly, I still think a good set of well thought-out shell scripts written by someone that understands what's being automated still beat modern tools, even when the person doing the automation is the same.

I don't quite know why this is, but there's something timeless about shell scripts. I've also seen shell script automation survive for a long time unattended and with zero issues. Not so with some of the modern tools that are supposed to be all unicorns and rainbows.

Re: “It's The Future”

#92

Post by kalleboo »

TickleSteve wrote: post #12

Sometimes it seems the webdev world is unaware of the complexity its creating simply to execute instructions....

What do you mean? I'm just running bytecode on a virtual machine ontop of a virtualized container on top of virtualized hardware on a CPU where the instruction set is virtualized in microcode...

Re: “It's The Future”

#93

Post by 2100821021 »

oelmekki wrote: post #78

"Hi, my name is dokku, and I have no idea what you're talking about" :) This rant sounds just like any rant from old dev mocking a new tech. "This is less efficient, this is too complicated, this can't be taken seriously, this won't last". Creating a character obsessed with "this is dead" hardly dissimulate the obsession with "this won't work". Do whatever you please, we don't care. But don't mock others about what t…

You mean B.S. written to impress investors and dominate a market segment for 2 or 3 years until the "founders" have a good exit.

Re: “It's The Future”

#94

Post by augustl »

mrhektor wrote: post #31

"-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…

> Any positive experiences with micro-services here?

In my experience, any monolith that can be broken up into a queue based system will benefit enormously. This cleans up the pipelines, and adds monitoring and scaling points (the queues). Queues removes run-time dependencies to the other services. It requires that these services are _actually_ independent, of course.

I do, however, avoid RPC based micro-services like the plague. RPC adds run-time dependencies to services. If possible, I limit RPC to other (micro) services to launch/startup/initialization/bootstrap, not run-time. In many cases, though, the RPC can be avoided entirely.

Re: “It's The Future”

#97

Post by BellsOnSunday »

StreamBright wrote: post #53

What a nice clickbait title. A is better than B, even though A is an apple while B is an orange, and we use them for entirely different purposes. Some functionality provided by Heroku can be replaced with Docker, and some missing features of Heroku are in the Docker infra, that can be added to Heroku using software (like service discovery: https://blog.heroku.com/managing_your_microservices_on_herok... )

It's a humorous lament on the fragmented state of devops, not to be taken too seriously.

Re: “It's The Future”

#99

Post by asimuvPR »

firasd wrote: post #55
mrhektor wrote: post #31

"-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…

I'm building a podcast discovery app and I find myself being de-facto pulled towards modularity. It's because my feed checker is in Elixir, my site is WordPress-based, and I communicate between them using the WP API, and I'm using Google Cloud SQL, and Elasticsearch on its own virtual machine... The thing is though, the Elixir feed checker has its own database table that tracks whether it's seen an episode in a feed.…

I think your problem might be not expanding wordpress. PHP will gladly do the above through wordpress plugins and cron jobs. I built something similar and ended up going that way. The system is still running to this day. Sure, its not hip but gets the job done with miniml fuss and makes money.

Re: “It's The Future”

#100

Post by firasd »

iagooar wrote: post #73
firasd wrote: post #55

Earlier quoted context omitted.

I'm building a podcast discovery app and I find myself being de-facto pulled towards modularity. It's because my feed checker is in Elixir, my site is WordPress-based, and I communicate between them using the WP API, and I'm using Google Cloud SQL, and Elasticsearch on its own virtual machine... The thing is though, the Elixir feed checker has its own database table that tracks whether it's seen an episode in a feed.…

Care sharing your progress with the podcast discovery app? I'm a cofounder of Podigee which is a podcast hosting service. Maybe we can exchange know-how, find some synergies or even join forces on certain topics. Feel free to drop me a line at mati@podigee.com

Sure, emailed. Also added a screenshot/twitter to my profile in case anyone else is interested.
Post reply on HN