We discuss quite a bit about , however it’s often those with an already huge infrastructure, such as enterprises, that can find the move and change daunting. We see many companies from the likes of to managing it but what does it look like in action? In this article, we share some best practices and insights on the serverless designs that can scale massively and represent enterprise models. For a real life example, you can also check out how from a traditional cluster - psst, they’re also giving away their winning strategy for a smooth transition. going serverless for SMEs and startups Coca-Cola Netflix Shamrock Trading Corp migrated to serverless As AWS says, the most important foundation to keep in mind is that no matter the size, well-designed serverless applications are decoupled, stateless, and use minimal code. As the projects and applications grow, simplicity and low-code needs to be maintained. Moving away from Monoliths While , with a business and application that is going serverless, moving away from this traditional style will save a huge amount of time. By grouping common functionalities together into smaller services and creating separate code repositories and microservices, the evolution of an application including new features will be more straightforward. This design also reduces security risks, deployment issues and bugs that can cross-contaminate. monolith designs can still suit some functionalities So, what is the best way to group these? Often, the best way to consider this is through the functions and resources that define a microservice. The design itself is also important; we don’t want to build a large repository that’ll end up as a monolith, however too many of them will mean duplicate code and difficulties in sharing resources. The aim here is to have one single piece of functionality that does that one thing very well. Consider Concurrency It can be tempting, when using automatically scalable services such as and , to not consider the backend relational database being used. We want scale that will match demand - that’s one of the beauties of these serverless services at the end of the day! However, without the correct and, most importantly, necessary intermediary services to buffer requests, bottlenecks, throttling, outages and even loss of valuable data can occur due to exhaustion. AWS API Gateway AWS Lambda While API Gateway and Lambda are able to spin up thousands of concurrent requests quickly, it’s key to remember that not all AWS services are the same, such as AWS RDS. Instead, including services like AWS Kinesis or AWS SQS that poll for new records and can return findings to Lambda functions means greater control without any downtime or latency. Take advantage of individual AWS Services Using bundled code libraries may feel like the simpler route, but once again, as your application scales, this design will create a monolith that restricts developers. So instead of this: Source: AWS Let’s go to this: Source: AWS API Gateway API Gateway offers native routing functionality. It’s also capable of validating parameters meaning less custom code, and provides protection against unauthorized access. Don’t forget about security! Lambda In this latter example and following best practice, Lambda functions should consist of minimal code and fewer dependencies. This simplicity is crucial in enabling easier testing and for different developers to work on functions separately for speedier builds and ultimately, safe deployment. Step Functions Following on from the theme of simplicity, Step Functions should be used for workflows as opposed to Lambdas, which can make changes more difficult and cause idling, resulting in avoidable high costs. Step Functions, again, means less custom code, code that will last and it enables in-flight executions. Multiple AWS Accounts This is a basic but critical standard best practice to consistently follow. From a security perspective, it’s a no-brainer as permissions and access levels can be set according to the rule of least privilege. However from a CI/CD pipeline point of view, with each developer having their own account, their actions won’t impact on the production environment or other’s due to the limits set. This can be further taken advantage of when using AWS SAM or CloudFormation templates, as functions can be tested locally against live cloud resources within their own machines and accounts. It’s also useful to create accounts for beta deployment and production, in order to create separation. Within the multiple accounts, groups can be created with policies attached enabling the sharing of scripts and avoiding manual processes. Maintaining Visibility As any developer knows, visibility is key to ensure autonomy, assurance and confidence. As applications grow and more features are involved, new AWS accounts created and further services employed, monitoring becomes increasingly important as the potential for failure increases synonymously. We want to maintain , understanding how it looks and feels from the client’s front-end to how clean functionality and performance is at the backend. This means being able to look at all environments including test, beta and production. end-to-end visibility on our serverless architecture Using a that can reach all aspects of your serverless infrastructure from supporting all services used, providing insights into performance and costs, and simple and quick switches between accounts will provide full assurance that you know exactly what is going on within. Many monitoring systems use an for failures or errors, which is undeniably helpful for instant acknowledgement and quick remediation. monitoring system alerting system Wrapping up And so, it’s clear that the common themes for successful large scale serverless projects are varying degrees of separations and simplicity. Scalability in the serverless world is dependent on independent services that interact with each other but aren’t wholly reliant on another. AWS has created a plethora of brilliant services that can integrate seamlessly with each other, here’s a , to get you started. However to get the best out of each of them, make use of their full capabilities and don’t be shy to employ other services within a function for extra productivity. list of AWS services we think everyone should have in their starter toolkit Lastly, don’t forget about security and that crucial visibility into your infrastructure’s performance so you know all is safe and running as it should be! Learn more about how Dashbird can help you with keeping on top of your application’s performance . Previously published at https://dashbird.io/blog/serverless-for-enterprises-large-scale-projects/

Coca-Cola

Netflix

How To Use a FastAPI Abstraction To Query AWS Data Lake

The Great Serverless Cost Debate 

Serverless af

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Devops

Nominated for 2022 - HackerNoon Contributor of the Year - Serverless

Nominated for 2022 - HackerNoon Contributor of the Year - Aws

Too Long; Didn't Read

Serverless Playbook For Enterprises

Serverless Playbook For Enterprises

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

10 Things in Engineering We Don't Spend Enough Time On

101 Stories To Learn About Cloud Infrastructure

10 Things in Engineering We Don't Spend Enough Time On

10 Things I Did To Increase CloudTrail Logs Security

10 reasons to give cloud computing a go

10 Lessons from 10 Years of AWS (part 2)

10 Things in Engineering We Don't Spend Enough Time On

101 Stories To Learn About Cloud Infrastructure

10 Things in Engineering We Don't Spend Enough Time On

10 Things I Did To Increase CloudTrail Logs Security

10 reasons to give cloud computing a go

10 Lessons from 10 Years of AWS (part 2)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps