by Michiel on March 3, 2010
This morning I got out of bed, made myself a bowl of cornflakes with milk and headed over to the kitchen table where my dad always puts down the newspaper I’m subscribed to: NRC Next. It’s a Dutch tabloid-format newspaper with daily news and in-depth articles around recent happenings in the world.
I recently resubscribed to it and I love it: I have redacted important news that fit’s to my size of wanting to read a newspaper. I just HATE folding around a large newspaper all the time. I want to have a portable newspaper that I can take with me, easily put in my bag and that falls on my doormat every day. Every night when I read the last less important articles in NRC Next, I’m already waiting for the new issue so I can enjoy another new newspaper-reading day.
Continue reading this post…
by Michiel on February 6, 2010
I just wanted to share with you this presentation I created yesterday to communicate to other people and ourselves on how we use Scrum in Firmhouse. This is a first set of tools I’m creating for ourselves to get going with Scrum to create our products. But it can be a good piece of information for you too. The slides are great to keep as a reference on what kind of meetings you are going to have and what you need to discuss in them.
Expect more detailed Scrum and Agile Development stuff in the near future. We’re getting to an awesome workflow here. In the mean time, read 37signals excellent post about how they are going to approach development of new features in their products.
Here are the slides via SlideShare embed:
by Michiel on January 14, 2010
So I thought I’d give you an update on Qloudwatch. Qloudwatch is going to be the easy-to-use web service that allows you to get insights on your Amazon Web Services cloud usage, group your instances into project and set budgets and warnings for AWS instance costs.
We’ve been working really hard the past few weeks to get ready for a first public release. Bob is busy thinking about an honest and functional business model and researching our terms of service and I’m crunching feature development, tweaking, adding even better security.
What we’re currently looking at releasing in our first launch is the following:
- Create projects and give other people access so you can collaborate on a cloud project. Multiple users with different AWS accounts can be added to a project so you can share costs and get a good overview what your application or cloud team is using, spanning possibly multiple AWS account.
- Adding instances to project by accessing the AWS API with your AWS credentials. Yes, we do ask you to enter them into your account for now. Because of this, we’ve implemented SSL security and encryption into our database. Even in our demo period you can test right now at http://qloudwatch.com
- Give you total and monthly cost estimates based on the running hours of the instances in a project.
- A personal dashboard where you can get insights in the instances your personal AWS account is running.
We’re going to rapidly develop more statistics and are going to build in ways to collect better usage data from your instances if you choose to. If you want to influence our priorities, please give us some feedback of what statistics and overviews you would like to see first.
Here are some more sneak preview screenshots:
by Michiel on January 4, 2010
Amazon Web Services (AWS) is great and we use it as our #1 hosting infrastructure at Firmhouse. We still have some “old” traditional virtual servers laying around on some (also great) servers but we are slowly moving away from them to be totally scalable in a cloud environment.
There are however, one few problems with AWS if you’re hosting multiple websites or web applications on multiple instances for a variation of different clients and internal projects: you can’t keep track of costs and usage statistics in a categorized or budgetized manner.
Because we want to bill our clients what they are using from us (we do their managed hosting) and not give them some lame server package that is overpriced because of the overhead (100G they won’t be using) anyways, we want to give them an honest picture of what they are using and what virtual instances we have installed for them.
Amazon just gives you a credit card bill at the end of the month, which makes it very hard to split all costs and usage into projects or budgets.
Also, Amazon bills you on one credit card but if you have multiple people working on one project with several AWS accounts, there is currently no way of getting some insights in what instances the members of a tream are launching and how much they cost all combined. All you get is $-signs on the credit card bills and the i-instance id’s in your management console(s).
And, budgets would really come in handy when you have a web application or piece of software that automatically scales itself on EC2 and launches instances by itself. Budgets shouldn’t mean terminating or stopping instances if the costs rise above a certain treshold but it would certainly come in handy if you would get a warning e-mail telling you the costs for this weeks where really of the charts so you could act accordingly and maybe re-thing your pricing strategy or make another business-wise decision.
BTW, I should use another word for “budget”. I hate that word because usually involves guessing and the only thing you can guess is that your app shoud be scalable. But my usage of “budget” it should clarify my point. If you have another word, let me know 
So, having that said: *drumroll*
We’re Introducting Qloudwatch
We at Firmhouse have the need for solutions to these problems and we see these problems pop up in forums and mailing lists about AWS on other places we decided to get sweating and create a web app for this: Qloudwatch. We have a basic version up and running, so if you would like to try it please contact me at michiel@firmhouse.nl. The basic app currently has the following functionality:
- Create projects in which you can add instances recognized by the API in your AWS account.
- See the total cost of the project until “now” or view a history of the costs by month.
- Add billable and non-billable instances so you can for example bill all production instances to your clients and not bill your test instances.
- Invite other Qloudwatch users to a project so they can also add instances that can be set billable or non-billable so you can “share” statistics and costs on your instances.
- Get an automatic e-mail notification if you have running instances in your AWS account that you haven’t added to a project yet so you will never forget to categorize that one test hour you ran at 4 AM in the morning when your caffeine withdrawal started to kick in.
We would LOVE to know what you think: wether you disagree, wether you agree, what features you would like to see, if you would like to use the app for free, if you would like to swipe your card for it or if you have any other questions about our work on AWS. Let us know!
Here are some sneak preview screenshots:
by Michiel on January 2, 2010
At Firmhouse, we are working on a new web service and we’re releasing an in-development demo to everyone who is interested. Normally, in demo apps security is less the case and there is always some disclaimer that says you shouldn’t use real production data like passwords and API keys. In my opinion, this sucks because you allways want to use your real-life data to test a demo and see if it’s useful for you specifically. That’s why, the best way to have some security in your demo app is by using a self-signed SSL certificate to secure passwords and other sensitive account information your demo users will be adding.
For our web app, we use Ruby on Rails running on Phusion Passenger, served by Nginx.
This blog post will guide you trough the process of adding a self-signed SSL certificate to your Rails app, running on Phusion Passenger and Nginx by following these steps:
- Generating the required SSL key and certificate files for use with nginx.
- Recompiling the nginx server through the passenger-install-nginx-module command.
- Configuring your web app in nginx to redirect non-secure connections to the secure address of the app with https:// and make sure www. will get redirected on both versions as well.
I use a few other blog posts in this article, so I would like to thank the authors for providing the information publicly and freely.
Ok, now let’s start:
Continue reading this post…
