Nice feedback on the book!

I've been really delighted to see such positive feedback on the book. When I got the thing published I was just glad it was going to be out there in the world and was going to act as a good go-to for my usual thought processes on building ML solutions. I didn't ever anticipate it would get such good reviews and endorsements!

Some of my favourites are given below:

Editorial Reviews

"ML Ops is one of the hottest topics in analytics and data science at the moment. This book does a great job of providing a useful overview of the subject and really practical examples of how to do it in anger. If you are a data scientist or want to be one you should buy this book and read it before your next interview or big team meeting." -- Zachary Anderson, Chief Data and Analytics Officer, NatWest Group

"If you want to know how to take ML from applying the theory to actually doing it for real this book provides an excellent roadmap. For industry practitioners, this is going to become a required text and for academics like myself, this provides a detailed overview of the extra bits that we need to get students to consider in our courses. I cannot recommend this book highly enough!" -- Gordon Morrison, Professor of Data Science and Head of Computing Department at Glasgow Caledonian University

The third editorial review is Vincent Boucher's one given above.

The Book

If these reviews make you feel like you might want to check out the book, then please do at the following sites!





Machine Learning Engineering with Python - available for pre-order!

Machine Learning Engineering with Python: Manage the production life cycle of machine learning models using standard processes and designs by [Andrew McMahon]

After many months of writing, developing, designing and researching after work and at weekends, my book is now available for pre-order on Amazon!

I'm really excited as I've always wanted to write books and I had set myself a goal of writing at least one book by the time I was 30. So as long as the book is fully available for order in October as planned I would say challenge completed (my birthday is at the end of November).

Why did I write this book?

I have been working for a few years in a variety of roles in data science and machine learning (ML), and my career has now strongly went in the direction of focussing on productionization. A totally made up word that we all now use to mean 'taking ML proof-of-concepts and making them into working software solutions'. I've found this to be the hardest problem in industrial data science and machine learning, or at least the hardest problem that comes up often enough to justify focussing on it.

So given this focus and how much I know teams can struggle to understand some of the things they need to go from cool idea or draft model through to working solution, I decided to write this book. It's by no means perfect, but I hope it's a good collection of some of the ideas, tools and techniques that I think most important when it comes to ML engineering.

What's in it?

The book consists of 8 chapters:

  1. Introduction to ML Engineering
  2. The Machine Learning Development Process
  3. From Model to Model Factory
  4. Packaging Up
  5. Deployment Patterns and Tools
  6. Scaling Up
  7. Building an Example ML Microservice
  8. Building an Extract Transform Machine Learning Use Case

The book will kick off with more strategic and process directed thinking. This is where I talk about what I think ML engineering means and what is so different about building ML solutions vs traditional programming.

We then move onto learning about how to create models again and again by building training services and then how to monitor models for important changes like concept or data drift. I then discuss strategies for triggering retraining of your models and how this all ties together.

Moving on there's more of an emphasis about some important foundational pieces like how to create good Python packages that wrap your ML functionality and what architecture patterns you can build against.

The last piece of the book focusses on deep dives on a specific topic covers mechanisms for scaling up your solution, with a particular focus on Apache Spark and serverless infrastructure on the Cloud.

Finally, the book finishes with 2 chapters on worked examples that bring together a lot of what's been discussed earlier in the book, with a particular focus on how to make the relevant choices to be successful when executing a real-life ML engineering project.

What's next?

First of all, I'm just super excited this is real. As I mentioned at the top of the article this has been a dream of mine for a long time and I think the topics are important ones to discuss. Hopefully the book can help people in data science, software development, machine learning and analytics roles be successful. That would make me happy too.

In terms of what's next I'm thinking that it would also be beneficial to expand the topics of the book into an online course. That way, people who would like the material structured in a slightly different way can also get the benefit. It would also allow me to expand on some of the material a bit more, giving a more conversational flavour to the material. I like the sound of that, hopefully you do too!

All in all, I just hope people enjoy the book and get benefit from it. I benefited immensely from technical books in this space when I was starting out (and I still do) so I'm really glad I can make my own small contribution to that body of learning.




Machine Learning Architecture - Designing Scalable Solutions

A large part of my job involves designing, building and deploying machine learning solutions for the company I work for. In this post I'm going to quickly highlight some of my key thoughts on this so that if you are new to ML architecture, you can have some good pointers to get from from "blank sheet of paper" to "deployed and running" faster.

The Main ML Architectures

The way I see it, there are only a few ML solution architecture types (they may have fancy names somewhere but I won't know them). I reckon you could assign most, if not all, machine learning implementations into one of these categories (probably because they are so vague/wide-reaching):

  1. The ML Microservice
  2. The Streaming process,
  3. The  Batch process,
  4. The  Integrated approach

I'll go through each of these and list some examples to get you acquainted with what I mean.

The ML Microservice

Imagine you have a map based product, and the user can interact with this product by clicking on one of the entities on the map, for example a truck, and then they can click a button that says "Predict ETA at destination". If I was building an ML based solution for providing that prediction then it would most likely be behind a REST API to some application that read in a request for a prediction and quickly returned that prediction. One way of doing this would be to deploy a lightweight web application (like a Flask app) to a cloud based hosting service. You could design the Flask app to read in your pre-trained machine learning model from a model repository (cloud based storage) and serve predictions via a simple HTTP request-response interaction.

The Streaming Process

In a 'streaming' approach, you are going to work directly with the data as it comes in. This is a type of 'event driven' architecture, whereby an action in one part of the system initiates the next and so on. It is particularly useful for processes which can be a bit ad-hoc in terms of frequency requirements. For example, you may want a streaming process to analyse click data from your web site as it comes in since the production of results works on the same frequency as the ingestion of the data. When there are more clicks, there will be more analysis, when there are no clicks, no analysis. This also means that you do not have to wait for some threshold amount of data to be ingested before performing your action, like you might in a 'batch' approach (see below).

You can do this using tools like Apache Kafka or Spark Streaming.

The Batch Process (or 'ETML')

If the solution has the aim of producing a relatively standardised dataset with some kind of machine learning result on a schedule or very consistent basis, then it may make sense to deploy this as a batch processing service. In this case, you build a pipeline that extracts data, performs the relevant transformations to prepare for modelling, you then perform the model based calculations and surface the results. These steps are why I often call this 'ETML' ('ETL' being 'Extract, Transform, Load', 'ETML' is 'Extract, Transform, Machine Learning').

In my experience, this sort of architecture is often the easiest to develop and deploy. You are building something that is very stable and you usually do not have to worry about successful triggering of the pipeline. In streaming or dynamic services for example, you have to ensure that the REST API request or the event-driven trigger you employ works appropriately in a variety of circumstances through rigorous testing. For a scheduled batch process this is usually much simpler. You just set up your schedule via a cron job or other process, ensure that it works the first few times and then you're off.

The Integrated Approach

This final option is really a kind of exceptional case. I can totally imagine a scenario where you want to embed the machine learning capability directly within some general solution, rather than externalised as a separate service or process. Some good examples where this may apply are:

  • 'Edge' deployments: When you have machine learning running on an IoT device, potentially one with limited connectivity, it might make sense to directly put the machine learning functionality in your main piece of software. However, I would recommend actually following the 'ML Microservice' approach here using something like Docker containers.
  • Integration with another microservice: In this case, you may already be developing a microservice that performs some simple logic and the machine learning is really just an extension or variant of that. For example, if you have already built a Flask web app that returns some information or result, the machine learning could just be another end-point.
  • Out of the box product: If your team is in charge of adding functionality to a piece of software that you are selling onto a client, you may have to package up the machine learning inside the solution somehow. I'm less sure how this would work and I do think that you'd be better using a microservice approach in general.

In Summary

There's a few different ways to package up your machine learning solutions, and it's important to understand the pros and cons of each.