Everybody is running after this and gets stuck at one stage or the other unless their product or application is still in black and white on some notebooks or just in the wireframe and has to be built from the ground up. Now if you are going to build a new application, it can be designed to take full advantage of the cloud by combining multiple microservices, leaving out more time and resources to do the application into a perfectly usable solution. Whereas we are considering migration of existing applications into the cloud. The development language, database as well as design approach of the whole application should be considered when thinking about migration. It means that migration to the cloud should be considered on a case-to-case basis and there is no storyboard which fits all use cases.
For the ease of my current article, I am considering a PHP laravel based API backend which uses the MySQL database for data storage. Assumptions extend again that the front-end is Angular and typescript which can be built to static web application when deploying. Deploying the Php laravel on AWS Ec2 and database on AWS RDs or MySQL on Ec2 is the most simplest form of go to the cloud. But that does not scale well or the scaling requirements might need more overheads with the Operations team. Also releasing code updates through CI/CD will be a herculean task.
So the suggestion is still around lift-and-shift making use of docker, elastic container registry, elastic container service, AWS fargate cluster, AWS aurora MySQL database, and AWS application load balancer to achieve an entry into the aws serverless migration path. For a fully running application backend, this could turn out to be more costly than running it on EC2 instances and when TCO is considered, migrating to lambda would be much more cost-effective.
Before any considerations of the above is underway, suggested to do a query profiling on the application using Open PHP-MyProfiler one can download the profiler and sampler host it on a local environment to collect all queries and analyse them.
Well when cost and scalability are a concern or we need a good balance across, redeveloping the application in any recommended scripting language with each component into functions leveraging Function As a Service – the AWS lambda API Gateway, SQS, SNS etc would turn out to be much cheaper if planned well ahead and deployed likewise.
Utilizing DynamoDB with global tables and deploying multiple copies of the application across regions and AWS accounts the cost can be controlled. By utilizing the latency-based routing and edge-enhanced delivery customer experiences can also be improved drastically. When considering this distributed architecture, anyone would think that this is getting really complicated and maintenance as well as release cycles could be cumbersome. Exploiting the Infrastructure As Code (IAC) AWS CloudFormation or AWS SAM CLI and code pipeline combined with some crucial DevOps techniques the software release cycle can be fully automated with integrated testing, blue-green deployment and whatnot.
Building a serverless Laravel application is a good reference document but the section 4 in Deploy Laravel and Bref with AWS SAM a git repository is referred to and the template has some complications with the s3 bucket names hardcoded and my fork has the updated template with corrected source path also stack name in the s3 bucket names.
https://github.com/jthoma/php-examples-for-aws-lambdaIn the near future I might start on a new lambda layer based on the stackery project with the latest php and a fully new document can be expected soon which does not use the bref and bridge. For a fully new development of API backend in php just checkout my minimal routing framework php::mf which can be used to quickly churn out rest api backend