Global
A day in the life of a developer used to consist of dividing their time between writing code and maintaining the server infrastructure.
The serverless servers was introduced by Google when they released Google App Engine in 2008, and life for developers started to change by relying on a third party to take care of the servers.
With the serverless market expected to reach $7.7 billion by the end of 2021, it has become much more mainstream.
As you build your cloud strategies, it’s essential to understand the concept and know when your organization should go serverless. Further, we will also look at when to go serverless.
Serverless concept
While the term implies no servers are needed, that’s not true.
The concept of serverless servers or computing means you can build and run applications and services without your developers spending time provisioning and maintaining the infrastructure needed for deployments.
Instead, a cloud service provider (CSP) such as AWS or Microsoft Azure handles these infrastructure-related activities. Let us look at some ways of when to go serverless or when to use serverless servers. Amazon AWS serverless architecture stack has AWS Lamba, Amazon API Gateway, Amazon DynamoDB for NoSQL database storage, Amazon S3 for object storage, and Amazon SNS and SQS for messaging and queuing.
When to go serverless?
Here are a few ways on when to go serverless or when to use serverless servers.
Short-Running and Event-Driven Apps: A serverless computing architecture is ideal for short-running and event-driven applications because they have more predictable surges in demand.
Since these applications can sit idle for periods, a serverless computing architecture model allows you to use the resources you need instead of physically taking on your servers to handle peak capacities.
Serverless computing works best in these scenarios:
- Microservices-based architecture
- Mobile backends
- Chatbots
- Machine learning (ML) inferencing
- Internet of Things (IoT)
- Modest streaming processing
- Service Integration
Why go serverless?
Here are few reasons on why go serverless.
Improved Cost Control: Serverless computing is a cost-effective option. You’re only paying for your computing time based on actual usage. This also means you can scale on-demand without paying for servers that are not in use.
Dynamic Agility & Scalability: Serverless computing brings great agility and scalability. You can rapidly scale without re-architecting your infrastructure, and it’s easy to do. It takes just milliseconds to provision. No matter if the application is handling 1,000 requests or 1, there is no difference in performance and reliability.
Focus on Innovation: Anytime you can free up your team to work on more strategic tasks, it’s a huge win for the business. Developers can focus more on the business aspect of the code versus spending time on infrastructure-related items. This can translate to more time spent on the application’s front end and better customer experiences.
Faster Time to Market: With fewer operational dependencies, the development cycle can naturally speed up and allow the team to deliver more functionality faster.
Serverless Computing
Serverless computing is an option for any size organization in any industry. It provides an opportunity to focus more on business-driven processes rather than spending time on the technical efforts associated with maintaining servers.
Past this point, the next logical step in this process is to make a move to serverless services.
Transitioning to serverless services
Just as the transition to microservices is generally gradual, with more and more services breaking off the monolith until the monolith disappears, the switch to serverless generally follows a similar pattern. So the challenge for many at this stage becomes how to make it a smooth transition. Below we’ve highlighted ten tips to help you tackle this common challenge and seamlessly move to serverless.
Serverless security best practices
1. Define your goal: What business problem are you trying to solve by moving to serverless? Is slow feature delivery causing you to lose customers? Are scalability and stability problems damaging your brand? Are you looking to reduce the cost of running your system? Do you want to lower your developers’ operational overhead and have them focus on creating business value? Whatever the reason is, understand the business impact you want to create by moving to serverless.
2. Identify low-risk business areas for the pilot: It’s essential to recognize that innovation and change require learning. Learning requires taking risks and making mistakes. Start migrating low-risk, non-critical business processes to minimize risk and avoid costly mistakes. The key is to prevent big-bang migration wherever possible and ensure you have your stakeholders’ support.
3. Prototype, learn, and repeat: This is the fun part where you build proofs of concept (POCs) to learn and validate your assumptions. These POC projects are your playground where you can learn quickly and fail cheaply; do not confuse them with production code. Be sure to delete them after you have extracted maximum learning from them.
4. Apply continuous delivery: The sooner you apply continuous delivery (CD) to your serverless project, the better. This is the time to choose a tried and tested Go serverless framework. While it can be tempting, resist the urge to create your own – it’s precisely the type of heavy lifting you want to avoid.
5. Automate testing: With a move to serverless, your code has become simpler than ever; however, the complexity doesn’t disappear. Instead, the complexity moves around. It is now in the configuration and security of your functions and how they interact with external dependencies. These are the things that are most likely to break your application now. What is tested should reflect this change in the risk profile. The focus here should be on integration and acceptance tests using automated testing tools.
6. Build observability into the code: This stage involves a few key factors for consideration – leverage and ship your logs to a log aggregation service where they can be easily searched. Use structured logging with JSON and complement log messages with contextual data helpful in finding related logs. For example, include the order ID as an attribute in every log message related to an order. This is the opportune time to create dashboards and alarms for key performance indicators.
7. Focus on security: Follow the principle of least privilege, meaning each function should have only the permissions it needs – nothing more, nothing less. Apply account level isolation so each environment has a separate account to help contain a security breach. You can also use git commit hooks to stop account credentials from leaking to ensure serverless security.
8. Apply continuous learning: You’re in production; congratulations! But don’t stop there. Keep experimenting, learning and iterating on your designs. Share what you’ve learned with other teams and with the broader developer community.
9. Standardize error-handling and correlation IDs: Identify common patterns and cross-cutting concerns. Then, look for ways to standardize how you deal with these concerns—using middleware engines such as middy is an excellent way to normalize your code.
10. Automate operations and security monitoring: Use the power of serverless security best practices to automate processes and security monitoring. For example, you can adopt ChatOps using AWS Lambda with Slack integration.
Serverless pros and cons
Here are few serverless pros and cons. The pros are It is cost effective, scalable, reduces administrative burden, can be quickly deployed, and is flexible. The cons include, it has cold start issues, offers limited control to developers which can limit troubleshooting, might result in vendor-lockins, offers debugging challenges, and has a lack of standardization since it a new technology.
