A number of interesting points but not a lot here that I haven’t seen elsewhere and not any questions answered that I haven’t had elsewhere.
But a few particular (some old) questions:
- what are “hardened APIs”? (I’m nit picking on this one unless someone has a significant answer to make me smarter.)
- Such services are typically simple, yet they can be composed into very rich and elaborate applications. Does this mean that the only way to combine microservices is through an “application” that calls individual microservices and you can’t have a microservice calling other microservices? We still have an unclear definition and characteristic interactions between “(micro)services” and “applications”. This eventually gets to the reuse questions.
- You're probably not doing microservices if: • Services share a persistence store. But this tells me nothing about how two (micro)services that must make consistent use of data — or even just informational use — will share that data. Transaction will have eventual consistency (which may be good enough) but how about if I just need to use your name in several places?
I’d be happy to schedule time to discuss this at our next meeting.
Ken
P.S. A longer (but not difficult) read I’d recommend is still “Building Microservices” by Sam Newman.
------------------------------------------------------------------------------ Dr. Kenneth Laskey MITRE Corporation, M/S F510 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
Bob--Sure, I wasn't trying to judge MS completely based on this
short write-up and I get it that the author was focused on what he
sees as the potential workgroup-effectiveness benefits of the MS
approach. I was hoping he might expand on what he meant by saying
"it's not for everyone" and "the path to successful use is
difficult" but he did not. Anyhow, why dodn't you join the ne
On 8/19/2016 10:55 AM, Natale, Bob
wrote:
Thanks,
Martin … I thought the article was pretty good … the author
can (IMHO) be considered an authoritative source in this wrt
how the hyperscale cloud service providers are creating the
de facto standard model for microservice architecture. The
article assumes that readers already understand that
a microservice is a packaging construct for a substantive
and separable chunk of business functionality exposed
via an API-based service interface and corresponding SLA. Supporting
observations from
http://thenewstack.io/succeed-failure-microservices/ “Microservices
architecture is
the biggest misnomer since global warming,” Reinhardt
said. “‘Global warming’ rolls off the tongue so much better
than ‘climate change.’ The drawback is that every time you
have a cold winter’s day, people say global warming doesn’t
exist, whereas climate change just says that the frequency
of weather events is more extreme. It’s the same with
microservices:
people by instinct immediately focus on the micro part.
But
microservices architecture is an architectural approach that
takes into consideration
the way we work and the way we organize.” -
- - - - One
tangential take-away from the ACM article that was a
light-bulb moment for me was: “The
effectiveness of a set of tests can be measured less by
their rate of problem detection and more by the rate of
change that they enable.”
I don't find this very convincing but
it's short. <g>
One thing i noted is lack of indication that MS tied to use
of containers.
|