Serverless Case Study – Coca-Cola

A while back I talked about how big companies have started using serverless in production and how this is a clear sign that we will see more implementation of the serverless infrastructure in the near future. I’d like to take some time today and talk about one of the companies that are using serverless in production: Coca-cola.

Back in 2016, Michael Connor from Coca-Cola North America, the person in charge of the company’s cloud migration strategy, has taken the stage at AWS Re-invent to give a glimpse into the tools and strategies they’ve developed in order to make their next generation of digital marketing applications completely serverless, and a peek into the innovative ways they’re planning to use AWS Lambda in the future.

While explaining the multiple issues that traditional servers have(he was at a Serverless conference, the server bashing was mandatory) he came across a point that really resonated with me personally:

Nowadays, developers need to know devops in order to build enterprise applications.

Think about it for a second. Most companies rely on developers to run and manage their servers. That’s not a good use of their time. It’s fun to know whatever black magic needs to be inputted into those Linux terminals in order to make the app load but that should not be a prerequisite.

[Caution! “Back in my time” story coming up. Overt your eyes]

When I started out coding there was little to no difference between frontend development and backend development. In fact, we used to all be in the same boat, Developers. For web, front-end development meant html and css. Then, around the year 2004 when Ajax became a thing we added Javascript to the mix of things that a front-end developer needs to know. A couple of years later, the powers that be, decided that a frontend developer needs to know a little design, maybe a little Photoshop or Illustrator, and some user experience and user interface design.

Don’t believe me? Lookup job ads for front-end developers right now and compare them to job ads from 2006 – 2009. You’ll see a clear pattern.

Ok, fast forward to 2018. As a frontend developer, you need to know all the technologies mentioned above plus a little Angular, React, Redux, VueJs, Aurelia, SemanticUI, Bootstrap, Bulma, Foundation and the list can go on for quite a while.

And that’s for the frontend of the application. The backend is even worse. Add to that “the new normal” which is that a backend developer needs to be able to deploy, monitor, manage, make security updates, and so on so forth. Again, look up backend job ads, you’ll come to the same conclusion.

How is serverless any different?

Serverless will still have you learn and use a bunch of the same frontend frameworks but it will take away the pressure of doing all the backend, management, plugging of security holes, etc. This will allow you to focus on the app, the UX, UI, and the business logic while everything else will be served on a platter.

Coca-cola ❤️ Serverless

Back to the topic at hand, let’s see how Coca-cola uses serverless to improve their service.

Their vending machines that you find around the globe have an integrated communication system with the Coca-Cola HQ. This is how the guys servicing those machines know if a particular machine is running low on a beverage or if something is broken. The same system is used by the marketing teams that can create campaigns like “Buy one get one free” or the ones where the user gets credit for every Coke product he buys.

To start comparing the two options, infrastructure as a service vs functions as a service let me explain what Coca-cola was doing before serverless. Their oldest vending machines (the ones with the functionality I mentioned above) are about 10 to 12 years old. Up until 2016, they had been using 6 EC2 T2.Medium machines that cost them $12,864/year to operate. This included Automation, Elastic load Balancer, Management, Security, etc. Within this, close to $13,000 they got everything they needed to run those vending machines for a year.

After moving to a serverless framework, adding up the costs for all the features they needed, it came down to $4,490/year. This was calculated for the 30 million requests they were getting at the time. Connor stated at AWS re:invent that the break-even point, where having infrastructure as a service would even begin to make sense would be around 80 million calls per month. That’s 3 times what they were expecting to get at the time.

Coca-cola went from $13000 per year to $4.500 per year after switching to serverless.

So how does it actually work

The logic behind the vending machines is quite straightforward. The client buys a drink, the machine calls the payment gateway(which so happens to be a Coca-cola Partner) to verify the purchase which makes the rest API call to the AWS API Gateway which triggers a lambda. The AWS Lambda will handle all the business logic behind the transaction. If a user-initiated the transaction through a mobile device there’s a 5th step involved which is to do a push notification to their phone submitting the information to Android Pay or Apple Pay.

Another impressive aspect of their serverless implementation is that all that communication happens in less than 1 second and they only have to pay when they have an actual request.

The conclusion

Serverless has been such a big step forward for The Coca-Cola company that they have made it so when you have an idea in the company and you take it to the architecture review board, your idea has to be based on serverless.

Right now they are forced into using both the EC2 instances and the newly developed serverless system until they replace the old vending machines with a newer model that works on serverless. Basically, they will have to support the old machines with the 6 EC2 instances that cost $12K a year for the foreseeable future or until the oldest vending machines can be “sunset”.

With Serverless this will never happen. Imagine for a second ten or twenty years from now when they’ll switch a different system(not sure they’ll ever do that but for the sake of the argument let’s imagine a scenario like that). As the serverless vending machine die off the cost will decrease to the point where if they have less than 1 million requests per month they will get their cost down by 99%.

I personally look forward to hearing more from Coca-Cola and how they implemented serverless within their organization. And while I’d love to keep writing this article but I have to run down to the store because for some reason I have this unexplainable urge to drink a crisp cold bottle of Coke.

Coca-Cola’s migration to serverless is one of the best examples of how to make serverless technology work for you. But things can go wrong, especially if you don’t know what you’re doing. Serverless itself as a new technology, with the sheer amount of data it generates, can be a lot to take in, especially if you’re just starting out.

It’s important you monitor your serverless setup. That’s where Dashbird comes in. Built by serverless developers with specifically serverless technologies and AWS Lambda in mind. So if you’re building your environments on AWS, Dashbird is here to make sure you’re running smoothly: save you hours..even days – on average, Dashbird users have seen their discovery time of an error reduce by 80% – on debugging, give you customized and actionable insights based on the AWS Well-Architected Framework to further improve your infrastructure, and provide a quick and easy to understand real-time overview of the health and performance of your serverless infrastructure.

You can give Dashbird a try for free:

  • No code changes
  • No credit card required
  • Simple 2-minute set up
  • Get access to all premium features
  • Start debugging and securely working with your data immediately
  • Simple, clean, and easy to understand interface
  • One of the most budget-friendly monitoring and troubleshooting solutions in the market
  • Small-team-friendly all around 🙂– see what Dashbird users are saying

Read our blog

4 Tips for AWS Lambda Performance Optimization

In this article, we’re covering 4 tips for AWS Lambda optimization for production. Covering error handling, memory provisioning, monitoring, performance, and more.

AWS Lambda Free Tier: Where Are The Limits?

In this article we’ll go through the ins and outs of AWS Lambda pricing model, how it works, what additional charges you might be looking at and what’s in the fine print.

AWS Lambda vs EC2: A Comparative Guide

Made by developers for developers

Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

What our customers say

Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.

Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.