Our thoughts on nanoservices and the future of serverless development as well as learn from one of our experiences this week.

Hi there,

We're coming off a busy week for us and we're excited to share what we as well as the broader serverless community were up to. We have so much to talk about!


Last week we talked a lot about nanoservices and AWS Serverless Application Repository (SAR). That's because we wanted to get you ready for our blog post.

Rise Of The Nanoservice: How AWS Application Repository Will Accelerate Serverless

At ServerlessOps we're excited by the prospects nanoservices bring by allowing engineers to quickly compose applications through the assembly of deployable, reusable, and useful domain logic. SAR is a step towards building a repository to collect the experience and knowledge of engineers and make it easier for others to find the pieces they need.

We see this combination of nanoservices and SAR leading to rapid prototyping and feature delivery. While building an application using mostly off the shelf parts may not be perfect at first, it let's a team gather feedback to know if they're moving in the right direction and if they should continue on improving or pivot. A team that can fail faster can also deliver success faster.

Additionally, we see nanoservices as an amazing learning tool for those leveling up their coding skills. At ServerlessOps we 1) know operations engineers need to code and 2) it's a weak point for many of those engineers. The simplicity of nanoservices makes them more approachable than a monolith of microservices. We think nanoservices will lead to growing more effective operations engineers and in turn more reliable serverless systems.

Learn From Our Experience

At ServerlessOps we make mistakes. But that's great because you get to learn from them! Last week we were working on a project (more coming soon!) and a simple error resulted in a very late night.


In addition to following the best practices for Lambda-backed custom CloudFormation resources, test your functions before adding a custom resource into your stack. That means run your function locally first. You may even opt to deploy your stack with the function but without the custom resource so you can test your function further. If you're writing custom resource functions, these libraries will also make your life easier.

Coming Soon!

We know great serverless systems and applications require great engineers. We'll soon have more and how we're working to make great engineers.



Tom at ServerlessOps

How did we do on this edition?
Good   or   Bad
We're ServerlessOps and we help you design, build, and run reliable serverless systems in AWS. Whether you're a startup, cloud native, or just beginning your cloud journey, we're here for you. We work with you to identify where serverless fits your needs, build necessary infrastructure and tooling, and work with your engineering team to make going serverless a team success. If this sounds exciting to you then drop us a line at hello@serverlessops.io to discuss how we can work together.
Causeway St
Boston, MA 02114

ServerlessOps Twitter ServerlessOps LinkedIn
You are receiving this email because you signed up to receive content from ServerlessOps on our blog. If you don't want to receive these emails, you can unsubscribe at any time.