Tag Archives: serverless

Over the last six months, I’ve had the opportunity to learn about Serverless ecosystems in AWS from the standpoint of someone who is quite familiar with the Azure serverless ecosystem in Azure.  I don’t feel that I’m a cloud novice, however at the same time switching context from something very familiar to a whole new model and context had me feeling like a complete novice very early on.  In some ways, I was probably hindered more than someone who’s just learning cloud and AWS completely new. I was also trying to do things, subconsciously, the Azure way instead of just following how AWS intends for things to be done. Early on I created a spreadsheet that mapped out the equivalent component offerings between the two which was a good first step at not feeling so lost and frustrated.

The purpose of this advent day is to not go into the pros or cons of AWS or Azure. The hope is to provide a bridge between the two for developers that might be migrating from one to the other or needing to skill up reasonably quickly.  I initially did this with a spreadsheet and simple mapping (which got messy when I started looking into the networking…but you’ll see that later). For this article, I’ve opted to stay within my wheelhouse and serverless offerings.

Developer Accounts and Dashboard Features

A lot of what I’ve learned about AWS and Azure was from my free time and non-work related to personal accounts.  So, I’m going to highlight one of the most significant differences between the two cloud providers in how they handle their developer accounts.

AWS has a “free tier” which offers the lowest performance offerings of most of their proprietary services for free use, within limits for one month.  Sorry, no free Kubernetes clusters. I know some developers that create a new free tier account every month. Azure, on the other hand, offers every account $150.00 free usage per month indefinitely.  Both Azure and AWS allow you to set up warning thresholds on cost and usage limits to help protect you from a runaway experiment. Two very different models for letting developers get hands-on experience with their cloud offerings.

Amazon AWS and Microsoft Azure are two similar yet different beasts at the same time.  I think it’s pretty much summed up, to me, in the differences between operating in a Windows world vs. a Unix world.  AWS is very much you are in control of everything, and there’s a lot of configuration that can and does happen that you are in charge of from the onset.  With Azure, you have similar controls, but they are mostly hidden and abstracted behind a UI. You can dive behind the scenes with Azure and have as fine-grained control as you do in AWS with direct Azure API calls, but it’s not the default experience and can sometimes take a frustrating amount of searching to find what is easy to find for AWS.  This can be highlighted quite nicely by a basic comparison between the Azure Portal Dashboard vs. the AWS Management Console, the two entry points to the providers.

Azure Portal

AWS Management Console

In my opinion, the Azure Portal is the equivalent of a code editing IDE (like Eclipse or Visual Studio), and the AWS Management Console is text editor (like Vim or Atom).

I bring up these basic differences between the two service providers because it’s these philosophies and mindsets that permeate this overview.  You can do the same things in either operating system, they both work and it’s just that it’s different. In Azure, a lot of things are done for your “behind the scenes” and only available via API for manual configuration. In AWS, you are expected to wire up a lot of it yourself.  In this article, I’ll try to bridge the gap and provide a quick and rough translation between the two for one workflow.

The scope of this comparison is roughly around the domain of creating a hosted code API offering that would use an eventing model to trigger more hosted code to do some business logic on data and persist it in a relatively secure way.  To do this, you need an external IP address for the API, a message system, some code to listen to that message system and a data store. You’ll also need to have a smattering of networking infrastructure to secure and front things (Internet Gateway, v-net, maybe sub-nets, resource groups, instrumentation, logging…etc.).  This is in no way a comprehensive guide, but it should have the basics for you to have enough information to start asking harder questions of better-informed people.

Base Services

At the core, from my developer’s perspective, is code.  Both AWS and Azure have similar offerings with Lambda and Function Apps that support a wide range of common languages and platforms (C#, Java, JavaScript and Python to name a few).  Both of these offerings are pretty similar with the same feeling I outlined above. Function Apps can integrate with different Azure Eventing services and datastores through dropdowns, and Azure can wire things up for you quickly and easily.  Lambda has Blueprints and 3rd Party Templates that offer some similar functionality. Additionally, with Lambda you can construct everything and do the wiring yourself.

I’m really excited about hosted code in the form of Lambda and Function Apps.  I’ve been using Function Apps since they were in Beta. I loved the concept. I started from a new project in Visual Studio to have a service that did something within 5 minutes. My service did something real to the database within 15 minutes.  I will not lie, Lambda took me a lot longer. However, in the weekend I had devoted to playing with Lambda, I was able to create an Alexa skill for my partner to use and interact with at home… which is very different from having an API that does some serverless business logic.

If you are creating a message based eventing model you need some way to send and receive events. AWS and Azure offer all sorts of offerings from proprietary offerings to common consumer options depending on how much you want to spend.  As I’m experimenting on my own dime, I tend to go with free options and scale up once I have income coming in to spend. Azure offers the proprietary options Event Hub, Event Grid and Service Bus. AWS offers proprietary Simple Queue Service and Simple Notification Service.  In the end, what type of eventing model you use will depend on a lot of different factors outside of the scope of this article. Suffice to say, either have offerings to do a simple, cheap prototype.

Most applications need to store data. So, we need to be able to do some simple read and writing with serverless offerings.   I picked the two most common types: SQL and a non-SQL option (a Document Database). Amazon has RDS for their SQL offering and DynamoDB as a document datastore.  Obviously Azure has SQL Server and a lesser-known document database Azure Cosmos DB. For the uses that I had in mind, all four of them performed similarly. I really couldn’t tell them apart.

The fantastic part is that that the three systems: hosted code, eventing, and data store are all serverless. You can now use code to create, setup, and connect your systems.  That code can be stored in your version control and create your infrastructure at will whenever and wherever you want.

The heart of a general event-based microservice pattern serverless implementation is to receive messages either through API or the event system, do something (get, save or manipulate data) and push another message.  That’s the simple part; the nuances and complexity start when you consider hardening, monitoring and reporting from your system.

Hardening and Supporting Services

As soon as I started looking at how to make my internal services invisible to the outside world, I started to see how fundamentally different AWS and Azure are.  This continued as I layered on monitoring and reporting, too. Both services give you ways to do it that make sense. They provide different routes and building blocks to accomplish the same thing.  This is a stark contrast to the data storage example, where it was pretty much a 1:1 Service to Service comparison. They both have offerings to make a robust and secure system that you can instrument well, it just starts to look very different.

For example, AWS promotes using Amazon CloudFront that layers over an Amazon API Gateway that abstracts your AWS Lambda function. Note, the AWS section was a raw personal prototype and might not have passed security review and probably would require more layers of AWS services to meet the security requirements that the Azure implementation did. Whereas in Azure if you want to not make your HTTP publicly visible, you have to use a Network Virtual Appliance, V-Nets, Subnets, an API Management Service, and probably a few other things that I’ve forgotten since setting it up a few years ago.

They both require User Management. Azure uses Active Directory whereas AWS uses Identity and Access Management. Both are similar functionally but slightly different in implementations and nuance. I want to stress that both allow you to do what you need to do, but how to accomplish this differs more between AWS and Azure because the foundational cloud philosophies and infrastructure are different.  E.g., if you build your app the way Azure or AWS wants you to think, the implementation makes complete sense, and then the other service implementation looks a little wonky.

Conclusion

All told there aren’t a lot of major differences between AWS Serverless and Azure Serverless offerings, based on my use cases.  They are both great sets of offerings and offer a developer a great way to prototype something and possibly get feedback and value very quickly.  There are absolutely differences between them that stem from their origins and design choices/philosophies.

Sometimes those differences can be incredibly frustrating because you just want to do one simple thing that you could do in the other.  AWS is the current industry standard, with the lion’s share of the market, and Azure has a significant presence too. As someone who lives in Seattle, equidistant from both Microsoft and Amazon campuses, it behooves me to know both providers; their strengths and their weaknesses.  Over the last five years, it has also nice to see them both evolving and learning from each other.

About the Author

Steve Kuo is a speaker, mentor, and developer who is driven to raise awareness that writing code has a responsibility and is a craft locally to Seattle as well as at conventions.  He is active in the in the Seattle Area facilitating CodeRetreats, running the Seattle and Eastside Code Crafter meetups, speaking about high-quality code techniques, talking about creating cultures of learning and sharing stories with other technology industry professionals.

About the Editors

Jennifer Davis is a Senior Cloud Advocate at Microsoft. Jennifer is the coauthor of Effective DevOps. Previously, she was a principal site reliability engineer at RealSelf, developed cookbooks to simplify building and managing infrastructure at Chef, and built reliable service platforms at Yahoo. She is a core organizer of devopsdays and organizes the Silicon Valley event. She is the founder of CoffeeOps. She has spoken and written about DevOps, Operations, Monitoring, and Automation.

Ed Anderson is the SRE Manager at RealSelf, organizer of ServerlessDays Seattle, and occasional public speaker. Find him on twitter at @edyesed.