5 years of Ualá, 5 years of Lambda
Introduction
Five years ago we launched Ualá in Argentina…
What was initially a small virtual wallet has now grown to a full blown banking ecosystem, with operations in multiple countries in LATAM, more than 1500 employees and over 5 million users.
It’s been a wild ride..
Over the course of those 5 years we’ve navigated through different architectural styles and made complete technological shifts, like changing our main programming language from Java to Go… story for another time.
One thing has remained constant though, almost all our computing infrastructure is deployed on AWS Lambda Functions.
In this article I’ll discuss why we made that decision 6 years ago (before our first launch), and a bit on how it has indirectly shaped our company culture.
Making the initial decision
Right now Lambda (or something similar from different cloud providers) is seen as fairly popular, microservices still reign supreme, but nanoservices like Lambda are steadily earning more ground year by year.
That wasn’t the case back in early 2017..
With barely 2 years since launch, Lambda was still fairly unknown. It was something completely innovative, but still had a lot of work to be done. It was a huge risk to adopt it as our main computing component, but we saw a huge potential.
Being Ualá as small as it was then, it felt like the right time to take the risk and try it out. In hindsight, it was the best decision we could ever make.
Unfortunately, it wasn’t a smooth ride all the time. The initial journey was rough, and we learned a lot of lessons the hard way.
Since Lambda was basically new, the documentation you would find online wasn’t as thorough as it is now, and googling an issue usually led to desperately searching upwards of page 10 of Google to find even the smallest of clues.
Just look at how much it has grown on StackOverflow for posts tagged with “aws-lambda”.
So any design decision we made, we couldn’t base it on any existing documentation or project, because there basically were none.
Stuff like what gitflow to use, how to manage repos, what CICD we used, configurations, etc, were all done from scratch. Not to mention that no one in the team had any previous experience with Lambda, and finding anyone who had was basically impossible, we were still a very small company.
So then, why did we make the decision?
All the cons listed weren’t enough to compete with the pros and potential we saw.
It gave us the ability to design truly distributed event-driven architectures, with a high focus on single-responsibility functions, which in turn gave us huge potential in flexibility, scalability and encapsulation, and all the good words that excite software architects.
Our company’s vision was to be innovative and groundbreaking, why not apply this vision to our technology as well?
No one at that time would think of building a whole ecosystem with Lambda. But, we did.
Another positive point is that since it’s a managed service, we didn’t have to worry about any configuration overhead on the functions or OS configurations or anything else.
5 years since launch, and a lot of the Lambdas we deployed initially basically remained untouched.
Any update we did was mostly for better architectures, code changes or changing the programming language but rarely for configuration changes.
And that’s going from having 1 user to 5 million, Lambda just… scaled… all automatically.
All of this without discussing costs….
Lambda, at that point, was basically free. It wasn’t until we reached a considerable amount of users that we actually had to pay our first dollar for using Lambda.
Even now, having dozens of AWS accounts, with hundreds of nanoservices each, with millions of users actively using them, Lambda still is surprisingly cheap.
We even managed to reduce the cost even more (by aprox. 34%) by shifting to Graviton2!
So you have low operational costs, low maintenance cost, less time spent configuring, more time spent coding… It makes itself easy to sell.
How it shaped our engineering culture
Taking teachings from Matthew Skelton and Manuel Pais’s book, Team Topologies, and Conway’s Law:
“Organizations which design systems.. are constrained to produce designs which are copies of the communication structures of these organizations”
Or as Ruth Malan mentions
“If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.”
The organization should be shaped in the way we want our architecture, not the other way around.
We organize our teams across business Streams, where multiple squads are involved, including platform, core (complicated subsystem) and DevExp (enabling) squads.
Internally, each squad is restricted in their domain by business features, or architectural limits.
Meaning that each team is responsible for a set of Lambdas (and many other stuff like SQS, Api Gateways, Dynamo tables, etc) that solve a certain domain or architectural layer.
Being Lambda as nano as they are, teams can be broken into specific workflows without bumping into other teams, allowing teams to be as granular as possible.
Taking that into account, of course Lambda, and everything that goes with it, has had a huge impact on our culture.
Teams had to be shaped and empowered to take complete ownership of:
- The cloud architecture of their solutions
- The code of the different lambda functions
- The infrastructure that supports everything
- Their CICD pipeline
Basically Lambda, powered by Infrastructure-as-Code (Terraform) and GitOps, has allowed our teams to be as autonomous as possible.
They are complete owners of their solutions, from architecture, to code, to infra, to cicd.
You may argue that the same can apply to just using Microservices, yes, in truth, they share a lot, and I’m not discussing whether one is better than another.
But, with nanoservices, constraining team domains and orchestrating collaboration between them seems clearer than ever.
Lambdas should be grouped by services (SOA), same as you should with microservices, but being able to move one function from one grouping to another to adjust to teams responsibilities or software lifecycle isn't much of a problem.
Of course this also brings a complete set of challenges that arises, such as setting (as Spotify puts it) a guided autonomy based on a Golden Path of best practices, or extra effort in knowledge transfer and trainings.
Also, it’s very easy to end up with distributed spaghetti if you’re not careful.
But it has paved the way for our teams to be able to completely own their code, release very often, breaking as little as possible, and for the company to scale without worrying.
Conclusions
So, after 5 years since launch I would like to thank Lambda, and all our engineering team that has carved the way to where we are right now.
Looking back at how we started to how we are now in our engineering practices is truly unbelievable.
This would have never been accomplished if it wasn’t for so many great engineers that have come and gone through the years.
On a future article I’ll discuss some of the lessons we learned on the way in more detail.
It’s been a wild ride, and I wouldn’t have had it any other way.
