3 ms·

I'm not in this arena at all but Amazon's lambdas seem like a way bigger architectural decision than azure vs AWS or Oracle vs sqls

• scarface74 8y ago
  It’s acrually smaller. A lambda code wise is just a function that takes in two parameters. Like I said before, architecturally, your lambda entry point should be skinny - take in lambda event data, map it to your domain object and call your domain services (not http services, your business layer). In fact, you can take a standard C# web api and using the AWS SDK deploy the same code either as a lambda or you can do a standard deployment to IIS or a self hosted executable with Kestral I’m speaking in terms of .Net but the same concept applies to any language. One project has your lambda interface with a dependency on your domain classes. A second project has your standard controller code with a dependency on your same domain classes. You can have yet a third project that in my case uses TopShelf - a nuget package that makes it easy to create Windows services - that also uses Kestral to self host a web service. I can deploy the same code to either IIS, Windows as a service, a Linux VM (with Kestral without TopShelf) or lambda. The only difference is the code deployment part of my CI/CD Pipeline. I use AWS CodeBuild with a preconfigured .Net Core Linux Docker container that builds to either target and stores the artifact as a zip file to S3. None of this onerous. I test locally on my Windows machine and just push to git everything else just works based on some yaml files.