Kiva Systems/Amazon Robotics

logo (3)

 

 

I left Oni Medical Systems to join Kiva Systems just as they were being acquired by Amazon to become Amazon Robotics.

I had a couple of options as I left GE/Oni. One company was starting up a medical robotics group with an associated CT scanner development. The other was Kiva Systems.

As I had just spent ten years working in medical imaging and Kiva had some pretty exciting technology I decided to take the riskier option and go with Kiva.

Kiva developed warehouse (Amazon calls them fulfillment centers) robotic systems where small blocky orange robots roll under sets of shelves and lift up the selected shelving unit to bring it over to a human who can pick out the appropriate material to be shipped.

The original Kiva control system ran on Redhat linux on a blade server with various services distributed across the blades. It was coded in Java with data persisted in a MySQL database and a third party configuration tool to manage warehouse specific settings.

I joined the team to support that third party configuration management system and the Java code that provided customization for it. This was my first serious exposure to Java programming and I accepted a senior level position with the expectation that it would allow me time to become more proficient in Java programming while fill a role the team needed.

After the Amazon acquisition, there was a push to move the bot control systems into the AWS cloud.

The first attempt involved running the existing version of the code on AWS instances (as if they were blades in the blade server). It rapidly became apparent that the characteristics of AWS instances were not compatible with this approach (particularly the fact that instances can go away at any time and there’s no real way to manage the persistence implications of this).

Having failed trying the simple port approach, the team moved on to a ‘chunky’ microservices approach. Initially there was no plan to have central configuration management for fulfillment   center instances or the services themselves. Teams were expected to provide the management user interfaces and storage implementations for their own services.

Having each team do their own thing and with each team having many higher priorities than providing support services with a consistent and safe interface to their service configuration, things became chaotic rather quickly. At this point we argued that having a configuration management micro-service would benefit everyone.

 

After about a year working at Amazon Robotics I concluded that I wasn’t enjoying the culture there and the role I was in was not letting me do the sort of work I enjoy most of the time. It took six months or so but in the end I found a role at KMC Systems and left Amazon.

logo (4)