Summary of Udi Dahan’s “Integrated Service Approach” presentation from µCon 2014: The Microservices Conference

Video: skillsmatter.com/skillscasts/5235-keynote-an-integrated-services-approach
Length: 1 hour, the site requires registration (email) before showing the video. There are a lot of interesting video materials on the site.

Udi Dahan is the author of NServiceBus and a very talented speaker and teacher. I have been following his performances for several years now - Udi always has something to say and listen to it is informative and interesting.
')
The presentation was opened on the 2nd day of the conference dedicated to microservices, Udi funfully and convincingly ridiculed the popular topic of microservices now and suggested tracking the logical and physical implementation, once again thinking “why do we need this circus” and draw a paralelli between the org structure, services and multifunctional teams. I personally was very interested in moments not “how to write / deploy microservice?” (Like tactics), but “why?” And “how is this approach better?” And actually how it can live in a large organization (like a strategy).



This text is a summary, written in general for understanding and memorizing material. I am rather a “Chukchi-reader” than a “Chukchi-writer”, therefore I will not follow the rhyme especially. I work as a small development manager in a large company (200 - 12.000 - 90.000 people, depending on what to count) and participate in several projects, where I am a participant, and where I’m also a spectator. Recently, organizational and political tasks are striking in their complexity and “pee code” is perceived as a rest. It was me who “complained about life” and now we turn to the summary.

"

The video lasts almost an hour; video and sound are very good; I did not find the slides because I took screenshots; English is easy and intelligible, the most difficult word is “cohesive”, so I highly recommend that you look, you can even the whole team, so that there is a common understanding and terminology.



Microservices will not solve many problems - the incorrect formulation of the problem, weak processes and bad habits of employees:

• Incorrect formulation of the problem - the customer may be wrong, either “he himself doesn’t know what he wants” or “offers a solution (add me this column)”.
• Processes - microservices are more complicated than motoliths in terms of deployment, and it will not be easier to live, if there are any problems with DevOp or Continuous Integration / Deployment, they will come out very quickly.
• Bad habits - bad code won't get better.

And only discipline and maturity will help us, amen.



And there is also a law of compliance of the product architecture with its organizational structure.
Here, Udi walked slightly under the insurmountable 40-year-old laws ...



Further more - fashionable concepts are presented as de facto better than old ones, which is fundamentally wrong. And in general - everyone struggles with the dependencies (coupling) in any of their manifestations, practically raising them to the main architectural principle: strongly_dependent = monolith = bad and weakly_dependent = microservices = good!



Udi offers to look at the coupling again.



On the left - this is how we wrote “always” - one process, class C1 calls the method of class C2 directly and also directly transmits the parameters.
On the right - we placed C1 and C2 in different processes (of course, classes now need to be made up as components, but this logically does not change anything). All direct call we now use RPC or XML + SOAP or JSON + REST. Can it be said that the components have become “logically independent”? Not. Has logic changed “conceptually”? Not.

Further, Udi says that one has to be afraid of an initiative programmer who considers himself the most intelligent and creatively decides what he considers an important task - the fight against obvious dependencies between components. The data, in fact, “hide” in the database and transmit “only ID”. Particularly intelligent and advanced hide the DB database in a “service” which is “very scaleable and not at all SQL”. And they proudly say - here are two weakly connected services!



But everything became worse: an obvious, well-tracked and documented almost at the level of source codes dependency is now “hidden” and disguised by a dozen layers of different protocols, languages ​​and technologies. And this is just the beginning!
Further worse - services write different commands and the scheme in the database ceases to be “someone's” - it is now in itself. But the “smart” programmer does not give up here, but hides part of the scheme just in the field - is JSON the string, e? Yes! And here's your “extensibility”! And here's the metadata and business rules - do you need it? Well, because cool and fashionable? Yeah !!!
And now let's compare “add one more parameter x to Foo (a, b, c, d, x)“ and “one more field” to what happened after the new-fashioned improvements.



And at some point we understand that there are things that “should be logically connected” and we should not fight it. If, for example, to break bonds in an atom, then we will get a lot of destructive energy, and the same in business logic. Udi suggests using the concept of “cohesive” (cohesiveness).



And then as it becomes easier - yes, we see that there are several atoms in the system (which should not be broken!) And they are somehow connected.

Further, Udi notes that the UI is also part of the “service” (atom, microservice) and the traditional approach when “we have a team of HTML / JS / CSS experts — they will do everything for us, and we will talk about complex server parts” this is not the right approach. And that the UI should be, for good, also divided into microviews. And the “traditional” approach in which the “product” includes both the price and the name and picture, etc. - This is a very simplified approach that has nothing to do with business or reality.



And a little bit about the fact that (micro) services can be different - both in terms of technology and deployment requirements.



Further, Udi somehow imperceptibly moved to the place of microservices in “real life” and in the process of project management, where the product works on different platforms and is written (usually) by different teams.



And everything happens very slowly and naturally, but at some point it turns out that the same, conceptually, blocks are repeated in different projects, and they can also be viewed as larger services or components.



And everything seems to be good, but you can take a closer look and see that the technology stack is very different - where is .Net, and where is Objective-C. And somehow it is already strange to see many technologies inside one microservice (uS1) and ask questions like “we have a team that writes in Objective-C, and a team that writes in T-SQL”. Yes, here we are faced with Conway's Law - the organization is trying to crush the project under its structure. You can try to offer a cross-functional team, but this is also perceived through the prism of Conway's Law - “yes, yes, of course, programmers and testers should work together, the main thing is for programmers to work in the same technology as me.”

Further, Udi explains that programmers must work in different technologies. Then we seem to remain within the organizational structures ...

... then I stopped the video and tried to compare whether I had seen this in life? Yes and no. First of all, I have not seen many programmers who can switch between .Net - CSS - JavaScript - Java - Objective-C during the day. Anybody can switch to “talk”, but probably switch to “debug complex code” - no, I have not. But probably it is often - during the day, and it’s difficult to imagine such a thing - it’s not work, but rather abrupt one. If we consider switching “once a quarter”, it is more realistic, but also, I know very little, very, very few people who can meaningfully write new things in different technologies. The middle team will also have to retrain the people quarterly - the average programmer very quickly forgets even his own code, not just the features of some kind of library or utility configuration.

And secondly, at this moment it usually turns out that code should be written in parallel, and a separate team is recruited for each technology-language, and the developers that Udi speaks about are not programmers, but business analysts or product (service) owners - anyway, we still stay within Conway's Law ...



And you ask yourself the question - is it right to call such a “microservice”? Especially when we see that it is not at all micro ... and they seem to be in different places - that is, they seem to be different services. But the “from deployment” approach is not the main one - for example, almost always everything that we want to stuff into a mobile application will be packaged in one package - simply because it will work faster — start — and so on. That is, we will combine many “services” into one package simply because such is the specifics of this device. Well, well - these are physical components.



The final part of the report is, in fact, an attempt to appeal that all the assumptions and habits that we have been using all these years can sometimes be revised in order to understand - do they work as well as before? or can something be improved?