United Rentals (https://unitedrentals.com Fortune 500 pre-covid) uses Laravel for one it's back-end API that supports its android app, iphone app, and several web apps.
You won't find any major companies saying they are "built with Laravel" because they aren't. That doesn't mean they don't "utilize Laravel".
At scale, you're going to see most companies implementing distributed systems and using something like a server-less distributed system that allows for several containerized services in the cloud.
One of those many services distributed across a large company's entire cloud infrastructure may be an API and that API may be implemented using Laravel.
In the case of United Rentals, one of - if not the - most important APIs is built using Laravel.
It's an extremely important service within the entire distributed systems architecture, but by NO means what so ever would I consider United Rentals "built with Laravel".
If anything, United Rentals is built on top of aws and the cloud - but even that's not entirely accurate as their are resources outside of the cloud infrastructure and the cloud acts as a middle man in a lot of cases between the clusters of databases and the 5 to 8 front end clients.
With that said, United Rentals uses Vue for its E-commerce front end, React for some sort of learning platform offered, Java for it's android app, Swift for its iphone, aws lambdas for handling serverless events coded in node/typescript/python, aws code pipeline, aws code deployment, aws codestar, aws codecommit etc... for continuous integration and continuous deployment.
United Rentals uses AWS SNS in which AWS Lambdas can subscribe to via their topics, and AWS SNS (Simple Notifications) are then able to be used to trigger lambda functions (aka server-less event handler) that handle every kind of event you can imagine. These events are queued up using AWS SQS and then I personally was responsible for getting them over to our sales force team.
Then you have to talk about the actual Virtual Private Cloud that internally wraps a subset of your system which is only accessible via the AWS API Gateway which requires AWS Route 52 to configure the DNS/nameservers/Hosting Zones and regions.
Then you've got to add in the storage. Optionally, you could go with AWS Dynamo DB if you choose the NoSQL route as well as add in the AWS service for a relational database to use it instead or even use both databases at the same time - which often cases is the right decision in large scale applications. What if you want to store files/documents? AWS S3 is a solid choice - then you have a lot of data in large scale applications so you're possibly going to need to create an incredibly cheap way to store data that is outdated but still needs to be kept. Needing cheap instead of efficient, you may choose to use AWS Glacier.
You also have to take into account access, who is able to access these AWS services - what about the access allowed for dev API keys and secrets when they programmatically use AWS? IAM roles allow you to create roles that have permissions, these roles can be assigned and allow for resource policies to control access.
Then you have to talk about keeping all of this infrastructure supportable over time, if you had multiple teams working in the same codebase without version control the app would break extremely often. Same goes for cloud infrastructure within distributed systems, so the idea of "Infrastructure as Code" comes into play. You create your infrastructure using Definition files and version control it like you would any other codebase. These definition files define what your cloud infrastructure amounts to and ultimately supplies a way to maintain it in a way that doesn't break constantly.
Okay, so what else? Well, how's the whole computation thing work in the cloud? Example? Laravel can use vagrant as a virtual machine via Homestead...but how's that work when there are 100 services and only one of them is Laravel? Do you boot up 100 Vagrant Virtual Machines like homestead and manage/configure them while keeping them up to date?
Hell to the f no you don't, you'd probably go broke using virtual machines and it'd be a huge headache - instead you use containers like docker.
Docker containers allow you to separate the services infrastructure dependencies from the code itself. Ex: a single server doesn't, nor should it, depend on any other services runtime.
You can use Node in one service via a container that pulls and runs Node, Python in the next via a container that pulls and runs Python, and PHP in another one because that's what it needs to run some good ol' Laravel.
The MySql/NoSQL database would also be its own service and thus would use their own containers to support their own runtimes respectively.
There's also the AWS SAM framework for devs to easily invoke and deploy server-less infrastructure code locally and directly deploy it to the cloud.
Now with a part of the distributed system explained, I'm going to end with a final portion of that distributed system that matters more than most.
The ability to duplicate/replicate a given service to allow for horizontal scaling needs to be set up.
How's this work?
Well that Laravel app being its own service with its own docker container isn't the only thing that a service in the cloud is.
A service with a Laravel app and associated docker container in the cloud should be duplicated multiple times over. The cloud allows us to create, for example, 6 instances of the same service.
In this 6 instance example, this means we have 6 Laravel Apps each with its own docker container. This allows us to put a load balancer at the entry point so that when the IP address to use the Laravel service is hit, the load balancer will actually distribute the traffic to any one of the many instances of our Laravel App.
We're able to configure the replication of instances for any service to automatically scale and descale based on traffic demands so that we are optimally using computational resources while also being able to scale without losing any of the speed that we had when the traffic was extremely low.
One user or one hundred million users, by using the cloud we're able to add multiple services into a complex distributed system while maintaining the speed of an application via horizontal scaling and improve site reliability by having multiple instances that allow traffic to hit another instance of the same service if a specific one out of the many fails.
Now, knowing what you know after reading this post, would you call United Rentals a "Laravel Application"? Laravel is a single, very important service - but to call it a Laravel application would be an incredible understatement.
This doesn't mean Laravel isn't used at scale, simply means scale requires an entirely different way of building applications that goes beyond any single framework - including Laravel.
Also, not huge yet - but https://cleancode.studio was approved for a $5k AWS grant and will be using Laravel for one of its backend API s as well (totally a zero shame self-promotion, but hey - convince me this isn't more of a blog than a comment and blogs are backlink worthy - aka self-plug justified :D )
