We’ve added a new mindmap to our catalogue here. This covers the core of GraphQL. The catalogue contains both the image and a Word representation. The map is built based on a reading of Learning GraphQL by Eve Porcello & Alex Banks on O’Reilly.
I have been working my way through Building Evolutionary Architectures by Neal Forward, Rebecca Parsons and Patrick Kua. Three senior and respected members of Thoughtworks (also the home of Martin Fowler). Having read and listened to Neal and Rebecca’s presentations and writing I had expected a deeply thought-provoking read, but have to admit to being disappointed. There are some good points without a doubt, but the book pretty much focuses on one idea, the application of fitness functions. But I’m not convinced it warrants several hundred pages of a book as a result the point does at times feel laboured.
There are some arguments made, that leaves me thinking that there is a view that the only answer is microservices in the conventional model of Kubernetes, Docker etc, which I agree is a powerful paradigm to allow solutions to evolve, but it isn’t a silver bullet and not always right in every case (if you have a team lacking the underlying appreciation of the goals, or put in to place in an ad-hoc manner (see Chris Richardson‘s work) it isn’t going to help.
Alongside this, there is little said about the interface definition for microservices (typically APIs of one form or another). Whilst mention of leaky abstractions are made, the material illustrations such as code lead API definitions are omitted (risk being, code changes, the API changes and the impact cascades).
What surprised me the most is the on more than one occasion the books points to ERPs not being sufficiently customisable. Yet, anyone working with ERPs will tell you that ERPs are at their best when you use them to leverage industry best practices rather than crowbar them to fit unconventional ways of operating. If you’re a manufacturer, is fiscal reporting part of your differentiator; probably not, so why not take best practice OOTB.
As usual, I have mind mapped things as I read through the book. The dynamic/interactive version is here, the image (but not in full detail) is below.
Earlier this year, I wrote a short post on Chris Richardson’s book Microservice Patterns (Praise for Microservice Patterns). When I read the book I mind mapped my notes which can be seen at Mindmap Index or access directly here. The mind map is no substitute but should act as a reasonable aide-memoire.
We would highly recommend getting and reading the book.
After months of labour, the arrival of new family members for a couple of the authors the Implementing Oracle API Platform Cloud Service book as finally been published. The book has been included into Packt’s Expert series so, earns(?) the privilege of having photos of the authors on the cover. The book can be purchased directly from Packt (go here) or from book retails such as Amazon (here).
It has been an interesting experience. Whilst working as part of a team of four authors lightened the writing load, a lot more energy went into communication so things were lined up. If you want a challenge, why not read the book and try to work out who wrote which chapters!
I’ve been reading Chris Richardson’s new book Mixroservice Patterns published by Manning (here or here). Whilst I haven’t finished the book yet, I have read enough to feel I can provide worthwhile observation.
The book is supported by Chris’ website microservices.io which provides the patterns and related content in summarised form – great for a memory jogger and quick reference, but doesn’t make a substitute for the book.
When it comes to the book, Chris’ writing is extremly engaging whilst economic with its language – no long passages when a short sentence can convey everything necessary (unlike this one for example 🙂 ). For example, in three short paragraphs is an explination as to why there is a tendancy for IT people to point at particular technologies or techniques as silver bullets. As a result is incredibly informative and points to sources that inform the thinking – such references can be as diverse as Sam Newman’s Building Microservices to the (real) architect Christopher Alexander and Jonathan Haidt (The Righteous Mind).
The book is grounded in honest real world thinking being upfront and clearly pointing to when Microservices aren’t the right answer, to talking about the difficulties that can be expected in working with microservices. This won’t surprise anyone who has heard Chris speaking (here for example).
A recommended read.
I have been wading through Eric Evan’s Domain Driven Design Book. As with many design and architecture focussed books I try to mindmap as I go so I have a quick reference resource. The mindmap for this book can be seen below and is linked to the WiseMap version which is dynamic.
In terms of of a review of the book, it contains lots of nuggets of helpful ideas and information but it is a rather heavy going to read. Some points feel over laboured such as the use of consistent language, at times it feels like half the book is dedicated to this one point. Whilst Chapter 14 – Maintaining Model Integrity sounds unadventurous as a chapter, I found this to have a lot of really helpful content such as going into the details Bounded Contexts and so on which is highly relevant to the world of microservices.
When it comes to ensuring I keep up good practises, I try to look at books in areas I think I have a good handle on such as APIs. Why? well it confirms and validates I’m upto date; sometimes another view point can spark ideas on how to make something better, improve an approach or simply understand another way of explaining an idea. The later is important as the key benefit of knowing something is the opportunity to help someone else. Not everyone communicates or understands ideas in the same so this is always helpful.
So recently I ran through James Higginbotham’s Designing Great Web API’s book(let). Often when goping through a book I mindmap it so that I can share it, and refer to it as a lit of prompts reminders if necessary. Whilst’s James’ book doesnt reveal anything new or relevatory for anyone working with APIs it does provide a good succinct explination to basic practises. So here is the mindmap:
Now the big news, we have just agreed with Packt Publishing to write a book around Oracle’s new API Platform Cloud Service (APIP CS). This is going to be more of a team effort with 4 of us working on the book. With all the authors working for Capgemini as well it should be a lot easier in terms of effort The book is being targeted for late this year to be published so that we can cover the major features being released this summer which will make the product a lot more rounded and complete.
The book will also bring in another initiative that has been running in a fairly low profile manner, but starting to shape up in the form of something called OMESA (OMESA.io). This initiative is a cross party approach to define a reusable reference architecture that engages both the legacy landscape along with API driven / microservices based contemporary solution delivery.
We will of course continue to blog about ICS at https://oracle-integration.cloud
Recently I’ve given some time over to catching up on some reading. Which has included Walter Isaacson’s tremendous book Innovators. I picked this up more because I liked Walter’s approach to the Steve Job’s biography. I thought this was going to be more focused on individuals and how they brought through new technology innovations. But actually it is a very good potted history of the development of modern computing. Whilst I work in IT and thought I knew key contributors, from Babbage, Lovelace to von Neumann and Turing. I was rather surprised at how many signficiant contributors I didnt know, or only vaguely aware of. For example the work of Douglas Engelbart who pretty much lead the design for the mouse. What about Vint Cerf who made key contributions to TCP/IP? Stephen Crocker who was responsible for the RFC that we all associate with the IETF now?
Not only is the history interesting, the book looks at the dynamics of innovation and how much innovation comes from the individuals working away on their own and having a eureka moment compared to that constant dialogue between people which sounding off each other lead to new ideas? The later is beautifully illustrated with the development of the transistor and the work of John Baarden and Walter Brattain. It’s interesting that as the history moves into the pre-internet era that more and more of advancements are a result of collective effort, but also recognised as such. I wonder whether that is because technologies made collaboration easier, or the effects of socio-cultural developments that meant people recognised the collaborative efforts?
I’d recommend this book to anyone who is interested in IT has developed or even just interested in the interplay of personalities and events such as World war II that influenced scientific advancement.