Recently Mike Amundsen posted a list of the tools he uses for developing cloud applications. He also asked for others to provide their lists. So here goes:<section>
The one true development environment that all others aspire to be like when they grow up.
Mike has been using Cloud9 and really seems to like it. I have had my eye on the browser based dev environments for a while. Maybe it is time to to give them a go.</section> <section>
RoR is still the best way to build web applications ever created.
(I know node.js is getting a lot of buzz these days, but it optimizes for the wrong thing. It optimizes IO performance, but what is really important is developer productivity. Except for a few very niche situations runtime performance is way less important that getting stuff done.)</section> <section>
For small to medium size data sets CouchDB is the best option for cloud based data storage. It is easy to use, there are good libraries for it, and you can setup it up to be very reliable even when running on unreliable virtual instances.
We have been using Cloudant for a while now. It has been reliable, but it is a bit slow. However, that problem is easily overcome with the violent application of caching. You communicate with CouchDB over HTTP so it is very easy to setup caching.</section> <section>
We are using Git without the hub. It is great tool even without all the fancy gui collaboration support. If you are using any SCM tool that is not a DVCS you are missing out. Go switch to Git (or Mercurial) right now.</section> <section>
Working in the cloud really drives home the impermanence of all things. Machine disappear, or lock up, APIs become unresponsive, etc. Being able to build a replacement instances automatically, and quickly, is vital.</section> <section>
Fog is an adapter, in ruby, for the various cloud providers which gives them a similar interface. This is invaluable if you plan on working with more than one cloud provider.</section> <section>
The product we are developing is an open platform-as-a-service so we use the IaaS offerings to provide the compute power we need.</section> <section>
Conclusion
My tool chain for developing in the cloud is pretty similar to the one i used for developing apps for dedicated hardware. The biggest change is definitely the change to a document store. Traditionally relational databases just don’t work in the dodgy environment of the cloud yet. I expect that will change over time, but for now the ease of replication with document stores make them compelling for clusters of unreliable virtual machines.</section>
… thinking long-term is a high status thing to do because smart people are better at it. Thus, being a long-term thinker signals that you are smart. However, as we might expect with status competitions this is overdone.
When we started developing CloudSwing we decided to develop CloudSwing as if quality actually matters. By quality i don’t just mean that the code functions as designed. High quality products also meet the needs of the business and customers.
In the past there has been a sense of disconnection between the business, QA and development parts of our team. (An all too common situation in my experience.) If quality actually matters there must be good connections between all the stakeholders and quality must be considered at every step of the process. We don’t have a product manager, or a large QA team2. That means that if quality is going to be considered at every step it is going to be because the developers are doing it, there is no one else at many of the steps.
Our solution is to acknowledge developer responsibility for all aspects of feature development. That unification reduces the chances of things being overlooked. It does change the workload of developers, though. Now developers must:
elicit requirements from all stakeholders
write testable acceptance criteria
develop automated acceptance tests
implement the feature
verify all acceptance (included pre-existing ones) pass
verify that the feature, as implemented, matches the desire of the champion
deploy changes to production
This has lightened the load on QA to the point that our one QA resource can keep up with four developers. QA still has a lot of responsibility:
verify the acceptance criteria make sense
verify the acceptance criteria is testable
verify the acceptance criteria cover all important variations of the feature
verify the acceptance tests cover all important variations
refine acceptance tests
verify all tests pass in a production like environment
perform visual inspections in various browsers
accept features into the production branch<figcaption>
We have been using this version3 of the process for a while now. I think is has worked really well. In fact, during our last retrospective our QA guy stated that he thought our quality management processes belonged in the “Good things” category. I think that is a first i have ever heard a QA person be so positive about processes.
Only time will tell if this approach produces significantly better results but I am very optimistic. So far it seems to have created a world of difference.
In practice the process is more fluid that it looks in the diagram. Developers are empowered to do what it takes to get the job done. Including not following the process. However, not following the process requires an affirmative defense when QA asks “WTF?”.
</p> <figcaption>CloudSwing</figcaption> </a>If the idea of deploying your applications on commercially supported open source stacks with built in application monitoring and cost management sounds appealing you should check it out.I learned an immense amount, even though i have been using cloud computing for years. The view from inside is a bit different than it is from the outside. It has been a fun ride, and there is a lot more to come. (Including some more posts here about some interesting things we learned.)
<figcaption>CloudSwing</figcaption>