Our recent ZipChat on Serverless technology was insightful and replete with real-life experiences. Serverless is more than infrastructure. It’s a mindset that helps in understanding how good software gets built. A quick poll at the beginning of this ZipChat illustrates that most are still dabbling with serverless technologies. Before we delve into the details, here is a quick introduction to the discussion panel,
- Gandhi Raketla is a Senior Solutions Architect for AWS. He works with AWS customers and partners on cloud adoption, architecting solutions that help customers foster agility and innovation.
- Matt Griffith is the Chief Architect at Intertek Alchemy. He has been developing enterprise and web applications for 20 years professionally. Passionate about knowledge sharing and coaching. He is committed to leading by example and empowering people to seek and develop the skills they need to achieve their goals.
- Philip Edge is the Vice President, Engineering & Chief Security Officer, at Intertek Alchemy. He has 20+ years of driving enterprise app & platform development as well as 11+ years implementing cybersecurity programs (PCI-DSS, NIST, SOC2, GDPR, ISO 27001, OWASP).
The session was moderated by Mike Watson, VP of Engineering at Synerzip is a veteran engineering leader. He has over 15 years of experience leading software teams. Mike’s passion is in helping software product development organizations transition into strong Agile practices and cultures within.
Why serverless
Mike starts the discussion by asking why an organization should go down the route of serverless technology.
Gandhi responds that it is vital to understand how applications’ role has changed considerably in the last 20 years. In the past, applications were a utility to accomplish specific functions, often in an assisting capacity only. However, applications today form a part of the core revenue generation model.
Today’s competitive advantage lies in bringing functionality that customers need and want rapidly to the market. A serverless infrastructure strategy enables you to do just this. It offloads all the operational responsibilities of managing environments such as patching, maintaining tools, etc., to a cloud provider. This offloading helps you focus more on the development strategy that adds business value.
Potential barriers to entry
A quick poll showed that serverless barriers were evenly distributed between there being no challenges to dealing with monolithic applications.
Agreeing with this idea, Mike notes how much of the code for setting up and managing infrastructure is already commoditized. Reinventing it would waste valuable time. He further leads with a question for Gandhi on the considerations and barriers an organization must evaluate before going down the serverless path.
Application architecture
A lot depends on the business model, and the way applications add value, adds Gandhi. When business owners start thinking about serverless products, they must rethink the application architectures, the events it triggers, and how it behaves to change. While the serverless application architecture looks a lot like traditional architecture, there are some differences in its logic and implementation. He delves further into some salient points, such as modularity of services, which is the realm of microservices.
Modularity of services
Microservices contain functions that perform a specific task and improve scalability and resilience. Another change with serverless infrastructure is how these functions within microservices communicate, including events, messaging systems, and queues. The third most crucial change is a purpose-built data strategy with the right database for the right job instead of a single database for every purpose.
Gandhi further elaborates about a single release pipeline that multiple teams share. This sharing causes bottlenecks and complex interdependencies that prohibit faster releases. With serverless technology, teams that handle functionality rather than a technical component are free of this interdependence. They can now move at their own pace and release functionality at speed.
Real-world motivations for serverless
Matt talks about his motivations for going ahead with a serverless framework. He narrates how they built a modern application that is device agnostic and needs integration with the principal (monolithic) application. Along with this, some of the features had to scale at the backend.
Bridge integration apps
Adding to Gandhi’s point, he talks about how serverless technologies helped them detach from the headaches of worrying about the infrastructure and not needing to reinvent the wheel with a lot of backend processing. Serverless helped them bridge many of the integration gaps with the services that AWS offers today.
Philip stresses how serverless technology comes built-in with many components such as DynamoDB, Lambda, etc. He also notes how the overall service is very fault-tolerant, where you are not paying for any idle time. Developers can have their clone of the production environment and not worry about running on their machines.
Sense of ownership for developers
One of the biggest eye-openers for Matt and Philip was the ownership it bestows on developers. It does away with all the chores of asking IT for infrastructure to deploy code. With serverless technologies, developers now have everything they need to run their code and focus on what they do best, developing apps and writing programs.
Gandhi further adds that developers traditionally needed to set up their IDEs and then integrate that with the CICD pipeline, manage IDs, etc. This setup took away valuable development time. Serverless lets the developers launch their IDEs in the cloud and configure them with the development pipeline quickly.
Production grade quality out of the box
These cycle time reductions empower serverless technology to reduce the development of a production-grade API from months to days. They now don’t need to worry about testing the function for scale, reliability, etc., because serverless technologies give them robustness and production-grade out of the box.
Piggybacking off this point, Philip adds that serverless technologies enable them to develop prototypes and demos quickly. This rapidness lets them test their assumptions, fail fast, and rapidly improve time to market. The time to proofs-of-concept has come down from months to days and even hours.
Tying benefits of Serverless technology with business gains
Mike further asks Philip how their developers are now doing with this fast and furious method of development. Philip states that their customers are actively using their products. The serverless idea has enabled them to architect secure, robust products. The team sees that there is more market availability now than they had yesterday. They’ve had some quick wins right out of the gate, and that has been an eye-opener. He further states that they are now building a cloud-native platform using serverless technologies along the way.
Matt further elaborates on how they have been serverless for a little over a year now and helps them with automation that leads them closer to automated CICD. Being cloud-native helps them take advantage of being serverless.
Hybrid approach with monolithic applications
At this point, Philip talks about a hybrid approach. They had an app that couldn’t stand on its own, and the developers did not want to build a brand new database just for it since it still needed to integrate with the core. The primary frontend is being served with React from S3 buckets. They were also using nodeJS with Lambda along with the traditional PHP monolithic application that it communicates with.
They were building REST endpoints but didn’t want to build APIs specifically for this. Hence the hybrid approach allowed them to retweak some of the existing APIs to enable the integration with the central core. Matt and Philip started from the ground up for the new platform but needed to test the waters, and this hybrid approach allowed them to move faster by learning and failing faster.
Overcoming challenges
Training and certifications
In the initial stages of the project, Matt and Philip were not fully aware of AWS services, how they work, and their role. Hence training and certification were some of the first things they accomplished. Also, the certifications and training trickled down to the entire team, where they learned how to integrate and work with AWS services. 98% of the engineering team is AWS certified, with a few already on their next certifications.
Asynchronous workflow
To understand the serverless functionality, Matt explains that you need to understand the asynchronous workflow. In the traditional software development workflow, the entire team works on everything. However, the asynchronous model tasks need to hand off to another service or team to move ahead. This workflow is more pronounced in the frontend than in the backend. Matt explains how they’ve needed to adjust the frontend to accommodate this asynchronous workflow.
Infrastructure as code
The other challenge that Matt talks about is DevOps. Traditionally, DevOps managed and tweaked the infrastructure. With serverless, infrastructure is code, and hence developers now needed to be more aware of network security and other infrastructure nuances that were traditionally the stronghold of DevOps professionals. On the other hand, the DevOps teams were becoming more aware of how developers were now doing more of the infrastructure. Coming together as a team has been a learning experience and an ongoing process.
Selecting the right project candidate
In the initial stages or while experimenting with serverless technologies, Gandhi adds that it is essential to choose the right candidate, which does not have too critical a business impact but is also a functionally important piece. Getting this balance right is challenging.
Change in thinking
Gandhi further elaborates that a shift in thinking about how a serverless function operates is essential. Thinking the same way you would for a monolithic application would port all of those challenges to the serverless environment. He further elaborates that thinking modularity and prioritizing functions is how clients get real value from serverless technologies.
Gandhi suggests looking for areas of the function that can truly leverage serverless. He also emphasizes that choosing the appropriate framework is essential since it comes with the right tools to aid that change of thinking.
Philip further elaborates on how a lift-and-shift move to serverless is disastrous. He emphasizes the need to focus on business logic. However, many already possess monolithic applications, and newer applications that leverage serverless technology still need to work with these legacy applications. Hence a hybrid approach is a way to go in such situations.
Questions from the audience
Q: How do you get visibility into pieces of the application and what they are doing? If things go wrong, how do you debug, and where would you look?
Matt elaborates on how they are looking at more charts to understand workflows. He talks about tools that can scan your AWS account and draw architectural diagrams based on the applications in use by developers.
He then explains how step functions, SQS, and SNS queues help them break down workflows into more detail. Tools such as LucidCharts or Visio help draw those charts. It helps to review if they are doing what they are supposed to do and how they match your intended goal.
Philip talks about using one monolithic application performance management tool (New Relic). This tool helps them see how parts of the application function in real-time and if they have the intended flow.
Matt further talks about a tool from AWS called Control Tower that lets you manage access and accounts from a single sign-on for various AWS services. This service helps in setting up sandboxed environments for developers. Even in the event of a breach, it limits the damage because of account segregation.
Gandhi further adds setting up teams by function such that managing and monitoring service is more effortless. He also adds the usage of the right frameworks, such as Amplify, that give the right tools to manage and monitor the application. For example, tools such as Xray help trace the function calls and time taken at each stage.
Q: While Lambda services work great with event-based use cases, are there any services that work with microservices patterns such as circuit breaker, clients-side discovery, etc?
Matt talks about using step functions to do this. He describes how they write individual Lambda functions to do specific tasks and then chain them together using step functions to build a workflow. Gandhi further adds the use of API Gateway to achieve these functionalities. He talks about using REST-based communication between services. AWS AppMesh is also another service that enables interservice communication.
Further resources recommended by the panel:
Serverless and SaaS are a decisive match, as are Synerzip and AWS. Synerzip is uniquely positioned to design and build SaaS applications for various verticals and use cases, having serviced public and private, startup and enterprise clients. The serverless mindset intersects with a SaaS model in that both equip your business with the flexibility and agility to be cost-effective and mitigate risk. The robust suite of AWS services provides the peace of mind needed to let go of the operational component and instead focus entirely on driving profitability and growth. As an Advanced Tier AWS Consulting Partner with a serverless SaaS delivery specialization, Synerzip can help you achieve faster time-to-value with your application.
