Motwin at QConLondon 2015 – Day #1

It was fun and interesting icon_smile QConLondon 2015 in a few figures:

  • 2 days of tutorials
  • 3 days of conferences
  • 3 keynotes (1 per day)
  • around 102 speakers
  • 96 conferences
  • around 2000 (?) attendees

So, quite a big conference… Add to this a nice place (the Queen Elizabeth II Conference Center near BigBen and Westminster Abbey), good food (yep, it’s important for the French…), famous speakers… and for the most part, sunny days. Each conference day was divided into tracks you can find at  Every morning, before the keynote, every responsible of the track was trying to convince the public to attend their track. Some with passion, some with British humor, … On the whole, I’ve found this to be a nice idea. Then, a keynote opened the day before any conferences or open-spaces. Open-spaces were places where goodwills could discuss, debate and share their own experience about the theme of the track. Another nice idea.

Day #1

To the Moon by Russ Olsen

The first conference day was opened with « To the Moon » by Russ Olsen. Russ Olsen is the author of the « Eloquent Ruby ». And Russ did literally bring us to the Moon indeed. He started his story during the Cold War in 1962, when Kennedy decided to send men on the Moon: « We are taking a person, sending to the Moon and returning him safely to the earth by the end of the decade. »… ok, not for the glory of the humanity, but for political reasons (ah, Cold War!)…  Russ told us how one political decision became a headache for lots of engineers,  and how those engineers tried to make the problem simpler by sending (i.e. crashing) empty spacecrafts to the Moon: it was the Ranger project, which were the « baby » steps before the Apollo project was born.  The second part of the Russ’ story started on July 20, 1969 when a boy of ten years old (himself) was starring at the TV set as many and many other people waiting for two men to land on the Moon. Russ brought us into Space with the three astronauts that were approaching the Moon at high speed as well as problems. First, no more radio for an unknown reason, then a cryptic « 1202 » computer error (the ancestor of the Windows blue screen ;)) and then a navigation issue. Russ described with passion how the NASA team on Earth and the astronauts kept a cool head and manages finally to land on the Moon. In essence, what can be learned from this story is:

  • little things can kill you (the navigation issue was caused by a little switch that was not turned in the right position)
  • trust your team at critical situations: whenever things go wrong, team-mates need to trust each other. That what have done the NASA team when they lost communication with the astronauts: the team trust them
  • if you do something sweet and hard unexpected side effects happen
  • leadership vs hero: when you are doing something technically sweet and hard, you make people believe in this wave
  • impossible is possible
  • a Kennedy quote « We choose the Moon not because it is easy but because it’s hard… »

That was really an inspiring keynote and Russ received a long and vibrant round of applause. I recommend to see the video of this keynote if you have the occasion. By the way, the term « software engineering » has been created right after and the engineer, who crafted the computer software able to « bypass » low priority tasks and prevented an abort of the mission, was a girl: Margaret Hamilton.

Evolutionary Architecture and micro-services: a match enabled by continuous delivery – by Rebecca Parsons

Rebecca Parson is a « big » authority in matter of architecture: CTO of Thoughtwork, she has a long past in architecture expertise. If one word was omni-present in this conference, it was undoubtedly « micro-services »: few were the talks that did not mention this word (maybe less than the fingers of a hand). « micro-services » was THE word, THE HYPE word of QConLondon (and private jokes come if you didn’t mention it in your talk) (note: Docker was another hype word, but that’s another story…). « micro-services » were everywhere, and sometimes, I was wondering whether some talks mentioned it only to be in the center of THE fun thing to do…

The talk was quite a big picture on « micro-services ». Rebecca started by remembering all the things about SOA:

  • the promises of SOA
    • components reuse
    • database integration
    • etc.
  • the positive aspects of SOA
    • split monoliths into independent services
    • integration over coupling
    • acceptance of the eventual consistency
  • and at last what messed up SOA
    • monster services
    • complex business logic owned by the orchestration
    • difficulty to change and to test

She continued with the assets of micro-services:

  • the need to focus on the business capability
  • small and sustainable units
  • independence of deployment (for each micro-service, you can choose the right techno for the right purpose)
  • smart end points and dumb pipes (as opposed to SOA orchestration).

All of this implies:

  • the granularity of a micro-service is crucial since there is now a tension between the cohesion and the low coupling
  • the independence of the micro-services from the ones to each others makes the micro-services scalable independently.
  • the monitoring of the micro-services is crucial
  • the design of micro-services must explicitly be thought with failures in mind
  • the infrastructure and the deployment of micro-services must be automated

To face these implications, Rebecca mentioned some hints:

  • bounded contexts (see Domain Design Driven) to address business capabilities (and not technological capabilities). To do so, you need to think as from the consumption perspective: what the consumers want NOW?
  • data architecture must be handle with care
  • be a tolerant reader: what do I really need to read when I call a service? What about the other data: don’t care, just ignore them.

Rebecca also warned us to be prepared to split a micro-service into several or to combine several micro-services into one: you can’t get the truth at the first time… Micro-services can be the foundation of an Evolutionary Architecture. In such an architecture, changes are first class citizen. We must be prepared to changes in order to recompose services in some way we haven’t foreseen before. To do so, we need to:

  • focus on “evolvability”
  • be a tolerant reader
  • embrace the Conway’s law (another expression you could had to your buzzword bingo list):

    Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure. 

  • take care about appropriate coupling
  • define contracts
  • be able to test intensively

The multiplication of the micro-services means also:

  • more deployments
  • more monitoring
  • more failures too

As matter of fact, if you don’t have « a strong DevOps culture + an automation rigor » then you go to the CRASH.

The last question was: how to start? Rebecca stated that there is no silver bullet. One can try to add new features as micro-services to your monolith application.

Micro services made easy with Spring Cloud and Netflix OSS – by Dave Syer

The room was crowded but that was not my favorite talk. One is already available on InfoQ and this one was quite the same as. One interesting lecture has been mentioned about micro-services:
After a short presentation of Pivotal (SpringSource, VMWare, blabla and now Pivotal) and a presentation of what SpringBoot is, Dave Sayer talked about SpringCloud, more precisely about the Netflix tools that SpringBoot offers to easily wrap. Honestly, you can find the same information on the SpringCloud site. One thing to note was the fact SpringCloud team develops a quick project starter as there already is for « standard » SpringBoot ( I was quite happy about that and Dave shows us how to get a SpringBoot project with the Netflix Config Server working and running in a few minutes. All was generated thanks to this site: Great thing: it will help us to discover more easily how to make Netflix stuff work together. I think I will try to play with the SpringBoot Netflix Config Server with a local git and some Eureka servers. A few hours later, I read tweets I receive the day before and the was mentioned. Too bad for me…
Dave ended with a sample demonstrating the use of SpringSession + Redis + SpringSecurity with a single annotation @EnableRedisHttpSession. But it was too short to have the time to grasp the demo in the whole…

Refactoring to Functional – by Hadi Hariri

Hadi complained that every time he is talking, it is after lunch when people are digesting, but as usual, he knows how to keep peoples’ attention. The first part of the talk presented how to transform a « for » loop on a list of elements  into a more functional style with different operations (map, flatMap, filter, fold, etc.). The code is reduced, thus, more readable and more expressive. If you know a bit about Scala or Java 8 Streams, there was nothing new to learn.
So, for me, the second part was more interesting. Hadi explained how some OO patterns can be turned into a functional style. « Use functions to pass behavior » was the motto and cooking recipe. Thus, it demonstrated how to rewrite a bunch of classes that implement the template patterns into one class. Again, thanks to the “use functions to pass behavior” principle. The Strategy pattern is also a good candidate for being rewritten in a functionalish style: the strategy has only to be encapsulated as function. Elegant code and less code: cool ! And as matter of fact, “Patterns of yesterday can become anti-patterns of today” (which is more or less a citation I don’t remember the author). Another use-case of Hadi is when the dependencies of a class grow. Firstly, it may mean that the code smells bad. Secondly, it may mean that we have lots of dependencies just because we need to use dependencies behavior.  As in a functional style, you can “use functions to pass behavior”, … you get the trick, now. In functional programming, as a function can return a function, you can get a pipeline of functions call. That can also contribute to making the code shorted and more readable. Hadi just warned a too long pipeline can be in turn unreadable… so, be wise and encapsulate behaviors in meaningful named functions to avoid a too big chain of functions. Finally, three suggested readings by Hadi:

  • The little schemer, by Daniel P. Friedman
  • Learn you a Haskell for Great Good! by Miran Lipova?a
  • Functional Programming in Java: Harnessing the Power Of Java 8 Lambda Expressions by Venkat Subramaniam

By the way, the language used by Hadi, was Kotlin (company self promotion did not damage, I guess :)) and it looks quite cool. Maybe, I’ll give it a try.

A Taster of Random Decision Forests on Apache Spark – by Sean Owen

I was interested into discovering Spark but it was the wrong session for me. If you hadn’t some strong background knowledge in Machine Learning, it was not the session for you (and thus not for me). Basically, what I understood is that in Machine Learning, decision trees give decisions while linear models give coefficients. Decisions tree can be seen as a tree of “if / else”. Combining decisions trees gives decision forests that can enhance the accuracy of the machine learning request. Spark has libraries that nicely helps to model decision trees. Hum, that’s almost all I understood… but if you’re a big data expert, you may be interested in viewing the talk video.

Implementing Continuous Delivery: Adjusting your architecture – by Rachel Laycock

Another talk about micro-services architecture. For Rachel, Architecture is “stuff that is hard to change” and there is always a tension between coupling and cohesion that you have to pay attention to. Sometimes, you may achieve a compromise: more coupling, less cohesion or less coupling, more cohesion. And three things of a good architecture that are fundamental for her:

  • keep things small: small things can be rewritten easily and thus are easier to maintain
  • evolve your architecture: be prepared for the unknown (which is also an argument of Rebecca Parsons)
  • the Conway’s law applied: siloed teams give siloed applications architecture. As matter of fact, Rachel encouraged to have cross-functionnal teams (dev, ops) committed to deliver capabilities: she called them “feature teams”. I must admit that I didn’t know this law before attending this conference but it became clear to me that “Conway’s law” was most recurrent term in the talks after “micro-services” icon_smile

Lots of arguments of the talk were the same as Rebecca Parsons, so I offer a few additionnal tips:

  • as your system gets more distributed, prefer BASE (Basic, Availability, Soft-state, Eventual-consistency) to ACID (Atomic, Consistent, Isolated, Durable) (see CAP theorem)
  • prefer choregraphy to orchestration: which is the same as Rebecca Parsons’ metaphore of “smart endpoints and dumb pipes”

Practical steps to secure your APIs for mobile – by Mark O’Neill

Mark started his talk by presenting security issues for APIs:

  • data harvesting
  • insecure plain HTTP request: SSL should be considered as the basic level of security.
  • API key sniffing: is all the more easier that often the security keys are passed in the url as a query parameter or a header. Mark mentioned the Amazon way to secure the API: a HMAC for signing each request and an access key ID to identify the client. Good point for us! That’s what we do with

Mark referred to  an interesting blog post ( and illustrated his talk with known security attacks (hacks of some company or government sites, etc.).
The second part of the talk was dedicated to API management portal (it was a sponsor talk).

Software development tales from the Continent – by Enyo Kumahor

This was the last talk of the day for all the sessions, and pretty interesting one. Enyo told us how software development can be challenging in Africa which is the only “Mobile only continent”, and it doesn’t miss challenges! In healthcare, education, agriculture,… She presented some projects that circumvented the poor infrastructure constraints as well as some cultural constraints to deliver high valuable services: a payment solution with SMS, an offline browser that can update the content of your page when you get back network, a barecode solution to manage patients folders and a community marketplace that helps people to fix appliances, recycle them, exchange or sells stuff and services. Lots of challenges and lots of ingenuity to circumvent lots of constraints! If any of you are interested in facing such challenges you can tweet her (@enyok).

Share it :

Give it a try!

Try streaming any JSON REST API within 30 sec
curl -v "[]&param2=[]"

Leave a Reply

Your email address will not be published. Required fields are marked *