I’ve participated in several Garage48 events in last few years. What I like about them is that it puts the agile approach on steroids. As the event’s name suggests, a small team has only 48 hours to go from an idea on paper to a running app in production. And that brings streamlining to an extreme. One has no choice but to focus on development and avoid everything that even hints at overhead.
When you think about it, though, this approach is not reserved for 48-hour weekend hackathons only. It is applicable to startups as well. It is surprising how long a lean, lightweight dev environment can hold up. It’s only much, much later when the time is suitable for more heavyweight practices.
Obvious Tip #1: Use Platform as a Service (PaaS)
A big part of the early challenge is infrastructure shenanigans. For example, I like Amazon EC2 a lot, but using it in its pure form (e.g. launching a vanilla Amazon Linux AMI) means you have to set everything up yourself. Even though this may not be a huge burden at first (provided you know which software packages are needed and how to set it all up under Linux, as well as configure it, including certificates), it takes time. And if you want to do it the right way, it will take even more.
Given the before-mentioned time constraint, is it really justified? Even in not-so-agile-more-than-48-hour developments, how much effort would you be willing to spend on setup, away from developing your precious, killer app?
That is why it’s a good idea to take a look beyond the simple computing capacity offered by EC2 and see what better options are there for deploying the freshly baked Java app. Even Amazon rather sees the pure EC2 as a component in a toolchain, not a preferred platform to use directly for deploying webapps:
There are many options available, and more to come, but I’m thinking of just seven major players to choose from in the PaaS landscape today: Amazon’s Beanstalk and OpsWorks, Google AppEngine, Jelastic, Cloudbees, CloudFoundry, Heroku and OpenShift.
There is a little bit outdated but otherwise great article from InfoQ about most of them: http://www.infoq.com/articles/paas_comparison
All the offerings provide some way to host and run your app, with a large catalog of add-on services you can enable (for a price): databases, load balancing, analytics, etc. Also, it’s interesting to see that everyone offers both SQL and NoSQL options.
- Amazon offers Elastic Beanstalk, which is a great starting point, especially when you’re already accustomed to the Amazon platform. It is more permissive than several other PaaS offerings, which makes it superb when you are about to invent something more sophisticated than a mobile version of your cute-kittens-browser app. Ready to use database options include Amazon RDS, SimpleDB or S3.
- Amazon’s OpsWorks offers a slightly more complicated solution that is equally more powerful. Depending on what you set out to do, you may be better off starting from there, especially so when your team has cultivated a DevOps culture and has experience with tools like Vagrant and Chef . You can use Amazon’s storage solutions like with Beanstalk, or set one up yourself via Chef recipes.
- Google takes a more restrictive approach with its App Engine. You can only use a subset of the core API, cannot write to file system or use serverSockets (and only paid apps may use sockets). Database options are integrated into GAE, such as App Engine Datastore (schemaless) or Google Cloud SQL. If your app can live within the sandbox requirements, GAE can be a good option and simple to use.
- Jelastic allows you to deploy standard .war files with few restrictions. You get to choose the container (Tomcat & TomEE, Jetty, Glassfish) and the database solution (MySQL, MariaDB, and PostgreSQL as well as NoSQL: MongoDB and CouchDB). An interesting feature here is automatic scaling, which allocates (or frees up) computing resources dynamically, based on application load.
- CloudBees platform revolves around the application lifecycle (from dev to production). Its central component is a hosted Jenkins which builds your code, runs the tests and deploys the app. Database is resolved via CloudBees connectors, which support various SQL offerings as well as NoSQL.
- CloudFoundry takes even more abstract approach and also bakes popular framework support into their offering. Like a good little Pivotal tool, it supports Spring, Grails, Play and Lift frameworks out of the box. Other frameworks could be used via custom build packs. Database options include MySQL, PostgreSQL and MongoDB.
- Heroku offers an interesting approach that is both abstract and low level. It requires you to push your application as a Maven 3 project, in source form, via Git. On the other hand, any Java app can run there. For web apps, this means you have to include the container in the app yourself (such as embedded Jetty). Various databases can be used like in other offerings. Interestingly, it also has out-of-the-box support for AmazonRDS (which you have to set up and administer separately).
- Red Hat’s OpenShift platform wires the application together from modular service components called cartridges. An app must have a web cartridge, such as JBoss-AS or Tomcat, and database options include MySQL and MongoDB cartridges. You can optionally add DB admin cartridges as well (such as PhpMyAdmin or RockMongo). A Jenkins cartridge is also included so you can run the whole lifecycle there.
Obvious Tip #2: Track your progress and keep things lightweight
Even small projects benefit greatly from using an issue tracker. In fact, our recent Developer Productivity Report 2013 even quantified the effect issue trackers and other beneficial tools have on the predictability of software delivery in organizations.
It’s a tremendous help to distill vague(ish) ideas and must-have features into a simple concise list of stuff to do, even if the team consists of 2-4 people sitting in the same room. But you already knew that, right?
The important part is keeping it lightweight. Going full blown Jira with workflows, estimates, 7 issue types and 256 fields is definitely overkill.
That is why I use Trello for small hobby projects all the time. It uses the same simple layout that resembles Jira’s “agile” board (when Greenhopper is installed), but without any of the heavyweight enterpriziness. It’s free of charge, too.
In its simplest form, you could use three columns (todo, doing, done) and prioritize tasks within a column by dragging them up and down. You could also create columns based on the component (frontend, backend, API) if you want, but I personally prefer the Scrum’s classic layout.
I don’t dislike Jira or its extra features. We use it heavily here at ZeroTurnaround. But we are a 7 year old company too with a large number of developers. Using heavyweight tools too soon will only slow you down in the beginning.
Obvious Tip #3: Share code via distributed version control (DVCS)
The easiest way to do this is via modern distributed version control. Joel Spolsky makes a great case for Mercurial (and distributed version control in general) at http://hginit.com/. It applies equally well to Git too. I personally happen to prefer Mercurial. You could set it up in a local server (by simply invoking “hg serve”), but I prefer using it via BitBucket (which also supports Git). It’s free to use for up to five private repositories and hassle free to set up. Do not spend time on setting up your own infrastructure.
Obvious Tip #4: Learn to say NO sometimes and enforce ‘MVP’
MVP stands for minimal-viable-product. Even though this one is less technical than the previous ones, it’s likely more crucial than the others. When launching something new, your only worry should be showing it to the world as soon as possible. The sooner you can achieve that, the sooner you can get the feedback from actual would-be customers and make adjustments. It helps with the motivation, too.
Yes, it means you have to say no and cut features. A lot of features. But it’s better to have a small working app ready and in production than something potentially better somewhere beyond the horizon. There are many blog posts and articles written about this, but I like the quote from LinkedIn’s founder Reid Hoffmann the best: “If you are not embarrassed by the first version of your product, you’ve launched too late.”
Obvious Tip #5: Set up Continuous Integration
When all you have is 48 hours, setting up a Continuous Integration (CI) server can wait, but not long. Otherwise it’s never too early to it up. Simple unit tests in src/test/java only get you so far. What makes a difference is a good suite of integration tests.
But don’t take me word for it: Martin Fowler has written a great essay on the subject. The perceived value can be low at first (when your app is still small and just taking off), but this will change very quickly. Very soon you will find yourself in a situation where you need to test the app with different sets of data and circumstances. Also, don’t forget about the differences in development and production environment. With CI, it’s easy to test everything in a clone of the live environment and even have it deploy the app when all the tests pass.
IMHO, there are two major offerings to choose from: Jenkins (um, or Hudson) and Bamboo. Both are lovely and have great features. While Jenkins is free, you need someplace to run it. Installing in on your laptop works OK when you have a one person team, but you otherwise you need somewhere to host it. If you don’t have a spare machine laying around in the office (do you even have an office?), hosting it in EC2 costs about as much as Bamboo in Atlassian onDemand. Some platforms include Jenkins hosting which removes this pain (Cloudbees, OpenShift). For others it may be simpler to use the hosted Bamboo.
Common sense wins
The biggest asset in getting things done is common sense. Agile methodologies and practices are merely tools to get there, if used properly and in the right time. In the next article we’re going to dive in those seven platforms mentioned and see where each shines the most.