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

71–80 of 536 posts

Re: “It's The Future”

#71

Post by mrweasel »

buro9 wrote: post #54
mrweasel wrote: post #50

Earlier quoted context omitted.

>Any positive experiences with micro-services here? It makes sense for some thing. We run a webshop, but have a separate service that handles everything regarding payments. It has worked out really well, because it allows us to fiddle around with pretty much everything else and not worry about breaking the payment part. It helps that it's system where we can have just one test deployment and everyone just uses that d…

> have a separate service that handles everything regarding payments. It has worked out really well, because it allows us to fiddle around with pretty much everything else and not worry about breaking the payment part. Is the payments service a single service that manages the whole transaction, or have you go for multiple services handling each part and, if so, how did you manage failure with a distributed transactio…

It's a single service. It just sites between us and our PSPs. That way no other system needs to worry about integrating directly with the PSPs.

Re: “It's The Future”

#72

Post by nogox »

jondubois wrote: post #40

Kubernetes/Docker will become increasingly accessible to developers and it will loosen the reliance on lock-in PaaS like Heroku - This is the future; I'm betting everything on it. With tools like Rancher http://rancher.com , you can already see things moving in that direction. Next step is rancher-as-a-service. When it comes to developers, I think open systems will always prevail in the end (it's just more flexible).

How is rancher related?

Re: “It's The Future”

#73

Post by iagooar »

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

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

Re: “It's The Future”

#74

Post by nickjj »

Or just put your app(s) into containers and run them through docker compose on a single VPS. That bypasses about 99% of the things listed in this article.

You can still easily set things up so it's a git based deploy which is hands free after the initial push.

Now you have a single $5-10/month server that runs your app's stack without a big fuss. Of course it's not "web scale" with massive resiliency but when you're just starting out, 1 server instance is totally fine and exactly what you want.

I've ran many projects for years on 1 server that did "business mission critical" tasks like accepting payments, etc..

Re: “It's The Future”

#75

Post by golergka »

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 conversations with _who_ you are and _what problem_ are you trying to solve, of course the other side will seem stupid.

Re: “It's The Future”

#76

Post by nathan_f77 »

I've spun up a lot of kubernetes clusters to test it out. A few months ago I also tested out Flynn, Deis, Deis Workflow, Openstack, and a lot of other options. I still haven't found a simple bootstrap script that gets everything set up on AWS and lets me simply deploy my application. And it's true that storage still seems to be an unsolved problem with kubernetes.

Heroku is great, and free for small services. On the other hand, a highly-available kubernetes cluster is going to set you back at least $100 per month, which is just too much for small startups and side projects before they take off.

I think I'm going to forget everything and head towards http://serverless.com/. No Heroku, no Docker, no micro-services, no servers. Just everything running on AWS Lambda and DynamoDB. And everything static in S3 behind Cloudfront.

Or maybe just Firebase. But I really am tired of managing servers.

Re: “It's The Future”

#77

Post by vmateixeira »

nicolas_t wrote: post #43
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 think that splitting into micro services is valuable if and only if you reach a scale where it makes sense to split into micro services. By scale, I mean the number of people on the team (if you have a lot of people, it can make sense to split into micro-services to limit communication bottlenecks between developers) or in term of traffic, in which case microservices can be very useful to better optimize the system…

I think it's more to do with a need rather than going straight just because you have enough people on a team. For instance, if you find that some of your processing/specific request handling can outperform better by using a different framework, programming language than the ones it's currently developed on, then you should definitely consider a microservice approach by decoupling that specific service/functionality from your current stack.

Re: “It's The Future”

#78

Post by oelmekki »

"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 they please.

Passing through that, let's address the critics.

Microservices and docker are not necessarily tied. I write only monolithic apps, and use them with docker through dokku.

Etcd is a microservice problem, not a docker one.

You don't need coreos or kubernetes to use docker in production. You need them if you want massively scaled applications, just like you would have many servers running the same app with replication without docker. Most of us don't need that (and those who need it probably won't find it more complicated than what is needed to do that without docker).

If you don't want to manage servers, well, don't manage them. That's what cloud services are made for. But please tolerate some people love devops and not spending much direct money into infrastructure.

Re: “It's The Future”

#79

Post by jgalt212 »

fs111 wrote: post #58
jgalt212 wrote: post #44

Earlier quoted context omitted.

remember? Thomson Reuters on demand APIs are still largely SOAP based.

never touch a running system...

fair enough, but I posit X users started consuming this API when SOAP was prevalent and Y users started when ReST was prevalent and Y >> X. Furthermore, SOAP is hard to maintain these days because it's so ancient. i.e. the libraries are not new and/or actively maintained.

As such, I maintain SOAP should be gone for the good of the running system.

Re: “It's The Future”

#80

Post by zer0gravity »

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…

"Message passing as the fundamental operation of the OS is just an excercise in computer science masturbation. It may feel good, but you don't actually get anything DONE." -- Linus Torvalds

He said that about micro-kernels but it may apply to micro-services as well.

Breaking things apart too much will only cause you grief.

Post reply on HN