Who Will Make Our Future Serverless?
No matter where I go, or who I talk to, all I seem to hear about at the moment is serverless. It has almost got to the point where I ask myself: why would we be using anything else?
In this article I will look at the different serverless frameworks from Amazon, Microsoft and Google and imagine using them to build a piece of large-scale software with a sizable development team. I will then explore the other elements of the application lifecycle and look at how we can manage those applications, control their costs and resolve common issues like release management, business logic maintenance and evolution.
Let’s get to know our hypothetical company. We are a young hip and vibrant startup. We have just obtained a $40m investment by crowdfunding, decked out an office in London and hired 25 consumers of dark warm beverages.
Our goal is to disrupt the relationship management application space. Our application, let’s call it RelX, will be the go-to application for managing your contacts. Think of it as an ultra modern version of the little black address and phone book that, if you’re as old as me, you use to have to store people’s phone numbers and contacts.
Of course, everyone in the world needs to manage this type of data so we have to design our application for hyperscale. Also, in this modern, connected world, we need to make sure that this data is accessible to other popular SaaS applications like Trello, Asana, Saleforce.com and others.
As we live in the age of serverless, we are going to build or application using only serverless functions and cloud PaaS services so that we can achieve 'NoOps', reduce our TCO and decrease our time to market .
One fine day, we all pull up a bean bag to discuss the elephant in the room: Whose serverless framework should we use?
Joe suggests Lambda...
Joe, our Cloud Strategy Evangelist, takes a sip of his iced latte and, with a defacto air, says: "There is not much to talk about. Lambda is practically perfect in every way. Why even consider anything else? Let’s go with that".
Practically perfect…well let’s see about that shall we?
With AWS you get an IDE (Cloud9) and a framework to build more complex applications (SAM). Also on offer are support for multiple languages C#, Java, Node, Python and Go. AWS also has plugins for traditional IDE’s if you stick with C# or Java and has tooling to enable DevOps style CI/CD (CodeCommit, CodePipeline and others).
Once the application is written and deployed AWS give you tools to operate it. X-Ray will let you introspect your Lambdas and you will get logging and monitoring through the AWS CloudWatch service.
The best thing about Lambda is that it is integrated with practically every service AWS offers and this makes it easy to compose complex applications taking full advantage of the full suite of services Amazon has to offer.
Cloud9 is not exactly a best of breed IDE and it’s biggest defect is probably that you have to be connected to the internet to use it (no coding on those long haul flights). Cloud9 also comes at a cost (while most other IDE’s are free or have free versions). This is because it runs in the Cloud and will cost you by the hour.
CodeCommit and CodePipeline are a good start but are still missing many features provided by more traditional CI/CD stacks; including GitHub/Lab and Jenkins. The other key pain point will be around CloudWatch, which doesn’t really provide the detailed information needed to operate a modern application.
Amazon offer a complete and comprehensive serverless development experience. Everything that you need is included in the package so any shortcomings can be easily ignored. It will absolutely get the job done.
Jane likes Azure
Jane is probably one of the oldest members of our sub 30’s startup. She has almost four years of development experience under her belt and did her thesis using .NET and C#. Since she has spent most of her career looking at code behind Visual Studio on a surface she makes the argument that nobody does developer tools better than Microsoft. Developer tooling is incredibly important because it makes developers more productive and more developer productivity means more time at the ping pong table (and happier investors of course).
Microsoft have centred their offering around Visual Studio arguably the best IDE available today. Through Visual Studio and Visual Studio Team services you have everything you need to build your serverless application with a large team of developers. Language support is comprehensive and deployment is integrated directly into the IDE as is the version control and CI/CD environment.
Once deployed Microsoft offer a comprehensive management suite through Application Insights and like Amazon have allowed Azure Functions to reach to pretty much every service they have on Azure today. Language support covers F#, C and NodeJS with offline debugging and editing offered by the IDE.
Language support. Though Azure Functions support Java there is no support in the IDE and what happened to Python, Go, RUST, Julia and the myriad of other languages out there today?. The other issue is that Visual Studio is great "on windows" and though versions do exist for Mac and Microsoft also have Visual Studio Code the versions for other operating systems are nowhere near as good as the version on Windows.
Top notch development experience and good services all the way through the application lifecycle. If you are ok with the languages on offer and coding on a surface this is the serverless platform of choice.
Zac likes Google
We picked up Zac in a coffee shop while he was coding away on his Chromebook and asked him if he wanted to do something cool. Zach points out that Google is at the forefront of technology and has also created one of the first serverless environments "Google App Engine" why not go with Google?
Monitoring and log management are good on Google thanks to Stackdriver and you get some decent tools to manage CI/CD not only via the standard GCP services Source Repositories and Build, but also through 3rd parties such as CircleCI.
GCP is not quite as mature as the offerings from Microsoft or Amazon and is missing quite a few things. (Node 8 and Python) still only have support in Beta and there is not much support for other languages either. There is no real IDE, though good command line support means you can use things like Sublime Text, Atom or Visual Studio Code to get a pretty good developer experience.
GCP Cloud Functions don’t really look they they are ready to support a large scale software project. This does not mean it would not be possible by putting a bit of effort into tooling a proper DevOps process and some collaborative organisation between developers. The road is just a little less smooth than with Amazon or Microsoft.
After much deliberation our intrepid crew of startup developers decide to go with Jane’s suggestion to use Azure. Microsoft has done an impressive job of putting developers first and, if you are going to build a new serverless application from the ground up, the tools do make a difference.
Even though we choose Azure in this instance it is important to point out that the developer experience is not the only consideration you should be making when you decide what platform to use as each Cloud Service Provider has strengths and weaknesses.
Amazon do have a very compelling offering in the serverless space and a very strong ecosystem and developer community. If we add that almost all the AWS services are well integrated with Lambda we may just want to exchange some developer productivity for more PaaS.
Google’s strength lies in the excellent big data services they offer and given that those services are well integrated with their serverless offerings you may well decide to put a bit of effort into building a few scripts to give your application first class big data services.
Whatever serverless framework you decide to adopt for your next application please do go serverless as I strongly believe this is the best option for greenfield applications today.