Many of you have been asking us what we think of AWS finally moving into the cloud management space with OpsWorks. This post answers that.
AWS releasing such a product was inevitable, simply because its customers found cloud management extremely useful, as our growth and that of our competitors can attest to. Not too long ago, Amazon acquired Peritor, a German consulting firm that created “Scalarium”, a cloud management product, which most likely accelerated on their delivery and brought them valuable expertise. So we anticipated that.
What we didn’t anticipate is how closely it resembled its competitors. Their objects have different names of course (stacks instead of farms / deployments, layers instead of roles / ServerTemplates), but the overall architecture is identical. This worried us.
After using it yesterday (when OpsWorks was released), we found it simple and pleasant to use. However it took us less than 10 minutes to explore and use everything, and were left wanting for more. Currently few supported “layers”, limited scaling options, no orchestration capabilities, a so-called “self-healing” that considers hardware health without regards to service availability, no collaborative features, no integrated backup and recovery, the list goes on.
At that point, I must admit we felt relieved.
We don’t doubt that AWS is going to continue to improve on OpsWorks in making it a great way to use Chef, and continue to be inspired by the best of what the industry has created in the past 6 years, but it isn’t the tool a professional tech ops wants to maximize his productivity. Scalr, on the other hand, is still ahead, still open source, still rapidly improving, and saves you from additional cloud provider lock-in.
So with a day behind us, that much more perspective, and after an initial scare, we welcome OpsWorks to the party, confident that if you like OpsWorks, you’ll love Scalr.
If you enjoyed this read - why don't you sign up for email updates?
We'll let you know when we publish new blog posts, we won't spam you.