- group-of-Processes, …. not group of resources.
- Initially named “Process Containers”
- 2006 started at google
- 2007 “mainlined” into linux kernel
- Not available beyond linux, as far as I know
I feel both the MSA architecture and the low level container technology can have a long-term impact thanks to cloud.
The implementations might be replaced by newer implementations in a few years. but some of the ideas may evolve. Now is still the volatile early phase… ## proliferation → consolidation.. beware of churn
Both of them are easy to launch on elastic cloud
Both of them can be started on multiple machines as a wolf pack to handle bigger workload.
One of the main (perhaps #1) justifications for MSA is devops including testability, phased roll-out, resilience …
Useful terminology — A particular microservice has a single service provider and some “consumers”.
REST is the simplest implementation, but async (with msg broker) was highly recommended by Chris.
Q: too many services, too many failure points?
A: async (with msg brokers) improves reliability and availability
— cloud and MSA
container is not the only way to host a service in the cloud. Chris mentioned “lambda” as the simplest alternative.
— each service can use a different programming language. Chris said this is controversial but can be useful. Say we are migrating from golang to node.js. We could implement one of five services in the new language and migrate in phases.
— “validation” in production environment #we don’t say “testing”
- deploy a new version of a service to production but has no traffic routed there
- expose the new service instance to the same production requests as the live service, but in readonly mode, so there’s no write to data store, no visible output except logging.
- Now run it in full mode
- route some fake traffic (like a test symbol in mvea) and validate the output
- route some real traffic in small quantity and rely on comprehensive service monitoring
— My questions + other audience questions
Q1: UDP as alternative to TCP?
A: UDP is used for low latency in microsec. Many MSA use cases are in millisec
Q2: latency … I would think monolithic is fastest
A: no simple yes/no answer
A: MSA definitely improves scalability. I would think the web2.0 shops do care about latency too.
Q3: distributed transaction/rollback …. I thought this technology is reliable for decades?
A: CAP .. choose between consistency and availability. I think Chris means
A: there’s a paper
Q4: c++…. is MSA unsuitable?
A: the prominent voices tend to be java, dotnet, node.js , golang, and python, but c++ is not unsuitable. Some key software projects are in c++ (I think for efficiency)
Am an enterprise java developer, not a web developer. I feel PaaS is designed more for the web developer.
I agree with the general observation that IaaS doesn’t impact us significantly.
I feel SaaS doesn’t either. SaaS could offer devops (build/delivery) services for java developer teams.
PaaS has the biggest impact. We have to use the API /SDK provided by the PaaS vendor. Often no SQL DB. Can’t access a particular host’s file system. MOM is rarely provided.
[[cloud architecture patterns]] is a nice thin book.
The second of many patterns is this essential pattern.
Example – wordpress back-end engine … after I import, the webpage tells me to wait for the completion email.
Task Queue (or message queue?) is a common cloud service.