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.

Yesterday (January 2024) I got my first presciption as an e-presciption.

In 2004, as a young, aspiring IT architect, together with a colleague I built IBM's demo of an electronic prescription system for the CeBIT fair. I would not have believed it would take so long to get an e-presciption system live.

In my current project I work as Infrastructure architect rather than as application architect that I am due to shortage of resources. We had to set up a large Infrastructure based on IBM cloud, using three data centers, bare metal servers, IKS clusters, and various cloud services. Of course, infrastructure as code was set from the beginning, with a gitops repository to store the infrastructure code.

However, what I learned was, that just "infrastructure as code" is not a solution. It's only the beginning!

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.