MicroServerlessLamba.NET Series – Intro: A Scalable Server-less Architecture in AWS Lambda with ASP.NET Core Microservices

Over the last 18 months I have been working with our team to develop a scalable microservice architecture in AWS Lambda.  Starting with very little experience in AWS prior to this undertaking and now feeling MUCH more comfortable with it, I wanted to summarize our journey and share it with others who may find it useful.  I would also love to hear and learn from those of you who may have feedback on our approach.

Ship with no containers.

First, why server-less?

While containers seem to be all the rage in the software industry (and I do appreciate their utility), I do not believe they are the silver bullet many present them to be.  In our situation, we were building a greenfield solution with no dependencies to shackle us requiring a hosting mechanism that allowed for OS-level customizations or installs. 

Server-less offerings were also a new cloud trend in the industry which almost everyone was using in one way or another so we definitely knew we would utilize it as well.  The more we researched it, the more we thought we could use it for everything with little to no compromise.

Every adopted technology has a cost in learning and developing an expertise.  This is especially apparent with a small team.  We wanted to move fast and were looking for every opportunity to save time.  The time we saved NOT learning Docker/Kubernetes/containers/orchestration definitely helped us deliver a working solution faster.

I have no doubt we will eventually leverage containers for certain use cases but we will continue to defer until we find a case where their value outweighs the costs.

.NET Core

The vast majority of our 10 years of code was developed in .NET 4.5 with a brief and unsuccessful detour in NodeJS.  Leadership wanted a new scalable API to extend our success with smaller customer to larger customers through API integrations with their software systems.

At the time, .NET Core was just starting to gain some See the source imagetraction offering cross-platform execution, better performance and improved APIs, all developed in open source.  These features coupled with the easier transition from full .NET framework made it the clear choice.  We settled on using .NET Core 2.1 in Linux as our base for the architecture.

Cloud Selection – Azure vs AWS

image

We started our new development effort with a 3-4 week evaluation in both Azure and AWS.  We leveraged architect teams from each vendor to expedite our POCs and leverage their expertise to further develop our designs. We successfully developed a simplified version of our planned architecture in each cloud and evaluated the experience.

This was a really valuable step in our journey.  Thankfully it was fairly easy to setup time architects for both vendors by working with our cloud representatives.  Both also provided access to their product teams for deeper questions and assistance. You should absolutely leverage these services if you are in a similar situation.

In the end we decided to use AWS for a few reasons.  First our team had more AWS experience overall and were more comfortable with it.  Next Azure didn’t yet support .NET Core 2.1 and wouldn’t for another 4-6 months.  And lastly, our legacy products were already in AWS.

Overall, both offered very similar capabilities/experiences and either could be an excellent choice for building a new server-less architecture.

Summary

In closing, this was the process we used in choosing the core platforms to build our new architecture upon.  I plan on writing a series of posts to continue sharing this journey and how we brought these platforms together.

If you have feedback on this post or questions that you would like covered in future posts please leave a comment below.

Cheers

Leave a Reply