Domain-Oriented Microservice Architecture

Post by sagichmal » Sat, Jul 25, 2020, 4:40 PM UTC

scarface74 wrote: post #88

sagichmal wrote: post #85

Earlier quoted context omitted.

That reason is oft touted but experience has pretty unambiguously revealed that it never pans out in practice. I mean you do get that benefit but the price you pay for it is absolutely disproportionate if that's the only thing you want. Opting in to microservices purely for presumed technical benefits is absolutely a mistake.

How is it a “presumed” benefit when we actually did sell access to our APIs to clients? Some of our APIs initially had very low usage during the day until a batch job came in, others saw a spike in usage by over 100% when we bright a new client in. We were used by health care networks. Can you imagine the increased use post-Covid? We even had some that were both hosted on Fargate (Serverless Docker) with lower latenc…

Post by sagichmal » Sat, Jul 25, 2020, 5:23 PM UTC

scarface74 wrote: post #92

sagichmal wrote: post #91

Earlier quoted context omitted.

My point is that you don't need to rearchitect your application in an entirely different style to be able to scale in response to load.

If only part of your “application” has more load than others what do you suggest? That instead of being able to granular take part of the application that had a larger load, and run it on a Firecracker micro VM (the underlying VM for lambda and Fargate) with 256MB RAM and 1 core, we add enough VMs to scale a monolithic app - even the parts that don’t need it on a full scale VM with 8GB RAM and four cores? We did actu…

Post by clintonb » Sat, Jul 25, 2020, 5:53 PM UTC

jmchuster wrote: post #79

dkersten wrote: post #7

Somewhat off topic but maybe someone can enlighten me: > Uber has grown to around 2,200 critical microservices Even thinking about the very largest systems I’ve worked on, I can’t think of what could possibly be split into 2000 separate individual services. What are these thousands of microservices and how micro are they?

Hmm, would it be easier to imagine PayPal or Stripe requiring a lot of services? Given its volume of payments, Uber has basically had to re-implement PayPal internally, custom-tailored to its own flow. Companies at this size/scale basically contain multiple whole companies within them. Think of like all the SAAS services that your company relies on, and then imagine that your company now owns all of them and all the…

Post by sagichmal » Sat, Jul 25, 2020, 6:32 PM UTC

scarface74 wrote: post #94

sagichmal wrote: post #93

Earlier quoted context omitted.

Scale the whole thing. The cost of doing that is usually orders of magnitude less than the true CapEx and OpEx of microservices. edit: If breaking out one service from your monolith worked for your use case, that's great. I'm not trying to deny your experience. It is atypical, however.

We are talking about a 16x difference in resources. Would you also suggest scaling a database that was more read heavy than write heavy instead of splitting reads and writes when you can deal with eventual consistency and just autoscale the read replicas?

Post by jmchuster » Sat, Jul 25, 2020, 8:44 PM UTC

clintonb wrote: post #95

jmchuster wrote: post #79

Earlier quoted context omitted.

Hmm, would it be easier to imagine PayPal or Stripe requiring a lot of services? Given its volume of payments, Uber has basically had to re-implement PayPal internally, custom-tailored to its own flow. Companies at this size/scale basically contain multiple whole companies within them. Think of like all the SAAS services that your company relies on, and then imagine that your company now owns all of them and all the…

Uber uses Stripe and PayPal to process payments. They don’t need to reimplement either, and doing so would be a bit of a waste. It’s worth pointing out that not all of the 2200 services may be user-facing. Some may be internal, such as admin tooling or CI services. That said, 2200 seems like a lot!