Phill Barber's Blog

 This blog will my thoughts from JUXT's XT 26 conference: https://www.juxt.pro/xt26/   Summary: We are mid storm - AI is changing the industry. No one knows what's going to happen, if they claim to know, they are just trying to sell you something. We were promised that AI would make us 10x more efficient - it's not. We have shifted the bottleneck from coding to PR reviews.  You can out-source your thinking but you can't outsource your understanding    Intro   After a hectic morning I managed to just catch Jon's intro which explained we are "mid storm" given the changes AI is making to the industry.      

Green IO Opening Remarks - Gaël Duez Founder - Green IO Gaël started the Green IO conference (this was a track within the APIDays conference) with a very welcoming and friendly tone that felt quite different to other conferences. He encouraged us to greet our neighbour and say hello which went really well.  The room was completely full with many people standing at the back. I can imagine that next year this conference will be moved into a bigger room.  Gaël Duez Kicks off Green IO Keynote: Consensus As A Climate Lever Room: Commercial 3 Chris Adams Executive Director - Green Web Foundation Chris explained to us "just how messy carbon calculation can be". My main takeaway from Chris's talk was exploring the concept of consensus and how having too strict a definition can be counter-productive. Instead people now realise that to get things done we need to instead aim for "rough consensus" and came up with a great quote... "We reject: kings, presidents, and vot...

 I was fortunate enough to attend API Days London today. Here are my thoughts from the various talks. Welcome Breakfast Panel Discussion: The API State of the Market Report 2024 Edition The room was almost completely full to host a panel discussion with: Mehdi Medjaoui Founder and Chairman of Apidays Conferences, Author of Continuous API Management - Apidays Mark Boyd Director - Platformable. Maurizio Garzelli - Sr Consultant, Solutions Architecture - Boomi They showed a big image with 2500 icons of different vendor supplying different solutions. They said that eight years ago this was just aroud 150. The point was made that, although this looks complicated, all of these different vendors have the goal of simplifing things for the developers of APIs. Mark made the point that multiple forces are driving the explosion of API tech providers. Firtly, social media, secondly sharing of data from devices being connected. The point was also discussed regardg the "bundling / unbundling...

I was fortunate enough to attend and speak at XT24 .  Here are my notes and thoughts from the event. Fran Bennett - Interim Director & Board Member - AI: UNINTENDED CONSEQUENCES Fran made some great points regarding the risks of trusting AI too much.  While some people are worried about super intelligent robots, Fran points out a far more likely set of "unintended consequences" that have already started to materialise. How do you test a system is working?  You need an acceptance criteria.  Developing a set of requirements is a hard to thing to do and it's easier to just... not specify them.  If that's the case, how can you test your system is working? Fran made the comparison of AI products with the recent British Post Office scandal  where people blindly assume "The system is infallible".  Clearly IT systems are not, real life is messy!  We must always keep in mind that the system could fail in weird ways. Human testing AI output also ha...

In this article I'll discuss my thoughts on a potential design flaw relating to systems (primarily microservices) which use a workflow engine.  This issue was discussed in Sam Newman's excellent "Building Microservices" book.  I've lived through this and felt compelled to explain my take on it! TLDR: Using a workflow engine runs the risk that other services called by the workflow are pushed to be data only with CRUD APIs and no behaviour.  Centralised workflow engines that perform all behaviour should be avoided.  Domain driven design should be considered first for your services.  Only then consider small embedded workflow engines as a way of writing the internal code. Why Use a Workflow engine? Workflow engines are a fantastic design choice when the process you are modelling is complex and involves many sequential or parallel tasks.  They can show: non technical users the actual workflow representing the process that can be easy to follow and never drifts...

EDIT: This blog post took so long that by the time I published I discover that just five days earlier, Netflix announced they " will discontinue maintenance of Conductor OSS on GitHub ".  Here's my post anyway....  I have spent several years developing a service (within a big organisation) which uses the workflow engine  Flowable to orchestrate the complexity of calling many different services.Whilst the project was a success and we saw the benefits of using a work flow engine, we did encounter a number of rather significant issues with Flowable itself ( I'll explain these on another post later ). This leads me to think that I would use a workflow engine again, but not necessarily Flowable.  So what other workflow engines are out there?  Netflix conductor is one which I plan on evaluating in this post.   First - Some background The service I worked on provided a RESTful API to its clients.  On receiving a request it executed a workflow which c...