The problem serverless is solving is not a technical problem (unless you work for a serverless vendor, such as AWS, Azure, and others). It's way more important than that because it directly affects the business value of the product you are building.
How? Let me try to tell you a story. But before we begin, I want to warn you that serverless is not the main character in this story, but it is one of the heroes of the story, I promise!
In 2018, we finally decided to build a simple product that will allow us to manage leaves in our company without having a complicated and expensive HR system. We were a team of 15 people, and we needed a simple tool that will do just one thing.
We tried to find something simple, but I guess we didn't try hard enough because everything was too complex and expensive for us at that moment. While exploring an idea to build that tool, we talked to our friends from other small and medium businesses. They had the same issues, and some of them told us that they would love to use a tool similar to something tried to build. And the idea sparked in our minds -- this could be a real product!
But to be able to solve the problem, you need to understand it well enough. For the sake of simplicity, I'll show only the basics of a single user journey.
Meet Anna; she is an excellent manager in the fast-growing smart house maintenance startup Sonic Screwdriver. Besides many other jobs, Anna needs to manage leaves for her team. That includes knowing who is not working, tracking the number of remaining and used PTO days, and managing leave requests. Besides that, she needs to plan future leaves and team capacity, manage leave policies in their intergalactic team, and many more responsibilities.
To be able to stay on top of the user leaves, Anna is using a bunch of products, such as calendars, spreadsheets, different communication channels, etc. This process includes a lot of manual work. Also, calendar and spreadsheets don't always give you the information just-in-time. You often realize that your coworker is ooo at the moment you need that final PSD file. At that moment, they are already enjoying a mojito at the beach half the world away.
Well, this defines a problem, but to solve it, we need to analyze it and act on it. To do so, we use Wardley maps, maps that help us with the representation of the landscape in which our business operates. If we put the previous value chain in the Wardley map, it looks similar to the following image.
The Y-axis represents a value chain, on top are the things that our customer sees, and on the bottom are things invisible to them. The X-axis represents an evolution of components. Everything starts with genesis; for example, an idea of electricity exists from ancient times. Then people start building custom solutions, and at some point, convert to a product. Finally, things end up as commodity or utility, for example, electricity is everywhere today, and we pay only for what we used.
If we want to build a leave management app, that app becomes a product for Anna, and the map starts looking at something similar to the following image.
Our app becomes just a dot on the map for Anna, and everything below it is entirely invisible to her and her team. But that dot is another massive map for us, that has its components, value chain, dependencies, etc. And we need to manage things below it, in the value chain.
When you work on a startup, your capacity and budget are limited (especially if you bootstrap your business as we did). You need to pick your battles very carefully. Each solution is the source of the next problem.
Is it more relevant to Anna to be able to get just-in-time notifications and synchronize team calendar, or to know that your app has a beautiful data center? That was the obvious question. But we can ask less obvious ones, for example, does Anna care about our excellent framework or Kubernetes? I don't think so. I don't care about Dev.to tech stack, and I am a programmer.
So what can we do to be able to free up our time for the things Anna cares about? We'll we can outsource some of our responsibilities. But what should we outsource? Leave tracking? Our business logic? Nope, that's the core of our business. However, we can try to outsource everything else, such as user management (we do that through Slack or Microsoft Teams), sending emails (MailChimp, or even better customer.io), infrastructure, etc.
Wait, did I just said infrastructure?
Yes, and here comes the hero of the story -- serverless. Let's see the map first.
As anything else, compute evolves and moves to the far right of our evolution axis. With compute as a commodity, servers became a commodity, then OS too. Which OS is running in your infrastructure? Who cares while it works. We don't install things manually anymore. One thing sliding to commodity pulls many other things and unlocks new opportunities.
How do serverless fit that image?
Serverless is all the things that you'll not need to take care of in the future. Do you need to send a leave request? Slack or web app will send it to some API endpoint, and your provider will trigger a function in the background that will execute your business logic. That function will save the leave request data to some database and then send some notification. However, all of these things will be fully managed and mostly hidden from us, even if we are developers.
You probably don't assemble your new computer hardware anymore unless you are nostalgic, and you want to have fun. Why would you assemble your infrastructure? Other people do that better than us (or at least me), and in most cases, the business logic of products we build don't care about infrastructure.
But if we want serverless to fulfill that goal, we need to adopt new coding best practices for the new evolving ecosystem.
Does that mean that serverless is not ready?
Not at all! We run our product on serverless from the beginning. Last month we served more than 13M requests, and we paid around $100 for our infrastructure (I am lying, we paid $0 because we have credits). With almost 500 happy teams using our product, I would say serverless is ready. And I am sure many others would agree, including products such are Codepen, MindMup, and many, many others.
If we don't need to babysit our infrastructure, we can focus on other things essential for Anna and other awesome people using our app. And again, we can take a look at our map, and focus on things that are still custom-built for them.
But the map is just the beginning, and as the creator of Wardley maps, Simon Wardley says, all maps are imperfect. You need to evolve it and also to communicate with people using your product, because in the end, without them you don't have a product.
By the way, if you have the same problem we had, or you want to see the result, check our product: Vacation Tracker.
Before we finish, you might ask what about containers? Are they also trying to solve the same problem? Is serverless better then containers, and if yes, why?
I think that both containers and serverless are leading us toward the future of app development. What's that future? I don't know; it depends on all of us.
Maybe we'll build our apps by talking to the computer, or something completely different, we'll see. But I am 100% sure it will not require us to manage the infrastructure.
This evolution will have significant inertia, mostly by you, me, and other people that were early adopters of the things that are now standards. But like in all other cases, the technology will evolve regardless of our opinions.
If you pick containers or serverless, you'll be a step closer to that bright tech future. Serverless might not be perfect for all use cases at the moment, but I saw the incredible evolution of that ecosystem in the past five years. I also met many people way smarter than me working on taking it to the next level. Also, remember that with serverless, you'll be slightly more on the right side of that Wardley map up there, probably just behind that big inertia wall. And all things are slowly leaning that right side. Pick your battles very carefully, and build excellent products.
Top comments (6)
Thank you for sharing this! I have similar problem and turned out that serverless is much more time & resource efficient, even though the first time of the migration is a pain the head.
Thanks! I would love to hear more details. What are you building, and what are your biggest challenges with serverless?
The company I work for is used to the conventional/traditional method. We rent servers somewhere, and do all stuff by ourselves (configuration, maintenance, patching, installing, you name it).
And here it comes, a new project that is asked by the client (which we cannot refuse) to use serverless tech.
As a first-timer, the hardest part of this project is figuring out how the serverless work.
There was one day that one of my API endpoint didn't work. It supposedly return an image, and it just didn't. I spent about almost two days figuring out what on earth happened with my code. Seems like nothing wrong. No error. But it didn't work.
In the end, it turned out there was a config in the serverless part that I missed, and it was solved in a minute by just installing the apigw binary plugin.
I still laugh at it 😂
Haha, I know that problem :)
There were many weird issues in the last five years, but AWS services are better and better every year. For example, API Gateway HTTP API is a cleaner and more simple version of the REST API.
Love this. So well-articulated. #ServerlessForEveryone!
Thanks!