Alexa skills are built in many different ways. For some skills, you will have a team of people building together, both technical and non-technical. In this case, you may want to cleanly separate your content creation from engineering (or even separate different engineering roles) to avoid bottlenecks in building your Alexa skill. Even as a lone developer you might want to cleanly separate your content management from engineering to avoid breaking your backend (and spending valuable time to debug your errors). Microservices are a solution to these problems. They are simply small services with a clearly defined purpose. If you ever wanted to learn how to use Amazon Web Services (AWS) to build microservices in the context of Alexa skill development, you will want to check out our newest Node.js code code sample, which teaches you how to connect your Alexa fact skill to a custom fact-vending AWS microservice.
In this sample, you'll learn how to decouple the contents of your voice experience from the frontend Alexa skill without needing to manage dedicated hosting. You will be using the serverless toolkit of AWS Cloudformation, Amazon S3, Amazon API Gateway, AWS Lambda, and more. In the last step, you'll connect this to a fact skill, building a full stack application from the datastore layer to the Alexa skill frontend. This blog post will talk about why you should think about architecting your Alexa skill as a set of microservices. If you prefer to jump straight to the step by step instructions, go to Github to get started now.
Building serverless microservices gives a number of benefits over traditional monolithic services. Microservices can each own a specific type of data and define an API which is kept consistent to all of the services’ downstream dependencies. Splitting the tasks into microservices allows smaller engineering teams to own the sole source for a particular piece of data without breaking work done by other groups. Each team maintains its own service, getting more detailed insight into usage patterns so they can develop customized architecture for their service at their own pace. Any frontend that you create (such as an Alexa skill, mobile app, or website) can be considered a microservice as well. Because you are making and adhering to a defined API, the frontend can create the experience that is needed for your desired user experience and your backend can update independently as it needs to.
Serverless architectures mean you do not have to manage physical machines for your software stack. This means engineers no longer need to apply security patches or provision new machines to handle increased traffic, saving them time. In addition, you do not need to own hardware or cloud infrastructure. Without a serverless architecture, you would need multiple machines to handle even a small amount of traffic with redundant backups. For instance, you could set up your main machine and a backup machine or two at a minimum for just one region. In a global application, you can see how this becomes even more harder to maintain. With a serverless system, you can simply handle more traffic when you need to and it will automatically scale down during low traffic periods. If you are already building Alexa skills with AWS Lambda, you have seen these benefits firsthand.
The skill sample takes a simple fact skill and takes it one small step forward with some backend engineering best practices, but you can apply these lessons to much more advanced architectures. You will learn the basics of using AWS services such as Cloudformation for reusing and managing your software stack, Amazon S3 for storage, API Gateway for serving internet traffic, Lambda for backing the API, and Cloudwatch for logs. In addition, you will use Lambda permissions, and IAM Roles to manage access control between services. Learning how to use these tools can help you to build better experiences for your customers and create more scalable architectures for your Alexa Skills. Check out the Github repository to get started. There you will see the step by step instructions broken out by section:
After going through the instructions in the code sample, you will have a repeatable pattern for creating your own more complex microservices with infrastructure as code to help create the same infrastructure each time. You can even add more to this example. For instance, you can create a web app which allows input of new facts to add to your Amazon S3 bucket for your non-technical partners to use. If you have any questions, comments, or suggestions, feel free to reach me on Twitter @JoeMoCode. Good luck with your projects, and let me know what you create!