Remember startups? The good old days where a single individual started a company on his basement/garage with only a basic computer and an idea. Well, got bad news for you, startups are dying because of two main reasons: investors and competition. But don’t worry, there is a way to fix it, and it is by going Serverless!
- Startups are Dying
- Serverless Architectures
- Numbers are Always Important
- What have we learned?
Startups are Dying
A startup’s strongest asset is their “idea” or “product to-be” which provides a big opportunity; but, they also have a big threat which is competition. It is not surprise that in the tech world big companies are always fighting to stay in power, and that also means to create new flashy products that come from either ideas designed in-house or buying startups with good ideas. You may ask “why would a startup sell their product to a big company?”, well, it could be either for money or because they can crush them if they don’t; by building a similar product but with lots of improvement. Big companies have the resources and even the infrastructure already in place to serve millions of requests per second.
Young firms struggle to compete as deep-pocketed companies like Facebook and Amazon clone products and consolidate their power
– The Guardian
In short, if big companies think your idea is good, they might try to either buy you out or outpace your development with better service and infrastructure. Then, lets talk about getting getting an investor to fund some capital and get a fighting chance. Tim Ferris, author of the best seller “The 4-hour workweek”, got turned down 25 times before selling 1.3 million copies translated into 35 different languages. Getting an investor is not easy, they just care about the money and how much they can make and I don’t blame them for that, that is their business. But for a startup it means two things: you have to give them a good product that they can understand and you have to convince them competition is not a problem.
People are not getting funded because Amazon might one day compete with them. If it was startup versus startup, it would have been a fair fight, but startup versus Amazon and it’s game over.
– Startup Founder who wished to remain anonymous
But what if I told you there is another way? Indeed there is a way you could at least get a better fighting chance by getting good infraestructura to develop and get into production with almost no investment, and it is powerful enough to be able to compete with the big names: Going Serverless!
Before getting into Serverless Architectures, lets take a step back and talk about BaaS. Backend-as-a-Service (BaaS) is a cloud service model in which developers outsource all the behind the scenes aspects of an application so that they only have to write and maintain the frontend and the business logic. BaaS vendors mostly provide pre-written software for activities that take place on their servers.
BaaS are not automatically serverless architectures, they need proper design for them to be considered one. Serverless architectures are usually broken into functions, event driven, can be run from anywhere and are highly scalable.
Recently there has been a movement to transform big monoliths of code into smaller chunks; moving from the monolith to micro services and then into small functions. The benefit from doing this is that code is isolated from other functions making them more maintainable, faster to deploy and even easier to test.
Take for an example a blog like this one, in a monolith application you would have all functions. In a microservices world you would divide it into functions, for example a service that manages posts and a service that manages users. In a serverless world, you would take a step further and divide each of the microservices into functions for example one for creating a post, another one for editing a post and another one for removing a post. So, if there was a bug on a function, it shouldn’t affect other functions and you would only fix and deploy that particular function.
Serverless applications are event-driven, meaning that the functions we create cannot be executed out of the blue. Something needs to happen for those functions to be ran such as whenever a database table creates a new row, when a date/time is reached or when a request goes into ApiGateway on a specific format.
Anywhere and Nowhere
Functions of Serverless applications can run anywhere, which is a confusing concept. Essentially, the BaaS provider decides where and when this function is executed, the developer might have some control on a subset of areas where it can be ran but ultimately it is not tied to a specific server. This means that our functions are completely stateless and are not tied to a specific IP address as you would normally do with servers.
Usually BaaS providers define how functions get executed, but at least on Amazon AWS, the functions get created randomly on a specific zone when requested and are destroyed after 5 minutes of inactivity, so next time it would get executed on a different server. Now, if the current server running the function is busy with a request, another different server in the zone would load the function (hot start) and take the second request; just like having multiple workers spawn on demand on a conventional server.
For the same reason that functions are stateless and can be spawned anytime a new worker is needed, serverless architectures are highly scalable. If you have an application with very high throughput, a BaaS might be able, check limitations of each provider, to spawn millions of functions at the same time to respond to millions of requests that came in at the same time. At the same time, if you don’t need a lot of requests and use it only every now and then, functions will get created only when needed and then destroyed.
Easier Operational Management
Since we are going to leverage all of our infrastructure with a BaaS provider we no longer need to worry about the biggest hassles of having a digital product. Automatic scaling will be provided on demand whenever more functions need to be created to keep up with the requests. Deployment is easier and faster since now we can deploy isolated functions instead of a big monolith. We finally get into having to do zero system administration since all servers, uptime and maintenance will be managed by the BaaS provider. Additional to this, a serverless system does not require continuous integration, continuous delivery or containerization tools; if you improve a feature you can just deploy it and rollback in case needed with ease.
Now that we have no administration required with reduced operation time, means we can spend more time generating innovation, imagine what this would do with Agile Methodologies. Now developers could really be spending all their time in building new features and concentrated on the business logic. THE DREAM!
Reduced Operational Cost
One of the great things of Serverless architectures is that you pay only for what you use. This is great especially for startups since at first one would expect they would have only a handful of users, there is no need to buy the big hardware and spend a lot of money in order to provide them with the best infrastructure and fastest response, BaaS will take care of that for you. This is also great for Development, Staging and Sandbox environments; since imagine for 2 weeks you had no requests going into Staging, this means you won’t be billed at all even when the functions where ready to respond to any requests that might had come in. Even in some cases, if you are just starting you might get a free development environment if you are below specified usage limits.
Not everything is rainbows and unicorns, it sounds like the perfect world but there are a few things that we might need to consider before going all in with going serverless.
Third-Party API system
There are a couple of disadvantages of using a third party to control your infrastructure. First of all, they have control over everything; they might provide developers a few options but overall they decide where functions are executed, when are they destroyed, the operating system on which they are run, etc. Multi tenancy problems are also common, some BaaS providers might offer to work to create a good architectural design that meets their needs. Last, but the biggest one is Vendor Lock-in. Once a vendor is chosen, you are locked in and migrations to a different vendor might come either at a great cost or some time investment to work to migrate, it is not easy nor cheap.
Lack of Operational Tools
Not owning the servers come at a great disadvantage in debugging and monitoring your functions and ultimately your application. Developers are limited to the tools that their BaaS provider has given for them to debug errors in their functions and monitoring how their systems are doing; sometimes even at an extra cost.
Given the nature of stateless and un existing functions that get loaded/destroyed as needed, architecture becomes more complicated. It’s great advantages require more design and more time to think how everything is going to be working for the application to be running smoothly. It might not be evident at first, but lets start by saying that you will need to plan for additional design sessions.
Numbers are Always Important
Serverless architectures give us great power, just imagine the possibilities of having unlimited processing power for your application to be fast enough to compete with the big names side by side. Just as an example, if you were building a crawler, you could create a lambda to get a list n websites, at the same time that function can spawn one function per website, then each spawned function can spawn even more functions. Making the functions in parallel would make processing much much faster than if you had to wait for a website to be crawled in order to start the new one; that is the kind of power you will now have in the tip of your fingerprints.
But, with great power comes great responsibility. You get billed for what you use, so you can spawn millions of processes per second, but you will be billed for that, and since you might need to setup a credit card for your BaaS service, you’ll have to pay for it. Many providers give you the ability to setup billing alerts and notifications in order for you to know and act in the right time to prevent excessive costs. So, if you are starting up, you could setup a billing alert for as low as $1/month, so when you get the alert you could double check if you are using the resources you expect to be using or just shutdown any processes that might be running intensively.
This is a nice graph I’ve found online and it gives you an insight into how much more you could be saving when using serverless architectures against AWS EC2 (processing) instances that are billed monthly. So for example if you have a t2.micro instance with Linux and SQL you will be billed around $57 per month, it doesn’t matter if you use it or not and you are limited to 1vCPU and 1GB of Memory. On the other hand, using serverless architectures the breaking point is 500K requests per day. So if you do less than 500K you would pay less and it could even be free.
What have we learned?
Serverless architectures are not for everyone due to its complexity, design and APIs that BaaS providers give to developers. Plus, you get locked into a vendor so migrating later on could become a pain. So take into consideration if serverless architectures are the best for your project before starting the design phase and consider other options.
Serverless architectures are great for startups and summer projects, due to free tiers that some providers (such as Amazon AWS) will give you to play around without even paying a dime. They also help you concentrate on whats important in your application, your business logic. Remember every new project you start you might need to design authorization/authentication? Well, not anymore! They are also highly scalable getting you the best infrastructure you could get.
This is a lot to digest and I hope it helps clarify some doubts you might have around this new technologies. Soon I will start a new post where I will give more deep into code so you can get your fingers moving and get you to practice the concepts we went through already.