Sunday, 12 November 2017

Programming Microservices

I remember watching the movie Avatar, by James Cameron at IMAX. Seeing the richly built world of Pandora on a larger than life screen was awe inspiring. Like every true fan, I looked beyond the state of the art CGI and was hooked on to Na’vi, the language of the natives, that James created for his movie.

Reviewers from movie magazines asked James the need of creating a new language. James explained that he had many requirements which necessitated it. First was for the symbolism, the metaphorical references to oppression, colonialism and annihilation of the indigenous communities and the philosophy of the nourishing, all providing, omnipresent female. James used voiceless consonants in the language, as used by many primordial languages of Asia and Americas and modeled Na’vi based on the Mayan and Polynesian dialects to achieve this.

He also wanted the language to allow his actors to emote expressively, in addition to it being nice to hear and easy to speak. The language uses varying tones and vowels of varying length to achieve an expressive yet pleasing intonation. The new language helped him to not to limit his creativity based on the conventions of English.

When developing Microservices, it is relatively easy to do what is required. Components and RESTful interfaces are some of the low hanging fruits. As we develop, we discover that it is difficult not to do what is not required. The hard-to-avoid antipatterns are structured composition, centralised data and about managing mutability.

Microservices need to be composed functionally, not structurally. Teams fall back on structural composition as an incidental effect of using a programming language with a procedural/imperative style. The most popular programming languages - C, C++ and Java are imperative and coding in them let you compose structurally, usually in a pattern of some central providers and many contextual users. The problem with structured composition is that it creates dependencies (on the providers) which makes it difficult in creating independent and loosely coupled Microservices. A litmus test for your composition would be to look at the module names and check whether they are in English or geekish. For e.g. module names like iNode, checkpoint etc. suggests a structured composition where as names like replication, backup suggests a functional approach.

Centralised data is a consequence of dependencies created by building your application structurally. Decentralising requires intuitive frameworks, which may need to be created for the popular programming languages like C, C++ and Java, using some reactive programming techniques.

Most of the popular programming languages have mutable data types, which creates a need for managing mutability to enable concurrency. This is an incidentally complex problem in C, C++ and Java, requiring locks and identifying critical sections. Even the best implementations have deadlocks and race conditions, in spite of these synchronised methods. Is there a simpler alternative?

In the next part of this blog, we will look at how to avoid these antipatterns and the features of some programming languages that would help us to do so.

No comments:

Post a Comment