In 2017 I wrote an article on managing transactions in the cloud [1], that described common patterns to achieve consistency across multiple components and Microservices. The world has moved on, and I have worked on an IBM Academy of Technology study on how to achieve transactional semantics with Microservices. Of this I want to report here.

Note: this article has originally been published on IBM's architecture website end of 2020, and is here republished within IBM's publishing guidelines.

As a customer buying an item in a web shop, you want to have the order quickly processed and delivered. As a bank customer, you want to make sure your money does not magically disappear during a transfer. In enterprise applications, classical transactions guarantee qualities such as consistency or isolation from other transactions. Distributed transactions provide such guarantees across multiple resources such as across your shop database and your enterprise resource planning (ERP) system. The transactional qualities are usually provided by your middleware infrastructure and make life easier for the average programmer.

In the cloud, however, the middleware often does not guarantee such qualities; distributed transactions are usually not available, while at the same time the infrastructure can be much more volatile.

In Part 1 of this two-part series, I describe some of the background of transaction processing, qualities guaranteed by transaction, and what is different in a cloud setup. In the second part, I will show alternatives to classical transaction processing for calling non-transactional services.

Note: this article has originally been published on IBM's developerWorks website on 18. March 2017, and is here republished within IBM's publishing guidelines.

In Part 1 of this series, you learned about transaction processing and distributed transactions. Transactional properties help to reduce the error-handling effort in an application. But we also found that distributed transactions, which manage transactions across multiple resources, are not necessarily available in cloud-based runtimes. Here in Part 2, we look at the cloud setup, and ways of ensuring transactional qualities across multiple resource managers even without distributed transactions.

Note: this article has originally been published on IBM's developerWorks website on 18. March 2017, and is here republished within IBM's publishing guidelines.

This article describes a case study in which the Smarter Monitoring approach that helped reduce the time for initial problem analysis from hours to minutes. The additional information contained in the logs because of the smarter instrumentation also helped reduce performance problem analysis duration. An implementation approach that ingests 500 million log entries or 70 GB per day of data is briefly described.

Note: this article has originally been published on IBM's developerWorks website on 7. September 2016, and is here republished within IBM's publishing guidelines.

Almost two years ago I demonstrated a 10MHz accelerator card for the Commodore PET on the Classic Computing exhibition. For this presentation I wrote a small demo program that draws a 3-D cube on the PET's screen - first with 1 MHz, then with 10 MHz. As I was concentrating on the 10MHz speedup, I didn't have enough time to look deeply into the demo program itself. So it was questioned why it was so slow in 1MHz compared to other demos. Finally I found the time to have a look at this, so I'll make this an example of a performance optimization job. Read on to learn about how the proper approach for a performance optimization even helps fixing performance problems in an old Commodore BASIC program.

It is a well known fact that bugs are the harder and the more expensive to fix the later they are discovered in the project lifecycle. The cheapest one is the bug not made of course. The most expensive one is when your business critical application crashes and can not be recovered. And everything in between.

I have often been called into projects to investigate performance problems or to optimize a system for performance. What I find is that performance problems can have a lot of causes. Some are design problems, for example using the wrong algorithm for a problem, or processing items one by one instead of by collection. Others are database problems caused by bad access patterns. Network problems add their share. With the growing complexity of modern distributed systems (think cloud!) the situation is getting even worse. More and more systems and services are being combined to provide the business functionalities. Each one could be the cause of a performance problem.