The Journey to Serverless: How Did We Get Here? [Infographic]
It’s the beginning of a new year and when it comes to computing, going serverless is the resolution of many engineering teams. At Stackery, this excites us because we know how significant the positive impacts of serverless are and will be. So much, in fact, that we’re already thinking about its applications for next year and beyond.
But while Stackery is toasting to serverless just as much as the headlines are, it’s crucial at this juncture to ensure that there is a wider foundational understanding. Our team is thrilled that so many others are anxious to rethink how they approach computing, save money with a pay-per-use model, and build without limits using serverless. However, we’re also proponents of knowing your serverless strategy inside and out, thereby having an airtight business use-case that anyone on the team can explain. After all, serverless didn’t rise to the top of Gartner’s top 10 infrastructure and operations trends overnight; its (figurative) source code was being drafted decades ago and this is why it’s much more than a trend. Just as we learned in history class, what’s past is prologue; the developments of yesteryear are the stage directions for today’s innovation. In other words, understanding the origins of serverless will give you a competitive advantage.
So, how exactly did we get to the edge of widespread serverless adoption? What historical developments make all of this more than a temporary buzzword? Why have the conversations about serverless been growing among your peers and leadership team, not dying down? To answer these questions, let’s interrupt our regularly-scheduled New Year celebrations with a trip back in time to 1995…
At Stackery, we’re helping engineering teams build amazing serverless applications with limitless scalability. The best part? The stage for the next decade of software development is being set now. Join us in shaping serverless computing for the next generation. Get started with Stackery today.
Nate Taggart | February 26, 2019
Cloud-Side Development For All with Stackery's Free Tier
#### Further Reading On Cloud-Side Development:
__The Anatomy of a Serverless App__ We call an application deployed into a cloud service provider an active stack. This stack has three primary components - the functions where the business logic resides, the managed cloud services that serve as the building blocks of the application and then the environmental elements that define the specific dependencies and credentials of for a particular instance of the first two components. This [anatomy of a serverless application](https://www.stackery.io/blog/anatomy-serverless-app/) post goes into the full detail of what serverless teams will build and manage. Our friends at Lumigo on [the need to test cloud-side](https://hackernoon.com/serverless-testing-from-the-trenches-790e77301c74) (and some slower and manual non-Stackery methods for doing so). Corey Quinn of Last Week in AWS (sign up for the snark, stay for the news, pay for the bill reduction) [sparked this conversation](https://twitter.com/QuinnyPig/status/1092794159415611392) on twitter.
While I appreciate AWS's support for the local development model, I can't shake the feeling that it's the wrong approach to Serverless development. Can we talk about that?— Corey Quinn (@QuinnyPig) February 5, 2019
Likewise, this “[localhost is dead to me](https://twitter.com/mweagle/status/1093590457278390272)” rant by Matt Weagle, organizer of the Seattle Serverless Days, won him a shiny new Stackery account. This thread also garnered some helpful nuance and commentary from Amazon engineers James Hood, Preston Tamkin, and iRobot's Ben Kehoe.
1/ Twead incoming...— Matt Weagle (@mweagle) February 7, 2019
I think we need to distinguish between local execution of user code & local emulation of managed services. I don't think anyone's against the ability to run a function locally. But if it calls a DynamoDB table, local code should call a real table, put there via a CFN deploy— Ben Kehoe (@ben11kehoe) February 8, 2019