Friday, September 24, 2021

Ruminating on R&D investment capitalization

When organizations invest in R&D activities, there are accounting rules for claiming tax credits. The reason governments give tax credits is to encourage innovation thorough R&D spending. 

Earlier, the accounting rules mandated all R&D investments to be shown as "expenses" on the Profit and Loss (P&L) statement in the same year, the investments were made. But this poses a problem as the return of a R&D investment could be over multiple future years. Also R&D investments can vary widely every year and its net profit can be significantly higher or lower because of the timing of R&D spending. 

Hence in the new accounting rules, instead of treating R&D investments as an "expense" in the P&L statement, it is treated as an "Asset" in the balance sheet. This is referred to as "Capitalizing the R&D expense". 

Once the R&D investment is treated like an "Asset", the company can claim amortization (or depreciation) benefits on it over multiple years. For example - A software firm has invested 1 MM USD in R&D to build a product in 2021. The economic life of the built product is 5 years.  The company can then amortize/depreciate the capitalized R&D expenses equally over the five-year life. This amortized amout per year is a line item in the yearly P&L statement. 

A good explanation of this concept is given here -

Wednesday, September 08, 2021

Ruminating on Systems Thinking

Systems Thinking is an approach towards problem solving that emphasizes the fact that most systems are complex and do not have a linear cause-effect relationship. We need to view the problem as part of a wider dynamic system and understand how different parts interact or influence one other. 

The crux of systems thinking is the ability to zoom out and look at the big picture (holistic view) - to understand the various factors or perspectives that play a role. 

By steering away from linear thinking into systems thinking, we will make better decisions in all aspects of business. System thinking also helps us to think in terms of ecosystems and not just be confined by traditional boundaries. 

The following video is an excellent tutorial on Systems Thinking -

Other good links showing examples of system thinking: 

- Use of DDT for mosquitos:

- Systems thinking for water services - e.g. understanding the impact of rainfall, educating customers to improve the quality of wastewater, external factors such as new building development, rising river levels, etc :

Wednesday, September 01, 2021

Ruminating on Data Drift and Concept Drift

 Quite often, the performance (accuracy of prediction) of a AI model degrades with time. One of the reasons this happens is due to a phenomenon called as "Data Drift". 

So what exactly is Data Drift? 

Data Drift can be defined as any change to the structure, semantics or statistical properties of data - i.e. model input data.  

  • Changes to structure of data: New fields being added or old field deleted. This could happen because of a new upgrade to a upstream system, a new sensor, etc. 
  • Changes to semantics of data: A new upstream system is sending temperature in F and not C. 
  • Changes to statistical properties of data: Changes to the atmospheric pressure threshold levels due to environmental changes. There could be also data quality issues such as a bug in upstream system that delivers junk data. 

To maintain the accuracy of our AI models, it is imperative that we measure and monitor Data Drift. Our machine learning infrastructure needs to have tools that automatically detect data drift and can pin-point the features that are causing the drift. 

Changes to the underlying statistical properties of data is also called as "Concept Drift". A classic example of this is the current pandemic. The "behaviour" or "concept" has changed after the pandemic - e.g. models that predict the amount of commute time are no longer valid. Models that forecasted the number of the cosmetic surgeries in 2021 are no longer valid. 

Most of the hyperscalers provide services that enable us to monitor data drift and take proactive actions. The below links provide some examples of cloud services for data drift:

Thursday, February 04, 2021

Process Discovery vs. Process Mining

The first step in automation is to gain a complete understanding of the current state business processes. Often enterprises do not have a knowledge base of all their existing processes and hence identifying automation opportunities becomes a challenge. 

There are two techniques to address this challenge:

Process Discovery

Process Discovery tools typically record an end-user's interactions with the business applications. This recording is then intelligently transformed into process maps, BPMN diagrams and other technical documentation. The output from the Process Discovery tool can also be used to serve as a foundation for building automation bots. Given below are some examples of Process Discovery tools:

Process Mining

Process Mining is all about extracting knowledge from event data. Today all IT systems and applications emit event logs that can be captured and analysed centrally using tools such as Splunk or ELK stack. As one can imagine, the biggest drawback of Process Mining is that it would not work if your legacy IT systems do not emit logs/events. 

By analysing event data, Process Mining tools can model business process and also capture information on how the process performs in terms of latency, cost and other KPIs (from the log/event data). 

Given below are some examples of Process Mining tools:

Tuesday, February 02, 2021

Ticket Triaging with AI

The below link is a comprehensive article that introduces "ticket traiging" and also explains how AI can be used to automate this important step.

Some snippets from the article:

"Automated ticket triaging involves evaluating and directing support tickets to the right person, quickly and effectively, and even sorting tickets in order of importance, topic or urgency. Triage powered by Natural Language Processing (NLP) technology is well-equipped to understand support ticket content to ensure the right ticket gets to the right agent.

NLP can process language like a human, by reading between the lines and detecting language variations, to make sense of text data before it categorizes it and allocates it to a customer support agent. The big advantages of using NLP is that it can triage faster, more accurately and more objectively than a human, making it a no-brainer for businesses when deciding to switch from manual triage to auto triage."

Wednesday, December 16, 2020

Ruminating on JAB (Java Access Bridge)

Quite often, we need to build automation around Java desktop apps. The default MS UI automation framework would not be able to identify Java UI components (based on Swing). 

Hence we need to use a bridge..and this technology is called as JAB (Java Access Bridge). Using the JAB dll on windows, you can access Java client UI controls and build your automation use-case. All commercial tools such as UiPath, AA also use JAB behind the scenes for Java desktop automation. 

Google has also released a cool tool called "Access Bridge Explorer" that can allows exploring, as well as interacting with, the Accessibility tree of any Java applications that uses the Java Access Bridge to expose their accessibility features,

Wednesday, October 28, 2020

Finding the .NET version on windows

 In Java, you can execute a simple command "java -version", but unfortunately it is not so straightforward in .NET.

The below stackoverflow thread shows some commands that can be leveraged to find out the .NET version -

The commands which worked for me on Win10 are as follows:

Command Prompt (cmd):

dir /b /ad /o-n %systemroot%\Microsoft.NET\Framework\v?.*

The above command will list down all versions of .NET except v4.5 and above. 

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\full" /v version

The above command will work for .NET versions v4.5 and above. 


gci 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -recurse | gp -name Version,Release -EA 0 | where { $_.PSChildName -match '^(?!S)\p{L}'} | select PSChildName, Version, Release

The above powershell command is the most versatile and will list down all versions. 

Saturday, October 24, 2020

Ruminating on Ontology

Ontology is nothing but the structure of knowledge (a language to represent knowledge). The primary objective of an Ontology is to describe the knowledge about a domain (concepts and relationships). 

In data science, ontologies can be used to create a semantic layer on top of existing data to make existing organizational data FAIR (Findable, Accessible, Interoperable and Reusable). 

Protege ( is an excellent free opensource tool to create ontologies. A fun example of a pizza ontology can be found here

The Web Ontology Language (OWL) is a suite of knowledge representation languages for authoring ontologies. For UML lovers, there is also a OWL profile for UML. A good example of using the OWL profile for UML is here -

Friday, October 02, 2020

Ruminating on Automation (RPA) Security Risks

 Intelligent automation & RPA can drive operational efficiencies at organizations and help boost the productivity of enterprise resources. But there is also a risk of cyber-attacks as bots introduce a new attack surface for hackers. 

Without proper measures, enterprises may face increased risk exposure due to bots. The following recommendations would enable organizations to mitigate the risk of such security attacks.

  1. Secure Vault: All credentials required by the bot to execute tasks on applications should be securely stored in a Vault (e.g. CyberArk or HashiCorp Vault). This ensures that the target application credentials are not stored by the bot and only accessed at runtime by the bot from the vault. 

  2. Least Privilege Access: bots should not be given a blanket access to perform all operations, but should be given only appropriate access as required for the automation usecases - e.g. many automation usecases would entail 'read-only' access to databases/applications. 

  3. Selecting appropriate Automation use-cases: While down-selecting automation usecases, it would be good to have 'Security Risk' as an parameter for assessment. If a bot needs admin access across multiple applications to perform critical business functions, then the organization can decide to NOT automate this usecase and handover the case to a knowledge worker. The bot can enable this smooth transition to humans (via a workflow or case management tool).

  4. Change Bot passwords/secure keys: As a security best practice, change the passwords and secure keys for the bots (and machines where bots run) regularly (e.g. once a month). 

  5. Security Testing of Bots: Ultimately bots are also software components and we need to make sure that the bots undergo both static code security analysis and runtime security testing. 

  6. Audit Trail & Proactive Monitoring: The automation framework should provide a detailed audit log of all bot activities. Each and every step executed by the bot should be available for forensic audit if required. Proactive monitoring of this audit log can also be automated to quickly alert users of any anomaly pattern or security breach. 

  7. Governance Framework - Last but not the least, it is important to setup a proper governance framework for bot lifecycle management. The governance framework should clearly define the roles and responsibilities and the proper process to be followed for the entire bot lifecycle. 

Thursday, August 27, 2020

Automating API creation over existing data-sources

 If you need to quickly build REST APIs over existing data in excel sheets, RDBMS, NoSQL data stores; then the DreamFactory toolkit is immensely helpful. 

DreamFactory is available under the Apache 2 license and you can host it on your public/private cloud platforms. Just with a few clicks, you will have a complete secure API service available to perform CRUD operations on your data. DreamFactory runs on the Apache LAMP stack ((Linux, Apache, MySQL, PHP/Perl/Python). 

Besides generating the APIs, DreamFactory can also dynamically generate a Client SDK for HTML5 frameworks like jQuery, AngularJS, and Sencha, and a code library for native clients like iOS, Windows 8, and Android.

DreamFactory also has a toolkit to convert your SOAP webservices into REST APIs -

It also has a cool feature called DataMesh wherein we can create virtual foreign key relationships between tables in the same database or between completely different databases without altering your schema or writing any code. Create, read, update, or delete objects and related objects with a single API call.

DreamFactory also automatically creates Swagger API documentation and has basic API Management capabilities built in (e.g. rate limiting)

Displaying PDF, Word, PPT docs on web pages

 If you need to display documents in PDF, Word or PPT formats on your web application, then the following JavaScript toolkit will come to your rescue. 

ViewerJS -

ViewerJS uses 2 other JS libraries behind the scenes - PDF.js ( and WebODF (

Any document that is following the Open Document Format (ODF) can be rendered using ViewerJS. All Office 365 files now follow the ODF format. 

Wednesday, August 12, 2020

Ruminating on the hype around hyper-automation

 So what exactly is hyper-automation?

In simple terms 'Hyper-Automation' is going beyond plain RPA. In RPA, the bot just mimics what a human would do. 

But in hyper-automation, along with the RPA tool, we use other technologies like AI/ML, workflow engine, rules engine to automate E2E process flows. Thus we make the business process more streamlined and robust ---- essentially better than what the human was doing. 

Even Process Discovery Tools are considered to be an important part of the hyper-automation journey. Process Discovery Tools enable us to understand the current state business processes and offers suggestions on streamlining it. It does not make sense to automate a fragmented process, but we should first streamline the process, remove redundancies and then automate it. 

Example - A bot reading an unstructured email and understanding its intent, extracting relevant data points from it (AI) and completing the requested transaction via a desktop app (RPA). 

Wednesday, June 24, 2020

Ruminating on Asynchronous Request-Reply pattern over HTTP

Quite often, a HTTP request would entail processing on some back-end that communicates via messaging. In such cases, do we keep the server thread waiting for a response on the queue? or do we have a better design pattern to handle such scenarios.

The following article on Microsoft illustrates a good pattern for Asynchronous Request-Reply pattern over HTTP -

Excerpts from the article: 
  1. The client sends a request and receives an HTTP 202 (Accepted) response.
  2. The client sends an HTTP GET request to the status endpoint. The work is still pending, so this call also returns HTTP 202.
  3. At some point, the work is complete and the status endpoint returns 302 (Found) redirecting to the resource.
  4. The client fetches the resource at the specified URL.

Sunday, May 31, 2020

Ruminating on Mutual Authentication

In mutual authentication, both the server as well as the client have digital certificates and authenticate each other. If both the server and client are using CA signed certificates, then everything would work OOTB and there would be no need to import any certificates. This is because, both the server and client default trust stores would have the root certificates of most CAs.

But during testing and in lower environments, teams often use self-signed certificates. To enable mutual authentication using self-signed certificates, we have 2 options. 
  • Peer-2-Peer: Create a client certificate for each agent. Import this cert into the trust store of the server. 
  • Root cert derived client certifications:  Create a client root certificate and using this root certificate, create/derive client certs for each agent. Then you just have to import the client root certificate into the server trust store ( and not of all the agents).    

Thursday, May 28, 2020

Ruminating on Azure RTOS

Microsoft acquired ThreadX from Express Logic and re-branded it as Azure RTOS. ThreadX was already a popular RTOS that is being used by more than 6.5B devices worldwide.
** Gartner predicts that by 2021, one million new IoT devices will come online every hour of every day. In 2019, there were approx 27B IoT devices.

Besides ThreadX, Azure RTOS has also packaged other modules such as GuiX, FileX, NetX, USBX, etc. 

The below link points to an interesting conversation with Bill Lamie - founder of ThreadX. 

Jotting down some interesting points below. 
  • The most important characteristic of an RTOS is size. RTOS size is typically in KB, whereas general purpose OS is in MB or GB. Because of this size, RTOS can be used in the smallest of devices...even battery powered ones - e.g. fitness wearables, medical implants, etc. So essentially RTOS is great for constrained/smaller devices. 
  • RTOS is "real-time" because the OS responds to real time events in a deterministic time frame. An RTOS guarantees that certain actions can happen on IoT devices within defined time limits - a feature called as determinism. 
  • The size of Azure RTOS can scale down all the way to 2KB. A cloud connected RTOS would take 50KB.
  • Azure RTOS also brings in best-of-class security with multiple security certifications. 
  • The complete source code of Azure RTOS is open-source and available on GitHub at
Before the acquisition of Express Logic, Microsoft had an offering called Azure Sphere OS that was positioned as an OS for edge devices. Azure Sphere is more secure and is Linux kernel based, but cannot run on highly constrained devices. Also it has a Linux kernel and is not an RTOS and hence cannot provide deterministic execution. 

Though Microsoft is currently stating that Azure RTOS and Azure Sphere are complementary, only time will tell which OS the industry adopts. 

Saturday, April 18, 2020

Performance instrumentation via DataDog

Recently my team was looking for a solution to implement custom metrics in Java microservices that would then ultimately be fed to DataDog. We explored the following multiple options to add custom performance instrumentation.
  • Using StatsD: StatsD is a  network daemon that runs on the Node.js platform and listens for statistics, like counters and timers, sent over UDP or TCP and sends aggregates to one or more pluggable backend services (e.g., Graphite, DataDog). StatsD is very popular and has become a de facto standard for collecting metrics. Opensource libraries are available in all popular languages to define and collect metrics. More information on StatsD can be found here -
  • Using DogStatsD: DogStatsD is a custom daemon by DataDog. You can consider it as an extension over StatsD with support for many more metric types. This daemon needs to be installed on the node where you need to collect metrics. If a DataDog agent is already installed on the node, then this daemon is started by default. DataDog has also provided a  java library for interfacing with DogStatsD. More information can be found here -
  • Using DataDog HTTP API: DataDog also exposes a REST API that can be used to push metrics to the DataDog server. But it does not make sense to push each and every metric using HTTP. We would need some kind of aggregator on the client side that would collate all data for a time period and then make a HTTP call to DataDog server.
  • Using DropWizard bridge: If you are already using the popular DropWizard metrics library, then the developers at Coursera have created a neat opensource library that acts as a bridge between DropWizard and DataDog -
  • Using Micrometer Metrics Facade: If you are using Spring Boot, then this is the best seamless option available for you. Spring Boot Actuator has default support for Micrometer facade library and already provides a DataDogRepository implementation that can be used to push metrics to DataDog. The advantage of using Micrometer facade library is that we can switch to any other metrics backend easily - e.g. switching from DataDog to AWS CloudWatch. Also we can have composite repository wherein we can publish the same metrics to multiple backends. 
We finally decided to use the Micrometer metrics library, as all our microservices were on Spring Boot. Spring Boot 2 has many OOTB metrics configured in micrometer that are of tremendous value for DevOps teams -

Behind the scenes, the micrometer DataDog repository uses the DataDog HTTP APIs to push metrics to the server. There is a background thread that collects/aggregates data and then makes a periodic call to the DataDog server. Perusing the following source code files would give a good overview of how this works:

To configure DataDog in Spring Boot, you just need to enable the following 2 properties. 
management.metrics.export.datadog.api-key=YOUR_KEY //API key 
management.metrics.export.datadog.step=30s //the interval at which metrics are sent to Datadog

It is also very easy to implement micrometer code in Spring Boot. Sample code below: 

Wednesday, April 15, 2020

Kafka poll() vs heatbeat()

In older versions of Kafka, the consumer was responsible for polling the broker frequently to prove that it is still alive. If the consumer does not poll() within a specified time-limit, then the broker considers that consumer to be dead and starts re-balancing the messages to other consumers.

But in latest versions of Kafka Consumer, a dedicated background heartbeat thread is started. This heartbeat thread sends periodic heartbeats to the broker to say -"Hey, I am alive and kicking!..I am processing messages and will poll() soon again".

Thus the newer versions of Kafka decouple polling functionality and heartbeat functionality. So now we have two threads running, the heartbeat thread and the processing thread (polling thread).
The heartbeat frequency is defined by the property (default = 10 secs)

Since there is a separate heartbeat thread now, the authors of Kafka Consumer decided to set the default for the polling timeout as INTEGER_MAX. (attribute:
Hence no matter how long the processing takes (on the processing/polling thread), the Kafka broker will never consider the consumer to be dead. Only if no poll() request is received after INTERGER_MAX time, then the consumer would be considered dead.
Caveat: If your processing has a bug - (e.g. infinite loop, processing has called a third-party webservice and is stuck, etc.), then the consumer will never be pronounced dead and the messages will start getting piled up in that partition. Hence, it may be a good idea to set a realistic time for the polling() interval, so that we can rebalance the messages to other consumers. 

The following 2 stackoverflow discussions were extremely beneficial to us to help us understand the above.

Wednesday, January 22, 2020

Converting Java libraries to .NET DLLs

If you have a nifty java library that you love and would want to use it in your .NET program, then please have a look at this useful toolkit called IKVM.NET -

ikvmc -target:library {mylib.jar} ------- will create mylib.dll

Java libraries for SSH and Powershell automation

If you are doing some basic automation and want to execute commands on Linux or Windows, then the following open source libraries would help.

JSch is a pure Java implementation of SSH2 and once you connect to a Linux server, you can execute all commands. A good tutorial is available here -

This is a simple Java API that allows to interact with PowerShell console. Sample code below:

Saturday, June 08, 2019

On @Cacheable annotation of Spring

The @Cacheable annotation of Spring works like magic, allowing us to create caches easily with just one line of code.
But it is important to not that the caching will NOT work if you are calling method is in the same class !
This happens because Spring injects a proxy at runtime to implement caching and if you are making calls to cacheable methods from the same class, the proxy is not used.

More information on this thread -

Sunday, April 14, 2019

Ruminating on Digital Twin

A 'Digital Twin' is a digital replica of any asset, process or system.

Digital Twin of an Asset

Let's take for example a digital replica of a fixed asset like a CNC machine or a moving asset like a truck. Using the power of IoT, we could create a digital twin of the asset on the cloud that would have the same 'state' as the asset on the field
Once you have the digital twin of an asset on the cloud, you can realize business value from it in the following broad areas:

  • Remote Monitoring and Diagnostics - using sensor data
  • Predictive Maintenance - using ML 
  • Enhancing Product Quality - using closed loop engineering and integrating your PLM data and Field Service data with IoT data
  • Transforming Consumer Experience - understand how consumers are using your products and build new differentiated digital capabilities such as hyper-personalization, etc. 
Digital Twin of a Process/System

A digital twin of a complete process would enable us to identify process bottlenecks and take necessary steps to streamline processes and improve the productivity. Such a capability is of immense business value in the process industry. 

Digital Twin of a Person (Relationship Graph)

This is something which all social media companies already have - e.g. FB, LinkedIn, Google, etc. Besides storing all personal attributes, a digital twin of a person would also create a relationship graph that shows how the person is connected to other people and leverage this graph for business value. There are ethical concerns around how much data we are sharing with these large social media companies and the potential misuse of that data. 

Wednesday, December 12, 2018

Blockchain in Healthcare

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.

Tuesday, November 27, 2018

Autonomous car levels

There are 2 systems of classification for autonomous cars prevalent today: National Highway Safety Administration (NHTSA) and Society of Automotive Engineers (SAE).

A good article illustrating the various levels is here -

Ruminating on POC vs. POV

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

Cloud computing from the trenches

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

Ruminating on Consumer Driven Contracts

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).

Anyone still not convinced on using Consumer Driven Contracts should peruse the below link without fail -

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 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

Ruminating on Kafka consumer parallelism

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. 

Batch ETL to Stream Processing

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.

Snippets from the article:

  • 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

Tips and Tricks for Thread Dumps

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 : which gives a beautiful report on the threads running inside the JVM that can be analyzed.