Is it a blank page ? I don't see any text.
Your browser is dead. Use servo instead. Works on servo.
“It's The Future”
41–50 of 536 posts
Re: “It's The Future”
#42This needs a "(2015)" adding to the title.
Re: “It's The Future”
#43"-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 piece by piece.
A small team starting a new project should not waste a single second considering microservices unless there's something that is so completely obviously decoupled in a way that not splitting it into a microservice will lead to extra work. It's also way easier to split into microservices after the fact than when you're developing a new app and you don't have a clue how it will look like or what the overall structure of the app will be in a year (most common case for startups).
Re: “It's The Future”
#44Obligatory link to "The S stands for simple", a SOAP-bashing classic: http://harmful.cat-v.org/software/xml/soap/simple
Everything must be in XML. Except the SoapAction header. Which has no defined standard. Yeah I remember all that madness.
remember? Thomson Reuters on demand APIs are still largely SOAP based.
Re: “It's The Future”
#45Question:
Is there an advantage to using docker when it takes 3 hours to rebuild our relatively small database?
Re: “It's The Future”
#46Kubernetes/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).
I thought it's more important WHAT you run inside containers than containers itself.
I got really upset about this rancher tool because it doesn't design my database schema.
Shit, future was so close.
Re: “It's The Future”
#47"-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…
saw done properly once, with good separation of services etc, but it still required a truckload of commitment to make it work, because one thing is interface changes when the code just don't work when you merge, another is figuring out the publish and restart order of each service when you have to add an operation so you don't have to knock out the whole system at every upgrade.
I don't really like that model applied to everything, but eh now you are kind of forced in a hybrid approach - say, your macro vertical plus whatever payment gateway service, intercom or equivalent customer interaction services, metrics services, retargeting services, there are a lot of heterogeneous pieces going into your average startup.
but back on topic, what Docker really needs now is a whack on the head of whoever thought swarms/overlays and a proper, sane way to handle discovery and fail-over - instead we got a key-value service deployment to handle, which cannot be in docker and highly available unless you like infinite recursion.
Re: “It's The Future”
#48Reminds me of https://www.youtube.com/watch?v=b2F-DItXtZs
Re: “It's The Future”
#49show me an easy way to push a rails application to aws (with docker) that uses RDS ? is there ANY way i can spin up a server, add the ssh keys to some configuration file somewhere and just "docker-magic push" and have my rails application running ? or do "docker-magic bundle exec db:migrate" and have that command run on the server. Or push a Procfile with worker definitions and have the PAAS automatically pick it up,…
Deis will do exactly that.
Re: “It's The Future”
#50"-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?
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 during testing of other systems.
I've also work at a company where we had to run 12 different systems in their own VMs to have a full development environment. That sucked beyond belief.
The idea of micro-service are is enticing, but if you need to spin up and configure more than a couple to do your work, it starts hurting productivity.