Skip to end of metadata
Go to start of metadata

Last weekend was busy since we decided to move off of Amazon Web Services EC2 cloud that was hosting our core systems infrastructure and move to Contegix Managed Hosting Services. We've had our Website hosted by Contegix for the past few months, but our larger infrastructure (x7 systems) was on AWS.

AWS was okay - until our needs grew

As a service, AWS was fine in terms of bandwidth and access - no complaints. However, as our efforts, projects and engagement has grown, so too was our fees on AWS - which is part of the snag.

The more time (literally, by minute) you are on AWS systems, the more your business grows in size, the more you pay.

Very quickly, with our team being from US, UK, and AU - and accessing systems almost around the clock, it became UN-cost-advantageous, let alone service UN-advantageous (since there is no service support - you are on your own).

Why we like Contegix


Contegix has become a better solution for us.

Why - well people put a whole lot of argument and discussion on cloud providers but it's really quite simple in our opinion.

With Contegix:

  • you buy the server and/or VM and plenty of diskspace, RAM, and CPU power to serve you needs
  • if you also go with managed hosting, you get 24x7 technical support and monitoring of your systems.
  • you can also get regular "backups" support (daily or weekly).

But if we really need to sum it up:

Working with Contegix is like having a bunch of new guys on your team with great expertise -- overnight, for the same price (or maybe less) than it is on AWS -- where you have to do it all yourself!

Upgrades to latest releases - W00t!

Currently, we have the complete Atlassian Suite installed as our base framework for our cloud-hosted SDLC work environment.

These systems are the backbone to our company, let alone efficiency. AppFusions is a HUGE believer of the full suite for software development lifecycle best practices. Admittedly, we don't use them perfectly yet, but every week we push on them and get better and better, and so for that, we're good with it.

Since we had to migrate our data anyways to Contegix, and our systems will only get bigger, we decided to take advantage and upgrade to latest versions to get latest features. Internally, we now have:

  • Confluence 3.3 (rels'd June 2010) - Latest feature news and video here.
  • JIRA 4.1.2 (rels'd June 2010) - Latest feature news and video here.
  • GreenHopper 5 (rels'd June 2010) - Lastest feature news and video here.
  • FishEye/Crucible 2.3.3 (rels'd May 2010) - Latest feature news and video here.
  • Bamboo 2.6 (rels'd June 2010) - Latest feature news and video here.
  • Crowd 2.0.5 (rels'd July 2010) - Latest feature news and video here.

THIS is a W00t!!!

Collaborate online - no email (in general)

We have a general "no email" rule. I'd say we are about 90% working that way, and very little email communications is needed that is not better served in the Wiki and/or JIRA task.

We started this approach from the get go, so this was our initial habits.Sometimes we break out into 1-1 emails, but really they are rare now.

And if someone breaks out and shouldn't - you get accused of being so "Web 1.0"... Ouch. Slaps you back into the systems fast.

I'm super psyched that our "communicate in the systems" mode has not only taken off, but everyone seems to appreciate it.

SVN now, but evaluating Distributed Version Control System (DVCS)

We use SVN, now, yet we are evaluating Mercurial - seems it might us one step more efficient. Good quote on the topic:

"Mercurial is your smart friend who likes to explain things to you. Git is your genius coworker who sighs and rolls his eyes everytime you ask him a question." -- from thebuild.com

We have team members in the US, UK, and AU, so we need both reliable systems and flexibility.

Mercurial's Distributed architecture

Traditional version control systems such as Subversion are typical client-server architectures with a central server to store the revisions of a project. In contrast, Mercurial is truly distributed, giving each developer a local copy of the entire development history. This way it works independent of network access or a central server. Committing, branching and merging are fast and cheap.

Mercurial seems like it will give us what we need - and we can also take advantage of Atlassian's latest tricks too.

Here's a REALLY AWESOME video/talk on the subject, including great discussion on Git vs. Mercurial.