I've been super honoured to give an ignite talk during DevOps Days Vancouver 2014. Ignite talks are intense, as the slides mercilessly fly-by every 15 seconds, and this for 5 minutes sharp (yes, that's just 20 slides!).
In this talk, I tried to present some of the lessons we've learned at Unbounce while rebuilding our page serving infrastructure. Our availability target is five-nines (that's an allowance of 6 seconds of downtime per week) so we've put lots of effort into building a stable, self-healing, gracefully-degrading piece of software. We had a few close calls though, hence the lessons learned shared in this talk.
I was initially planning to cover this subject in a 30 minutes talk and had gathered tons of material to go in-depth, so delivering this material in 5 minutes was an interesting challenge! It was good actually, as it forced me to be drastically concise, while trying to preserve interesting content.
If you can put up with my French accent, you can watch the recorded presentation here:
Otherwise, here are the slides:
Saturday, November 15, 2014
Wednesday, November 05, 2014
yopa is (almost) Your Own Personal AWS
If you're using AWS SQS and SNS for more than trivial things, you've probably wished that you could run your queues and topics locally, and be able to peek at the message flows happening in topics subscriptions.
Enter yopa, a local SQS and SNS simulator whose sole purpose in life is to make developers' lives easier! Open sourced by Unbounce and coded in Clojure by yours truly, yopa builds on the solid foundation of ElasticMQ and adds its own SNS implementation.
Granted, yopa only supports SQS and SNS for now so it's light years away from truly being Your Own Personal AWS but, hey, let's start small and see where it goes. And actually, there are already discussions about adding support for some EC2 and S3 APIs features as well.
So if you're using SQS and SNS, please give yopa a try! Pull requests are more than welcome.
PS. Oh, there's also a Docker image available...
Enter yopa, a local SQS and SNS simulator whose sole purpose in life is to make developers' lives easier! Open sourced by Unbounce and coded in Clojure by yours truly, yopa builds on the solid foundation of ElasticMQ and adds its own SNS implementation.
Granted, yopa only supports SQS and SNS for now so it's light years away from truly being Your Own Personal AWS but, hey, let's start small and see where it goes. And actually, there are already discussions about adding support for some EC2 and S3 APIs features as well.
So if you're using SQS and SNS, please give yopa a try! Pull requests are more than welcome.
PS. Oh, there's also a Docker image available...
Saturday, April 05, 2014
I write only about funny animals
The rabbit is out of the hat: I'm indeed working on a new book. It's called "RabbitMQ Essentials" and is published by PackT Publishing. Yes, you're reading right, after Mule, it's now RabbitMQ's turn! Clearly, I'm specializing in writing about animal-named technologies.
Why writing yet another book about RabbitMQ? After all, there are already several very excellent books on the subject out there. I think Ross Mason gave the best answer to this question on Twitter:
Let me further articulate the reasons why I decided to embark on this new book project while the ink on Mule in Action is still wet:
Hopefully you'll enjoy this journey too and will learn a few things while reading RabbitMQ Essentials. You can pre-order your copy right from PackT's website.
Now what could be the next animal I could write about?
Why writing yet another book about RabbitMQ? After all, there are already several very excellent books on the subject out there. I think Ross Mason gave the best answer to this question on Twitter:
Let me further articulate the reasons why I decided to embark on this new book project while the ink on Mule in Action is still wet:
- RabbitMQ is a great piece of open source technology and I think it can use all the coverage it can get. From the get go, RabbitMQ has been built with the idea to make things right: it's a breeze to install and configure. Adding extra plug-ins is a no-brainer. It's enterprise-grade software without the enterprise kludge. Moreover, AMQP is one of the rare messaging protocol that is truly interoperable so it too deserves to be discussed again and again.
- It's 2014 and surprisingly many developers still don't have a good grasp of messaging concepts. Beyond covering RabbitMQ, I'm covering more general principles around building distributed applications that leverage messaging as a decoupling agent. In the book, I'm sharing the love for everything asynchronous!
- I love to write not only code but about coding as well. I'm not an outdoor person by any stretch of imagination, so this new book is a perfect project for the gloomy and wet winter that we get in the Pacific North-West.
Hopefully you'll enjoy this journey too and will learn a few things while reading RabbitMQ Essentials. You can pre-order your copy right from PackT's website.
Now what could be the next animal I could write about?
Saturday, March 01, 2014
Explicit content required
I had this post in gestation for a while but the recent post on SmartBear's blog ("Please stop saying Java sucks") decided it me to finalize and publish it.
I believe that it's a complete fallacy to equate "less code" with "better", this whether one is considering a language or a framework. In that matter (like in many others), I think the Zen of Python provides the correct viewpoint:
I'm inclined to add that not having any code to read at all hinders the capacity to reason about a piece of software, hence reduces the ability to work with it.
One could brush aside this argument and argue that if a programmer knew better language X or framework Y, he or she should now that this or that behaviour would implicitly apply in the considered context. I would then posit that readability trumps knowledge.
Applications tend to last longer than fashionable tools, languages or frameworks. Long after the knowledge of the intimate details of whatever technology has been deemed useless and dumped into oblivion, someone will have to read the code and maintain it. This someone will appreciate to have the capacity to navigate all the aspects of the application by following explicit seams that bind them together.
When everything is implicit, an application code ends up like a novel where important points are pushed to footnotes, but without any reference to these footnotes. In that respect, I find Scala's implicits to be emblematic of a good approach to make code disappear and this because these implicits need to be explicitly used.
Coming back to SmartBear's post, old Java's code signal to noise ratio is the key problem. Things are getting better release after release: noise is decreasing and thus the ratio improves.
And that's the whole point of this post: throwing away the signal with the noise is not the solution. Code needs to be explicit so we can reason about it and so we can evolve it with confidence.
I believe that it's a complete fallacy to equate "less code" with "better", this whether one is considering a language or a framework. In that matter (like in many others), I think the Zen of Python provides the correct viewpoint:
Explicit is better than implicitWhy is this important? Here is a quote from Bob Martin's Clean Code:
The ratio of time spent reading (code) versus writing is well over 10 to 1 ... (therefore) making it easy to read makes it easier to write.
I'm inclined to add that not having any code to read at all hinders the capacity to reason about a piece of software, hence reduces the ability to work with it.
One could brush aside this argument and argue that if a programmer knew better language X or framework Y, he or she should now that this or that behaviour would implicitly apply in the considered context. I would then posit that readability trumps knowledge.
Applications tend to last longer than fashionable tools, languages or frameworks. Long after the knowledge of the intimate details of whatever technology has been deemed useless and dumped into oblivion, someone will have to read the code and maintain it. This someone will appreciate to have the capacity to navigate all the aspects of the application by following explicit seams that bind them together.
When everything is implicit, an application code ends up like a novel where important points are pushed to footnotes, but without any reference to these footnotes. In that respect, I find Scala's implicits to be emblematic of a good approach to make code disappear and this because these implicits need to be explicitly used.
Coming back to SmartBear's post, old Java's code signal to noise ratio is the key problem. Things are getting better release after release: noise is decreasing and thus the ratio improves.
And that's the whole point of this post: throwing away the signal with the noise is not the solution. Code needs to be explicit so we can reason about it and so we can evolve it with confidence.
Labels:
Craftsmanship
Subscribe to:
Posts (Atom)