はてなブックマーク

Vincent Viallet on August 26, 2014 I gave a short (last minute) presentation at the Shanghai Docker meetup last Saturday at VMware's office. We talked about how experience using Docker while building devo.ps and gave some basic advices as to what to do (and what not to). Why we chose Docker? Separation of concerns and Scalability: devo.ps is a complex system. We want to isolate features as micro-s

And now let me geek a tad more about the main features... Native clusterization Node v0.6 introduced the cluster feature, allowing you to share a socket across multiple networked Node applications. Problem is, it doesn't work out of the box and requires some tweaking to handle master and children processes. PM2 handles this natively, without any extra code: PM2 itself will act as the master proces

While devo.ps is fast approaching a public release, the team has been dealing with an increasingly complex infrastructure. We more recently faced an interesting issue; how do you share configuration across a cluster of servers? More importantly, how do you do so in a resilient, secure, easily deployable and speedy fashion? That’s what got us to evaluate some of the options available out there; Zoo

Dealing with servers doesn't have to suck Build and automate your own servers, deploy your apps on it in a few minutes Try it for free Deploy your own machines on your preferred cloud PaaS can be a great way to get something up and running quickly, but you're effectively locked out of your infrastructure. With devo.ps, you can use your own account on Amazon EC2, Rackspace, Digital Ocean or Linode

It’s no secret that the devo.ps team has a crush on Javascript; node.js in the backend, AngularJS for our clients, there isn’t much of our stack that isn’t at least in part built with it. Our approach of building static clients and RESTful JSON APIs means that we run a lot of node.js and I must admit that, despite all of it awesomeness, node.js still is a bit of a headache when it comes to running

Back when our team was dealing with operations, optimization and scalability at our previous company, we had our fair share of troubleshooting poorly performing applications and infrastructures of various sizes, often large (think CNN or the World Bank). Tight deadlines, “exotic” technical stacks and lack of information usually made for memorable experiences. The cause of the issues was rarely obv