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!

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.)

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.

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.

LJCConf “Chuck Norris Doesn’t Need DevOps” Slides

The LJC ran it’s ever-popular annual Open Conference on Saturday 23rd November, and this was the first time I’ve made it along. To say I was impressed was an understatement, and I’ll try and capture some more thoughts in a later blog post, but for the moment I wanted to share the slides from the main presentation I delivered “Chuck Norris Doesn’t Need DevOps”

 

Can’t see the presentation slides? Please click here http://www.slideshare.net/dbryant_uk/2013-ljcconf-chuck-norris-doesnt-need-devops

The original pitch for the talk was as follows:

“We all hear the term “DevOps” being thrown around on a daily basis, but what does it actually mean? With a little help from everyone’s favourite 80’s action hero, we’ll undergo a whistle-stop tour of the philosophy, culture and tooling behind this buzzword, specifically aimed at Java Developers.

We’ll also look at a real-world case study from Instant Access Technologies Ltd, and explore the key role that DevOps has played during a successful upgrade of the epoints customer loyalty platform to support increasing traffic. The core discussion will focus on the challenges encountered as we moved from a monolithic app deployed into a data centre on a ‘big bang’ schedule, to a platform of loosely-coupled components, all being continuously deployed into the Cloud.”

Thanks to everyone who attended my presentation! The feedback was most welcome, and the questions were great. If anyone wants to add anything further than please feel free to comment, email or tweet at me!

Overriding a packaged Spring application properties file via an external file

A common use case when developing a Spring application is the requirement to have multiple versions of configuration properties which vary depending on the target environment you are deploying to. For example, a database URLs or a feature flag may be environment specific, and the value you use for local (dev) testing may be significantly different than on QA or production etc.

Like most Spring development tasks, there are several way to solve the problem. My preference is based on the following assumptions and preferences:

• We create a default configuration properties file (e.g. ‘appConfig.properties’) and package this within the deployable artifact (JAR or WAR etc)
  • This file will contain a sensible set of default ‘baseline’ properties that the application requires to run successfully
  • This default configuration file will typically be used for development purposes i.e. the  appConfig.properties included within the application code will allow the application to work ‘out of the box’ on a well configured local development box
  • We are using Maven to package our application, and therefore we place the appConfig.properties file in the root level of the src/main/resources directory – this doesn’t mean you have to use Maven, but you will have to ensure that your application packaging process includes the properties files in a location that is on the classpath
• We want to override properties in the baseline appConfig.properties file via an external file located in the deployed application’s working directory
  • We typically name this file appConfigOverride.properties
  • We may not override all of the default properties, and therefore we want any properties not present in the override file to default to the values in the baseline appConfig.properties file
• It is possible to override application properties by passing parameters on the Command Line when executing the application, or setting system variables, but this is a separate topic 🙂

The Solution

We use the following structure for our application-context.xml:

	<beans xmlns="http://www.springframework.org/schema/beans&quot;
	xmlns:context="http://www.springframework.org/schema/context&quot;
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
	xsi:schemaLocation="http://www.springframework.org/schema/beans
	http://www.springframework.org/schema/beans/spring-beans.xsd
	http://www.springframework.org/schema/context
	http://www.springframework.org/schema/context/spring-context.xsd"&gt;
	<context:property-placeholder location="file:appConfigOverride.properties" order="-1"
	ignore-unresolvable="true" ignore-resource-not-found="true" />
	<context:property-placeholder location="classpath:appConfig.properties" />
	….
	</beans>

view raw

application-context.xml

hosted with ❤ by GitHub

The key things here, are the ‘order’ attribute, which forces properties found in the appConfigOverride.properties to be used when a property is also found in another file (effectively overriding values from the other file), and the ‘ignore-unresolvable=”true” ignore-resource-not-found=”true”‘ which allows Spring to continue loading the context if it can’t find the external file (or it doesn’t contain override all of the default properties from the appConfig file)

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