The Business Behind Microservices: Organisational, Architectural and Operational Challenges

On Wednesday I had the pleasure of presenting a new talk at the London Microservices User Group, which was entitled “The Business Behind Microservices: Organisational, Architectural and Operational Challenges”.

The key theme of the talk was exploring the often under-appreciated organisational and people impact that introducing (or moving to) a microservice architecture will have on a business. As mentioned in the talk, I’ve lead the implementation of microservices architectures in several organisation as part of my work with OpenCredo and Container Solutions, and so I was keen to share my lessons from the trenches.

You can find a recording of the talk over on the Skillsmatter website, who were our generous hosts for the evening https://skillsmatter.com/skillscasts/6450-the-business-behind-microservices-organisational-architectural-and-operational-challenges 

 

You can also find the slides on slideshare:

LMSUG 2015 "The Business Behind Microservices: Organisational, Architectural and Operational Challenges" from Daniel Bryant

 

The original talk abstract was as follows:

The technology changes required when implementing a microservice-based application are only one part of the equation. The business and organisation will also most likely have to fundamentally change. In an ideal world, this shouldn’t be a problem – what with the rise of agile, lean and DevOps – but this is not always the situation I encounter in my consulting travels. I would like to share some stories of successful (and not so successful) strategies and tactics I have used over the past four years when introducing service-oriented architecture into organisations.

Join me for a whistle-stop tour of the business and people challenges that I have experienced first hand when implementing a greenfield microservice project, and also breaking down a monolith. We’ll look at ‘divided companies’ vs ‘connected companies’, determine the actual impact of conway’s law, briefly touch on the lean startup/enterprise mindset, dive into change management without the management double-speak, and look at the lightweight processes needed to ensure the technical success of a microservices implementation.

As usual, please do let me know if you have any questions!

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!

The Crafty Consultant’s Guide to… DevOps

On Thursday I once again had the pleasure of presenting at the London Java Community (LJC) meetup. This time I presented a new talk “The Craft Consultant’s Guide to… DevOps”. This builds on a DevOps parody talk I gave at last year’s LJC Unconference, and also combines some of my thoughts from my earlier “Chuck Norris doesn’t do DevOps, but Java developers might benefit” talk.

The goals of this talk was to provide a high-level overview of some of the key themes of DevOps, specifically from a tooling perspective. It’s worth stating at this point that in my opinion DevOps is more about methodology, process and culture more than it is tooling. However, for the intended audience of this presentation the focus on tooling provides a framework on which to build understanding for the non-technical issues. The slides can be found below:

The original abstract for the talk can be found in the next paragraph, and as usual, if you have any comments, thoughts or (constructive) criticism then please do get in touch!

“Come along and learn how the Crafty Consultant makes his money by consulting craftily in DevOps. We’ll see how silos can be broken down by introducing more independent and isolated team, how only idiots automate everything, and why monitoring only provides actionable insight that simply confuses your clients…

…and then we’ll look at the real world implementation of DevOps 🙂 The primary aims of this talk are to introduce the concepts behind the DevOps movement, and we’ll do this by debunking all of the Crafty Consultant’s advice. We’ll cover the drivers of breaking down silos (in business and in tech), the benefits of automation (especially with provisioning and configuring infrastructure), and the power that monitoring provides (particularly when deploying to the cloud, or implementing a microservice architecture).”

Details of the event can be found on meetup.com

[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!

Microservices in the Enterprise: Friend or Foe?

A micro approach to a macro problem?

The microservice hype is everywhere, and although the industry can’t seem to agree on an exact definition, we are repeatedly told that moving away from a monolithic application to a Service-Oriented Architecture (SOA) consisting of small services is the correct way to build and evolve software systems. However, there is currently an absence of traditional ‘Enterprise’ organisations talking about their adoption of microservices. This blog post is a preview to a larger article, which explores the use of microservices in the Enterprise.

Interfaces – Good contracts make for good neighbours

Whether you are starting a greenfield microservice project or are tasked with deconstructing an existing monolith into services, the first task is to define the boundaries and corresponding Application Programming Interfaces (APIs) of your new components.

The suggested granularity of a service in a microservice architecture is finer in comparison with what is typically implemented when using a classical Enterprise Service Oriented Architecture (SOA) approach, but arguably the original intention of SOA was to create cohesive units of reusable business functionality, even if the implementation history tells a different story.

A greenfield microservice project often has more flexibility, and the initial design stage can define Domain Driven Design (DDD) inspired bounded contexts with explicit responsibilities and contracts between service provider and consumer (for example, using Consumer Driven Contracts).

However, a typical brownfield project must look to create “seams” within the existing applications and implement new (or extracted) services that integrate with the seam interface. The goal is for each service to have high cohesion and loose coupling; the design of the service interface is where the seeds for these principles are sowed.

Communication – Synchronous vs asynchronous

In practice, we find that many Enterprises will need to offer both synchronous and asynchronous communication in their services. It is worth noting that there is a considerable drive within the industry to move away from the perceived ‘heavyweight’ WS-* communication standards (e.g. WSDL, SOAP, UDDI), even though many of the challenges addressed by these frameworks still exist, such as service discovery, service description and contract negotiation (as articulated very succinctly by Greg Young in a recent presentation at the muCon microservices conference).

Middleware – What about the traditional enterprise stalwarts?

Although many heavyweight Enterprise Service Bus ESBs can perform some very clever routing, they are frequently deployed as a black box. Jim Webber once joked that ESB should stand for “Egregious Spaghetti Box,” because the operations performed within proprietary ESBs are not transparent, and are often complex.

If requirements dictate the use of an ESB (for example, message splitting or policy-based routing), then open source lightweight ESB implementations such as Mule ESB or Fuse ESB should be among the first options you consider.

I usually find that a lightweight MQ platform, such as RabbitMQ or ActiveMQ is more suitable because we believe the current trend in SOA communication is towards “dumb pipes and smart endpoints” In addition to removing potential vendor fees and lock-in, other benefits of using lightweight MQ technologies include easier deployment, management, and simplified testing.

Deploying microservices – How hard can it be?

However you choose to build microservices, it is essential that a continuous integration-style build pipeline be used which includes rigorous automated testing for functional requirements, fault-tolerance, security and performance. The classical SOA approach of manual QA and staged evaluation is arguably no longer appropriate in an economy where ‘speed wins’ and the ability to rapidly innovate and experiment is a competitive advantage (as captured within the Lean Startup movement).

Behaviour of your application can become emergent in a microservice-based platform, and although nothing can replace thorough and pervasive monitoring in your production stack, a build pipeline that exercises (or tortures) your components before they are exposed to your customers would appear to be highly beneficial. As I’ve argued in several conference presentations, a good build pipeline should exercise services in the target deployment environment as early in the pipeline as possible.

Summary – APIs, lightweight comms, and correct deployment

Regardless of whether you subscribe to the microservice hype, it would appear that this style of architecture is gaining traction within practically all software development domains. This article has attempted to provide a primer for understanding key concepts within this growing space, and hopefully reminds readers that many of these problems and solutions have been seen before with classical Enterprise SOA. We would be wise to take care not to reinvent the proverbial ‘service-oriented’ wheel.

Please click here for the complete original article, which provides additional information on microservice implementation options on the JVM platform, and also discusses the requirement for Continuous Delivery. A version of this article was originally published in the DZone 2014 Guide to Enterprise Integration.

References

A full list of references and recommended reading can also be found in the original article and a recent article discussing the business implications of microservices.

Why do I contribute to the JCP (and at the same time evangelise the Spring framework)?

Josh Long, Richard Warburton and myself were having an interesting conversation on twitter about standardisation early today, specifically related to the Java Community Process (JCP), which is the mechanism for developing standard technical specifications for Java technology. Josh asked a question that I often get asked “what does JCP standardisation offer?” (I’m paraphrasing here slightly). This is a totally fair question, and I thought it deserved a little more explanation than I could craft on Twitter.

Innovation and Standardisation; Ying and Yang

The key thing to remember about the JCP process is that it is not about innovation. Quite the opposite in fact. For a standard to be created there must have an initial requirement or problem, significant innovation creating solutions, ideally some competing ideas and implementations, plenty of evaluation and discussion, and ultimately an agreed approach on how to meet the requirement. This process takes time, and it is only at the second from final point the JCP can start creating standards. This is the biggest misunderstanding I encounter when running JSR hack days around the world, particularly with junior developers, as they think the JCP is some mystical think tank who crank out the latest and greatest innovative frameworks (I appreciate calling EJB ‘latest and greatest’ is very ironic 🙂 ).

It’s also worth mentioning at this point that the work of the JCP is now undertaken in the open (I do appreciate the fact that it didn’t used to be, but JSR-348 has made great progress to abolish the ‘behind closed door’ work). This openness provides a platform that allows anyone who wants to get involved to be able to contribute opinions and ideas to the process, and if a standard will cause problems (or is evolving in a problematic fashion) then the community can rise up and publicly duke this out with the spec leads (no Duke pun intended!)

Now on the flip side to this there exists organisations like Spring.io/Pivotal who are all about innovation, and are constantly pushing the boundaries of what a language or framework can do. Personally I love this. I have an entrepreneurial background, and I thrive on innovation and playing with the latest tech and bleeding-edge frameworks as do many of the companies I work with. The Spring framework really does excel here, and this is why I made the transition to coding in Spring back when the framework was at version 1.X and I was really struggling with building J2EE applications. However, as a consultant I appreciate that not all my clients (or the industry in general) think like this, or desire this level of innovation or disruption.

Many companies are inherently risk adverse (sometimes with good reason) and they want to ensure any investment in technology or training their people in a specific technology offers a long-term return on investment (ROI). Such organisation also often desire portability of application/code, and although the practical implementation on the Java platform of this philosophy may not have been perfect in the past, I’ve personally moved several large(ish)-scale Java EE applications across differing application servers with minimal effort. In my mind this is where standardisation can offer enormous benefits, particularly if the standardisation work is undertaken out in the open. On a related note, last year within the London Java Community (LJC) we undertook a community survey of our members, and many Java developers were in favour of standards such as those offered by the JCP (check out the result here http://londonjavacommunity.wordpress.com/2013/09/16/the-java-community-process-survey/)

Horses for Courses…

I strongly believe that innovation and standardisation are far from mutually exclusive, and in fact are very much mutually beneficial (perhaps to the level where one cannot exist without the other, but this is just my opinion). Without innovation we wouldn’t be the embracing the benefits offered by the latest incantation of Service Oriented Architecture (SOA), currently being labelled as ‘microservices’, lead by the likes of Spring Boot, Dropwizard and Ratpack in the Java space. I am very much enjoying working in this space, and the fact that I don’t have to follow any kind of specification results in some very agile, flexible and effective applications.

However, you don’t have to look too far to see the problems that an absence of standardisation can surface. Earlier in the year Facebook announced that it was attempting to create a specification for PHP, as none had existed up until this point, and this made it difficult to decide what the ‘correct’ behaviour of any particular PHP runtime should be. Recently the AngularJS team announced a new version of their framework, and suggested that there will most likely be no clear migration path between the current 1.X and new 2.X versions. This will surely stifle innovation and hamper maintenance of code within companies who have invested significant resources into version Angular JS 1.X (not to mention the problem of dealing with thousands of lines of code that are currently running in production). There are a couple of other related examples that spring to mind, but I won’t mention them as I hope readers will follow my intentions. On a related topic, I’m also very interested to see what will happen with the .NET platform now that Microsoft have open sourced the underlying code with an MIT/Apache2 licence…

Summary

So in summary, I think there is most definitely a place for innovation and standardisation, and I believe both are very useful. This is why I choose to publicly evangelise the Spring platform (and write stacks of code in Spring Boot), and at the same also support the great efforts of the JCP and the OpenJDK which help to drive the future of a standards-based Java platform.

I would be keen to hear other’s thoughts, and so please feel free to comment below 🙂

Disclaimer: I am a member of the OpenJDK Adoption group, and also contribute to the excellent work undertaken within the JCP via the London Java Community JCP committee. However, in contrast 90% of the Java code I write when consulting is currently Spring-based (specifically Spring boot of late), and I publicly evangelise the superb innovation undertaken by the Spring framework team.

JavaOne 2014: “Cloud Developer’s DHARMA: Redefining ‘done’ for Cloud Applications”

I’m currently at JavaOne and have just finished presenting the latest iteration of my “Cloud Developer’s DHARMA” talk, which was great fun. As promised, here are the slides:

 

 

The abstract for this talk is included here (just for the search engine’s benefit 🙂 )

“Building Java applications for the IaaS cloud is easy, right? “Sure, no problem. Just lift and shift,” all the cloud vendors shout in unison. However, the reality of building and deploying cloud applications can often be different. This session introduces lessons learned from the trenches during several years of designing and implementing cloud-based Java applications, which we have codified into our Cloud Developer’s “DHARMA” rules: Documented (just enough); Highly cohesive/loosely coupled (all the way down); Automated from code commit to cloud; Resource-aware; Monitored thoroughly; and Antifragile. “
 

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