Microservices and SOA: The antagonism is not technical but..
Microservices and SOA: the antagonism is not technical but...
Figure 1: Microservices and SOA war
Recently, browsing on YouTube, I re-watched the lecture given by Martin Fowler in 2014 on the microservices. As usual, Martin was a wonderful speaker, clear and concise. But in the middle of the lecture when he talked about differences between Microservices and SOA, I found his speech a bit more confusing and his conclusion on that topic was unclear and vague. If you pay attention to his speech, before saying his conclusion on that chapter, he reported two witness statements: the first was from SOA people who developed successful SOA projects, surprised by the lack of innovation and freshness in the microservices definition and practices, and the second, from microservices people, mainly coming from big companies, fed up with SOA, who see SOA as ‘Enterprise Services Bus’ and ‘committee that wants to lay down standards’. Then, Martin concludes by an evasive definition that Microservices is a subset of the SOA.
|
Figure 2:Technical vision of SOA and microservices
|
However, he did not give any border line between the two domains, but said that the term, SOA, is a too broad and the microservices is a useful subset of SOA.
Roger's database
Roger and his database
Introduction
Last week, I tripped in the Belgium and I met a nice guy called Roger (of course it is not a material public figure). In a bus, we had a friendly chat and after a while, he told me that he was an IT consultant and works as a DBA for a renowned insurance company. For the ones who complain about their software editors, I would like to report the Kafkaesque story that Roger told me.
The context
Roger’s company has used for years the ERP JD Edwards. Recently, JD Edwards has been bought by Oracle which has other ERP in its portfolio such as Oracle Applications. Roger manages and monitors Oracle DB V9 used by JD Edwards. For months the EPR and the database worked perfectly together.
First act
Two months ago, for the first time, the database crashed. Roger is a good DBA and was able to quickly restore the database. Alas, afterwards a few hours the database went down again. Roger found out a sticky bug in the database and to ascertain a resolution, he shouted out the Oracle support which was not surprising since the bug was easily recognized. An Oracle consultant told Roger to change a parameter “P” from the value X to Y. “Perfect solution”. The database worked well and did not crash anymore.
Second act
A few days after the cash episode, the users complained that the ERP performances decreased by 10 to 100. Quickly the company found out that the bottleneck came from the database. Another Oracle consultant stepped in to optimize the database and diagnosed the problem. THE SOLUTION was quickly found out: The parameter “P” set to the value Y must be set to X. Immediately, Roger reacted and replied that the value X crashed the database.
The solution
Oracle took the problem and suggested to migrate the database from the version 9 to the version 10. Indeed, the new version solved this problem. Alas, the JD Edwards does not plump for the version 10 of Oracle databases, even if the ERP and the database belong to the same editor. As a final solution, Oracle offered to simply drop, JD Edwards from the company and rebuild the organization with Oracle Applications. Of course, Oracle would assist the company during its migration.
Happy end
The CTO aware of this problem saw red and threaten the editor to withdraw all the Oracle products if a solution was not find asap. During the week, a patch was sent to Roger and all the issues were fixed.
I trust you enjoyed the depressing tale of Roger and his database.