CraftConf 2015 – Mind Successfully Blown…

So, I’m just heading back home after an awesome few days in Budapest, where I was attending the second edition of Craft Conference. I didn’t realise the conference was happening last year, but when my twitter stream was flooded was interesting looking #CraftConf tweets I had a look at the UStream live stream, and then I realised I was missing out! I managed to watch many of last year’s talks via UStream after the conference, and there was some great speakers and great content. As soon as this year’s Craft Conf was announced I bought a ticket, flights and hotel! Having completed the roller-coaster ride that was CraftConf 2015, I’m happy to say that I wasn’t disappointed…

The good…

A quick look down the list of speakers will give you an insight to the amount of tech rockstars that were in the building: Mary Poppendieck, Dan North, Jessica Kerr, Randy Shoup, Trisha Gee, Michael Nygard, Amber Case, Michael Feathers, Sandro Mancuso….need I go on? If you look back at the list, something may strike you as different compared to the majority of other tech conferences – many of the rockstars present are female.

Having first-hand experience of sitting on tech conference program committees myself, I know that it can be very difficult to organise and encourage talk submissions from a diverse group of speakers, of which gender diversity is just one part. I have to tip my hat to the CraftConf organisers for running a tech conference where 25% of the speakers were female, and the fact that they stated in the keynote that this isn’t enough should be applauded (kudos also to the organisers for offering ‘diversity tickets’ to attendees)

The vast majority of talks lived up the billing, and all four keynote sessions were phenomenal (and I don’t use this word lightly!). I left every keynote buzzing, and judging by the amount of chatter and questions from my fellow attendees, so did most other people. Don’t get me wrong, the keynotes weren’t all ‘ra ra – new tech’ or ‘developers, developers, developers’, they were genuinely thought-provoking and some of them boarder-line offensive (in a good ‘call to action’ kinda way). If you go to as many conferences as I do (including some of the bigger names), you’ll again realise how much effort must have gone into organising and planning this content – a big thanks once again to the organisers.

The ‘standard’ sessions running throughout the day were superb (with only a couple of misses detailed below), and the fact that talks were running from 9am to 7pm allowed me to definitely think I was getting value for my money. My general rule for tech conferences these days, is that if I enjoy over 50% of the talks I attend then I’m happy – CraftConf was in the 80-90% range, which is very rare (only the QCon series manages this usually).

During breaks, or when I did skip a talk session, there was always someone to talk to out in the sponsors area or one of the lounges. A tip of the hat again to many of the speakers, who constantly made themselves available and approachable when milling around the conference (and thanks in particular to Adrian Trenaman, Randy Shoup, Sandro Mancuso, Werner Schuster, Trisha Gee, Isra Kaos, Sven Peters, Simon Brown and James Lewis for some great chats).

I’ve listed some of my favourite talks below (in no particular order), and have included links to InfoQ summaries I have written where available (I will try and write more over the coming weeks).

• Complexity is Outside the Code – Dan North and Jessica Kerr
• Scaling Microservices at Gilt – Adrian Trenaman
• Coding Culture – Sven Peters
• Beyond Features – Dan North
• How to Save Innovation from Itself – Alf Rehn
• The New Software Development Game – Mary Poppendieck
• From Monolith to Microservices – Randy Shoup
• Implementing the Saga Pattern – Catie McCaffrey
• Software Architecture as Code – Simon Brown
• Great Engineering, Failed Product – Marty Cagan

There were also several talks I missed, due to InfoQ commitments or otherwise chatting to interesting people, and I’ll try to watch these back when they are released on UStream:

• The Ethical Developer – Grady Booch (heard great things about this talk throughout the conference!)
• DevOps for Everyone – Katherine Daniels (I follow Katherine on twitter, and she talks about some cool stuff)
• Automating the Modern Datacenter – Mitchel Hashimoto (who doesn’t know what Hashicorp do?)
• Consensus Systems for the Skeptical Architect – Camille Fournier (I again heard great things about this talk via twitter)

The logistics of the conference was also superb. I found the venue easily enough, registration was a breeze, and moving around the venue was straight-forward (after some initial hunting for the ‘tent’ room, which was actually a tent outside! 🙂 ) Lunches and breaks were well spaced apart and nicely timed, and the food and drink was also excellent (including getting fed for the entire day on the Thursday). The queues for the lunch sessions did get a bit disorganised, but after completing the Paris Marathon and nearly getting shoved to the ground several times when stopping for food and water breaks, I’m starting the think that queueing may be a distinctly-British thing… 😉

The (not so) bad…

I had a few minor grumbles, and to be honest these really were minor. A couple of the talks were too high-level or a bit disorganised, but I only left one early. I’m not going to name and shame people here, but if the conference organisers do ask for feedback then I’m happy be honest. What could help for next year is to indicate the intended audience ‘level’ for a talk, but even then I would expect quite deep content for each session at the conference that I believe CraftConf is trying to be.

I did have a couple of interesting chats with people who mentioned that CraftConf isn’t really a conference about software craftsmanship, and I do agree here – at least in terms of how we define mainstream ‘software craftsmanship’ in London and the USA i.e. focusing on clean code, TDD and outside-in development.

However, I strongly believe that CraftConf is a conference about the software development and delivery craftsmanship, and this is exactly what a generalising specialist like me wants. I care deeply about software development from idea inception through to development, delivery and ultimately validation (thinking about project management, leadership and stakeholder management along the way), and CraftConf hit all of these points nicely for me. The only reason I mention this fact, is that if you are a hardcore London or US-based software craftsman, then don’t come to this conference expecting the type of content you may be used to in typical craftsman events.

I’ve seen a couple of tweets and another blog (including the ever-informative Burning Monk) saying that there was a lack of deep-dive language and functional talks, but I think the conference was all the better for it. This is obviously a subjective opinion, and I enjoy learning about languages and functional as much as the next developer, but I tend to target specialist conferences around these subjects when I want to know more (for example, Scala eXchange or SpringOne 2GX).

For me, the balance of talks at CraftConf was superb, and there could be a danger of diluting the content (and the audience) if the organisers try to make the conference ‘all things to all people’. Just my two pence, but the organisers have run two amazing conferences already, and so I say listen to your heart, not necessarily the advice… (and I appreciate the irony of my advice in this context 🙂 )

And yeah, there was no ugly…

If you’ve read the above content, then you’ve probably figured that I think quite highly of CraftConf, and you would be right. I thoroughly enjoyed my time at the conference, and the combination of speakers, topics and attendees was fantastic. I’ll definitely attempt to head back next year, and this time I’ll keep an eye out for the CFP, as I would love to speak here as well.

The primary meme I took away from this year’s CraftConf is that software development is on the verge of breaking out of the traditional IT shackles, in much the same way computing infrastructure has broken-free and is rapidly evolving with the mainstream adoption of cloud. For anyone familiar with the diffusion of innovation graph, lean principled and business-focused software development is getting dangerously close to the late majority, and this really will shake up the industry (especially the traditional software development shops and developers). Alf Rehn’s and Marty Cagan’s keynotes were great example of this

I’m starting to think that the ‘full-stack’ developer of 2018 will not only have the skills that we expect now, but they will also be business savvy, and know enough statistics and data science to appropriately challenge slow moving executives as to what the expected return on investment will be from the latest (HiPPO) instructions from above… People may say this kind of thing happens now, and it does (and it famously has been in companies like Amazon for quite some time), but I believe this will soon happen in the majority of companies. Don’t forget, if you attended CraftConf or are reading this blog you are already part of a self-selecting audience who aspires to learn more and become better – and you’re in the minority within our industry…

The second meme that I picked up on was is that we are working in a golden age of tooling and process. With the emergence of technologies like cloud and containers, and practices like lean, BDD and TDD, there really is no excuse to be building bad software applications. It may take a bit more thought and design, as mentioned by Mary Poppendieck, Dan North and Jessica Kerr, but it is most definitely possible to build large complex systems that can be validated, tested and deployed with relative ease.

In summary, if you are looking for premium-level conference content at a frankly bargain price (with a fantastic location thrown into the mix), you can’t go wrong with CraftConf. I guarantee you’ll leave with more knowledge than when you arrived, and a whole-lot more questions…

Once again, many thanks to all of the organisers, volunteers and speakers – a great job by all concerned!

Advertisement

[Book Review] Building Microservices

Building Microservices – by Sam Newman

TLDR: If you are looking for an introduction to and overview of the current ‘microservice’ landscape and the concepts and thinking behind it, then look no further. I would recommend this book for architect, developer, QA and operations (DevOps)

Microservices are obviously a very hot topic at the moment, and everyone and their dog appears to have an opinion about this concept. Accordingly, writing a book about microservices and keeping everyone happy is going to be a challenge (and probably impossible).

In my opinion Sam has done a great job here and manages to provide key information on a range of relevant microservice issues, such as the motivations for microservices, how to model services, integration with other systems, deployment, testing, monitoring, security and architecting/implementing microservices at scale.

I’ve seen negative comments towards this book on other sites stating that more code examples should be provided, and although I appreciate their motivations, I don’t believe this will be the book to address these issues. In my experience, code contained within a book can quickly become stale, and the diversity of language (and the associated rate of change) that is currently being used to create microservice implementations would make pleasing everyone an impossible challenge. Instead I recommend people interested in code samples have a Google, or visit InfoQ, DZone or Voxxed where there is plenty of microservice implementation code.

In my opinion I will use this book much like I did the original ‘Continuous Delivery’ book by Jez Humble and Dave Farley – the book will provide an excellent high-level overview of the issues (and potential solutions), help me to understand core concepts and how key components and methodologies relate to each other, and also provide inspiration and pointers to further reading.

Much like I didn’t expect to create a full build pipeline implementation simply from reading the ‘Continuous Delivery’ book, I wouldn’t expect to build a complete microservice ecosystem from Sam’s book. However, after reading both books I began the respective tasks with a lot more insight then I originally had, and I made much smarter decisions (and knew what to look for when searching for more knowledge) once I understood the big picture.

As stated above, I would recommend this book for any software delivery role. I’ve personally seen the benefits of a microservice architecture when deployed for the correct use case, but the nature of this architecture creates new challenges whether you are a developer, QA or operations specialist.

(In the interest of full disclosure I did provide feedback on this book as it was being published via the O’Reilly Early Access program. However, I have endevoured to write a review that takes into account only the final published book.)

Microservices Maturity: Dogma or Dogfooding? You Decide…

I’ve received some great feedback after posting my proposal for a microservice maturity/classification model last week, some positive, and some negative.

Some private communications suggested that I may be getting caught up in the marketing hype, and several emails suggested that the microservice architecture really is just classical SOA re-invented. Other emails balanced out these comments by suggesting that microservices present an opportunity to learn and iterate on the mistakes made in the original implementation of SOA, especially now that we are embracing concepts such as domain-driven design, and are applying more consideration to well-defined software architectures.

The only public response I’ve seen so far is by my fellow London-based microservice and Spring framework expert Russ Miles – you can read it on the Simplicity Itself blog. In the interest of full disclosure I do know Russ personally (and have sank a few beers in his company), but that’s not going to influence what I think could be a great discussion about my proposal.

Maturity – not all it’s cracked up to be…

The first comment made by Russ is that the approach of creating a maturity model could be dangerous. I think this is totally fair, and it crossed my mind several times when writing the initial post. So much so, that I added the word ‘classification’ to the title as an alternative to maturity.

If you look at other maturity models, such as the Richardson model for APIs or the Continuous Delivery model, then there is a clear sense of scale, from negative to positive. As Russ quite rightly points out, there is room for interpretation in my model that smaller is better, and I probably should have taken more care to make it clear that I don’t think this is necessarily the case.

In some cases a monolithic, but well-structured, architecture may be the best solution. Russ has also conjectured in a recent talk a Skillsmatter that starting out with building a monolith and then moving to a microservice architecture may be the fastest way to build software. It’s definitely difficult to prove this beyond anecdotal evidence, but my instincts (and experience) tell me this is probably true in certain cases, especially at the current point in time where we have little in the way of modelling or tooling support for building microservices.

In my opinion Russ is quite right to think about how this model could be used negatively, and although my initial intention was to give people a model that they could look at and point to where they think their software is, it could easily be abused. I would be keen to get more feedback on how the model could be shaped or evolved to make my intentions clearer.

Size – it’s what you do with it that counts (but size still matters)

Russ also mentioned that size is a dangerous metric, and I agree. Although lines of code (KLOC) is potentially an arbitrary metric, especially with the variety of languages and frameworks currently available, I still do believe that size is important. Not in the “if you’re application is over a 100 lines, then it’s not a microservice” kind of way (which, in fairness, could have been read from my model), but in the perspective of encapsulation, responsibility and comprehension.

After a bit more thought, a measure of architectural/code cohesion is probably a better metric for this concept. I definitely believe the microservice architecture is rooted in the principle of high cohesion (and loose coupling), but it has been argued by the likes of Simon Brown and Bob Martin that this can be achieved in a monolithic codebase without the need for the creation of separate ‘services’. The key here is modularisation or componentisation.

Accordingly, I do believe that microservices should be ‘small’ in size. For me, this was one of the failings in the original approach with SOA. The lack of skilled modelling and architectural guidance allowed services to morph into ‘all singing and dancing’ applications that offered low cohesion. Hard system boundaries (and potentially expensive coordination and communication) provided by microservices in combination with the notions of ‘bounded contexts’ from domain-driven design (DDD) should make it more obvious to developers when we are straying outside the remit of a component.

Bloated vendor tools that emerged from traditional SOA also allowed developers to ‘cheat’ by circumventing the loose coupling that patterns such as the service bus initially proposed, and monstrosities such as the heavyweight ESB were born. These days we are seeing tooling emerge that encourage reactive systems and event-driven architectures based on small components (such as the very interesting AWS Lambda). With services such as AWS Lambda a codebase size limit is enforced due to the nature of execution. It will be interesting to see what applications emerge from these frameworks.

Putting a size limit on a codebase may not be an exact science, but I believe an upper bound can at least be used as a trigger to discuss if a service is growing beyond it’s original remit (or if the architectural quality is degrading). A lot of agile and architectural techniques I teach clients are not hard-and-fast rules to determine which decisions should be made, but often act as a cue for the team (or organisation) to engage in conversation or a whiteboard session to check that we are still designing high-quality software that models the business correctly.

Dogma or dogfooding – you decide…

The final section of Russ’ post contains the strongest argument, in that dogma over thinking will only lead us down the wrong path “A maturity model can be used in place of thinking; I’d like to avoid that if we can”. Yeah, this sucks, but I agree.

The problem is that my academic background drives me towards the sharing of ideas and proposals among my peers, and I enjoy the ensuing discussion. We should always take care to make sure we are being pragmatic in these discussions (and not “solving the world’s problems at the dinner table”), but I’m still a supporter of pushing stuff out to the public for comment.

Russ also makes a great reference to Greg Young’s talk at muCon last year, which should be essential watching for anyone building microservices. Paraphrasing Greg massively, he suggested that a lot of the concepts behind microservices have already been done before, and that if we aren’t careful then we will re-invent the wheel (albeit more ‘micro’ than before 🙂 ).

Greg’s observations about the negative impact of dogmatic standardisation and overly-opinionated vendor tooling were also especially damning, and I couldn’t help but nod in agreement through a lot of his talk (on a side note, the whole muCon conference was awesome, and I would highly recommend attending the next iteration later this year! Massive kudos to Russ for kickstarting this conference).

I’m definitely going to take care to avoid being dogmatic (or inspiring dogma), but I’m still keen to share my thoughts on things like the maturity/classification model. It might turn out that this approach isn’t useful, but I’ve already been using a slightly less polished version of this model with tech friends over the last few months to help them understand where their software stack currently sits in relation to the ‘unicorn’ organisations such as Netflix and Amazon (what else are techies going to discuss over a few beers! :- ).

Something that I believe could emerge from this type of proposal (which may be more valuable) is some kind of model that shows organisations where their software sits on the big picture scale of innovation, architecture and delivery. Each level of the model should also clearly show the benefits and drawbacks, and provide guidance on why (if at all) organisations should move some of their software to the next level. We would also need to show how organisations should go about doing this, both from a pragmatic organisational and cultural perspective (Conway’s law in action), and also from a technical tooling and process perspective.

I’m currently reading Jez Humble’s new book ‘Lean Enterprise’, and this is providing some superb inspiration for approaching these tasks. I’m also dogfooding some of my new models and processes, and as soon as I have some useful insights I’ll make sure I share them.

In summary…

I really appreciate Russ taking the time to reply to my original post, and I’m definitely going to think more of several of the great points he’s made (and I’m sure I’ll also catch up with him for a beer after an upcoming London Microservices User Group meetup).

I will also take more care to make my intentions clearer, but I’m still keen to share my thoughts and inspire debate. I’m also keen to avoid dogma, and focus more on dogfooding the model, and here I’ll use some of Russ’ comments to attempt to refine the model.

As usual, if anyone has any comments or feedback then please do get in touch!

Microservice Maturity/Classification Model Proposal – First Draft

I’ve been chatting to various people for quite some time about how there isn’t an agreed maturity model for the current trend to implement microservice architectures, and so I though I would have a go at creating one (quick link to PDF: Microservice Maturity Model Proposal).

I’m in no way suggesting this first draft is complete or definitive, but I hope it may stimulate the conversation around this topic. I’m sure some people will argue that a maturity or classification model isn’t necessary, but I believe it is a fun exercise, and it does enable us to explore (and discuss) what we think are requirements for a microservice implementation.

I’ve proposed six classifications of application architectural styles:

• Megalith Platform
  • Humongous single codebase resulting in a single application
• Monolith Platform
  • Large single codebase resulting in a single application
• Macro SOA Platform
  • Classical SOA applications, and platforms consisting of loosely-coupled large services (potentially a series of interconnected monoliths)
• Meso Application Platform
  • ‘Meso’ or middle-sized services interconnected to form a single application or platform. Essentially a monolith and microservice hybrid
• Microservice Platform
  • ‘Cloud native’ loosely-coupled small services focused around DDD-inspired ‘bounded contexts’
• Nanoservice Platform
  • Extremely small single-purpose (primarily reactive) services

I’ve then attempted for each classification to write about things such as, motivations, challenges, architecture, code modularisation, state data stores, deployment, associated infrastructure, tooling and delivery models.

The full proposal can be found in the following PDF ‘Microservice Maturity Model Proposal – Daniel Bryant (@danielbryantuk)‘

Please do let me know what you think – I’m keen to see whether this model could be useful, and also explore how it could be developed.

Thinking Fast and Slow with Software Development (Jfokus 2015)

I’ve just got back from my first Jfokus conference in Stockholm, Sweden, where I presented the latest version of my “Thinking Fast and Slow with Software Development”. The core concept of the presentation is based on Daniel Kahneman’s bestselling book, “Thinking Fast and Slow“, and I wanted to relate the discussion of decision making heuristics and bias contained in the book to software development.

I’ve included the slide deck below, and I believe the video of the presentation will eventually be available from Parleys

Jfokus 2015 "Thinking Fast and Slow with Software Development" from Daniel Bryant

Here is the original abstract:

In the international bestseller ‘Thinking, Fast and Slow’, Daniel Kahneman explains how we as human beings think and reason, and perhaps surprisingly how our thought processes are often fundamentally flawed and biased. This talk explores the ideas presented in the book in the context of professional software development. As software developers we all like to think that we are highly logical, and make only rational choices, but after reading the book I’m not so sure. Here I’ll share my thinking on thinking. Topics that will be discussed include; the ‘Availability Heuristic’, which can lead developers to choose the ‘latest and greatest’ technology without proper evaluation; ‘Optimistic Bias’ which can blind architects from the ‘unknown unknowns’ within a project; and more!

If you have any comments or questions then please do get in touch!

Geecon 2014 Review – An awesome conference :-)

So, I’m currently travelling back from my first Geecon conference in Krakow, Poland, and I must say it was an awesome experience! Firstly, I have to say a massive congratulations and thanks to all of the organisers and volunteers, and especially to Andrzej (@ags313), Konrad (@ktosopl), Adrian (@adrno) and Adam (@maneo). These guys and girls work tirelessly throughout the year in order to run Geecon, and when I heard that they do everything themselves (without paid-for project managers etc.,) I was even more impressed!

I learned so much at the conference that I’m going to try and do a couple of blog posts to brain-dump my thoughts (although I know from past experience I know that this may not happen, and so I’ll focus on the one post at the moment 🙂 ). I’ll start with a review of the conference itself, move on to key memes (that I saw), and then briefly outline the sessions and social activities that I attended:

Conference Overview

• The organisation of the conference is superb, right from the location (an out-of-town Cinema), the sessions, the speakers, the attendees, the food, to the amazingly helpful volunteers. My only small minus (and it’s really a symptom of the great success of the conference) was that the corridors can get super crowded during break times and lunch. I was chatting to Andrzej about this, and he mentioned that so many people wanted to come to Geecon that he had to stop accepting registrations after the initial 1200+…wow!
• Krakow is an awesome city for the conference. It has some amazing sight-seeing and historical opportunities (Old Town, Castle, Salt mines, Auschwitz). Everyone I interacted with in the city was very friendly, and the vast majority also spoke superb English (which again puts the UK’s language skills to shame!)
• Geecon is not just a Java conference, and this makes it all the better. It may be primarily focused on Java and the JVM, but you can easily pick sessions to avoid this (if you really wanted to?), and I managed to get a nice blend of different languages over the three days
• Geecon is at the cutting-edge of thought-leadership within software development. There aren’t many conferences that can claim a perfect mix of sessions on programming fundamentals (often ignored), DDD, crafted design and architecture, Agile good practices, Java 8, JEE 7, Spring boot, Groovy, Scala, JavaScript modularity, microservices, DevOps, Open Source Software, low latency performance and more (except perhaps DevoxxUK, but I could be biased 😉 )
• The social events and after parties are amazing – you’ll probably learn as much at the parties as you will in the main sessions 🙂
• Get plenty of sleep before the event, and also expect your brain to hurt after the three days of intensive knowledge injection. You know the part of The Matrix films where Neo ‘downloads’ knowledge on Kung-fu while plugged in to chair? Well Geecon is pretty much the beta version of this (fortunately without the wires plugging into your brain)

Key Memes

• Never stop learning, and make sure you keep revising the fundamentals as well as innovating.
• Jurgen Appelo’s awesome keynote set the tone for the first part of the above point perfectly, and I would recommend that all developers watch this talk when it is released on video by the Geecon team. The key takeaways for me were; have a goal, work relentlessly towards it (evaluating progress all the way, and adjusting were necessary); daily habits and discipline are key; be open to other people’s ideas; read more; read more; read more… 😉
• The ever-inspiring Kevlin Henney also did a superb job at both of his talks on Thursday. The first was a call to action for avoiding the common mistakes that many of us make when writing code, and also a reminder that style and layout matter. This can be summed up perfectly by one of his quotes “Style and layout matter in programming for the same reason they matter in writing” Amen to that… The second of Kevlin’s presentations was a homage to the ‘worse is better’ work by Richard Gabriel, and reminded us all of the fundamental’s of agile development, and that often less is more when it comes to software development. Key takeaways here were strive for simplicity, completeness, correctness, consistency
• Java 8 really is making a difference to developers. I realise that many of the people presenting at the conference are thought-leaders, and also at the cutting-edge of software design, but I could clearly see the impact of Java 8’s new Lambdas and Streams. For a start, it made a lot of the code on slides much more readable (no more crazy anonymous inner Class boilerplate), and also more expressive, which allowed for key memes to be demonstrated in a much more understandable way (for example, in the great talk about Netflix’s RxJava library by Tomasz Kowalczewski)
• Java EE 7 is also making a clear difference to developers. Many of the JEE sessions I have attended in conferences over the last few years have been about work-arounds for JEE versions <= 6, or the promised benefit of JEE 7, but at Geecon we actually got to see clear improvements from within the developer trenches (for example, Adam Bien’s and Arun Gupta’s sessions)
• JavaScript really is growing-up. I know that this observation is not particularly new, and the JavaScript language (and tooling) has been developing in leaps and bounds over the past few years, but again at Geecon I saw proper evidence of this. In particular, the session by Paul Bakker and Sander Mak on JavaScript modularity and the proposed enhancements in ECMAScript 6 look awesome.
• Microservices are at the tipping-point for mainstream adoption (and are in danger of being the ‘next big thing’). Both of Sam Newman’s talks about microservices were superb, and clearly demonstrated that Sam and the guys/girls at Thoughtworks have been doing this stuff in the trenches for quite some time. Sam is clearly ahead of the game in many areas of service design, implementation and delivery that I was very pleased to hear he was writing a book with O’Reily (which I’ve now bought in Early Access format here). Key takeaway’s from Sam’s talks included; software architects should be more like town-planners than building architects, especially when designing with microservices; be flexible with the implementation of microservices, but standardise the stuff ‘in between’ – monitoring, interfaces, deployment, architectural safety; strive for resource (not data or procedure) oriented designs; distributed txns are hard and should be avoided (see CAP theorem 🙂 ); distributed tracing and correlation IDs are very valuable (I’ll second this piece of advice!); get the testing strategy correct (think Mike Cohn’s test pyramid); make thing more ‘production-like’ close to the development (vagrant, docker, packer are useful here); consumer-driven contracts are very useful for testing; semantic monitoring is a great technique for testing in production.
• The need for well-crafted design and architecture is still as important (maybe more) as it ever was. Sandro Mancuso’s excellent ‘Crafted Design’ talk provided clear evidence for this. Building heavily on DDD-based principles, Sandro proposed a new architecture and package design for Java applications that allows more cohesive modelling of the problem domain, and promotes clear separation between the Model Domain and delivery and infrastructure mechanisms. I wouldn’t do the proposal justice if I tried to describe it here, but check out the slides on Slideshare. It’s seriously worth spending time looking at this, as creating the ideal package/module structure that represents the problem domain is somewhat the holy grail of Java developers. It’s also worth checking out Simon Brown’s related work in this field (of which I am a big fan), and although he wasn’t at Geecon you will be able to catch him at Devoxx UK in June. I chatted to Sandro at the conference, and we both agreed that it would be great if he and Simon could get together sometime for a meeting of minds!
• Several of the emerging languages and tooling are becoming a lot more opinionated, which I welcome. It’s great to have an uber-flexible language (Scala I’m looking at you here), but the flexibility and lack of constraints can confuse novices, and also stifle the creative challenge. Ken Sipe did an amazing job of introducing Google’s (very opinionated) Go language in an hour session, and this has inspired my to further look into this language as perhaps an alternative to some of the Python I write. Ken also did a superb advanced session on the testing framework Spock. I could see some people’s brains melting at some of the content (and mine got quite hot), but some of the power demonstrated looked simply awesome. Both of Ken’s talks demonstrated to me that the developers of the language/tool had clearly surveyed their respective fields and picked what they considered best for inclusion into their offering. This obviously could be hit-and-miss, but with Go lang and Spock I think we have a couple of winners.

That’s all for the moment, but if you ever get the chance to attend Geecon then make sure you do – you’ll learn lots, and have a great time doing it! if you have any comments then please let me know!

[Book Review] Java Application Architecture

Java Application Architecture: Modularity Patterns with Examples Using OSGi: A Roadmap for Enterprise Development (Agile Software Development) – by Kirk Knoernschild

TLDR: This book is a thought-provoking peek into a topic that I believe will be highly influential in the next stage of evolution within software craftsmanship. The concepts presented within this book sit nicely in between the low-level ‘clean code’ philosophy (SOLID principles, Design Patterns, TDD etc) and the high level system/platform architecture principles (loose coupling, message orientation, event-driven systems, EIP etc). If you are serious about becoming a well-rounded developer or architect then this book is a must read.

I’m a freelance software architect/developer who primarily works on the JVM stack. I’m a strong supporter of Uncle Bob’s ‘Clean Code’ principles, and I spend a lot of time on InfoQ and various other sites learning about historical and current big-picture systems architectural approaches, but until reading this book I hadn’t thought too much about what happens in the middle of all of this. As a seasoned developer I now have several formuli for designing the big-picture architecture, and am happy creating (what I think is) well crafted code. But in the Java world packaging components together for deployment can feel clumsy at times (fat JARs or stuffed WARs anyone?). This book aims to address this discomfort.

The key premise of the book is ‘Architecture all the way down’, and although this may not make sense to you now, I have a strong suspicion that after reading the book and watching the online videos of the author (at Parleys) you’ll be nodding along enthusiastically (or at least thinking that more attention should be focused in this space). Several of the principles within this book are discussed within the context of OSGi, and although I’ve been aware of OSGi for quite a while now, it always seemed peripheral to what I was working on, and chatting with colleagues used to produce the ‘isn’t that the huge frameworks used to develop app servers?’ type conversations. Although the book doesn’t deep-dive into OSGi per se, it did help to clear up a lot of the mystery and intended design goals for me.

Just to address a few comments made by other reviewers on amazon.co.uk:

* I also believe that this book will be suitable for a non Java developer/architect, although the reader may have to work a bit harder to relate the content to analogous frameworks and toolkit within their chosen language/platform.
* In regards to the review stating ‘not a general software architecture book’ I respectfully think the reviewer has missed the point of this book – ‘Java Application Architecture’ is clearly aimed at a well-defined and often over-looked niche within the software architecture domain, and should not be considered in isolation. It would be easy to say that a book on software design patterns is ‘not a good software development book’, but this is because the application of design patterns should be mixed with well-crafted code and other good design principles.

In summary, if you’re a fan of reading books like Uncle Bob’s inspiring Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) and the ground-breaking The Pragmatic Programmer you are going to enjoy this a lot. It may not leave you with concrete implementation details, but it will make you think a lot about how you assemble your software components.

Bonus: Check out Kirk’s Devoxx talk on Parleys: Architecture All The Way Down.

Click Here to buy ‘Java Application Architecture: Modularity Patterns with Examples Using OSGi: A Roadmap for Enterprise Development (Agile Software Development)‘ on Amazon (This is a sponsored link. Please click through and help a fellow developer to buy some more books! ).