Operating on Laravel within the serverless framework is incredibly effectively. It allows us to combine the technological creativity of the former with the straightforward simplicity of FaaS applications developed with the tech of the latter.

Our Goal

Our business is selling digital securities in an ever-changing environment. Because of the nature of this business, we don’t fully know what technology we’ll need in six months to book our bonds. That’s why we work within a large network of our own API first applications that have been loosely coupled. We’ve tried many different approaches to extend our network with new applications over the past two years.

Now, we’re on the verge of creating a new boilerplate because we’re not completely satisfied with our ECS Fargate setup for traditional applications. In that setup, it was still too complicated to host and run new applications on our network efficiently. Like many organizations, our goal is to create a network of loosely coupled applications that allow developers to dock compliant applications with quickness and ease. A service like Vapor might come to mind when you hear this description.

At first, an AWS Lambda + Gateway setup for such applications seemed liked an out-of-the-way solution. However, after our last Cloudformation ECS Fargate workshop for PHP developers, we realized that we can still come at this problem with the calm, undogmatic approach we prefer. Our answer? Just use AWS Lambda function for laravel. Some might question it, but we say so what?

Compliance Concerns

Tyler Otwell’s new service Vapor is another great product from a well-known name in the industry. However, most corporate enterprises won’t be able to use it because it will not meet compliance requirements. We are striving to gain ISO 27001 certification, so there’s no way for us to get around requirements such as AWS RDS, AWS S3, AWS DynamoDB, AWS ElastiCache and so on. ECS Fargate initially sounded like something out of a dream to us because we didn’t want to have to care about Linux machines or need to document everything again.

We found that we could outsource much of the procedure to AWS, but there were still difficulties in defining, adjusting and monitoring instance sizes. With our current setup, there’s no need to think about how many CPU cores an application needs. By using a native Cloud approach, we are able to create strong requirements for secret keys and passwords. This is another area where we’d ideally not have to deal with such requirements. In our perfect world, nobody knows the credentials of a database.

Keep It Simple, Stupid

In our system, each application has its own AWS account. We operate mini clusters for which an ECS Fargate cluster was found sufficient. We saw no reason to create a Kybernetes monster when we had an established EC2 environment that most developers understood. Many companies employ a Kybernetes cluster without knowing why, and we doubt that’s made them any more agile. Of course, they’re also in a bind when it’s time to find a Kybernetes engineer. When it comes to design on this level a simple rule applies: Keep it simple, stupid.

Application Network

We work with independent, remote teams that have an end-to-end responsibility to cover their respective business areas autonomously. At this level, we have been seeking the right setup to run these applications for two years now. After all, no one in today’s market is looking for a big lump of software. It’s far preferable to keep everything loosely connected so that systems are adaptable to a world full of constant changes.

It’s crucial that own processes can be put together with speed and diversity never seen before. For growing companies, the goal is no longer analogous to progressing technologically from skateboard to bicycle to car. Instead, companies need to deploy reusable components. Think of applications analogous to the tools needed to build men’s, women’s and racing bikes. Each needs brakes, chains and a frame, but there are unique needs for each build too. We’re endeavoring to create the conditions to break IT first.


As a business enterprise, you need to find API first solutions that allow you to write new applications quickly in order to meet your compliance needs. In order to build this type of system, we tried everything from EC2 applications to ECS Fargate applications to a Node.js application deployed within the serverless.com framework. We think that we’ve now found a solution that will work well for the next two years. Of course, we believe it’s important to remember that not every strategy applies to every company. If you are in a start-up phase and you’re working on a product as part of a three-developer team, you should carefully weigh whether you need an infrastructure that offers more services than developers.

Why? Because nobody develops faster than with just one application with server-side HTML rendering. And make no mistake, speed is what matters. On the other hand, the chances that you’ll ever work with more than 20 developers on an application after the launch of your startup are extremely low. If you do find yourself in that situation, it means that your business requirements and architecture look very different than originally planned. The lesson here is that you shouldn’t overwork anything. Remember that we aren’t all doing rocket science.


Another big advantage of our system is that developers can use this setup from home to run a side project without breaking the bank. There’s no reason for you to spend 200€ per month to access an AWS ECS Fargate, AWS RDS and AWS ElastiCache setup. You and any other developers will love our setup and will be able to use it privately.

A benchmark article that fully explains our strategy and system will be coming in the following weeks. We’ll be offering more information about how we manage independent AWS accounts for each application as well.