Announcing Zappa - Serverless Python Web Applications

by Rich Jones on Feb 8, 2016.

Today, I'm pleased to announce the first major release of Zappa - a system for running "serverless" Python web applications using AWS Lambda and AWS API Gateway. Zappa handles all of the configuration and deployment automatically - now, you can deploy an infinitely scalable application to the cloud with a single command - all for a minute fraction of the cost of a traditional web server.

You can see at the core library on Github here, or the first major client library, django-zappa, here. I have also produced a screencast here if you want to follow along while trying it out.


I've used the word "serverless" to describe Zappa - but what does that actually mean? Obviously, it's not completely serverless - there still is a machine returning the HTTP response to the client.

The difference is that the server's entire lifespan exists within the lifecycle of a given HTTP request. Where normal web servers like Apache and Nginx have to sit idle 24/7, waiting for new requests to come in, with Zappa, the server is created after the HTTP request comes in through API Gateway. It then turns the API Gateway request into normal Python WSGI, processes the request, and returns it back through the API Gateway to the client. And then, poof - the server is gone.



This comes with some major advantages over traditional web servers. The first is scalability. Because AWS Lambda handles all of the requests, you can have as many responses processed in parallel as you need. With AWS Lambda, you get 100 function executions per second right out of the box, but the limit is arbitrary and if you scale beyond that you only need to ask Amazon to raise your limit.


The next major advantage is cost. With AWS Lambda, you pay by the millisecond. So rather than paying to have a beefy EC2 machine running 24/7 for your website, you only pay based on the amount of requests you server - which typically means you'll only be paying pennies per month for an ordinary website. Not to mention the cost saving on not having to spend time on deployment, operations and maintenance!

Maintainability and Ease of Use

Zappa is also incredibly easy to deploy. It's literally a single command - python deploy production - to configure and deploy your code, and after that, you never have to worry about it again. No provisioning machines, no setting up web servers, no DevOps, no operating systems, no security upgrades, no patching, no downtime. It just works!


AWS Lambda and API Gateway are very new technologies, so there are a quite a few hacks that make this all possible. Those include, but aren't limited to:

  • - Using VTL to map body, headers, method, params and query strings into JSON, and then turning that into valid WSGI.
  • - Attaching response codes to response bodies, Base64 encoding the whole thing, using that as a regex to route the response code, decoding the body in VTL, and mapping the response body to that.
  • - Packing and Base58 encoding multiple cookies into a single cookie because we can only map one of a kind.
  • - Turning cookie-setting 301/302 responses into 200 responses with HTML redirects, because we have no way to set headers on redirects.

If you want to learn more, take a look under the hood!

Future Work

Though Zappa is now feature-complete enough for an initial release, there is still a fair amount of work to do. For instance, there is only one client library so far, django-zappa, but it should be fairly easy to add support for Flask, Pylons, and any other WSGI python web framework. The same principles that make Zappa possible should also work for NodeJS applications, but I find it's much more comfortable to develop in Python.

Try it out!

So give it a shot! It'll seriously change the way you think about deploying web applications. (If you just want to see a page served by Zappa, check out this little hello-world page with a self-signed certificate - real website coming soon!)

The easiest way to get started using Zappa is either going to be to read the Django Zappa documentation or to watch the introductory screencast.

If you're interested in contributing, you can also check out the code from GitHub and start submitting pull requests!


Putting Down the Tools

by Marcus Blankenship on May 30, 2015.

Putting Down the Tools, Avoiding the #1 Mistake All New Software Company Owners Make in a Crisis

Yes, we’ve all done it.

I’ve done it. My previous managers have done it. And most likely, it’s the default setting for many battle-worn team leads.

In those crisis moments when expectations are high, everything is going off the rails, and the deadline was yesterday, all new tech agency owners will utter one fateful sentence.

It would be so much faster if I just did this myself.

Then they pick up the IDE, close the office door, and retreat into the code.

What they don’t realize is that they’ve just kicked off a chain reaction of negative work practices that will plague their team for months.

Save Yourself

As you probably understand all too well, the programming world is full of fires to extinguish. No matter what your company’s size or specialty, you are going to hit many, many pressure cooker days.

It’s up to you to anticipate the inevitable before it happens and make a firm, conscious choice not to try to code your way out of a crisis.

Why We Make This Classic Mistake

Making the switch from programmer to owner-manager can be flat-out awkward at times. You’ve gone from playing in the orchestra from leading it, which really shakes up your identity.

The most significant shift comes with the realization that you’re no longer a production unit, but you’re still working in an industry that values production. If you’ve always taken pride in the tidy transaction of being paid for your output, management is a strange new world.

Mixed Messages

First off, while having your name on the door is a much-coveted status symbol, deciding to run your own shop carries a built-in mixed message. It’s as if you’re telling yourself, ” I’m such a great programmer that I can go out on my own… and spend less time coding! Now doing less coding often feels like you’re doing less altogether or that you’re not contributing to the bottom line, especially when you’re just starting out.

Dependent on Others

Then there’s the new reality of how production happens. As a programmer, your brainpower and clever workarounds could conjure magnificent code from your fingers.

The programs you created could keep manufacturing production humming or bring it to a standstill. Entire businesses hung on your creations.

Now you’re dependent on other people to create the code that works this magic. And making the switch from creating your own technological incantations to supporting other people’s efforts really feels awkward for a while.

It Gets Worse

That clumsy beginner’s feeling gets cranked up when you face the new aspects of team dynamics and the reality of being without your most powerful weapon: your ability to code.

But you really get triggered by array of new expectations staring at you, like:

-Figuring out your clients’ agendas
-Assigning work to peers or former co-workers
-Dealing with morale speed bumps
-Steering through software quality problems–as the person who’s supposed to have all the answers

Adding a management role to the rest of your responsibilities can feel like stepping into a plane’s cockpit without any flight training. There are all these complicated, unfamiliar dials and gauges you don’t understand, and you don’t know if that blinking light means an engine has failed or the coffee’s ready.

In order to escape this anxiety loop, many business owners new to management fall into one of two patterns:

1. Code less, but indulge their coding desires by putting out fires and debugging whenever possible.
2. Code even more intently, blocking out team members and undermining their credibility as a leader.

Each of these positions is a pattern that will cause you to fail.

Let me say it again. Retreating to the position of “I’ll do it myself” isn’t going to save you any time or frustration. It’s only going to crank up the problems.

‘I’ll Do It Myself’: Say Hello to a Cascade of Problems

Once you’ve uttered those fateful words, you are no longer doing the job you were paid to do: leading. And if you’re not doing your job, especially when your employees need your leadership most, then no one is.

If you follow through on your natural desire to just do it yourself, you’ve chosen to avoid doing the following critical items:


Checking in with your team members and other principals is the heart of your work. But chaining yourself to your computer stops that cold. Suddenly, you’ve cut off any discussions about quality, progress, or individual development. Everyone loses.


Jumping in to correct someone else’s work not only short-circuits their learning process, it teaches them to do substandard work. Pretty soon they only turn in partially completed work because they figure you’ll just redo it anyway.

“Why bother?”, they think. They lose their drive, you lose their trust, and projects start to suffer.

It’s like a conductor wrestling the tuba away from the tuba player


When you move back into production mode, there’s no one available to keep team moving forward. Essential work like status updates, work review, and new project preparation is completely out the window until you pick your head up.

You’ve just traded away hours of non-replaceable time and energy that should have been devoted to doing the job you’re hired to do. And when you get back to the work that’s been piling up on your desk, you’ve got to dig out all over again.


Let’s be honest. It feels great to be a hero, swooping in to save the day with a brilliant solution. But the cost is just too high.

A “quick fix” always takes much longer, turning your one-hour job into six hours (or more!) of panicked coding. While you code up a fix, your resentment and exhaustion build, and you’re teaching your team to depend on your last-minute efforts to bail them out instead of their own skills.

Management Skills

Running to your comfort zone feels safe, but it’s a very limited strategy that keeps you from making the changes necessary for you to be a good manager.

Trust me. Take a chance, drop the IDE security blanket and interact with your team instead.

Best Practices for Crises

While you’re waiting for your team to complete their work, you don’t need to sit passively or beat them with the boss stick. Here are a few tips that will keep you sane and your team on track.

Don’t Do it Yourself

If there’s a problem that you desperately need to rework, don’t do it yourself. Grab a programmer and say, “Let’s review this code together to fix it.”

Sure, you just scratched your itch by getting involved, but you’ve also established much-needed rapport and created up a teaching moment—for both of you.


Panicked about a deadline? Get a status update from the programmers, adjust the workload if needed, and contact the client to give them an update.

Once again, you’ve opened lines of communication and placed your focus on the overall project, not just your team’s to-do list or your stress.

OK, Go Ahead And Code…

Can’t keep yourself away from temptation? Fine. Then code. But don’t code anything that will be used in production.

I cannot emphasize this enough. If you absolutely, positively can’t resist, then choose a project that is on the back burner. You don’t want to muck up a project in process.

This Is About the Long Game

Great management practices depend on a solid, thoughtful foundation created outside the heat of crisis. But it’s worth remembering that reputations are earned and character is uncovered during crucial, adrenaline-filled moments.

Remember that your purpose as an owner-manager is to create a team that is capable of producing excellent code.

In those instinct-driven moments, especially in beginner’s panic, please take a step back. Avoid this classic management blunder.

How to hire an iOS Developer

by David Tate on May 28, 2015.
You sat down to work today and see *Find an iOS Developer* staring back at you from the top of your todo list. This isn’t a straightforward task like “complete expense report”, “buy new coffee filters” or “fire Ralph” - this will take time, technique, and steady effort to complete.

First, the bad news: iOS developers are in high demand and have gone into hiding only coming out for interesting projects and to attend the WWDC. When you find a good one they can be very pricey.

But then the good news: Because of the obvious demand there are also thousands of people trying to join these group of talented recluses. But the challenge for you is to find members of the first group: experienced, talented, motivated and not the second group: inexperienced, looking to work on their first real project.

But first let’s talk about you.

Do you need an iOS Developer (yet)?

An iOS developer should be hired when you have a clear understanding of what you want and have decided that it should be for the Apple mobile market first (or in total / only). Do you know much about your target market - do any of them use Android? If so then hiring for iOS will not easily allow you to later support them; you might want to instead look into PhoneGap or equivalents.

Do you know exactly what you want?

Do you have an idea or a plan? You are competing for developers and one of the signals you send to people who listen to your offer is how well thought-out your project idea is. Did you just dream up something that you think would be cool or have you proven that there is a market for the product and know exactly how it will work? Do you have mockups yet of what it should look like? With tools like and Invision you need no development experience yourself to create something that looks (and acts like an app on your phone!) to validate the user interface.

A solid iOS developer will entertain multiple project offers and you want to stand out as professional, hard-working, and with a fleshed-out plan. Your project should feel that it already has momentum and its success is an inevitability.

Let’s talk about candidates again.

Vetting Candidates

Let’s assume that you post to one of the millions of free-for-all job posting boards that serve as the new age classified ads. Your inbox is then full of developers awkward cover letters and details of their experience with technologies you have never heard of.

How can you tell if you are:
- Talking to someone with experience?
- Talking to someone that can actually complete your project?
- Someone that can communicate clearly with you in regards to the details of the user interface, project status, and any problems faced during the build?
- Talking to a real person and not a dog trained by a talented prankster?

Research online presence

Developers have a number of tools with which they can show general competence in technical and non-technical areas. Look into each candidate's online activity:
- Blog
- Github or other shared code
- Twitter profile

You don’t need to do any private investigation-style research here - you are looking to see if their blog or code contributions match the general tone of a professional, match with their declared level of experience, and don’t contain any odd red flags.

Look in more detail at code contributions

Open source is a great way to vet candidates - you can look at actual projects that they have built and use them to ask questions about challenges faced and areas for improvements. Open source contributions are a clear way to tell see who is active and hustling in the developer community. Watching popular projects is a good sign, committing to projects is a better one, and being the creator of projects that are used by others is the best tell that you are dealing with a good candidate.

Components Built and Used

Not all code can be shared though - working for big companies means that some developers are quite good but simply aren’t allowed to show it publicly.

This doesn’t mean you shouldn’t ask what they would pull off the shelf for a new iOS project. After giving them a few details about your project ask them where they would start at a technical level. What components would they use for authentication, logging, UI components, caching, network handling, testing, etc.?

Feel free to also ask about specific commonly-used libraries like AFNetworking, JSONModel, DateTools, etc. as well.

Complete Lifecycle Experience

An experienced iOS developer will have some pet apps that they have developed in the app store - either to make money or simply built when they were learning the platform. Ask them to showcase some of these and talk over the challenges they faced. Compared to all other development ecosystems the app one has the lowest barrier to entry: developers can directly make money from their work by only trading their time. What challenges did they face once the app was live?

Tool Opinions

A new developer loves everything about a tool, platform, or language while an experienced developer complains about its limitations. This is part of the experience lifecycle:
- You love it but feel like you don't fully "get it"
- You learn a good deal and start to realize the limitations of the new thing
- You master all the strengths of the tool, and start to feel the weaknesses
- You are challenged by the weaknesses and they frustrate you.
In that way very experienced people sometimes come across as hating the thing they use everyday while also quietly respecting it.

A good way to detect this phenomenon is to simply ask:
- What do you not like about Objective-C itself? How about Swift or Cocoa Touch?
- If given the chance how would you change the XCode interface?
- You are king for a day - how do you change the app review and feedback process?

Are They Constantly Learning?

Ask them about their first iOS project and things that they would do differently now versus in the past. Ask them what the last technical blog post, book, or talk they consumed that changed their knowledge was. What resources do they use to stay up to date with new tools, components, and techniques? How much do they know about WatchKit or HealthKit?

A Better Path

You could do all these things, roll the dice, and hope that your developer gets the project done or you could use where your job posting will be seen by a multitude of iOS developers pre-screened and ready to work.

Building a consultancy while living in Japan with Keith Perhac

by Jake Jorgovan on May 18, 2015.

Today I am honored to have an incredible guest on the show Keith Perhac.

Keith runs a digital marketing agency called Delfi-Net, and best of all, he runs the agency while living in Japan!

For the past 12 years Keith has been living in Japan while building up a business primarily with US based clients.

In this episode, we dive into Keith’s journey, how he got started and built the agency to the point where it is today.

There are a lot of great insights in here on building up a successful business and living a non-traditional lifestyle.

Mentioned in this episode:

APIs and Higher Level Abstraction of AWS SES

by Marcian Diamond on May 18, 2015.

Hello Fellow Developers! As we trek along deeper into the computing wilderness and climb to the higher rungs of development, we become keenly aware of the unfullfilled needs of the development community. These needs tend to be sated by brave souls who endeavor to author APIs. Some quintessential examples of this courage are jQuery, D3, and OpenLayers, just to name few.

Whats an API?

Well, we all know that it stands for Application Programming Interface. Thats easy. But...

What does it do?

APIs are a contract between the user and the API provider. Developers typically use the method signatures defined by APIs to handle program functionality without concern for the how the functionality is implemented. In Computer Science jargon, this is known as abstraction, hiding implementation details from users of the API. By authoring APIs we are creating tools for developers while taking our skills to the next level.

Why use an API?

For one, they are easy to use. Just invoke a function or method with the appropriate arguments and watch the magic unfold. Another important consideration is application configuration. APIs can save us much of our most precious resource, time, by providing well-understood and commonly-used functionality as well as encapsulating lower-level application details.

In this article, I will provide an actual scenario through which an API may arise to fulfill the needs of an application. We will examine how a simple API may be created to provide a higher level of abstraction for sending emails through AWS SES service. The purpose of this article is to demonstrate processes involved in creating developer tools.

The Problem

For over a year now, I've been developing a Flood Forecast and Warning System web application with the Santa Clara Valley Water District, located in San Jose. This application is still beta, but is to eventually allow site registrants to receive email alerts in the case of a forecasted flood event.

To implement this email alert functionality, I decided to leverage the Simple Email Service(SES) infrastructure provided by Amazon Web Services(AWS). SES offers developers several powerful solutions for sending emails.

My application simply needs to send an email that has been dynamically templated. For my purposes and from a developer standpoint, a simple sendEmail() function with arguments for recipients, sender, subject, and body is desirable, yet I couldn't find such a thing! All the available options provided by AWS require SES credentials, lower level SMTP configurations, and/or long query string formations to dispatch to the AWS SMTP endpoint. The closest thing to this ideal scenario that I could find was the Sending an Email Through Amazon SES Using an AWS SDK. The SDK does a swell job of encapsulating the lower-level details of email sending through the AmazonSimpleEmailServiceClient and SendEmailRequest objects, BUT all I want is a method with the signature:

boolean sendEmail(String[] toAddresses, String fromAddress, String subject, String body);

As you guessed, this method would send an email to the addresses in the toAddresses array and return true if successful an false if not so.

The Solution

This is an ample opportunity to create an API that is a higher level abstraction of the services already available through AWS SES. By doing so, It will allow users of the API to send emails using a sendEmail() function and they need not be concerned with the other low-level (but never dull) facets of SMTP and AWS SES. However, as the author of the API, these details must be known and understood!

Now, Amazon SES provides a simple, cost-effective way to deliver outbound-only email. There are two primary options available to developers for dispatching email messages through SES. The SES SMPT interface and the SES API. The SES SMTP interface is used with an SMTP-enabled software package, application, or programming language or to integrate SES with an existing mail server. The SES API is used to send email using raw HTTP(S) requests. The AWS SDK provides a higher level of abstraction for these raw HTTP requests, but the level of abstraction is not as high as we please.

Before we dive into hacking an API, its useful to follow some software engineering best practices. First, we should clearly understand the problem at hand. The problem is AWS SES doesn't provide us with a high enough level of abstraction for dispatching email messages. Next, we chew our pencil tips and stare blankly into space for some time to determine the best way to solve the problem. BOOM! All of a sudden, the solution is clear: we will author an API that leverages the already existing infrastructure of SES. Since we are only concerned with one thing, the API will provide just that: a single function for sending emails. Now if this API is realized, my dev team can be provided with the API and begin sending emails to their hearts content with minimal effort (most of the effort is undertaken by the API author/s)! In this context, the API author must have a working knowledge of the solutions provided by SES. Only with this knowledge (and coding experience) would an author be able to deliver an API providing a higher level of abstraction of SES.


Though I mentioned only a single sendEmail function for consumption by API users, there is plenty of room to develop more functionality over SES. How about this: client-side javascript that allows browser users to send email through a dashboard app? One solution is to have a javascript function that forms HTTPS query requests, using paramters from the user's input, and uses AJAX to dispatch the requests to the SMTP endpoint.

Sorry, I will not implement the API in this article (maybe a future article! Or even better: you can do it as an exercise!), I simply wish to demonstrate how the birth of an API may occur and how APIs make the lives of developers even more pleasant. By taking the next step from API consumer to API producer, developers further their skills in the field and provide assistance for fellow developers. As an author of a popular API, various opportunities to capitalize on your skills will present themselves! Happy Coding!

Learn and Earn!

Sign up for great tutorials, guides, rants, raves and opportunities to earn more money!