Wednesday, December 12, 2018

The usage of blockchain in healthcare is gaining traction. Any information that can be privately and securely shared between payers and providers is a good case for blockchain. Jotting down some of the blockchain use-cases that are being explored today -
1) Improving Provider Data Accuracy: Every year, Payers spend millions of dollars in maintaining an up-to-date record of their providers. Provider data management is crucial for maintaining an accurate provider directory. Accurate provider data is critical for connecting patients with appropriate network care providers.

But each Payer has an independent provider directory and repeats the process of collecting and validating provider credentials.
Having a secure blockchain backed provider directory makes sense; as all Payers can collaborate and share provider information. The Synaptic alliance was setup for this exact purpose. The Alliance views blockchain technology as a means to a critical end: ensuring that provider data is accurate and
sharable for reliable use across the healthcare ecosystem. More information about this alliance can be found in this whitepaper here.

2) Clinical Member Profile: Payers often need longitudinal clinical records of a member from different providers to manage the care better. Instead of spending time and effort in setting up brittle interfaces with hospital systems, payers and providers can use a private blockchain system to share clinical member records.
All data in the blockchain would be encrypted and immutable. A private blockchain can also help in regulatory compliance because they establish a trusted audit trail.

HIPAA compliant blockchain HER platforms are already present in the market:

Caveat: Today large volumes of unstructured data (e.g. DICOM images, PDF files) are not cost effective to be stored on a blockchain. It is recommended to store the ‘link references’ to these resources in the blockchain.

Of-late, it has become a fad to label any pilot project as a POV (Proof of Value), rather than a POC (Proof of Concept). But, is there a real difference between POV and POC?
Jotting down my views below:

A POC is typically an internal project and is not exposed to the real end consumer. The objective of an POC is to validate if the technology works or if a concept is viable.

POCs can be used to explore emerging technologies and share knowledge within the team. POCs also help teams come up with more accurate estimation of stories.

Thus a POC will prove that the technology works, but will it deliver the promised business value to the enterprise?

A POV will prove the business value of a concept - it can be in terms of increased ROI, lower TCO, faster GTM or increased customer satisfaction. If these factors can be measured, then you are delivering a POV !

Saturday, October 20, 2018

My team is loving building applications on the cloud and scaling them. Some of the best practices that we implemented in the last few cloud projects are as follows:

1. Infrastructure as Code: It is imperative that you develop automation to build-up and tear-down your complete application infrastructure with just a click of a button. This includes provisioning data services such as RDBMS database, NoSQL data store and populating the data-stores with data. Follow this by deployment of your docker containers containing your web apps/microservices - all managed by Kubernetes. Then finally run a few synthetic transactions to validate the complete setup.

In one of our projects, we could build-up and tear-down the complete pre-prod environment using automation scripts.

2. Stateless Services: In order to have seamless elastic scalability on the cloud, it is important to design your services to be completely stateless. Any state that needs to be saved, should be done in an external store. We have successfully used Redis as the store for many stateful applications or sharing data across microservices.

3. Circuit Breakers and Graceful Degradation: Make sure that service calls happen through a circuit breaker (e.g. Netflix Hystrix). This prevents overloading any system component in the event of a partial failure. Put in mechanisms for graceful degradation where ever possible - e.g. return data from a cache if database is down. Such measures avoid cascading failures.

4. Rolling updates and Canary Deployments: Kubernetes also supports a rolling update, so your downtime is reduced during service updates. Also canary deployments reduce the risk of introducing new features with faster GTM.

5. Autoscaling: Automate for elastic scalability - e.g. if a microservice is running on 4 containers, you should be able to scale-up and scale-down by a click of a button.

6. Redundancy / High Availability: Make sure that all your infrastructure services that are available as managed services on the cloud have redundancy across geographies built in - data stores, messaging middleware, noSQL stores, etc. Make sure that your services are also deployed in a redundant manner across data centers.

Wednesday, October 17, 2018

One of my teams has successfully implemented the paradigm of consumer driven contracts in a recent digital transformation program. We were very happy with the Pact framework and the OOTB integration available in Java (Spring Boot).

The fundamental advantage of Consumer Driven Contracts is that only parts of the API that are actually used by the consumer get tested. Hence any provider behavior not used by current consumers is free to change without breaking tests.
When you are about to change the contract of a popular API, you can quickly check which consumers would be affected and where to focus your efforts on.

It is important to remember that Pact should not be used for functional testing...it is to be used only for contract adherence. Pact can also be integrated into your CI-CD process, wherein you run all the consumer contracts as part of the build.

Saturday, September 08, 2018

Many developers struggle to understand the nuances of parallelism in Kafka. So jotting down a few points that should help from the Kafka documentation site.

Consumers label themselves with a consumer group name, and each record published to a topic is delivered to one consumer instance within each subscribing consumer group. Consumer instances can be in separate processes or on separate machines.

Publishers can publish events into different partitions of Kafka. The producer is responsible for choosing which record to assign to which partition within the topic. This can be done in a round-robin fashion simply to balance load or it can be done according to some semantic partition function (say based on some key in the record).

The partitions in the log serve several purposes. First, they allow the log to scale beyond a size that will fit on a single server. Each individual partition must fit on the servers that host it, but a topic may have many partitions so it can handle an arbitrary amount of data. Second they act as the unit of parallelism.

Unlike other messaging middleware, parallel consumption of messages (aka load-balanced consumers) in Kafka is ONLY POSSIBLE using partitions.

Kafka keeps one offset per [consumer-group, topic, partition]. Hence there cannot be more consumer instances within a single consumer group than there are partitions.

So if you have only one partition, you can have only one consumer (within a particular consumer-group). You can of-course have consumers across different consumer-groups, but then the messages would be duplicated and not load-balanced.

Many of our customers are moving their traditional ETL jobs to real-time stream processing.
The following article is an excellent read of why Kafka is an excellent choice for unified batch processing and stream processing.

Several recent data trends are driving a dramatic change in the old-world batch Extract-Transform-Load (ETL) architecture: data platforms operate at company-wide scale; there are many more types of data sources; and stream data is increasingly ubiquitous

Enterprise Application Integration (EAI) was an early take on real-time ETL, but the technologies used were often not scalable. This led to a difficult choice with data integration in the old world: real-time but not scalable, or scalable but batch.

Apache Kafka is an open source streaming platform that was developed seven years ago within LinkedIn.

Kafka enables the building of streaming data pipelines from “source” to “sink” through the Kafka Connect API and the Kafka Streams API.

Logs unify batch and stream processing. A log can be consumed via batched “windows”, or in real time by examining each element as it arrives.

Thursday, August 30, 2018

Tip 1#: To find out the number of threads spawned by the JVM, run the following command: ps -eLF
This command will also print a column called 'LWP ID' (light-weight process ID) that prints the thread-id and the CPU utilization of that thread. This same thread-id can be correlated in the thread-dump obtained from the JVM.

Tip 2#: The thread-dump can be obtained by using the following command: jstack PID
If you are using Spring Boot framework, then we can use the Actuator URLs to download the thread-dump.

Tip 3#: This thread-dump file can be uploaded to a cool online tool : http://fastthread.io/ which gives a beautiful report on the threads running inside the JVM that can be analyzed.

Wednesday, August 29, 2018

Recently we were analyzing the thread-dumps of some JVMs in production and found a large number of threads created in certain thread-pools. Since the name of the thread-pool was generic (e.g. thread-pool-3, etc.) it was very difficult to diagnose the code that spawned the thread-pool.

The following code snippets should help developers in properly naming their thread-pools and also limiting the number of threads. In a cloud environment, the number of default threads in a pool will vary based on the CPU's available - for e.g. in the absence of a thread-pool size, the thread pool may grow to hundreds of threads.

We had seen this happen for the RabbitMQ java client. The default RabbitMQ java client uses a thread pool for callback messages (ACK) and the size of this thread-pool depends on the number of CPUs. Since the JVM is not aware of the docker config, all the processors on the host machine are considered and a large thread pool is created.

Wednesday, July 18, 2018

In Event Driven Architectures, you often have to create a pipeline of event processing. One of my teams was using Spring AMQP libary and wanted to implement the following basic steps.
1. Read a message from the queue using a RabbitMQ channel.
2. Do some processing and transform the message.
3. Publish the message downstream with the same channel

The sample code given below will help developers in implementing this.

Another scenario is when you have multi-threaded code that is publishing messages to RabbitMQ, then you can use the RabbitMQTemplate with Channel caching. Sample code given below.

Wednesday, May 23, 2018

Over the past few years, we have been using story points for estimation, rather than using man-hours.
For a quick introduction of agile estimation, please peruse the following links that give a good overview.

But still folks struggle to understand the advantages of estimating by story points. During the planning poker session, all team members discuss each story point and arrive at the story points through consensus. Thus each team member has skin in the game and is involved in the estimation process.

The time needed to complete a story point will vary based on a developer’s level of experience, but the amount of work is correctly estimated using story points.

IMHO, velocity should be calculated only after 2-3 sprints. This average velocity (#story-points/sprint) can be used to estimate the calendar timelines for the project.

Sunday, March 18, 2018

Recently we successfully implemented secure Websockets in one of our projects and learned a lot of tricks to get things working together. Given below are some tips that would help teams embarking on implementing WebSockets in their programs.

1) Spring uses the STOMP protocol for Web Sockets. The other popular protocol for Web Sockets is WAMP, but Spring does not support it. Hence if you are using Spring, make sure that your Android, iOS and JS libraries support STOMP.

2) Spring websocket library by default also supports SockJS as a fall-back for web JS clients. If your use-case only entails supporting Android and iOS clients, then disable SockJS in your Spring configuration. It might happen that a use-case might work on SockJS on a web-client, but fail in native mobile code.

3) The default SockJS implementation of Spring, sends a server heartbeat header (char 'h') every 25 seconds to the clients. Hence there is no timeout on the socket connection for JS clients. But on mobile apps (pure STOMP), there is no heartbeat configured by default. Hence we have to explicitly set the heartbeat on the server OR on the client to keep the connection alive when idle. Otherwise, idle connections get dropped after 1 minute. Reference Links: https://stackoverflow.com/questions/28841505/spring-4-stomp-websockets-heartbeat
Sample server side code below.

5) On iOS, the following socket library worked very well with Spring websockets - https://github.com/rguldener/WebsocketStompKit. We faced an issue, where this library was throwing Array Index Range exceptions on server side heartbeat messages, but we made small changes in this library to skip process for heart-beat header messages.

6) It is recommended to give the URL scheme as wss://, although we found that https:// was also working fine. If you have SockJS enabled on Spring, then please append the URL with /websocket, as you would get a exception stating invalid protocol up-gradation. Hence clients should subscribe to/{endpoint}/websocket. https://github.com/rstoyanchev/spring-websocket-portfolio/issues/14

Tuesday, March 13, 2018

In my previous post, we discussed about how we can extract an arbitrary JSON value out of a JSON string. Very often, developers face another error while using Jackson - com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field error.

This happens when your JSON string has an attribute that is not present in your POJO and you are trying to deserialize it. Your POJO might not be interested in these fields or these fields could be optional.

To resolve this error, you have two options:

Option 1: Disable the error checking on the Jackson Mapper class as follows.objectMapper.disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)
Option 2: If you have access to the POJO object, then you can annotate it as follows@JsonIgnoreProperties(ignoreUnknown = true)

Saturday, March 10, 2018

One of the challenges my team was facing was to accurately identify the consumers of a RabbitMQ queue. Let's say if you have 5 consumers and you want to kill one of them through the dashboard, you need to identify the consumer.

Each consumer of RabbitMQ has a tag value that can be used to uniquely identify it. By default, RabbitMQ assigns some random number as the consumer tag, but just by looking at this random string tag there is no way to identify the actual consumer.

To resolve this, you need to create a ConsumerTagStrategy and associate it with the MessageListenerContainer. Code snippet given below:

Tuesday, February 27, 2018

Most BPM tools today support both BPMN (business process modeling notation) as well as CMMN (Case Management Modeling Notation). But when to use what?

It all depends on the process that you want to model. Given below are some tips that can be used to decide whether to model the process as a traditional BPM or a case management solution.Traditional BPM:

If your process is a predefined and ordered sequence of tasks - e.g. sending out a insurance renewal message, onboarding an employee, etc.

The order of the steps rarely change - i.e. the process is repeatable.

Business users cannot dynamically change the process. The process determines the sequence of events.

Case Management:

When the process does not have a strict ordering of steps - e.g. settling a claim.

The process depends on the knowledge worker, who decides the next steps.

External events (submission of documents) determine what next step the knowledge worker will take.

Case management empowers knowledge workers and provides them with access to all the information concerning the case. The knowledge worker then uses his discretion and control to move the case towards the next steps.

Using the above guidelines, you can model your process using BPMN or CMMN. Business rules can be modeled as DMN (decision modeling notation).

The team wanted to add additional filters to this pipeline of Security filters. There are many ways of achieving this:

Option 1: Create a custom filter by extending the Spring GenericFilterBean class. You can set the order by using the @Order annotation.

Option 2: Register the filter manually in the WebSecurityConfigurerAdapter class using the addFilterAfter/addFilterBefore methods.Option 3: Set the property "security.filter-order=5" in your application.properties. Now you can add upto 4 custom filters and set the order as either 1,2,3,4.
Another option is to manually set the order (without annotations) using FilterRegistrationBean in any @Configuration

Monday, January 29, 2018

In the V model of software testing, the fundamental concept in to interweave testing activities into each and every step of the development cycle. Testing is NOT a separate phase in the SDLC, but rather testing activities are carried out right from the start of the requirements phase.

During requirements analysis, the UAT test cases are written. In fact, many teams have started using user stories and acceptance criteria as test cases.

System test cases and Performance test cases are written during the Architecture definition and Design phase.

Integration test cases are written during the coding and unit testing phase.

Monday, January 22, 2018

We have been evaluating the Netflix open source Conductor project and are intrigued by the design decisions made in it.

Netflix Conductor can be used for orchestration of microservices. Microservices are typically loosely coupled using pub/sub semantics and leveraging a resilient message broker such as Kafka. But this simple and proven event driven architecture did not suffice the needs for Netflix.

A good article on the challenges faced by the Netflix team and the genesis of Conductor is available here. Snippets from the article:

"Pub/sub model worked for simplest of the flows, but quickly highlighted some of the issues associated with the approach:

Process flows are “embedded” within the code of multiple applications - e.g. If you have a pipeline of publishers and subscribers, it becomes difficult to understand the big picture without proper design documentation.

There is tight coupling and assumptions around input/output, SLAs etc, making it harder to adapt to changing needs - i.e. How will you monitor that the response for a particular task is completed within a 3 second SLA? If not done within this timeframe, we need to mark this task as a failure. Doing this is very difficult with pub/sub unless we code this ourselves.

No easy way to monitor the progress - When did the process complete? At what step did the transaction fail?

To address all the above issues, the Netflix team created Conductor. Conductor servers are also stateless and can be deployed on multiple servers to handle scale and availability needs.

Most REST services are stateless - i.e. they do not store state in memory and can be scaled out horizontally.

There is another concept called a 'idempotent' operation. An operation is considered to be idempotent if making the same call with the same input parameters repeatedly gives the same results. In other words, the service does not differentiate between one call or a million calls.

Wednesday, January 17, 2018

Deep learning is a branch of machine learning that uses multi-layered neural networks for solving a number of challenging AI problems.

GPU (Graphics Processing Unit) architecture are fundamentally different from CPU architecture. A GPU chip would be significantly slower that a CPU, but a single GPU might have thousands of cores while a CPU usually has not more than 12 cores.

Hence any task that can be parallelized over multiple core is a perfect fit for GPUs. Now it so happens, that deep learning algorithms involve a lot of matrix multiplications that are an excellent candidate for parallel processing over the cores of a GPU. Hence GPUs make deep learning algorithms run faster by an order of magnitude. Even training of models is much faster and hence you can expedite the GTM of your AI solutions.

An example of how GPUs are better for AI solutions is considering AlexNet, a well known image classification deep network. A modern GPU costing about $1000 takes 2.5 days to fully train AlexNet on the very large ImageNet dataset. On the otherhand, it takes a CPU costing several thousand dollars nearly 43 days.
A good video demonstrating the difference between GPU and CPU is here:

Quite often, we need a REST API to respond within a specified time frame, say 1500 ms.
Implementing this using the excellent Spring RestTemplate is very simple. A good blog explaining how to use RestTemplate is available here - http://www.baeldung.com/rest-template

Monday, January 08, 2018

On docker containers, developers often come across OOM (out-of-memory) errors and get baffled because most of their applications are stateless applications such as REST services.

So why do docker containers throw OOM errors even when there are no long-living objects in memory and all short-lived objects should be garbage collected?
The answer lies in how the JVM calculates the max heap size that should be allocated to the Java process.

By default, the JVM assigns 1/4 of the total physical memory as the max heap size for the Java runtime. But this is the physical memory of the server (or VM) and not of the docker container.
So let's say your server has a memory of 16 GB on which you are running 8 docker containers with each container configured for 2 GB. But your JVM has no understanding of the docker max memory size. The JVM will allocate 1/4 of 16 GB = 4 GB as the max heap size. Hence garbage collection MAY not run unless the full heap is utilized and your JVM memory may go beyond 2 GB.
When this happens, docker or Kubernetes would kill your JVM process with an OOM error.

You can simulate the above scenario and print the Java heap memory stats to understand the issue. Print the runtime.freeMemory(), runtime.MaxMemory() and runtime.totalMemory() to understand the patterns of memory allocation and garbage collection.

The diagram below gives a good illustration of the memory stats of JVM.

So how do we solve the problem? There is a very simple solution - Just explicitly set the max memory of the JVM when launching the program - e.g. java -Xmx 2000m -jar myjar.jar
This will ensure that the garbage collection runs appropriately and an OOM error does not occur.
A good article throwing more details on this is available here.

Also, it is important to understand that the total memory consumed by a Java process (called as Resident Set Size RSS) is equal to the heap size + Perm Size (MetaSpace) + native memory (required for thread stacks, file pointers). If you have a large number of threads, then native memory consumption can also be high (No. of threads * -Xss)

Since JDK 8, you can also utilize the following -XX parameters:-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap //This allows the JDK to understand the CGroup memory limits on the Linux kernel-XX:MaxRAM //This specifies the max memory allocated to the JVM...includes both on-heap and off-heap memory.

In Java 10, a lot of changes have been made to the JDK to make it container friendly and you would not need to specify any parameters.