The beginning of every new tech buzzword is surrounded with developer excitement. Through the excitement and alien-like technical terms, it may be hard to the tell will this new buzzword bring any benefits to your business. Serverless is one of the new top tech buzzwords at the moment. It started back in 2014. with Amazon’s re:Invent announcement of - a compute service claiming: AWS Lambda No servers to manage Continuous scaling and balancing Automatic fail-over Subsecond metering (paying only for used, not reserved time) If you’re not a tech-savvy person (or you’re explaining serverless to one) these things might not mean much. They sound like a bunch of technical words promising to help you serve slightly more customers, a bit cheaper. That might be good enough, but there wouldn’t be that much racket if it was just that. So, what does serverless mean business-wise and in what ways can it benefit your business? Shorter time to market Increased efficiency Your fixed costs have become variable costs Less waste Easier pivoting (more flexibility) Better service stability Better management of development and testing Let’s explain. 1. Shorter time to market For many companies, the path of delivering applications to market is a long one. Along with product planning, design and development, you also have to think about the needed infrastructure, setup and capacity. With serverless, you no longer have to worry about renting and buying infrastructure, its setup, and capacity planning. These steps are removed from your product development process and are now the responsibility of your serverless platform provider. You “only” have to think about how to properly plan, design and develop your applications. This significantly shortens your time to market, as the development cycle is shorter. 2. Increased efficiency by paying only for used, not reserved time Imagine you want to buy a car. A nice, but an also efficient one for you and your family. But the salesman states that the car you wanted has to be run all the time. Whether you’re using it or not. On full gas. Your car alternator may fail if you turn it on and off a lot, but your serverless function won’t. You’d think this guy might be insane. Why would you buy such a car? The way that car is working is actually how most of the current infrastructure your software is running on is working right now. On full gas. Let’s see it in the following example of a payment service for one of your products. Normally, to be able to run such a service, you’d need to rent or buy a server. The server would need to run all the time, sitting idle until a payment request comes. An average usage of the server would look like the following figure. The top border represents the maximum amount of requests your server can sustain. The left axis shows your estimated average server usage, going from 0 to 100%. The bottom axis shows the time during one working day. This looks fine, because this is how your servers usually “need” to work. Regardless of the quantity of requests, you “need” to pay for both the server idle and working time, if you want to have a functioning service. But if we simply inverse the perspective, you would get an average waste of the same server, like in the next figure. Currently, whether you’re renting virtual servers or owning a datacenter resources*. You’re whether your applications are being used or not. you’re wasting paying for the reserved time *This diagram does not show the different dimensions of that waste. Memory, disk space, power consumption and so on. With those, the waste is even bigger. Serverless changes “the game”, so you for the time it was . pay only used This diagram shows that with serverless, your capacity is strongly following your usage. Therefore making minimum waste. This might look OK, but where is the Y axis? And why did you remove the previous black frame box around the edges? The Y axis and the gray frame have moved, because with serverless, your capacity is scaled automatically per your usage, by your serverless provider. Serverless makes server capacity no longer your problem. That includes capacity planning, infrastructure, setup and large DevOps teams. 3. Your fixed costs have become variable costs Imagine your company has 10 million user requests daily. Each user request is also making a couple of internal calls too, totaling up to 30 million requests. (This is a simplified real-world use case from a client, so we won’t go into details) To handle that volume, currently you need to either rent a fleet of virtual servers or setup your own datacenter. Incurring infrastructure monthly costs ranging from several hundred to a couple of thousand dollars. If we add in the cost of a team of DevOps engineers to setup and handle your infrastructure, the data center costs, maintenance and so on, the cost goes much, much more. Serverless computing services bill you on used request time. An average Lambda pricing states a $0.20 per one million requests . Seems extremely cheap but that’s not your total. AWS Lambda is a compute service, so you will also need data storage, notification services and so on. Additionally, serverless (with AWS Lambda) recommends separating your application into many smaller services. Causing the number of internal calls to soar, totaling up to at least double or 60 million requests daily. That sounds a lot, but the cost for computation services along with data storage and others you might need will be ranging around $900 per month. AWS But that still not where the cost reduction comes from. The cost reduction comes from the fact that serverless made your fixed costs become variable costs. Serverless makes your fixed costs become variable costs. Fixed costs are the ones independent of the output. They include buildings, machinery, rent. Variable costs vary with output. Traditional servers force you to have a fixed cost. Whether you have or don’t have usage. With serverless, your costs vary on your usage.If today you had 60 million requests and tomorrow no requests, you’d pay around $100 for today, and for tomorrow. zero 4. Less waste When developing multiple products, certain features are repeatedly developed over and over again. For example, payment processing or user authentication. Imagine a car manufacturing company making their own tires for every new car model, over and over again. The price of the car would be the one of a Formula 1. Serverless with AWS Lambda functions focuses your team to develop product services as independent components. These components can then be effectively reused, reducing the waste in spent time and effort. 5. Easier pivoting (more flexibility) Businesses, especially startups, often need to pivot their products or ideas. When pivoting, usually you need to change the audience you’re targeting. Sometimes even rethinking the way your applications work. Nowadays, many applications are tightly coupled, which is a big problem. Even a slight change in your product course can cause painful refactoring or rewrites. Serverless increases your product flexibility. Serverless (with AWS Lambda) recommends you to separate your application into many small independent services. Thus increasing your product flexibility. Then if you need to pivot your product to a different market, you refactor only the services you need. 6. Increased service stability As a result of being independent, your newly-separated services are more stable. How so? Currently, a large number of applications are bundled in big blocks. You can describe them as bundled services or applications packed into a single block. Monoliths are not that bad. But they have a major flaw. A single service crashing can cause the whole monolith to crash. Like washing multicolored clothes, one cloth’s color can spoil the rest. 7. Better management of development and testing Building an application consisting of many independent services will help you have: Better project overview. Easier testing Better estimates Better project overview Developing your applications as independent services will help your measure your progress better. You’ll gain a better understanding how do your services work and interact with each other. Easier testing Designing your applications as multiple single responsibility units makes them easier to test. Usually while developing, you also need to setup multiple environments and pay for them as well. With serverless setting up multiple environments is free and easy. Better estimates Separate single units usually have a smaller scope. Small scope units are easier to estimate, develop and test. Nonetheless, there is no single approach, technology or strategy that is a silver-bullet, it’s all based on your . context What are the potential side-effects of serverless? Serverless does bring a lot of benefits to the table. Nonetheless, there is no single approach, or strategy that is a silver-bullet, it’s all based on your context. Also with serverless, there are potential side-effects that might make it unsuitable for your company or your case. technology 1. Vendor lock-in Running your applications in a serverless environment can tightly couple your applications and services with your platform provider. Even though your business logic isn’t reliant on the service itself, it still needs a direct connection to the platform provider services. With interface and protocol differences between serverless platform providers “in the mix”, any potential move of your applications to other serverless platforms will be a painful rewrite. You can mitigate some of the bad effects by applying Hexagonal architecture. 2. SLA — Service Level Agreements At the moment, for certain serverless services there are no strong Service-Level Agreements. In the case of AWS Lambda there are no uptime or operational agreements, yet. A found that AWS Lambda had an approximate uptime of 99.6%. That’s good enough for almost all businesses. But in case of critical tasks requiring higher availability, Lambda might not be suitable. AWS does not publish official uptime numbers for Lambda. paper by Gojko Adzic and Robert Chatley 3. Maintaining many small services may be troubling Some may debate on this. Maintaining and debugging many smaller services instead of a few bundled applications does require more focus and dedication. Especially for large-scale enterprise environments. You can avoid it by setting automated testing as a prerogative and using AWS X-Ray . 4. Potentially slightly slower service start Because your serverless provider is automatically scaling your applications, if you don’t have any activity for a longer time some of your application instances may be down when a new request arrives. The situation then requires a “cold” start of your services, which may result in a higher latency of up to 1s. The latency, naturally, depends on the environment. Node.js, Python have lower latencies below 1 second, while Java going a bit higher (between 3 and 10s). Hope you liked the article, feedback is very appreciated! Thankful for your shares, comments and critics! If you liked it, feel free to take a look at the book “Serverless Apps with Node and Claudia.js” I’m authoring with . Published by Manning Publications. Slobodan Stojanovic _First the buzzwords: Serverless computing. AWS Lambda. API Gateway. Node.js. Microservices. Cloud-hosted functions…_manning.com Serverless Apps with Node and Claudia.js I’d like to say a big thank you to my friends , , and who have helped me with reviewing, restructuring and sharing their insights how to improve the article. Slobodan Stojanovic Gojko Adzic Victoria Riquelme Viktor Tuba You can also find me on , and . Twitter LinkedIn Github
