Posted by Thomas Magill on May 26, 2020 10:00:00 AM
I was recently asked by a colleague to build a portal to allow engineers to start and stop two Amazon EC2 instances that host software used network discovery and mapping. The intent was to only have them running when necessary to reduce the cost of instances running when they are not in use. Jokingly, I asked if he wanted me to build this portal on an EC2 instance. He didn’t catch the joke, so I explained that running one full-time instance to control two other instances was probably not going to be very effective at saving money.
I decided this was a great use case to learn something that was on my “things I want to know how to use” list: AWS Lambda. I knew Lambda could be tied to Python scripts to start and stop EC2 instances via the API, but I didn’t know exactly how it worked yet. After a little research, I was able to find some pretty good tutorials about what was needed. The basic solution ended up being a combination of four AWS services:
- S3 – Static content hosting for HTML/CSS/JS
- Lambda – Serverless script execution (Python, Node.js, Java, Go, etc…)
- API Gateway – Used to expose an API to call Lambda functions publicly
- EC2 – Where the virtual machines live
However, because I wanted this app to be tied to our domain name, I also had to do a little work with:
- Route 53 – DNS
- Certificate Manager – Public SSL certificates
- Cloudfront – Static content delivery
With some work, I was able to glue all of these pieces together. The result was a working solution that required no servers to maintain. It was also “API First” and allowed users to hit the API directly and not even deal with the GUI, if they were so inclined. At the end, all I could think to myself was, “Wow! This is really cool and how I will build everything from now on.” It also occurred to me, “Wow! This is serious vendor lock-in.” Another concern is that most of the apps I build are for automation, orchestration, or visibility in a data center, and they may not have access to these public services—and many don’t have any type of connectivity back to their AWS VPC. Many customers also still have concerns about handing over control of their infrastructure to the cloud.
With the thought that anything worth doing usually has an open-source solution, I started looking at ways to host serverless apps internally. Building on what I already consider “the future” of development environments, I specifically started looking for a Kubernetes flavor; I was not let down. Function as a Service (FaaS) is the term used for Lambda-type behavior and OpenFaaS is how you can build it on Kubernetes. There is a project available on Github (faas-netes) that will build the complete solution.
Why go through the effort of standing up Kubernetes and OpenFaaS internally when you can just use AWS?
- Multi-Cloud: If you are trying to use FaaS in different cloud providers, that means using different methodologies and APIs for each one. OpenFaaS can be run on any public cloud, private clouds, or even a laptop. Yes, there are still servers even though it is “serverless.” With all technology, there is still someone (or something) running the hardware and creating an abstracted layer for the user. FaaS is just referring to this abstraction.
- Security: It’s not that public clouds lack security, but there are still a lot of customers who are not comfortable putting all of their eggs in the public cloud basket. This is especially true if the apps are capable of impacting other applications or infrastructure.
- Cost: Anyone using public cloud can attest to getting occasional unexpected bills. While services like Lambda have potential to cost much less than EC2 instances, there is still potential for costs to build up.
- Fun: OK, maybe this is just me, but building infrastructure around this type of technology shift is what got me into this business and why I enjoy learning new things!
If you haven’t looked at serverless computing, I highly recommend it, regardless of whether it is in AWS, Azure, GCP, or any other provider who offers it. If you are already working with Kubernetes and are interested in adding this FaaS layer in a private or multi-cloud model, or just have some free resources and are looking for ways to make them easier to consume, I would recommend checking OpenFaaS out.
GET A BETTER UNDERSTANDING OF YOUR DATA CENTER ENVIRONMENT
Our team of Data Center experts have designed the Data Center Foundation Workshop to fully understand your current environment, identify potential risk factors, and provide next steps to improve resiliency — which could include a move to the cloud. Schedule your workshop today.