Live Blogging at DeveloperWeek: An Introduction to Microservices with the Serverless Framework

I'm live blogging my experience at DeveloperWeek, en masse, at my site. You can follow along there, or look for me to post some talk summaries here, individually.

This is a talk by Fernando Medina Corey, of Serverless. He led into the talk with the caveat that he wouldn't be able to help us all debug a setup.

I'll cut him some slack, as long as I'm one of the people he stops the talk to help.

Anyway, he outlined 4 different goals:

1. Develop/test a microservice
2. Deploy to AWS
3. Debug the service
4. Monitor the service

Let's do it.  How would this go?  He has material for people afterward.

1. Create an AWS account
2. Install the AWS CLI.
3. Configure the AWS CLI
4. Install the Serverless Framwork: binary installer for Mac/Linux, Chocolatey on Windows, NPM.
5. Clone the project.

All of this will get to the point of building his toy application, "Serverless Jams."  I like where this is going.

Serverless Jams allows you to add a phone number, receive a voting code text, and then vote on songs.  The idea is to exercise a number of different APIs.

We're going to do this with Amazon API gateway, Lambda, a DynamoDB table, and Simple Notification Service.

What does the code look like?

Well, it looks like Python, at least on the backend, with 3 files. The client has Javascript, markup, and YAML.  On the backend:

• generate_code.ph
• get_votes.py
• vote.py

Simple enough.  Now, on the front-end:

• app.js
• index.html

And then serverless.yaml, which wires things up from a configuration perspective.  This is where the magic happens, and Fernando walked us through all of the information that needs to go in here to create the right sets of permissions.

I know only enough about this to shoot myself in the foot, but he's making me feel like I'd be able to handle it in an afternoon.

In furtherance of this, Fernando asked how many lines of code all of this would take, combined with the front and back end?

The answer? 436 lines of code, "with me being a pretty poor front end developer."

(I'm with you there, Fernando, but I think if we switched to a language without significant whitespace on the backend, we could probably slam all of it into 50 lines, tops)

Deployment Options

With the structure and code squared away, he mentioned 3 potential deployment options.

1. Local AWS Keys (with 2 different sub-options)
2. Using the Serverless Dashboard, assuming you've created an account.
3. Serverless CI/CD.  (He won't touch on this today, but this is a good approach for teams that have established a serverless approach)

Demo Time!

And, with that, he popped open an IDE and started working.  Then it was time to sign up for serverless and get into the dashboard. He did this all pretty quickly, but it honestly looked really straightforward.

After development, configuration and deployment, it was time to test and debug. First issue was that he mistyped his phone number, and the second was that he's already used his number for another demo. So this led to the actually-even-cooler situation where someone in the audience gave a phone number, received the code, and entered it.

At the end, perhaps not surprisingly, everything worked.  This left a little time for a deeper dive, and the audience voted to take a more detailed look at the front end.

In the end, enthusiastic applause.

My Takeaway:

This was a lot of fun to watch and well-presented. And there's something infectious about watching a talk that's basically, "look, this cool thing is totally more doable than you might have thought."

My takeaway here is that technologies like Lambas make glue code much more approachable.  But that's been true for a while, and I was aware of that.

But now, looking at Serverless as an orchestration framework, for lack of a better term, I have the sense that I can put together some very well integrated functionality very quickly. I have, perhaps, a false sense of confidence that I could do this in an afternoon.  But in reality, I can't imagine it'd take terribly longer.

If I put on my "old man programmer" hat, I can recall a time when building an app that sent me authentication codes via text would have required weeks, lots of planning and integration, and much pain. And it'd probably have been expensive.

Now, a lot of cool things are possible.  Look for me to auto-spam you all text messages sometime soon.