4 ms·

Having run k8s and _classical_ microservices before, I am now in a much happier place just using the AWS serverless suite (lambda, API GW, CF, SNS, SQS, eventbr

Having run k8s and _classical_ microservices before, I am now in a much happier place just using the AWS serverless suite (lambda, API GW, CF, SNS, SQS, eventbridge, dynamodb, etc). Is my setup "microservices"? Well, maybe, depending on your definition, but, in truth I don't really care - it works pretty well. We also do "DDD" with it and have multiple AWS accounts with these marking the domain borders. Comms between the accounts is via eventbridge or (very rarely) inter-account API invocation. This allows many of the benefits of microservices, without the pain of dealing with k8s. Clean separation of domains, reduced cognitive loads for teams, each of which looks after all the stuff in a single account (so-called feature teams, where each team designs/manages and runs everything in that account/domain). The hard bit was defining the domain borders, and the inter-domain protocols/interactions, but, once this is well defined, things work pretty well. Having come from a k8s world, this setup feels so much nicer, and lighter, and easier to get stuff built in a both fast and performant way. It would be interesting to see trends away from _classical_ "cloud-native" (k8s) setups with microservices, to true serverless setups. I wonder how much of k8s's lunch serverless has managed to eat so far.

bradwood 4y ago
it's also worth noting that, initially, we built everything in one account, and had 1 team doing all of it -- the cognitive load became too high at one point, and, only then, did we break out the "DDD" and split the concerns across many teams.
dagss 4y ago
We were really happy with Google App Engine for the same reason. It's a product that feels like it was "10 years too early". Like you I feel the whole microservice debate turns into a "depending on definition" kind of thing and feels odd. Write stateless code that can infinitely scale -- is it 1 or 100 services? Just depends on the perspective really...

bradwood 4y ago

it's also worth noting that, initially, we built everything in one account, and had 1 team doing all of it -- the cognitive load became too high at one point, and, only then, did we break out the "DDD" and split the concerns across many teams.

dagss 4y ago

We were really happy with Google App Engine for the same reason. It's a product that feels like it was "10 years too early". Like you I feel the whole microservice debate turns into a "depending on definition" kind of thing and feels odd. Write stateless code that can infinitely scale -- is it 1 or 100 services? Just depends on the perspective really...