Just run it twice

Often we use some kind of „clustered“ environment to run our software.

This promises higher performance and better availability.

And the frameworks seem to suggest that it is just a matter of starting it twice and it will magically work correctly.

There is nothing wrong with investing some thoughts on this issue. It can actually quite wrong otherwise…

So some questions to think about:

Where are the data? Does each service have its own set of data? Or do they share the data? Or is there some kind of synchronization mechanism between the copies of data? Or is some data shared and some data as copy for each instance of the service?

Do we gain anything in terms of performance or is the additional power of the second instance eaten up by the overhead of synchronizing data? Or if data is only stored once, does this become the bottleneck?

Then there is an issue with sending the requests to the right service. Usually it is a good idea to use something like „sticky sessions“ to keep a whole session or collections of related requests on one instance. Even if the protocol is „stateless“ and „restful“.

Is there some magic caching that happens automatically, for example in persistence frameworks like Hibernate? What does this mean when running two instances? Do we really understand what is happening? Or do we trust that hibernate does it correctly anyway? I would not trust hibernate (or any other JPA implementation) on this issue.

What about transactions? If storage is not centralized, we might need to do distributed transactions. What does that mean?

Now messaging can become fun. Modern microservice architectures favor asynchronous communication over synchronous communication, where it can be applied. That means some kind of messaging or transmission of „events“ or whatever it is called. Now events can be subscribed. Do we want them to be processed exactly once, at least once or by every instance? How do we make sure it is happening as we need it? Especially the „exactly once“-case is tricky, but of course it can be done.

How do we handle tasks that run like once in a certain period of time, like cronjobs in Linux? Do we need to enforce that they run exactly once or is it ok to run them on each instance? If so, is it ok to run them at the same time?

Do we run the service multiple times on the productive system, but only a single instance on the test and development systems?

Running the service twice or more times is of course something we need to do quite often and it will become more common. But it is not necessarily easy. Some thinking needs to be done. Some questions need to be asked. And we need to find answwers to them. Consider this as a starting point for your own thinking processes for your specific application landscape. Get the knowledge, if it is not yet in the team by learning or by involving specialists who have experience…

Share Button

How far to go with internationalization?

I had some experience with mobile apps in Sweden. Since I know Swedish, I did not bother to find out, if they support other languages. But they were potentially important and useful, but implicitly required a domicile in Sweden.

More concrete, the apps that I was interesting in using were „Dalatrafik“ and „Swish“.

Swish is a mobile app for payment. I think that is the way to go and the future. Credit cards are just not quite as good, in many ways. I use Twint a lot in Switzerland and I like it very much. You either have NFC with the phone and the payment device or there is a QR-code to scan. But I think Swish goes much further, because the entry barrier for becoming a receiver of a payment is much lower. It can be used for payments between individuals or in flea markets, where a credit card terminal is not an option or too expensive. Now Sweden is generally more advanced in terms of cashless payment than other European countries and of course a . Very rarely cash is required and even surprisingly often only credit card, debit card and Swish work and cash is not accepted. Swish can be used to pay to a number, for example a camp ground can be paid, when the reception is closed by just sending the amount according to the price list to the swish number. So I have installed Swish. And then the big disappointment: A Swedish bank account is needed to back it. Maybe it is eventually worth having one, but ad hoc it is not an option and only works for residents of Sweden or frequent tourists of Sweden who go the extra mile to open a Swedish bank account as a non-resident. This is even difficult in Switzerland. I have not tried it in Sweden.

Dalatrafik provides information about public transport connections within the Swedish region Dalarna. This really works well. But then it also allows buying tickets for public transport. In times of Corona it is actually the only possible way, because the driver does not sell tickets. In larger towns, there are a few shops that sell tickets as well, but that is neither conveniant nor helpful in most cases. So now the app has two payment modes. Swish and credit card. Swish we will see later. Other than in almost all other cases, it turns out that this app only works with Swedish credit cards. So the way to go by bus as a tourist is to just try to buy a ticket and if somebody controls it, to say, it did not work… Why not accept foreign credit cards?

So please think a bit more who is your user base and of ways of including non-residents or other „non obvious“ groups of users, that are actually important. Starting with something that works and omitting the parts that are really difficult to achieve is good. But it is worth exploring h ow to make it work for non-residents, especially for apps that are so crucial. Dalatrafik could obviously allow foreign credit cards, as almost everybody in the world does. And Swish could come up with a way to add a foreign bank account or a foreign credit card to back the payments. We will see what they will come up with in the future. On the other hand it is amazing, that almost all credit card terminals and ATMs in the world support 6-digit PIN-codes for credit cards and debit cards, although they seem to exist only in Switzerland. A 6-digit code that you may choose yourself is much better than a 4-digit-code that is imposed on you by the bank.

An example of a funny constraint, that has eventually been removed is that users of iphones and ipads needed a Windows-computer (or Apple-computer) somewhere to run their devices, because updates were only possible together with a computer of either of these two types. So Linux users could not buy i-things. Or people who did not have any computer at all and just wanted to use the i-device as their computer. Then they came up with the possibility to do the update just with the device itself without needing any computer whatsoever. This is what all my Android devices do and always did and what makes sense.


Share Button