I think we've gone back on forth on this over the years. The rate of new services is decreasing, so I think we have shifted more from lots of very small services (low thousands lines of code) to bigger ones that are more like an entire product (e.g. 100k LoC+). But I wouldn't be surprised if the pendulum shifts back again in the future - there are downsides with the larger services, like greater contention withe other engineers.

That's what I've seen elsewhere, at least.

2800 is not even that many depending on the company size. At my current employer I'd guess we have somewhere between 2-3x that, and those are more complex services than a simple lambda + endpoint in each. Just my user with its groups gives me ownership of some 200+ components.

Those are only backend microservices, not counting data pipelines, and other supporting applications.

What constitutes a microservice is a philosophical question very related to the company's culture, some companies will prefer very small single use-case services, some will develop microservices that support a whole isolated functionality (with business logic) to be re-used across the stack. There's no single definition that can be applicable to such variety of architectures.