On the Hailo.com blog Matt Heath has posted a series of articles about their transition from a "monolith" codebase out into a set of microservices for the Hallo app system.

Hailo, like many startups, started small; small enough that our offices were below deck on a boat in central London - the HMS President. Working on a boat as a small focused team, we built out our original apps and APIs using tried and tested technologies, including Java, PHP, MySQL and Redis, all running on Amazon's EC2 platform. [...] After we launched in London, and then Dublin, we expanded from one continent to two, and then three; launching first in North America, and then in Asia. This posed a number of challenges-the main one being locality of customer data.

They describe this customer data problem in a bit more detail with the issue mostly revolving around the geolocation of the user and their information. They talk about "going global" and the steps they took to make the move. In the three parts of the series, they explain the changes they made and why they were effective for their application:

• Starting Small
• A Cloudy Beginning
• Dealing with Complexity

They end the series with some links to other resources that help compliment the subjects mentioned and link to slides from a presentation around the same topic.

In a new post to his blog today Alan Skorkin compares two ways of thinking about developing software - either as a destination or as a journey.

There are two fundamental ways of looking at software development. One is all about the final product and the direct benefits you can get from it. The other is all about the lessons you learn from the process of building the software. I call them software as a destination and software as a journey. Historically speaking and even into the present day, the majority of companies that build any kind of software are 'software as a destination' companies.

He notes that, despite the company's stance on the software that's developed, most developers are more in the "journey" category and want to enjoy what they do and to evolve in their skills as they move through their career. Therein lies some of the problems with the software development industry - companies want the result, developers want what's best for the code and want to see it turn out as well as hoped.

I am not sure if there is any irony to be found in software, but if you direct all your focus towards your goal without paying due attention to the nitty gritty of what you're doing every day, you're likely to not get any useable software out of it. As long as you have a reasonable idea of where you want to end up, you just need to get the details right and the bigger picture will tend to sort itself out. On the other hand, you can have the clearest possible goal in mind, but if you let the details slide, bad things will almost certainly happen.