Serverless Architecture Explained
- 5 minutes read
A serverless architecture is a way for companies to build applications without having to manage the back-end infrastructure. It sounds like a dream, and it can be, but there are complexities to consider before making the leap. Read on to learn what a serverless architecture (also called serverless computing) actually is, what use cases are good candidates for serverless, how to get started with serverless, and some common pitfalls. After reading this article, hopefully, you’ll be able to answer: Is serverless right for you?
What Is Serverless Architecture?
Serverless architectures have come a long way over the last few years, but in essence, serverless is a way to model, deploy, and maintain your systems without having to manage infrastructure. You won’t have physical servers to manage or aging infrastructures to upgrade. Behind the scenes, your virtualized servers and operating systems are managed by a third party, generally a cloud provider like Microsoft Azure, Amazon AWS, IBM, Google Cloud, or others.
The benefit of serverless architecture is that your company can focus on your core product or service instead of running the hardware system and worrying about things like servers going down, or having enough storage capacity. Instead, you’re free to focus on your product roadmap, go-to-market timelines, and competitive features that make your business successful. Also, it provides cost efficiency, especially for applications that are burstable.
“Serverless computing is a key technology that is redefining the way we build, consume, and integrate cloud-native applications.” ~ Gartner
When to Use Serverless?
If we were to look at the serverless market three years ago, we would have been talking about “functions-as-a-service.” Everybody was screaming “microservices” and trying to break down services into single-level functions, which stood as their “serverless” aspect of their system. In fact, Gartner predicts that more than 50% of global enterprises will have deployed serverless function Platform as a Service (fPaaS) by 2025, up from less than 20% today.
Today, however, serverless is much more than just functions. There are all kinds of cloud-native “Backend as a Service” (Baas) services available now. Here are just a few examples:
- Serverless Databases: Microsoft Azure (SQL server) and Cosmos (no-SQL); AWS Aurora (SQL server) and DynamoDB (no-SQL)
- Queues: Queues help if you’re worried about backlogging your system and clogging the pipes, i.e. Amazon Simple Queue Service (SQS)
- ETL Services: Extract-Transform-Load services help move data from one point to another, i.e. Azure Data Factory (ADF)
- Service Layers: If you have multiple service layers, you can group your APIs or web services into a single bundle to handle the loads and implement functions, i.e. Azure App Service
- Functions: Functions are the backbone of the serverless implementations, i.e. Lambda or Azure Functions.
Bear in mind that going serverless may not mean that you move your entire infrastructure over at once, or at all. You can move only certain pieces of it. In fact, most customers move only certain portions of their infrastructure to serverless at a time.
The Pros and Cons of On-Prem vs. Cloud Environments
A traditional on-premise infrastructure is when your organization provisions the hardware that it owns. In this case, you generally have centralized security and IT teams who govern your procedures and operational policies. One challenge with this structure is that manual updates can become overwhelming when you’re doing your own maintenance. Another is that you can’t scale past the physical limits of your hardware. To grow, you have to buy newer, faster hardware, yet you still may have bottlenecks in your system on high-volume days. Plus, you still have a large upfront investment when you buy your server hardware and maintain a controlled environment for your data center. You know that you’re going to pay for the use of those servers 100 percent of the time, even though you’ll have lots of unused capacity during slow times, which is financially inefficient. But on the plus side, your organization maintains full control over your hardware and its security, and you have the ability to isolate your data more effectively.
A cloud environment improves this model by pushing hardware ownership and maintenance onto a service provider. The provider replaces your hardware every so often to keep up with advances in technology. There are a few iterations of a cloud infrastructure: Classic, Serverless, Hybrid, and Multi-Cloud.
A classic cloud implementation provides virtual machines or instances that you provision for a set amount of CPU memory. The benefits of this type of implementation are that you can use your traditional development and deployment processes, while you pay only for the servers that you use. You can put load balancers in front of your servers so that your system can scale up and down.
On the other hand, this structure could come at a considerable cost over the long term. Since you pay at the server level, you may spend anywhere from $100s to $1,000s a month, depending on the hardware that you allocate. Also, you’re still bundling a bunch of services on the server, and you’re not able to individualize your services to independently scale certain parts of your infrastructure. For instance, you might have a highly transactional part of your system such as order processing, that is bundled on with all of your other web services. So to scale your order processing you would need to add more servers for all your web services. Also, in recent years there has been some delay in adding or subtracting hardware for scaling up or down – maybe just 5 to 15 minutes, but there is this short delay between the time when your system detects that your volume increases and the time the additional hardware actually becomes available.
In a serverless architecture, there’s no hardware to provision or maintain. Your provider selects which and how many servers your instance will run on. You do have to establish upper and lower limits for your footprint – and that includes not only functions, but also Azure Data Factory services, data pipelines, SQS for queues, and other similar services. You set your limits based on how much you’re willing to pay for your traffic volume, so your system will automatically scale up and down very quickly to accommodate traffic spikes.
There’s very little warm-up period in serverless – it’s not zero, but it’s very small. For example, you know within a few seconds if you’re receiving 1,000 orders, so you can scale up just the order processing aspect instead of having to scale your entire system. That granularity of scalability goes all the way down to the near function level, even to the CPU or DTU unit level.
There are a couple of different ways in which serverless cloud services are metered, such as by RAM, transaction time, etc. But you really pay only for what you use. When you’re slow and you’re not using the service, you pay the minimal footprint. Maintenance headaches are gone, you don’t have to patch the operating system or underlying libraries, you don’t have to worry about hardware failures… all of that is managed by the cloud provider.
Benefits and Challenges of Cloud Services
In the last couple of years, the sheer breadth of cloud services has skyrocketed. These cloud services are natively accessible to one another, and you can leverage all these cloud-native integrations directly within your serverless infrastructure. One of the key benefits of serverless has become this integration, which is a huge time-saver. Things like logging and debugging, for example, become automatic.
Of course, there are also challenges. One of the challenges is that you have to have a mature process for your software development life cycle. Your developers have to follow best practices. They have to write good code. You have to have automation in place, especially during deployments. That’s because now, instead of deploying to a single server, you’re deploying to maybe hundreds of functions or services. Automation is key because it gets rid of human error and makes sure everything is deployed successfully.
The other key challenge is becoming locked into cloud vendors, such as Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Services (GCS). For example, if you are using Azure cloud functions and you want to move your application over to AWS to use Lambda functions, that would require a significant rewrite.
That’s where alternative architectures come into play. These fit somewhere between classic cloud and serverless architectures:
- Containerization – Docker containers are one of the most common forms
- Hybrid Cloud Solutions – This is where you combine some on-prem and some cloud solutions
- Multi-Cloud Solutions – This is where you leverage multiple cloud providers all together
How to Choose the Right Cloud Solution?
What’s the best way to decide which cloud solution is right for your organization? Here is a general 3-step guide for choosing the right cloud solution for your applications:
- If you have a monolithic, three-tier app and need a high level of operational control – choose a classic cloud architecture. This also enables a high level of support from outsourced independent software vendors.
- If you need a high degree of modularity and elasticity for microservice applications as well as for front-end web services, choose a containerized architecture. This also enables you to virtualize the OS and scale very quickly using Swarm, Kubernetes, or other container services.
- If you have event-driven architectures that can be decomposed into functions, choose a serverless architecture.
Gartner also has a good chart that calls out various selection factors.
How to Get Started with Serverless
Before getting started using serverless, you will need to prepare your organization to handle all the moving parts of a serverless environment that are different from on-prem or classic cloud environments. Here are some of the considerations that relate to different areas of your organization:
- From a financial preparedness standpoint, you need to understand the way that you pay for hosting. This is completely different because it’s metered based on different services. You might also need to mitigate your risk if you’re concerned about getting locked into one cloud provider for an extended period.
- From an IT perspective, you’re going to need to either hire or train for new skill sets. There is a cloud skills-talent gap if you’re used to an on-prem or classic environment. You might need agile training, cloud architect certification, or training on the languages that are supported in the cloud serverless infrastructure (including Go, PowerShell, Node.js, C#, Swift, or Ruby). Also, the philosophy is different in the way you scan for security and deploy code in smaller chunks along the Continuous Improvement-Continuous Development (CI-CD) approach. With serverless, developers may find they have more responsibility since they have to deploy their own code into production and do all of the quality checks and security scans themselves. This is a shift from the mindset of focusing on developing and deploying just one piece of code.
- For product development, the way that you manage your product backlog may change when you’re able to deploy features much more rapidly. You may move to a schedule with smaller, more frequent releases. You might also want to do a proof of concept because the first time you go into a serverless solution you’re going to make mistakes. You will want to pick a proof of concept so you can get hands-on experience.
- For operations teams, you have to shift your mindset to decentralize security. Instead of one team managing and enforcing security, now everyone who is participating in the project has responsibility for security. Also, every developer will need to know your best practices and make sure their code gets scanned line by line to ensure it fits those best practices. Each one of the services that you consume on the cloud will have its own security layer, and some may even have their own firewalls or IAM services.
Identify Your Use Cases
The next thing you need to do is identify your use cases. This needs to be done even before you can do a proof of concept. Some great examples of serverless use cases could be:
- Event-Driven – for instance, sending emails
- Highly Variable Volume – anything that’s burstable
- Feature or Component That’s Isolated – because it’s isolated, you can mock it up within your proof of concept
- Data Ingestion – reading data from external or even internal sources and routing it to the appropriate receiver
- Stateless – when nothing inside of the function requires information from some other part of the system unless it’s specifically passed in
- Routing of Data – for instance, if you have an invoice that requires customer data, then it could actually be passed into an invoice function in order to be processed
- Image, Video, and Audio Manipulation – or any other heavy CPU-intensive functions
Vendor-Specific Recommendations
Amazon Web Services has developed a “Well-Architected Serverless Framework” as a best-practices guidebook. It’s a comprehensive 73-page guide that includes a variety of different scenarios. We at CoStrategix have followed this framework several times with great success. Here are some of the key points AWS recommends for a successful transition to a serverless infrastructure:
- Identify the components of your system that can be transitioned
- Define your use case or your business case
- Determine what scenarios would exist
- Decide the best implementation
Microsoft Azure also provides a nice flowchart to follow if you’re moving over to the serverless cloud. It walks you through the decision-making process: Do you want to migrate or build? Do you require full control or are you willing to let the cloud provider manage your infrastructure? Do you require a high-performance computing infrastructure to handle extremely large batch-type volumes? Are you going to bundle all of your services together to run on an app service (for websites and asset management systems)? Or can you break down your infrastructure into microservices, and thus consume the functions as functions? In this chart, you start at the top and work your way through to the bottom.
Common Pitfalls
Lack of Process Maturity: I cannot overstate how important it is for you to have processes in place, and the discipline to follow your processes. If one of your processes breaks down, you’re going to introduce damage to your system – perhaps expanding your security footprint too much, or on the other hand exposing sensitive information to hackers.
Ineffective Monitoring and Alerts: You must watch how much serverless functionality you consume. Serverless scales up extremely fast, and to extreme sizes if you let it. If you don’t properly monitor your usage or cap your top limits, you could have a runaway function or an infinite loop that could scale the system incredibly large and cost you quite a bit of money. Ineffective monitoring could also damage your data or compromise the integrity of your system.
Poor Code Quality: You need to have code scrubbers in place to make sure you’re following best practices for security controls. If you set the controls too tight, your system won’t be able to function. But if you set them too loose, then you open your environment to malicious activity.
Little to No Automation: You want to automate your deployments! Don’t do manual deployments in a serverless environment! These environments can be complex, and you don’t want to open up your environment to human error.
Not Testing Enough: Make sure you’re doing the proper testing. You need to have your performance testing, security testing, and regression testing well-planned and executed.
Just getting started with serverless? Not sure if your use case is appropriate for serverless? Want help figuring out how serverless can fit in your larger cloud strategy? CoStrategix has helped guide many companies from consulting and strategy development all the way through architecture build-out. We have a versatile and agile team familiar with the most up-to-date technologies, a wide variety of programming languages, and user experience design. We can help you get from initial idea to full-scale execution rapidly. Let us know how we can help you!
