Scaling krodox.com

This post isn’t about the Krodox Web Applications – it’s about Krodox.com, our “content site” – the place where we market our services & ecosystem, publish help and other content, recruit new Krodoxs, and more. Ultimately, it is the place where we tell our story to the world.

When people think about web scalability, they often think about requests, servers, and load balancers. We use (and love) Elastic Beanstalk, so this isn’t a problem for us. The real issue is people: as Krodox has grown, the challenge is creating a system where many people from different teams (copywriters, marketers, developers, etc) can contribute to the various parts of our site.

Every team that reaches a certain size has this problem, and it is a much harder scaling challenge than adding servers. Teams that overcome it have great websites – where content is updated and the story evolves effortlessly with the team.

At Krodox, we’ve figured out a way to rapidly deploy changes to our content site. Non-technical teammates can jump right in and see their updates realtime, without bottlenecks, and without requests to developers. Everything we do is version controlled with Git – even copy changes. Virtually every team is contributing in some way to the site every week, and we do it all without a dedicated web developer. We’re saving so much time that we can write blog posts about it.

Here is how we do it:

Everyone learns Markdown; all content is in Markdown

Markdown is the minimum required skill to contribute to Krodox.com. You don’t have to know code. Luckily, if you can write, you can write Markdown. Everyone at Krodox reads this Daring Fireball article to get familiar with the conventions. If you need to use an HTML snippet, such as a video embed code, Markdown parses it without a problem.

Every page on our site is based on a Markdown file: every landing page, every article, every job listing, every product, and every showcase app. Literally every word on our site is in a Markdown file where anyone on our team can edit it.

We make our changes in Github

Our content (pages, articles, documentation, etc) is organized in private Github repositories that every team (at Krodox) has access to. For instance, Copywriters have access to the repository where the articles are; Marketers to the repository where the landing pages are; HR team to where the job listings are, etc, etc.

They create and edit the Markdown files directly through Github web interface. Technical teammates can clone the repo locally and use whatever tool stack or IDE they choose.

Non-technical teammates don’t need to know Git. In fact, they don’t need technical skills of any kind. They just need to know that “commit” basically equals “save” and that they can’t break anything because it’s all version controlled.

Why is this such a big deal? The vast majority of copywriters just need a Github account and a web browser. We give access to our content by sending a Github "invitation" to our repository. That' set!

At Krodox.com, no one has access to a "backend". Actually, there is no such a thing. We dont have to deal with permissions, passwords, and all the headaches and resources that might imply. We keep it simple!

Even more, the Github editor renders the Markdown after commiting changes – so our team members can see that their markdown styling worked. But even better than that, we’ve found a way to show our team members their changes immediately on the website itself.

Here’s how…

Our Testing server is realtime

Using Github’s Post-Receive Hooks, every time anyone commits, Github pings our testing server to pull and deploy a fresh version of the content. The person who added content can immediately see their change (in real time) on our testing server – and share it with the team if it requires feedback.

Before deploying, we test and approve

Before we pushed any change to our production server, a Chief Editor does the corresponding QA (Quality assurance) in the testing server to make sure that links resolve, resources (photos, videos, tweets, links) load, and there are no errors.

Deploying to Krodox.com

Our Chief Editor is the responsible for approving and committing to Production by merging the changes with the "approved" branch. Github instantaneously pings our production server to pull and deploy a fresh version of the content in that branch.

So, the content makes it all the way to our content site without any interaction of any of our developers, and more importantly... Secure!

The work in Github is synced to our online collaboration app (Basecamp)

Not surprisingly, we use Basecamp to track all the work we’re doing across the company. Anytime anyone saves / commits , they add the relevant basecamp task id #task_id to the commit message; this comments on the associated story in Basecamp with a link to the commit in Github, showing the whole team that the work has been done.

What about Media (Photos, Videos, etc)

Well... Thats a whole other beast... We'll be back about it.