Classification of medical devices by FDA

In the US, the Food and Drug Administration (FDA) regulates any apparatus involved in diagnosing or treating disease.

While we were working on an IoT enabled Diabetes Management Solution, we learned that the FDA classifies all medical devices into 3 categories  - Class 1 / Class 2 & Class 3.

• Class 1 devices are low risk devices and have minimum regulatory control. For e.g. dental floss, lancets, etc.  These devices must be listed in the FDA's medical device registry, but do not have a stringent approval process. 
• Class 2 devices have higher risk and need stronger regulatory controls. For e.g. blood glucose meters, test strips, insulin pumps, etc. 
• Class 3 devices have the highest risk and therefore have the highest level of regulatory control. For e.g. heart valves, continuous glucose monitors, artificial pancreas, etc. 

Digital in brick-n-mortar stores

While a lot of attention has been given to online experiences in digital transformation, there are a lot of opportunities in enhancing the in-store experience in brick-n-mortar stores.

Google has published some interesting stats on the use of smartphones within stores here - https://ssl.gstatic.com/think/docs/mobile-in-store_infographics.pdf

Some interesting stats:

1. 84% of customers use their mobile phone in stores to help them shop. 
2. Customers spend an average of 15 mins using their smartphones inside stores.
3. Customers use their smartphones for searching for products/services - 82% use a Search Engine, 62% use Store website, 50% use Brand website. 

Thus mobile has the power to transform the shopping experience in stores. Also beacons can be utilized to provide location context sensitive promotions to customers. 

SweetIQ has put up a neat infographic that illustrates how beacons can be used to enhance the in-store digital experience. 

Managing Database Versions in an Agile Project

Today we have a robust set of tools for code versioning, CI and release management - for e.g. Java, .NET, Ruby web or REST applications. Examples of tools are Github, Hudson, Jetkins, etc.

But what about the RDBMS? How do we manage it across the various environments - i.e. from development to integration to UAT to production. A good illustration of the typical challenges is given here.

Flyway is a tool to address these problems. Using simple techniques such as a schema-version table and automatically apply db scripts (that follow a naming convention for sequence tracking), the tool can help any Agile project in managing RDBMS instances across different environments. It would also be a nifty addition to your existing DevOps tools. 

Service Discovery Mechanisms in Microservices

In a microservices based architecture, we would not know the number of instances of a server or their IP addresses beforehand. This is because microservices typically run in VMs or Docker containers that are dynamically spawned based on usage load.

So consumers would need some kind of service discovery mechanism to communicate with microservices. There are two options to design this -

a) Server-side Service Discovery - Here the consumers make a request to a load-balancer/service registry and then the request is routed to the actual service end-point. This paradigm is clearly explained on this blog here. Examples of this design pattern is the AWS Elastic Load Balancer.


b) Client-side Service Discovery - Here the consumers use a small library for making service calls. This library makes calls to the service registry and obtains the load-balanced actual service end-point. Netflix uses this approach and its service registry is called Eureka and its client library is called Ribbon.

Handling failures and improving resilience in microservices

In a microservices architecture, one has to build services that can handle failures. For e.g. If a microservice calls another dependent microservice that is down, then we need to handle this using timeouts and implement the Circuit Breaker pattern.

Netflix has open-sourced an incredibly useful library called as Hystrix to solve such problems. Anyone building large scale distributed architectures on the Java platform would find Hystrix a boon. When you make a remote service call through Hystrix libraries, it does the following:

1. If the remote service call does not return within a specified threshold, Hystrix times-out the call.
2. If a service is throwing errors and the number of errors exceed a threshold, then Hystrix would trip the circuit-breaker and all requests would fail-fast for a specified amount of time (recovery period)
3. Hystrix enables developers to implement a fall-back action when a request fails, for e,g returning a default value or a null value or from cache. 

The full operating model of Hystrix is explained in great details on Github wiki 

It was also interesting to learn that the tech guys at Flipkart have taken Hystrix and implemented a service proxy on top of it called 'Phantom'. Looks like the advantage of using Phantom is that your consumers do not have to code against the Hystrix libraries. 

Ruminating on SemVer

Semantic Versioning (aka SemVer) of components has become mainstream today. The official page laying out the guidelines is available here - http://semver.org/

Following SemVer, each component has a 3 digit version in the format of 'Major.Minor.Patch' - for e.g. 2.3.23

• You increment the major version, when you make incompatible changes. 
• You increment the minor version, when you make changes but those changes are backward compatible.
• The patch digit is incremented when you just make a bug-fix and it is obviously backward compatible.
• With SemVer, pre-releases can be defined by appending a hyphen and the word 'alpha/beta' after it. For e.g. a pre-release for version 3.0.0 could be 3.0.0-alpha.1. 

Following SemVer is a boon in managing dependencies between components. So if component A is using version 4.2.3 of component B, then you know that as long as version B does not become 5.x.y, there would be no breaking changes. You can specify dependencies in the manifest file of a component.

While using SemVer for software components is fine, does it make sense to have the x.y.z version in the URL of public APIs?
APIs are the interfaces you expose to your consumers. Do your consumers really need to know about the bug fixes you have made? or the new features you have added? Maybe yes or no !
IMHO, just using a single version number in your API URL would suffice majority of real life business usecases. For e.g. https://api.company.com/v1/customer.

A good blog post by APIGEE on API versioning is available here. As stated in the blog - "Never release an API without a version and make the version mandatory."

If you want to constrain the amount of information that you want back from the API (e.g. mobile client on slow networks), then you can follow this strategy. Another alternative is to look at new options such as GraphQL. 

Ruminating on Netflix Simian Army

A friend of mine introduced me to the a suite of powerful tools used at Netflix for testing the resilience and availability of their services. The suite of tools is called 'Simian Army', which essentially is a collection of tools such as 'Chaos Monkey', 'Latency Monkey', 'Security Monkey', etc.

I was aware that Netflix runs its entire IT infrastructure on AWS and was happy to hear that all the tools are available on Github here - https://github.com/Netflix/SimianArmy/wiki

A good introduction to the genesis behind these tools is given on the Netflix blog here - http://techblog.netflix.com/2011/07/netflix-simian-army.html

Another interesting blog on the lessons that Netflix learned after migrating to AWS is available here.