OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: NGINX benefits and drawbacks of microservices


There are a couple NGINX eBooks that are informative and provide some depth of explanation.
- Microservices From Design to Deployment
- Microservices Reference Architecture

I’ve read the first and am in the process of going through the RA.

The D&D doc has two sections of particular interest, benefits and drawbacks, that I found particularly useful in thinking how microservices differ from our traditional discussions of SOA.

To begin with, I think this  group’s idea of SOA was architecturally a lot more in line with microservices than it was with services hanging off a centralized bus.  So many of the benefits of microservices are also benefits of SOA as long as you don’t saddle SOA with an ESB and other things that essentially turn it into a monolith.  Even then, many of the benefits are consistent with the SOA service.
- Decomposition of the problem space works for services and microservices.
- Both depend on a well-defined interface.  I would argue more broadly that both depend on a sparse — compared with the 50-70 page templates I’ve recently read — but sufficient service description as laid out in the SOA-RAF.  The microservices literature, as the SOA literature before it, ignores too much of what we identify as needed for description.
- SOA didn’t push the "micro” but there is nothing new in the microservices level of modularity.
- The development environment for SOA services can be as diverse as for microservices.  Both assume the implementation details are hidden behind the interface.
- Microservices talk to independent deployment of services, and this is potentially the same fallacy as advocated for SOA, i.e. if the interface still works, a new service version (or alternate service) can be swapped in for the one you thought you chose.  Assuming the new service does something differently than the old one, it was never resolved when the consumer needed to be told something changes vs. no notice and just the danger of unpleasant surprises.  I consider this an open issue.
- Microservices are touted for being able to be scaled independently but that was generally also true for SOA services.

Moving on to the drawbacks, network issues were resent with SOA but often avoided by putting everything on the ESB and not really have a widely distributed solution.  With SOA, we basically dodged the real network issue.  Microservice items like every service with its own database wasn’t discussed but there is nothing that says it couldn’t/shouldn’t be done.  SOA thinking was more at the logical level and this is an example of microservices being an extension of SOA thinking.
- The micro part focuses the discussion on size when scoped functionality is really the issue.  As noted above, SOA has no problem with this.
- A microservice application is a distributed system.  Developers need to choose and implement inter-process communications mechanism, and the system needed to gracefully handle failure of its parts.  We never resolved this with SOA.  We were concerned about network latency if services in a composition were distributed but most of the response was to build everything as a monolith around an ESB.  The eBook says this isn’t rocket science but it is more complex than a monolith.  I’m not sure how complex it need to get before it is rocket science.  But we do have rockets in regular use.
- There is that local database and eventual consistency ;-) A lot of this is handled through events, but that is still a solution approach that needs careful design and implementation.
- The other side to just slipping in changes if they work through an unchanged interface is the interface changes and that change needs to be propagated.  Same problem with SOA, but SOA implementations often fell back to the monolith where this is less of an issue when the same entity owns all the pieces.  Testing is another aspect of this; I think the SOA-RAF testing section tried to account for more of the testing challenges than other SOA literature.

I think some of this interacts with Martin’s draft questions (and may be the subject of another email tonight).  I also need to read Rex’s use case and see how that shapes the context..

Ken
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510          phone: 703-983-7934
7515 Colshire Drive                           fax: 703-983-1379
McLean VA 22102-7508



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]