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:
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!
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
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.
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!
I once again had the pleasure of presenting a lightning talk at the London Software Craftsmanship Community #LSCCtalks series. This time I presented a new talk I’m working on – “Crafting DevOps: Applying software craftsmanship to DevOps”.
The presentation (hopefully) does what it says on the tin, in that I talk about the ideas of applying software craftsmanship principles to DevOps . If the DevOps mantra of “Infrastructure as Code” is true (which I think it is), then I believe it makes sense to learn from the craftsmanship community – in particular TDD, BDD and continuous integration.
This is very much a work-in-progress talk, and I hope to develop it more over the coming weeks and months (please do send me your feedback!).
Thanks again to Sandro
from the LSCC for inviting me to talk, and as usual, if you have any questions, then please do get in touch. In particular please do let me know if you would like to see more on this topic.
As my other blog post (will soon) reveal, my entire experience of Devoxx UK 2014 was awesome, but in particular I enjoyed presenting “Moving to a DevOps Mode: Easy, Hard or just Plain Terrifying” with Steve Poole.
Steve and I have previously presented together about the OpenJDK at JavaOne, but this was a more ambitious project. Earlier in the year we both attended a series of meetups in London, and started talking about our respective experiences with enabling agility within organisation, and working with such topics as Continuous Integration, Continuous Delivery and ‘DevOps’. Steve has plenty of experience of this with large organisations, and I have experience from working with smaller organisations, and so we figure that a joint talk combining all of our learnings would be a good idea.
Both Steve and I were very happy with the talk, and we received some great feedback and questions at the end of the presentation. We will also be presenting a very similar talk at JAX London this year, and so we will try and address all of the comments here.
You can also watch the full video recorindg of the presentation at Parleys, but in order to view the content you will need to have been an attendee of the conference or pay a subscription:
As usual, if you have any comments then please do get in touch!
I once again had the pleasure of talking at Skillsmatter in early May, and this time I presented “Cloud Developer’s DHARMA: Redefining ‘done’ for Cloud applications”. I wrote about this on my company’s blog the night after I delivered the talk, but I’ve just realised I didn’t post anything here – therefore here we are. The synopsis for the talk can be found below.
As is always the case with giving a presentation at Skillsmatter, I very much enjoyed the experience, and there were some great questions and chat in the pub afterwards. Many thanks to all who attended – your comments and feedback are very much appreciated!
Skillsmatter have very kindly recorded the session, and you can watch my full talk here. You can also find a link to the slides on slideshare below.
Building 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 talk will introduce lessons learnt from the trenches during two 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.
We will look at these lessons from both a theoretic and practical perspective using a real-world case study from Instant Access Technologies (IAT) Ltd. IAT recently evolved their epoints.com(http://epoints.com/) customer loyalty platform from a monolithic Java application deployed into a data centre on a ‘big bang’ schedule, to a platform of loosely-coupled JVM-based components, all being continuously deployed into the AWS IaaS Cloud
If you have any questions then please do get in touch via the usual methods!