Impressions from the Cloud Foundry Summit

As last year we attended the this year’s Cloud Foundry summit taking place in San Francisco (9-11 June) to meet and talk to a number of Cloud Foundry enthusiasts. One of the major topics at the summit was the extended Cloud Foundry foundation which now owns 34 companies and anynines is proud to be one of them.

With joining the foundation and the trip to San Francisco we wanted to participate to the Cloud Foundry movement which wins a lot of momentum at the moment. And after 1,5 years of experience anynines had with Cloud Foundry it was also time to give something back to them.

Cloud Foundry Summit

The Roadmap

The current Roadmap was presented by James Bayer (@jambay) at the summit and contains some exciting features (unordered):

  • API to control an A/B routing to applications
  • Zero-downtime and Near-Zero downtime deploy
  • Dockerfile push
  • .NET support
  • Customizable App Healthchecks
  • SSH access to App Containers
  • Lifecycle hooks for source code management systems (SCM)

Hence the development of Cloud Foundry is agile the roadmap is as well and features and also prioritization can be changed. Furthermore James mentioned that the backlog is open and proposals are welcome!

The slides for James roadmap track can be found here.

Interesting Projects

At the moment there is an ongoing effort to rewrite a major Cloud Foundry component – The Droplet Execution Agent (DEA) which is responsible for running your application instances. The rewritten component also comes with a new name (DIEGO).

Onsi Fakhouri (@onsijoe) explained the reasons for the rewrite in an excellent talk, some of them are:

  • The DEA is domain specific, the only entity it handles are applications. DIEGO talks about “Tasks” and “Long Running Process”
  • It was hard to add and maintain new features
  • Simpler platform porting (The DEA was coupled to Linux)
  • DIEGO is written in go and utilize go’s strong concurrency support and promotes a better developer discipline.

To get an idea of the state of DIEGO you can have a look at the dedicated backlog.

Another project that was presented and and cannot be ignored in this blogpost was Decker. Decker was written and presented by Colin Humphreys (@hatofmonkeys) and provides way to deploy applications along with a docker image.

The Architecture style for the Cloud

Another very interesting talk held by Matt Stine (@mstine) was named “Cloud Foundry and Microservices: A Mutualistic Symbiotic Relationship”. The development using the microservices approach prevents a monolithic application architecture and so promotes well known tactics in computer science. Due to the single responsibility of each microservice the backing datastore (MongoDB, MySql, …) for each microservice can be picked by the specific needs and the development, maintenance and deployment of such a system is much painless.

In combination with Cloud Foundry microservices evolve a huge power since this architecture enables an efficient scaling of the applications.

The Cloud Foundry DACH user group

Motivated by the atmosphere of the summit a Cloud Foundry user group was founded in Europe. We don’t have to cross the Atlantic now to get in touch with Cloud Foundry enthusiasts.

Getting Git Right!

Last week brought Atlassian and their Getting Git Right event to Vienna (or Schönbrunn Palace Conference Center to be precise). By means of introduction Sven Peters talked about how Atlassian organizes a company with 300 developers working distributed, 850 employees in total, building Jira, HipChat, Bitbucket and a vast number of other developer tools.

Sven: “Developing software is a social challenge, Git helps ship software faster and smarter.” Atlassian switched from Subversion to Git 5 years ago. The technical part is one thing – the Jira team alone migrated 11 year’s work, 200+ committers, 21,000 files and 47,228 commits – Sven gives away, but the human side of things is a little trickier. Looking at its customers, Atlassian predicts 63% will have moved to Git by December 2015. That’s good news as Git users release daily to weekly as opposed to monthly, a trait of many a team using Subversion. Additionally, studies see 15% more code reviews when using Git (and their pull request functionality) than with other version control systems.

Happy developers

Nicola Paolucci (Git Evangelist for Atlassian) then took over claiming that Git adaptation makes for happy developers. Git brings speed as it doesn’t break the flow. Plus: it’s written in low level C by the main contributors of Linux and filesystem developers. It gives you the freedom to switch context fast (feature branching) and losing work with Git is very (very) hard. It’s easy to find history commits with git log commands and when all is lost, one can always fall back on reflog (only garbage collected every 90 days). Some nifty git log commands that were fairly new for me:

git log --after
git log --before
git log --diff-filter=D --summary

… and:

git branch --no-merged
git branch --merged

… to verify if I indeed merged a certain branch. Nicola also explained Rebase as ‘a way to replay commits, one by one, on top of a branch’. An --interactive rebase is that plus deciding ‘interactively’ what to do with each commit (pick; squash; rework; fixup, etc).

Effective workflow

Sven Peters went on to talk about how Git introduces an ‘effective workflow and improves code quality’. Demo-ing a brand new feature in Jira that allows you to create a branch straight from whatever issue, Sven emphasizes the pain tool switching used to be. Going over the various workflows within Atlassian teams, Sven highlights the merge strategies between branches (either hotfix or feature) and how Atlassian Stash (a repository manager much like Github) allows you to set automatic merges for your branches. Sven: “Code review meetings tend to be boring and even uncomfortable as your code gets discussed, but they lead to better quality and you learn heaps from how others write code.” Making code reviews part of daily work and doing them asynchronously (read: not in meetings per se) makes the whole thing ‘way less painful’. And Git’s pull requests call for code reviews before a merge, making it a more natural process.

As a last piece of advice Sven recommends to have every line of code connected to a real life problem / issue (in your bug tracker). And he tips checking out for tons of information about Atlassian’s migration and Git in general.

Docker and mutation testing at the Berlin Ruby User Group

We attended the RUG::B (Berlin Ruby User Group) yesterday – as we do regularly. It was full house at co.up (Adalbertstrasse 8) and the program interesting.

Working in a different country

Jan Schulte (@neinasaservice) started off with a convincing case on ‘where Microsoft did a good job to make developing software easier’. With an almost exclusive Ruby audience, that must have been a tough cookie.

Jan got started with .Net in late 2007, was employed mid 2010 as a .Net developer and ‘only’ got started with Ruby in October 2013. He now uses a vast number of tools (Ruby, JRuby, vim, Rake, git, ctags, Mac OS X, Vagrant, Virtualbox, CouchDB, MySQL, Elasticsearch, …) whereas in his .Net days his toolbelt was much smaller with Microsoft Windows [XP, Vista, 7, 8], .Net Framework, C#, Visual, SQL Server, Team Foundation Server, Office and Internet Explorer.

Jan praises Microsoft for having a solution ‘for everything’ with Office, Internet Explorer, Sharepoint, Team Foundation Server and libraries such as the Entity Framework for O/R Mapping – ready for commercial use. Product maintenance not being their strong point. Talking discontinued support for SilverLight Jan complains that does not only mean no more bugs will be fixed. You cannot fix bugs yourself as it’s not open source software, nor can you add features or even look at the code. (more…)