InfoQ Homepage Presentations Microservice Challenges
Microservice Challenges
37:08
Summary
Fred George discusses two challenges developing microservices: the asynchronous messaging bus and using functional programming which may be at odds with this approach.
Bio
Fred George is a developer and co-founder at Outpace Systems, and has been writing code for over 45 years in (by his count) over 70 languages. An early adopter of OO and Agile, Fred continues to impact the industry with his leading-edge ideas, most recently advocating MicroService Architectures and flat team structures (under the moniker of Programmer Anarchy). Oh, and he still writes code!
About the conference
Micro Services are a new paradigm for software architecture: small services in separated processes take the place of large applications. This way monolithic architecture can be avoided, and systems are easily scalable and changeable. The microXchg conference looks at a variety of aspects of Micro Services.
May 28, 2015
Community comments
Microservices or Clojure?
by Tuomas Hietanen,
Re: Microservices or Clojure?
by Faisal Waris,
Microservices or Clojure?
by Tuomas Hietanen,
Your message is awaiting moderation. Thank you for participating in the discussion.
Can microservices work like template-method-GoF-design-pattern? Why not? Then a microservice could also take a function (or another microservice) as a parameter.
The general attitude is that microservice-architecture is not build from scratch but rather refactored towards it. Why? Because we don't want to make a monolithic application that has a large shared state (over the services). If you want to split your Clojure-application to multiple parts that is ok, but good Clojure programs don't have a large shared state by default.
Clojure (and other FP-programs) are created by function-composition: How to combine little independent functions together. This way there not this typical OO-flow of multiple uncontrolled code paths. With Clojure, it doesn't matter if you have 1 file and 100 separate functions inside it or 100 files and one function in each: either way, the functions are independent. In FP-languages there is no this kind of dependency-jungle that basically OO-programs have. See: evelinag.com/blog/2014/06-09-comparing-dependen...
Microservices don't need to have some spesific API like Rest or event-bus, in Clojure, the “microservice-API” can be just a function call.
So the "Microservices or Clojure?" is wrong question. The setup is more like "if you use Clojure, you can always split your code to Microservices for the PowerPoint-architect to be happy, but it doesn't really matter for the developers".
Re: Microservices or Clojure?
by Faisal Waris,
Your message is awaiting moderation. Thank you for participating in the discussion.
Have to agree. I don't see any conflict between FP and 'microservices' (which BTW is just SOA, IMO). Service interface messages will always be more granular than local method/function calls - OO or not.
The issue with asynchronous communication is how to specify 'contracts' between services. I think protocol is a better term. In the 'old' WS-* days we talked about not doing "message slinging" (just throwing messages on the bus). Instead we wanted to describe meaningful flows (like W3C's now-defunct WS-Choreography standard www.w3.org/2002/ws/chor/).
In the brave new world we are back to throwing messages on the bus and the 'protocol' is left up to the guts of the services. There is no good way to abstractly represent flows and interactions so that we can reason at a higher level.