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.

Floppy disks are a thing of the past. Except if you’re in retrocomputing like I am. Recently I had to repair an old, vintage Commodore Floppy Disk drive due to leaking electrolytic capacitors. It was a dual drive and when re-assembling it I found that one of the drives had one head with a high error rate. But when I tried to read up on floppy drive theory and operation, I found it unbelievably hard to find anything useful on the web. So here are my notes of what I found.

In my home I am running a raspberry-pi based digital video recorder. To copy the recorded files to my server, I use a cron-triggered rsync script. While that worked in other situations just fine, here I always get an "error in rsync protocol data stream (code 12) at io.c(226)". Finally looking deeper into it I think I have an explanation and a solution.

When you come from using a classical source code repository like Concurrent Versions System (CVS) or Subversion (SVN), it can be difficult to understand the flexibility and the possibilities of Git. This article tries to explain the workings of Git and how it all fits together, so you don't have to try to remember the commands, but instead just know what to do because you understand it well.

Note: this article has originally been published on IBM's developerWorks website in 27 January 2015, and is here republished within IBM's publishing guidelines. Here is the developerWorks link.

Here is an interesting read about what Xerox PARC was really "worth". I often have the feeling that large corporations don't see the value in real invention anymore, but are only on the lookout for "innovative companies" to buy and squeeze out. Which may work for a short term to raise revenue and profit, and thus the share price - until this company has been assimilated, talent has drained to other companies, and a new one needs to be bought.at

For really a long time I have used a really nice feature of the X11 windowing system - remote login. That was rather easy to do. Just enable XDMCP and connecto to the X server remotely. It was not safe over the networks, but I used it only locally. My main use case was and is using the main PC in my home office from other places.

Now for a few releases the Linux distributions started to disable the protocol, or at least make it more complicated to use, as XDMCP isn't supported in the admin tools anymore.

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.

Recently I have written about refactoring a 20 year old code base, namely of the file system server code for my old Commodore computers (see here: Refactoring-20-year-old-code... ). Here is a description of the internal structure of that code. I do this description in the form of an "architecture overview", a form that I think is missing for many a software project.

When I was working on my selfbuilt 6502 operating system, I had a file system server on the PC, connected to the 6502 via a serial line (RS232). It was using a generic, packet-based protocol on the serial "wire", so I decided to reuse the protocol and the server for an AVR-based implementation of a Commodore disk emulator. The Commodore would talk to the AVR via IEEE488 or the CBM serial IEC protocol, which would behave as a disk drive and use the wire protocol to talk to the PC to server files from there. In the beginning it looked like a good idea. But it took much more time than expected. Read on for the full story.

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.

My name is André Fachat, and like the "extra miles" you go in your job, those "extra pages" are what I try to write in my spare time.

Sometimes it's more documentation, sometimes more call to action, sometimes rant.

Most will be about my ongoing hobbies and passions - 8 bit computing for one, with my main page here: http://www.6502.org/users/andre/index.html , but the other is software engineering quality, and more specifically performance and other non-functional requirements.

I work as an IT Architect for a living, however, this is my private blog. The postings here are my own and don't necessarily represent any employer's positions, strategies or opinions.

If you want to contact me, you can reach me via email on afachat@gmx.de. It has a strong spam filter and I am pretty busy, so it may take a while for me to answer, though.

I hope you enjoy these pages!

André Fachat