Given that we're building a SaaS that helps our client managing their infrastructure, our team is pretty familiar with leveraging VMs and configuration management tools. We've actually been heavy users of Vagrant and Ansible for the past year, and it's helped us tremendously normalize our development process.
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?
The devo.ps team has been putting quite a few tools to the test over the years when it comes to managing infrastructures. We've developed some ourselves and have adopted others. While the choice to use one over another is not always as clear-cut as we'd like (I'd love to rant about monitoring but will leave that for a later post), we've definitely developed kind of a crush for Ansible in the past 6 months. We went through years of using Puppet, then Chef and more recently Salt Stack, before Ansible gained unanimous adoption among our team.
I'll admit that the devo.ps team is a lazy bunch; we like to forget about things, especially the hard stuff. Dealing with a complex process invariably leads one of us to vent about how "we should automate that stuff". That's what our team does day and night:
Something went awfully wrong, and a rogue process is eating up all of the resources on one of your servers. You have no other choice but to restart it. No big deal, really; this is the age of disposable infrastructure after all. Except when it comes back up, everything starts going awry. Half the stuff supposed to be running is down and it's screwing with the rest of your setup.
We'll be having our usual Hacker News meetup at Abbey Road (45 Yueyang road, near Hengshan Lu) tonight starting 7:00 PM: come and meet entrepreneurs, technologists and likeminded individuals while sharing a couple drinks. The first round of drinks is on Wiredcraft.
As we're getting closer to shipping the first version of devo.ps and we are joined by a few new team members, the team took the time to review the few principles we followed when designing our RESTful JSON API. A lot of these can be found on apigee's blog (a recommended read). Let me give you the gist of it:
The March edition of the Shanghai Open Source meetup will happen at a new location near People Square. There are several well equipped rooms and we're pretty excited to get started with the new format: 1 presentation of 20 to 30 minutes followed by a few workshops.
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.
As usual, we'll be going to the monthly Hacker News meetup thrown by Wiredcraft for all our hacker friends out there in Shanghai. If you're into technology, entrepreneurship or simply looking for an interesting discussion, join us at Abbey Road (45 Yueyang road, near Hengshan Lu) tomorrow starting 7:00 PM. Look for the table with a maneki-neko (the lucky cat Vincent holds so graciously in the picture above).
As we started investing in our new strategy at my previous company, we looked around for solutions to document APIs. It may not be the sexiest part of the project, but documentation is the first step to designing a good API. And I mean first as in "before you even start writing tests" (yes, you should be writing tests first too).
At my previous company, we built Web applications for medium to large organizations, often in the humanitarian and non-profit space, facing original problems revolving around data. Things like building the voting infrastructure for the Southern Sudan Referendum helped us diversify our technical chops. But until a year ago, we were still mostly building regular Web applications; the user requests a page that we build and serve back.
It's been exactly a week since I landed in San Francisco: quite a bit happened in the mere few days I've spent here:
Here's what usually happens: on one side the development team wants to push new features as fast as possible to production, while on the other side, operations are trying to keep things stable. Both teams are evaluated on criteria that are often directly conflicting. The stronger team win one argument... Until the next crisis. And we're not even talking about other teams, they too have conflicting agendas to throw in the mix.