Cloud commoditized datacenters. People then tightly coupled their applications to cloud providers like AWS. After some time, containers came along and commoditized the cloud providers. Those applications no longer needed to be tightly coupled to a specific cloud provider. This reduced both costs and the risk of being invested in a single cloud provider.
Serverless (AWS Lambda) is just the cloud's way of trying to "de-commoditize" the containers that commoditized them. They want you to tightly couple your applications to their specific cloud provider again. And charge you more. How much is that function in the zip from S3 going to cost you to run in a container managed and run by AWS? And how long did you spend configuring the API Gateway (and where else can you apply what you've learned doing the configuration)? Next time you see an article fawning over serverless and saying things like "Containers just don’t matter in the serverless world" take a look at what the author does for a living. You'll start to see the same pattern I've been seeing.
Meanwhile, you could be spending less money and time treating AWS like a dumb processor with a network connection while only really configuring the open source software you already know. But it's your time and money.
If you write your Lambda function to put the interaction between the AWS Lambda service at the surface level of your application (i.e. the entry/exit point), and then write your business logic inbetween, you can create a function that is quite easily tranferrable between cloud providers.
The vendor lock in creeps in more around the surrounding services that the cloud provider offers. You can protect yourself from this though by writing good quality hooks that have pluggable backends, e.g. writing/reading to an object store should be abstracted
Wouldn't it be ideal if Docker (and other independent platform vendors) added function support? In my mind "cloud functions" are easily implemented on top of containers. Then we would get the best of both worlds.
I've had to answer many questions about delays in serverless functions that didn't come up with Docker. Serverless doesn't have the introspection necessary to answer performance questions.
What if Docker supported functions? I'd ask what we gain trading a main loop for only bindings. Similar bindings are made either way.
I honestly wish cloud providers would make their core SDKs as easily composable as their serverless offerings.
Exactly. This is the goal of http://FnProject.io -- power of containers + simplicity of serverless. No managed service yet but there will be, and anyone can run the bits to create a service of their own.
I do agree with Paul about containers having a greater update surface area, but we think this is also solvable and doesn't need to be a responsibility of the developer either.
Yes you can, but even that wouldn't be lock-in. Lock-in imo had much more to do with whether you have to write your code specifically to the vendor, and in the case of all 3 FaaS, the answer is mostly "not really." It is trivial to transfer the same behavior from lambda to Google cloud functions.
I just don't get the "lambda locks you in" thing. You write a server the same way you always would, but like an extra 50LOC exists to make it work on lambda. So if I wanted to deploy elsewhere what would the big deal be?
Lambda also provides a lot more than containerized services, as the article mentions - I no longer have to patch my system, which is a huge operational/ security burden that many companies struggle with. The time to configure API Gateway/ Lambda feels trivial compared to the work involved in maintaining a patched FAAS solution.
I agree, but in my experience, the lock-in with using Lambda is that you become integrated with other Amazon services (like S3 and DynamoDB) that are harder to replace if you abandon AWS entirely.
That really doesn't feel like it's inherent to Lambda at all. You could say the same thing about EC2.
On top of that, many of AWS's services use standard API's. It's not hard to move away from RDS or Elasticache, you're just using SQL/Redis anyways...
If we're talking about something like SQS, ok, well you can just as easily say you're "locked in" when you use RabbitMQ because there is work involved to not be using RabbitMQ.
There are a finite set of this to trigger the function and they become central to
API Gateway, kinsesis, s3 change/addition...
It definitely has more lock in potential than more "vanilla" offerings like EC2, RDS, S3.
You could name a replacement/competitor service for each of the above, but if the Lambda is triggered by S3 changes then that's a big barrier to putting your static files elsewhere
> That really doesn't feel like it's inherent to Lambda at all. You could say the same thing about EC2.
The major difference is that Lambda hooks into your developer tooling, and source code, in a way that EC2 doesn't.
Sure, you can use Lambda without calling AWS APIs from your app... But you'll be using SDKs, tools and documentation that push you to do so, every day. It will require conscious thought and effort in your development to avoid lock-in, and over time the required effort will increase, because more and more third-party tools and libraries will switch to proprietary dependencies, dragging you along with them.
To me, that's the opposite of lock-in. You can leave AWS because you can move away from any one service easily without affecting the others. There are even vendors who directly implement (for example) S3's API so you have almost no code to change.
Traditional vendor lock-in is when you can't move away from (e.g.) your Oracle database because you've got a dozen different applications that will need simultaneous rearchitecting if you ever want to get away from it.
If anything — 50 LoC seems like it might even be an overestimate. I use a wrapper function around all my lambdas that deals with translating from the aws http headers to an application standard, asynchronously retrieves a config object, and converts promise based business logic to the aws callback format. The actual business logic
is then written almost entirely in terms of the business domain. The wrapper is less than 50 lines and extremely easy to write. Making an equivalent wrapper for another cloud function provider would be easy ...
Someone thinking the need to adapt the input parameter format to achieve provider portability is by itself enough reason to add docker to the application stack is making a huge mistake in accessing the relative cost of these components ...
I don’t think deploying containers to different providers is anymore standard than the differences involved in deploying cloud functions to different providers so it’s not as if using docker would actually give a more uniform multi-provider deployment model ...
Is your wrapper code open source? If so, mind sharing a link?
EDIT: I'm actually less curious about the code, and more curious about how you're sharing code between different Lambda functions. Did you publish an npm package? Are you just repeating the code? Symlinks?
The wrapper isn’t open source. The project is node (typescript) and uses serverless [serverless.com] for packaging and deployment.
Serverless allows deploying multiple lambdas with entry points exposed from an npm package using cloud formation with standard code sharing practices applying — that is it’s easy to share code between entry points if all the entrypoints are defined in one serverless config file (one serverless config file corresponds to one cloud formation stack)...
It’s a bit more work to share code between stacks with serverless tho ... You either have to put shared code into a separate npm module and depend on that module everywhere you need the shared code (often incidental complexity for simple or unstable code!) or use symlink patterns that work with the grain of how the serverless bundling process works...
I actually created an issue suggesting a serverless feature to ease this a few months ago https://github.com/serverless/serverless/issues/4124. In that somewhat long feature request I describe the symlink pattern I’m using for easily sharing code and compilation contexts between stacks... I’m still using that pattern — it’s not terribly fun to explain to new developers on the project but it works well without a lot of gotchas so far ...
Why functions over Docker or Elastic Beanstalk? There's more than one PaaS path.
On vendor lock-in, I'm moving between clouds now. Serverless did not translate well at all. We would have saved a ton of time, and frankly had an easier operational experience, if we went with Docker from be beginning.
"Ok Jill, next we need to determine how Azure Storage Account bucket calls differ from AWS S3. Oh, S3 doesn't have queues so we need to use SNS which changes the transaction model...Yeah, we've gotta handle different guarantees"
Product at most places "doesn't have the time" for developers to abstract the serverless hooks. You have to change the interface that runs your app instead.of the interface your app provides.
I don’t understand why people complain about Serverless vendor lock in.
Let’s split lock-in into two categories:
1. Essential complexity
DyanmoDB and Firebase are different products with different features and complexities. There is no “ANSI SQL” here. They are as different as they are similar. Moving from one to the other is a non-zero cost because they have different features your app would have to make up for or adopt.
2. Inessential complexity
Serverless functions don’t necessarily need different signatures and it is conceivable that a standard for HTTP evented functions could emerge. Many are working on this. I expect this to be largely resolved over the next few years.
Lastly, I’m grateful for ANSI SQL but over the last 20 years I think I’ve seen one or two clients migrate a mature Java app from one database vendor to another (excluding some very recent moves to AWS RDS). Keep in mind that JDBC is about as good an abstraction as we’ve ever had for database agnosticism.
When you choose to build a lot of complexity upon an abstraction you have to be honest with yourself: have you ever dealt with a service (storage, queues, naming, auth, etc...) that didn’t have leaky abstractions? Of those with few/zero leaky abstractions how often did you need to migrate to a different vendor? Why do we expect a rapidly evolving set of systems and services to behave like mature commodity software?
Fear of vendor lock-in is a premature optimization.
API Gateway is the literal manifestation of the worst product I have ever had the misfortune of configuring. This is mostly due to AWS's incompetence at delivering any semblance of working documentation around the product. Looking forward to their new "open source" documentation.
I have just finished up using SAM and it is miles better than trying to wire API Gateway and Lambda together. Setting up an authorizer with cognito took some time to find the right examples and get the swagger right but yes I am a fan of SAM.
While we're on the subject, Cloudformation could definitely use some work too. AWS, please tell me what line the template failed at. We had to use the swagger extensions to integrate cognito and those were failing because of indentation errors, but it just kept complaining about invalid swagger 2.0 definitions. That is just so gross.
I can second this. I wanted to write a simple provisioning tool a while ago that sets up HTTP endpoint on API Gateway and forwards the call to Lambda and the process was extremely complicated.
Another issue with Lambda is that everything goes off the rails if you need to do something that Amazon hasn’t prioritized yet. Let’s say you want a GRPC endpoint, web sockets, http/2, mutual tls authentication, etc. Lambda won’t help you and you’ll be left building up your own patterns for those. Once you have those patterns, then Lambda’s use cases can be satisfied as well.
Also, Lambda doesn’t provide any sla’s on container reuse. They could restart your container multiple times per second or every few minutes. You are at their mercy to keep your containers warm.
Finally, with the meltdown example, would containers actually need to be patched if the parent OS gets patched since the kernels are shared between host and client containers? With Fargate, amazon would patch the base OS and your containers would be safe as they get rescheduled onto patched nodes.
Serverless is nothing more than PaaS - just at a more granular deployment/operation/billing/analytics scale. PaaS has always had a certain amount of lock-in because it's an abstraction, as any abstraction naturally does.
There are also some abstractions like Kubernetes that are neutral yet also managed with extras by all the providers which is a nice middle ground.
None of this is new or groundbreaking other than the silly hype words like "serverless".
I agree with you about the term "serverless" being silly, especially in a time when all the various forms of decentralized architecture are beginning to come of age. It makes it difficult to find information on "serverless webrtc signalling."
While other auto-scaling PaaS exist, the granularity of the lambda pricing model is fairly new and groundbreaking. A service can be launched that may see very little use and just costs pennies to test out during its initial phases. That same service will scale exponentially rather easily in comparison to a similar deployment on a traditional server.
It’s a cycle
Depending on where you start your argument, one can be the commodity or meta commodity
Your point is sort of moot
Cloud for next 10 to 20 years, is still about killing old it vendors and make people not worried to put everything they own on cloud. Container or serve less is but major milestones.
I agree with you in principal but AWS and Lambda feels significantly more complex than that. At least when I was FTP'ing my code up to some shared host I still had a lot of control over my environment (ini overrides, htaccess, etc...) With Lambda I feel like I have very little control. There is a black box running this stuff that I have no insight into. Even worse; when things break the resulting error is often unrelated to the actual problem.
one thing that would be great would be if it was setup in such a way that the API gateway / lambda functions had really simple, file based mappings on a virtual server that then automagically took care of deployment / scaling for you.
cp -r / symlinks could take care of the whole staging / lambda version aliasing stuff.
deployment is just scp'ing a zip file to a certain defined location.
all that insane complexity of configuring API gateway is replaced with some config.json or js file export defining what lambda to call and what permissions to use.
then to back the whole thing up you could just rsync it back to your local machine ... hmm though realistically you'd probably want to invert things and develop this whole hierarchy in a git repo that could be checkouted on that virtual server, or it could just natively understand git and branches just become the stages / alias as soon as you push them so no need to ssh in and pull.
Why is this a surprise? CGI is a great model for server programming. Lambda provides the same model packaged in a way that is enormously more convenient and powerful.
Deploying .zip files is one of my favorite features of Lambda, particularly when writing Go apps.
Docker always felt wrong with Go to me.
Why do I need a local VM, a Linux build service, an image registry and servers with container orchestration to deploy Go software? I understand how all this helps with "legacy" Rails or Java apps, but why can't I just throw a Go binary somewhere to run it?
Lambda is exactly this. I upload a cross-compiled .zip to S3 and everything else is taken care of. This was a big breakthrough for me, seeing a much simpler solution for deploys than all the container stuff.
I've been building a boilerplate app that demonstrates just how little "stuff" is needed to run a Go service on Lambda:
It actually wouldn't be too hard to build a MacOS tool for building scratch Docker containers with a cross-compiled Go binary. The docker image format roughly just a tar file containing a manifest json file and a tar file containing the root filesystem. *
Sure Lambda is pretty simple (just upload a zip!) and is very similar to what Google AppEngine has been doing since 2008 (AppEngine also uses zip). But you are signing up for complete lock-in...
Also, it's depressing to note that MacOS is now the only major operating system that does not have support for native Linux containers without the use of a VM. * *
You don't need all of that shit, though. You absolutely can just throw a golang binary into a super minimal alpine image and run it wherever you've got a Docker daemon installed. You literally don't need any of the things you listed! Plus, it is simply untrue that "everything else is taken care of" in Lambda. There is plenty of one-off configuration to do ("toil").
If you're just working with a golang binary, you shouldn't be using an Alpine container, you should be putting the binary in an empty, from-scratch container. Go binaries are typically static and don't need distro or the libs it provides in their container.
I can take my (docker) containers and VMs, move to an entirely different cloud provider, simply update DNS to point to the new IP and everything is up and running within 5 minutes of the host booting.
On AWS Lambda, I can't just rip out my entire infrastructure and move elsewhere. I'm stuck with AWS Lambda until I rewrite my functions to not rely on AWS Lambda and AWS Services.
If my hoster decides they don't like me anymore, I can move my business elsewhere within the hour. Can you move AWS Lambda to another provider within the hour?
Serverless has its upsides but it also has downsides.
In an ideal, pure, world it’s awesome. The problem is that your lambda function usually needs to use some sort of external resources. (It is pretty useless if you don’t interact with anything)
Now you have to worry about and understand how to do access control on the said resources, how to collect the logs, how to collect metrics relevant to your code, how do you troubleshoot and deploy the function itself, how do you integrate it with the rest of things you have/own.
You’re just shifting complexity from an area to a another area.
It works great in some cases, but it’s far from beeing a panacea.
Right, and one of biggest downsides to serverless: reusing database connections/pools between requests. Right now the only "standard" solution offered by serverless's biggest advocates is pretty much a hack: rely on AWS's preservation of memory across some warm invocations. Basically keep it in a global variable and if you get lucky it'll still be there the next time your functions runs.
I think a mixture of persistent proxies could work well with lambda functions for this use case. You can run lambdas in your VPCs with assigned security groups and IAM roles just like an EC2 instance and therefore lambda functions should be able to proxy through an intermediate server that performs the connection pooling on behalf of calling functions. Not sure what the standard solution for something like this would be though because every time I've seen connection pooling it's for use locally. Perhaps some nginx or haproxy hacking could make it work.
In this scenario you’re still paying the cold-connection cost to your proxy, and that’s just keeping a pool of tcp connections open, not necessarily doing anything smart/optimized in the sql driver.
Hey! We built http://readme.build to solve these problems (logging, metrics, deploying, SDKs, etc). It's free currently, and I'd love feedback (greg@readme.io)!
Reading through this comment thread, if anybody is interested in a much more streamlined “serverless” experience and superior API Gateway, check out StdLib [1]. We’ve built a product for getting APIs built and shipped, full stop.
Bonus: .tar.gz format for submitting packages instead of .zip (though our CLI handles it automatically), and a bunch of freebies - everything from automatically generated documentation [2], SDKs, simple local development and testing, and more.
Disclaimer: Am founder.
Disclaimer 2: At the risk of being borderline spammy, we’re hiring aggressively. If you’re passionate about building a future that uses serverless technologies to make software development and APIs more accessible, e-mail me. (And thank you, pre-emptively.)
I feel it is like reinventing executables, the dumb way.
We can compare that with ELF binaries or remote procedure calls when someone else maintains the OS and makes sure that the infrastructure scales. Actual not even executables, because it is still interpreted code, instead of being "compiled" it is packed and distributed with a spec much less precise than a typical platform. Just because someone has a machine ready to be deployed on and scale ad infinitum.
Am I the only one who finds that a dumb protocol for a remote call? Could someone point on which part is this a smart badass thing? Perhaps it is just a weird "renascence of Operating Systems"?
Edit: I still think that we got here because it was too much work to learn about pre-existing technology or hire an expert and it was more fashionable/easy/cool/sexy to kick ass and move on.
> Perhaps it is just a weird "renascence of Operating Systems"?
"Serverless" really comes down to being a fancy inetd(8). The "new" part is all in proprietary software-as-a-service to automate server deployment, cluster management and configuration, network configuration, access control, and log collection. In the next technology cycle 6-10 years from now, people will realize that having so much of your software tied into proprietary software-as-a-service is an idea that is even worse than running on proprietary operating systems (NT, Netware, VMS) was in the 1990s.
> I feel it is like reinventing executables, the dumb way.
Consider this: in the Unix philosophy, most executables consist of taking things that should be procedures and packaging them up as programs. "Serverless" is largely about applying the Unix philosophy to SaaS - "microservices." So now you are taking things that are really procedures, packaging them up as executables, then packaging those programs up as Internet servers.
I heard or read somewhere a quip that debugging this "stack" is something like the Russian fairytale about Кощей[1]: you have to find a needle, which is in an egg, which is in a duck, which is in a hare, which is in an iron chest, which is buried under an oak tree, which is on an island.
I agree with this sentiment and feel the same way. I also find this is a frustrating trend in our industry in where a lot of engineers seem to be spending more time learning about "services" from specific vendors than about things like network protocols and their workings and limitations.
> Maybe this is just inevitable evolution of the IT industry but I've noticed two things that are alarming.
I was at the Southern California Linux Expo[1] earlier this month, and one of the really weird things was how many people from Microsoft were presenting and attending (I wasn't the only one - Bryan Lunduke, ex-MSFT, did a podcast episode about it[2]). I think the trends you point out are from a lot of Microsoft, IBM, Oracle, Java, etc people now being forced into the Linux world, because Linux is now the default for new IT projects. Unfortunately they are bringing along their "practices" instead of retraining in good software systems engineering.
I kept waiting for the author to say, "Surprise, it's a jar file. Jars are just zips, and lambda supports Java." Then I realized author really was reinventing wheels for the reader who probably doesn't know what Java is.
I am totally with you... I think we are going backwards in technical choices just because some people had pain-points learning pre-existing technology or did not know how to deal with infrastructure. But if people pays for it, it is a market I guess.
I played with Firebase (Google Cloud) Functions recently and the developer experience was pretty good. It's like if serverless (https://serverless.com/) had first party support, in the form of the Firebase CLI. Deploying was simple, the Firebase dashboard is nice. That said, I only used it for a side project, so I don't know about any pains scaling. I would definitely use it again for another side project, though.
> You had to patch your containers and your instances/servers, but you didn’t have to patch Lambda functions.
This was right after talking about Fargate. Let's compare what you do and don't have to patch in Fargate / Lambda:
Kernel / host OS: Lambda and Fargate patch that for you without any work. This is the more important patch.
Container bins/libraries: some programs, like Chrome, which had JIT, could be exploited to read memory of that same process. In the case of lambda and fargate, you only needed to patch containers/zips that contained such programs.
If you were using something like 'serverless-chrome'[0] in lambda, you would have to update your zip file to get Chrome's workaround for meltdown. If you had a fargate container with headless chrome, same deal. It's practically identical in the cited case of meltdown.
There are many cases (like glibc or openssl vulnerabilities) where containers need to be patched, but lambda can patch it for you ... but in the case of kernel exploits, fargate and lambda can patch equally well.
IMHO Cloud functions serve well a very small niche. However most of the people advocating for cloud functions seem to misused them. Their use cases would be better served using a well designed PaaS(though I admit is hard to find a good one these days).
Don't think that building your whole service on lambda or google cloud functions with tons of code is the best idea, but it's a great shim between clients and backends. Tech changes constantly and you'll always be up against a change agent. Be nimble.
I actually do the same thing. Do the dependency install inside of a docker container in order to build the .zip. This is absolutely essential for compiled libraries in python or anything that involves postgresql. If you attempt to install psycopg on mac and then deploy that on lambda it will fail. So you either need a prebuilt version for ubuntu that you keep around, or you need to build in a docker container. We just build inside a docker container.
Yeah, it works really well, also allows me to configure CI/CD in VSTS/TFS via Windows agents for AWS deploys to Lambda. In the end, I'm pretty pleased with it. I've mostly used Node, but Python binary dependencies would have the same need.
Not entirely sure why I got the downvote, other than the tongue in cheek aspect and "lol" at the end.
I actually find zipping and uploading manually a PITA. Started using the Serverless framework [1] recently and now I just run `serverless deploy --stage dev --aws-profile profilename` from my repo (which is an npm script).
Uploading manually is a PITA. That’s because you really should automate it using CI/CD if it’s not your local dev environment. If you are manually uploading your code for a dev environment it would be worth exploring a better local, offline framework to avoid this. Don’t upload manually.
It’s not quite as bad if you use .NET Core (which is what I’m currently using for a number of things in an integration stack). I just have to run “dotnet lambda deploy-function” with a template set up.
I started with Golang, however, and found the “out of the box” deployment process pretty painful which is part of why I switched to .NET Core.
Why would you do it manually? Write a two-line script to do it. Downloading a framework to run an npm script that does the equivalent of running `zip` followed by `scp` (or `aws s3 cp` or whatever) seems crazy to me.
Another cool thing about Serverless is it can deploy a Python WSGI app (e.g. a Flask app) with little change in the code. It simplifies local testing and makes it easier to leave Lambda and move to dedicated hosting if I ever decide to.
When they do it for you it's awesome isn't it. I've been using Apex Up. It handles API Gateway config, the zip upload, SSL certs and deployment to AWS Lambda
I keep hearing responses like this about various aspects of serverless, but it makes no sense. If a lot of these serverless operations are "not any different" than various Docker operations, why should I be spending time and money to couple my application to AWS Lambda versus simply running the container myself? Why shouldn't I just deploy a container (pod) for my code if I'm already running kubernetes?
The more I hear people defending serverless, the more it feels like they're asking people to voluntarily increase their time and money costs, learn hyperspecialized and nontransferable skills, and make their application far less adaptable. All of this while accruing tons of technical debt for a pittance of some convenience.
To be clear, I'm not a proponent of serverless at all. I'm just pointing out in isolation that zipping and shipping something is not antiquated, it's just a methodology for shipping code. I guess it feels old because it's not wrapped up in a lickable CLI and online docs with great typography, but it's not fundamentally flawed.
To your point, I don't see any value of serverless over containers today. We are now at a point where container orchestration is mature enough that it's a sane default choice, but it took a while to get here. Serverless is where containers were 5-7 years ago (depending how you squint).
Will serverless ever be a credible replacement for containers? That depends on the vendors working out a whole lot of details. In theory, with the right services around it, serverless can be lighter than containers because they can fully control the baseline environment and build more into it, but that is also less flexible than containers. How much standardization will be possible between vendors? If the price comes down and the tradeoffs look good enough then I could see it eating into container marketshare, but I'm really not holding my breath. It's still 100% in the hype phase.
You know what would be better than a .zip? A .tar.gz file. Zip files cannot be unzipped without having the whole thing in memory. What's funny is that the Lambda environments (at least for Node) do not have the `zip` executable available which means that to zip/unzip something inside Lambda I need one written in javascript which has to be included in the zip file I upload to AWS instead of being able to use the native one.
You have it backwards. Zip files have a table of contents letting you unzip individual files without decompressing the whole thing, and you don't need to load it all into memory.
The table of contents in a zip file is at the end, not the beginning, so you need random access to the full file if you want to properly jump to the right location. Some zip files use the length feature of local file headers so you can jump ahead in the file without processing the data, but many skip the length so you have to work through the DEFLATE algorithm to find the end of the first file (to find where the second file starts)
Yes, you can and should use random file access to load things from a zip file. For example, Go's zip package takes an io.ReaderAt interface, not an io.Reader. Using sequential I/O for this would be inefficient.
I'm not familiar with s3, but it seems like if you want random access for a key-value database, you should store each file under a separate key? Storing an entire file archive as a blob (in any format) and downloading the whole thing just to access one file seems like a weird way to do it.
Apparently there is "s3 select" in preview [1], but it only supports gzipped CSV or JSON.
But if the zip file isn't stored locally, sending the entire thing over the network to access one subfile is very inefficient. Instead you'd want a network protocol where you request the files you actually want and the remote server just sends those.
Serverless (AWS Lambda) is just the cloud's way of trying to "de-commoditize" the containers that commoditized them. They want you to tightly couple your applications to their specific cloud provider again. And charge you more. How much is that function in the zip from S3 going to cost you to run in a container managed and run by AWS? And how long did you spend configuring the API Gateway (and where else can you apply what you've learned doing the configuration)? Next time you see an article fawning over serverless and saying things like "Containers just don’t matter in the serverless world" take a look at what the author does for a living. You'll start to see the same pattern I've been seeing.
Meanwhile, you could be spending less money and time treating AWS like a dumb processor with a network connection while only really configuring the open source software you already know. But it's your time and money.