The document discusses ways to add serverless functionality to legacy PHP applications. It begins by explaining what serverless is and the benefits it provides. It then explores various approaches to incorporating serverless starting with simple tasks like logging and moving to more complex uses like allowing users to run custom code. Challenges encountered include determining where to store settings and testing limitations. The document envisions further serverless integration like rebuilding the admin interface and customer portal.

1. Adding
Serverless Apps
to your
Legacy / Monolithic
PHP Applications

2. 2

3. 3

4. 1. What is “Serverless”?
2. Why bother?
3. Ways to get started with
serverless + legacy
a. From easy / low-touch, to…
b. Major functionality /
high-touch
What we’re gonna
talk about (broadly)
4

5. 5

6. 6

7. 7

8. 8

9. My thing ->
Me:
Generalist problem solver
In Austin or a big RV
@brettflorio
▪ Launched in 2007
▪ Processed over $1B for thousands of merchants
▪ Cart + Checkout. No CMS.
▪ 100+ payment, tax, & shipping integrations
▪ Level 1 PCI Service Provider
▪ https://foxy.io/ and @foxycart
9

10. FML
Why?
WHY!?
10

11. How to modernize?
Lots of options, but basically:
1. Complete Rebuild
2. Partial Rebuild/Refactor
We’re going to talk about
taking an iterative and
additive approach, using
serverless.
11

12. What is “Serverless”?
Broadly:
Running code without bothering
with the infrastructure.
It’s a natural evolution:
Physical servers (colo or closet)
-> Dedicated Servers
-> Virtual Machines / VPS
-> Containers
-> Serverless
12

13. 13

14. ▪ HTTP requests
▪ Scheduled events (like cron)
▪ Platform-specific items like…
a. S3 file events
b. SNS & SQS
c. CloudWatch Logs
d. DynamoDB & other data stores
EVENTS:
How to
actually run a
serverless
app.
14

15. Serverless Providers
& Stacks
15
Biggies:
▪ AWS Lambda
▪ Google Cloud Functions
▪ Azure Functions
Others:
▪ Cloudflare Workers
▪ Fn
▪ Kubeless
▪ OpenWhisk
▪ Spotinst

16. Make Serverless Easy
with serverless.com
● YAML-based
● Provider-agnostic
● Great ecosystem
● Local dev options
● Open source & enterprise
16

17. Let’s focus on Lambda
17
● HTTP requests
● HTTP responses
● Other events to trigger
● PHP is possible
● Filesystem (lack thereof)
● Cold starts
● Execution time limits
● Security via IAM

18. 18

19. THE GOOD:
▪ Hugely reduced infrastructure overhead & costs*
▪ Can encourage better programming &
encapsulation (especially in a legacy env)
▪ Easier path towards modernization
▪ Scalability OHMYGOSH
▪ Security (in general)
▪ Isolation from legacy app environment
THE GOOD,
The Bad,
& The Ugly
19

20. THE BAD (OR LESS-THAN-GOOD):
▪ Overhead of “more stuff”
▪ Languages & PHP support
▪ Incorporating with deployment procedures
▪ Figuring out local dev
▪ Additional overhead for logging & monitoring
▪ Adjusting to new approaches & ways of thinking
▪ Less control over environment
The Good,
THE BAD,
& The Ugly
20

21. THE UGLY:
▪ Vendor lock-in
▪ Cold starts, VPCs & database access
▪ Output formatting
▪ SO MANY SERVICES (and their learning curves)
▪ Balancing disparate systems / thresholds
▪ “Whoopsies” moments :)
The Good,
The Bad,
& THE UGLY
21

22. 1.
LOGS!
The easiest
please to start
with serverless.
22

23. 23
▪ Mail through SendGrid.com
▪ Logs at LogEntries.com (now Rapid7)
▪ How to get SendGrid’s webhook to
LogEntries endpoint, with authentication
headers?
▪ Serverless!
Our first foray into Serverless:
Getting mail logs to our log management system.
1.a
LOGS!
Start with handling
logs. Don’t even touch
the legacy app.

24. 24
1.a
LOGS!
Start with handling
logs. Don’t even touch
the legacy app.
var Logger = require('le_node');
var le = new Logger({
token: 'F00BAR-1234-5678-ABCD',
timeout:1000,
withLevel:false,
});
module.exports.handler = function(event, context) {
le.log(event);
le.on('error', function(e) {
console.log('LOG_ENTRIES_ERROR: ' + e.message);
context.done();
});
le.on('disconnected', function(e) {
console.log('done');
context.done();
});
};

25. 25
1.a
LOGS!
Example simplified
serverless.yml
service: sendgrid-to-logentries
provider:
name: aws
runtime: nodejs8.10
functions:
processSendgridWebhook:
handler: index.handler
events:
- http:
path: webhook/process
method: post
# NOTE: The previous function doesn't quite
# actually go with this, but it’s close :)

26. 26
The Use Case:
▪ Blocking IPs that generate excessive
e-commerce checkout errors.
▪ We don’t want our legacy app to handle
anything at the network level. IP blacklists
shouldn’t be a legacy app thing.
1.b
More logs!
Parsing logs to block
abusive users &
fraudsters.

27. 27
▪ CloudFront generates a LOT of logs, and
knows when Legacy generates a specific
error (ie. by response code 422).
▪ AWS has a WAF that looks fun, but…
▪ Legacy app can’t handle new 💩tons of data.
Serverless and Legacy see each other across the
room… Serverless catches Legacy’s eye… What is
this flutter in Legacy’s heart?
1.b
More logs!
Parsing logs to block
abusive users &
fraudsters.
▪ New skill unlocked: S3 events!
▪ Lambda can easily update the WAF blacklist.

28. module.exports.processCloudFrontLogs = (event,
context, callback) => {
// … some stuff removed up here …
parser.on('readable', function () {
let access;
while (access = parser.read()) {
switch (parseInt(access["sc-status"])) {
case 422:
process422(callback, access, ddb);
break;
case 504:
process504(access);
break;
default:
continue;
}
}
});
// do a bit more, removed…
};
28
1.b
More logs!
Parsing logs to block
abusive users &
fraudsters.

29. function process422(callback, access, ddb) {
async.waterfall([
function(cb) {
// Add the entry to DynamoDB
ddb.put(log, function(err, data) {
if (err) {/* ... */
} else {/* ... */
}
});
},
// Query Dynamo to get all the matching records
for the IP
function(ip, timestamp, data, cb) {
// Check the count of errors for the IP
// Then add the IP to the blacklist
},
], function (err, result) {
callback(err, result);
});
}
29
1.b
More logs!
Parsing logs to block
abusive users &
fraudsters.

30. functions:
processCloudFrontLogs:
handler: cloudfront.processCloudFrontLogs
events:
- sns:
arn: arn::::123ab:CloudFront-Log-Delivery
blacklistIpFromDynamo:
handler: waf.blacklistIpFromDynamo
events:
- stream:
type: dynamodb
arn:
Fn::GetAtt:
- blacklistTable
- StreamArn
30
1.b
More logs!
Parsing logs to block
abusive users &
fraudsters.

31. What just happened?
1. Serverless + logs = easy way to get started
2. HTTP event
3. File creation event
4. Database record creation event
5. Rock-solid, effectively zero cost, worry free
31
1.z
SUMMARY
HTTP event.
File (S3) event.
Database (DDB) event.

32. The Use Case:
▪ Blocking by response code works, but we can
get more specific to catch bad behavior.
▪ “Card testers” will push attempt many
transactions, using a new credit card # every
attempt. The cards that make a successful
transaction (often a donation) will then be
used in a more targeted fraud.
▪ Let’s blacklist IPs that attempt more than X #
of different CC#s in Y minutes.
32
2.
MOAR LOGS
Let’s finally have
Legacy actually talk to
Serverless.

33. ▪ Serverless: Add additional http event handler.
▪ Legacy: Add a little http request.
- Short timeout. Ignore errors.
33
▪ A serverless app is well-suited to adding
related functionality to.
▪ Legacy apps can usually be easily extended to
make an extra outbound request or two.
Serverless has an easy charm that Legacy can’t
resist. Legacy walks up and makes a REQUEST to
Serverless. Serverless responds with a 200 OK!
2.a
MOAR LOGS
Let’s finally have
Legacy actually talk to
Serverless.

34. public function logCheckoutAttempt($FoxyGateway) {
global $serverless_waf_endpoint;
$last4 = ''; // prep some data
$data_to_log = json_encode(array(
'ip' => $this->getCustomerIp(),
'host' => $this->store->getActualDomain(),
'store_id' => $this->store->getId(),
'last4' => $last4
));
$ch = curl_init($serverless_waf_endpoint);
curl_setopt(); // Better google "how to curl in php"
// for the 1,000th time
$result = curl_exec($ch);
curl_close($ch);
}
34
2.a
MOAR LOGS
Let’s finally have
Legacy actually talk to
Serverless.

35. s
# Let's add an HTTP endpoint for Legacy to hit
processAttemptedCheckout:
handler: app.processAttemptedCheckout
events:
- http:
path: checkout/attempt
method: post
35
2.a
MOAR LOGS
Let’s finally have
Legacy actually talk to
Serverless.

36. 36
▪ We don’t want to blacklist IPs forever,
especially for our “excessive errors”.
▪ Schedule serverless to purge “old” IPs every
day.
Legacy is in love!
“Can you text me a love note every 8 hours?”
“Totes yes,” promises Serverless.
2.b
TIDYING UP
Let’s get a cron going
to periodically remove
offending IPs.

37. s
tidyIPBlacklist:
handler: waf.tidyIPBlacklist
events:
# The Serverless Framework accepts either
- schedule: rate(6 hours)
- schedule: cron(0 6 * * ? *)
37
2.b
TIDYING UP
Let’s get a cron going
to periodically remove
offending IPs.

38. The Use Case:
▪ Webhooks are 🔥💯, but webhooks built in
2007 are definitely not.
▪ Legacy app already was sending a payload
to an arbitrary endpoint, so it was
well-suited to be augmented/replaced with a
serverless app.
▪ It’d also allow for additional 3rd party
integrations like Zapier.
38
3.
GOING BIG
Replacing a core
component of the
legacy app.

39. 39
▪ A single URL endpoint.
▪ No automatic reattempts on errors.
▪ Legacy XML API payload, that was…
▪ Encrypted with RC4, not AES, and…
▪ Was URL encoded (instead of Base64) (?!)
▪ Required a specific response payload instead
of a 200 response code.
What needed fixing?
Lots of stuff.
The old system was limited to…
3.
GOING BIG
Replacing a core
component of the
legacy app.

40. 40
▪ Needed the ability to send to multiple
endpoints, without slowing down legacy.
-> Queues of some sort.
▪ Didn’t need to be in the PCI environment, as
webhooks didn’t touch CC#s.
▪ We wanted to extend it to 3rd party
integrations, so it really felt more like a larger
& separate component.
Should we rebuild it in the legacy app?
Short answer: Yes.
But why?
3.
GOING BIG
Replacing a core
component of the
legacy app.

41. Challenges & Errors:
1. Where (legacy MySQL db
or serverless’s DDB) should
settings live?
2. Legacy caching v. DDB.
(Don’t bother with cache.)
3. $1000 testing “whoopsies”
4. Controlling serverless
settings via legacy API.
What we got right:
1. It worked!
2. It scaled.
3. It was silly cheap.
4. It allowed lots of options
without causing
problems for the app.
5. It allowed 3rd party
integrations.
41

42. 42
▪ Legacy app uses MySQL.
▪ Serverless uses DynamoDB.
▪ Trade-offs either way.
▪ We pushed more data into the serverless app
than we maybe should have.
▪ Using the serverless app’s datastore for
“temporary” things is fine, but “real” data and
config should be in the primary datastore.
Let’s explore a challenge we faced:
Where should per-account settings be stored? In
the legacy app’s MySQL, or serverless’s DDB?
3.
GOING BIG
Replacing a core
component of the
legacy app.

43. 43
▪ Legacy uses Redis (via ElastiCache).
▪ Legacy was caching serverless settings (from
DynamoDB).
▪ For our uses, DDB was just as fast as Redis,
so attempting to cache DDB data only added
complexity.
▪ KNOW YOUR TOOLS.
Know your tools: Caching.
Serverless apps may not require the same
solutions as legacy systems.
3.
GOING BIG
Replacing a core
component of the
legacy app.

44. 44
▪ Set reasonable concurrency limits.
▪ Set reasonable timeouts.
▪ Don’t accidentally blow through $1000 by
setting 5minute timeouts and max
concurrency :)
▪ Shout out to AWS for understanding!
Testing & Timeouts
Stress testing is great but remember you’re
paying by the (milli)second!
3.
GOING BIG
Replacing a core
component of the
legacy app.

45. 4.
RUNNING
USER-
SUPPLIED
CODE
User code.
On our servers?!
Within our app?!?!?!!!
45

46. The Use Case:
▪ Getting accurate shipping rates is near
impossible to pull off in a way that’ll easily
work for “everybody”.
▪ 99% of custom shipping hacks are easily
accomplished with a bit of custom code.
▪ Wouldn’t it be great if we could safely and
securely allow our users to run custom code,
within our application?
46
4.
RUNNING
CUSTOM
CODE
How to allow enough
flexibility? How about
allowing straight js?

47. 47
4.
RUNNING
CUSTOM
CODE
How to allow enough
flexibility? How about
allowing straight js?

48. How it works:
1. Serverless app repo
exists in filesystem.
2. App copies directory,
updates some files, and
runs `sls deploy --args`.
3. App stores custom code
and serverless app status
in db.
4. Serverless returns API
Gateway URI. App stores in
db.
5. App makes requests to URI,
and handles the responses.
48

49. What we go right:
1. Started small. No UI yet.
2. Security.
3. Robust documentation
and helpers.
4. The whole system is part
of the app. No issues
with builds/deploys.
Challenges & Errors:
1. AWS limits.
2. Async deploy process
difficult to handle within
legacy app and API.
49

50. 50
▪ Possible to reuse a single serverless app?
Yes, but… Why risk it?
▪ Every user gets an entirely separate
CloudFormation (serverless) stack.
▪ The Lambdas have effectively zero access.
▪ The Lambdas are in an entirely separate AWS
region from the main application.
Additional notes about this weird approach:
4.
RUNNING
CUSTOM
CODE
How to allow enough
flexibility? How about
allowing straight js?

51. 5.
TO INFINITY
Where are we going
from here?
51

52. “
Some people,
when confronted with a problem, think
"I know, I'll use regular expressions
SERVERLESS."
Now they have two ZERO problems.
52https://en.wikiquote.org/wiki/Jamie_Zawinski

53. Rebuilding the admin:
▪ Full serverless-powered web app.
▪ All back-end functionality via the existing API.
a. Allows for open-sourcing the whole thing.
b. Forces us to become API first.
▪ Utilize other AWS services like Cognito.
▪ Trivially easy to fork, modify, whitelabel, and
deploy for enterprise users.
53
5.
SERVERLESS
ALL THE
THINGS
Or lots of them,
at least.

54. Customer Portal:
▪ Add a public /customer endpoint served by
serverless, along with existing /cart and
/checkout legacy endpoints.
▪ Route requests to /customer to serverless app
instead of legacy (via ALB or CloudFront).
▪ The customer portal interacts with legacy app
only using existing interfaces (both back-end
and front-end).
▪ This is the foundation of additional core app
functionality. Not a “one-off”.
54
5.
SERVERLESS
ALL THE
THINGS
Or lots of them,
at least.

55. Credits Special thanks to all the people who
made assets used in this presentation.
55
▪ Watercolors by Catarina Garcia
▪ Other art by my children (who don’t have websites yet)
▪ Demotivational poster “Laziness” by Despair.com
▪ Presentation template by SlidesCarnival

56. Questions?
Thanks!
56
Happy to talk about this or most any other topic.
▪ Foxy.io / FoxyCart.com
▪ @brettflorio
▪ @foxycart
▪ Slides available at bit.ly/serverless-foxy