I am a Sr. Software Developer at Oracle Cloud. The opinions expressed here are my own and not necessarily those of my employer.
Recently I attended KubeCon18 in Seattle. I also was able to do couple of lightning talks on using Ansible, Terraform and Packer (my previous 2 blog posts were the foundation for these presentations).
I was also able to attend interesting presentations and spend time with other engineers. Here are my personal highlights from the event.
Serverless with F(n)
Serverless computing or Function as a Service (FaaS) allows us to break our applications into smaller units that are executed on demand. Today we might run 100 jobs and tomorrow 100,000. We pay per use and the system scales as necessary. Previously I leveraged this for various background tasks but I was hesistant to use it for internet facing applications. I was concerned whether it could scale fast enough. At the conference I attended a presentation by Dr. Christopher Woods from University of Bristol. He described several techniques to decrease cold start time and always have some FaaS capacity running (at a small cost). This way the system can respond quicker to any changes in inbound traffic.
At a previous job I helped build and manage a system where we had internet facing API servers receiving various advertising metrics. Since this was directly revenue impacting we overprovisioned the capacity to minimize any data loss. We also had auto-scaling enabled for the platform but since it took 7-10 minutes to properly provision a new instance we scaled early. A good portion of our monthly cloud bill was due to this.
But if we have a system where in less than 100 milliseconds new capacity is launched this allows us to think differently. We can have internet facing FaaS receving traffic, putting jobs into queues and then other FaaS processing data in the background. Having a queue will protect our downstream systems that might not scale as quickly as FaaS.
The challenge is developping and deploying these FaaS applications. Our functions likely will be grouped into microservices and will need to leverage 3rd party libraries. F(n) project builds on top of Docker containers and supports multiple language runtimes. We develop locally running various containers and it runs the same way in the cloud. I am looking forward to when F(n) becomes a hosted cloud service.
Another thing to consider is a cost of running such system. While some users are able to save money by not wasting capacity the costs need to be researched carefully. And having FaaS does not mean we should not follow good dev practices of writing modular code. When our logic is properly encapsulated in appropriate classes we can move into more traditional application design if it becomes necessary.
This is another project that I have been curious about for a long time. I was primarly interested in using it as a proxy for multiple Redis servers to shard data. But Lyft engineers described other use cases such as using it to collect various metrics to help troubleshoot prod issues. The proxy is very lightweight so it can be run next to Redis or MongoDB servers (it supports various protocol codecs). It also helps w service discovery and dynamic configuration.
For Redis use case Envoy provides an interesting alternative to Redis Cluster. The proxy handles the sharding of data and application does not need to be aware of how many servers are behind the proxy. The challenges come with re-ballancing shards (Redis Clutster can do it) and supporting multi-key operations with Lua scripts.
Running a few Docker containers locally for dev purposes is very different than running containerized production infrastructure. And we need a way to install 3rd party software. To install Redis with Helm we can just do
helm install stable/redis. Helm works with Charts which are YAML files to install various packages. Overall Helm significantly simplifies dependency management and I am looking forward to learning more about it.