DevOps for Cognitive Services

It is common to talk about “last mile” adoption problems for both Agile (usually traditional QA teams, in other cases, traditional business teams) and now DevOps (again QA and Data teams as the typical bottlenecks).

I have recently been working with the Microsoft Cognitive Toolkit (CTK), and asked myself the same question on how to create a continuous delivery pipeline for AI applications. If AI implementations grow as much as Gartner is predicting, the deploying AI apps have a good change of become the next “last mile” problem.

Researching on this, came across an article on DevOps for Data Science and AI: Team Data Science Process for Developer Operations, with the description “This article explores the Developer Operations (DevOps) functions that are specific to an Advanced Analytics and Cognitive Services solution implementation.”

However, instead of the (more recently) clear-cut how-to documentation that Microsoft has been providing as part of its VSTS products, this article seemed more like a list of building blocks that need to be distilled into at least a nice simple sample implementation.

Investigating the Azure Data Science Virtual Machine seems the next step to better understand how everything is connected. Among other things it has the CTK installed, which is what is attracting my attention in this area. As a production solution though, it is not the final answer, so to define a process to deliver from this machine as a development environment to a production business server, a lot has still to be done.

I will continue experimenting and will let you guys know next. My ultimate goal would be to use some version of Prolog.

Successful delivery of the first Microsoft DevOps FastTrack in Mexico

I just returned from Mexico where I worked for two weeks with one of the country’s biggest companies, and delivered  the first Microsoft DevOps FastTrack there (all in Spanish ;-)). It was a fantastic experience to work with such a tight knit team (about 16 people).

For obvious reasons I can’t share too many details about the engagement. I can however share one key fact that pretty much won over their hearts and minds on adopting VSTS not only for this project, but also for the rest of the company as well. Here is the list of tools we used:

Programming languages:

  • Jersey with Java 8 (JDK 1.8)
  • JavaScript with Angular 1.X
  • HTML 5, CSS3 with a Bootstrap template

Programming tools:

  • NetBeans 8.2
  • Visual Studio Code 1.19

Dependency Managers:

  • Maven 3.x
  • npm
  • bower

Testing frameworks:

  • JUnit and RestAssured for Java
  • Selenium for frontend

HTTP Servers:

  • Tomcat 8.54
  • Apache httpd 2


  • PostgreSQL 9.6, client PgAdmin 9.3
  • Flyway 5.0.5

Version Control:

  • Git 2.15.1

As you can see, it was all done using either OSS or non-Microsoft tools. The only Microsoft tool (other than VSCode) was VSTS for project Management and DevOps, and also for overall orchestration of the whole process.

So we started with a skeptical team thinking Microsoft (me on their behalf) is going to try and impose a Microsoft tool stack, and ended up with an elated team using their current existing toolset being coordinated with VSTS. For them this was a very powerful statement from Microsoft about their support for OSS and tool diversity: we can work with all kinds of toolsets.

Having worked with Microsoft during a time where it was heavily focused on just pushing its own products, the current general attitude of respect, openness and inclusiveness I am getting from all parts of Microsoft is a breath of fresh air, and customers are noticing (for a non-code example, see for instance this article).


<<  May 2024  >>

View posts in large calendar

Month List