Thu, 28 Jun 2018
Howdy there, I’m Jared Short at Trek10, and this is ‘Think FaaS’, where we learn about the world of serverless computing in less time than it takes to run an AWS Lambda function. So put five minutes on the clock - it’s time to ‘Think FaaS’.
This week we are starting a little mini-series on Serverless best practices. Our plan is to tackle a topic per episode, and dive in with our real world experiences, where we make decisions, what tradeoffs we’ve dealt with, and just general advice. Our topic for this episode is laying out a Serverless project and what we have seen work well in the real world for Trek10 and our clients.
There are a lot of options for frameworks and general management of your serverless applications and infrastrcuture. SAM, Serverless.com, .architect, sparta, apex, claudiajs, chalice, and apex up and more. Each one is going to have to parts that it excels at, and I encourage read at least a quick start and examples for a few before making up your mind.
• SAM (short for Serverless Application Model) is a great pick if you are inside the AWS ecosystem. Especially if you consider its capabilities when paired with Code Deploy for things like traffic shifting. • Serverless.com is one of the most mature, support for most major FaaS providers with a huge community and tons of plugins to do almost anything you need. • Apex Up is a phenomenal choice that just works if you already have a project that expects a normal http / server environment like nodejs express or a static website.
What’s most important to success is that whatever you pick, you are following a code defined ethos. Manual configurations and deployment is a recipe for disaster. In addition, realize that you aren’t stuck with any single choice. We use a healthy combination of all 3 I mentioned even within the same overall services.
One of the most common decisions you will face is how to organize code in terms of repositories. Should you break up by function? Micro-service? Just one giant mono repo?
I am going to copout a bit here and say there really isn’t a right answer, however there are some metrics that we look at that can help make the decision. When it comes to co-locating multiple micro-services, this can work pretty well, but the most important thing to look at is how mature and comfortable your organization is with Continuous Integration and Delivery practices. If you are well versed and have the background, there is no reason you can just have a team manage a fairly complicated suite of related services in a single repository. Managing the deployments of multiple services becomes trivial at that point.
That all said, we tend to isolate out certain stacks and services based on security contexts and boundaries. A configurations repo (IAM, DNS, etc), a data ingestion with a datastore and internal API repo, and a public facing API repo.
When it comes to co-locating frontends yet, we’ve seen this be successful for smaller utilities and projects but if your frontend is consuming more than one or two services or approaching any level of complexity, just break it out to its own repo.
As somewhat implied, we tend to think about this in terms of services (or micro-services if you will). Follow best practices of micro-services keeping your offering and its functions all handling with things in a closely related domain. A service may be a suite of scheduled jobs, event actors, api, or mix.
I would say in the real world most services tend to end up being around 3 to 8 functions. I would not break up each project to a single function just to follow some dogmatic isolation policy. More service sprawl can make it painful to naturally extend and integrate services. Any more than 8-10 in a single deployment package can introduce a little bit of risk and cognitive overhead for someone making changes. If you have great unit and integration tests, of course this is less of a risk.
As many things, you’ll need to play around with this a bit with your workflows and organization to see what’s right for you. It will change over time as you adopt new and better standards and learn the ecosystems and your tooling.
The most important thing is to just start. Pickup a framework and give it a spin, you’ll be surprised how fast you can get a function running… if you do we’d love to hear about it. You can find us on Twitter @Trek10inc, or myself @shortjared, and I’ll see you on the next episode of Think FaaS.
Explore the Blues Cell + Wifi communication module on a Raspberry Pi Zero, Notehub, and thoughts on the pros and cons of utilizing Blues in your IoT project.
