Over the last few months, we’ve received a lot of questions about serverless. Specifically, what we think about serverless, the problem that it solves, and why company culture and whether they have migrated to DevOps is a significant challenge in today’s industry.
Recently, I had the chance to sit with Alex Casalboni, software engineer and serverless champion, from Milan, Italy. Alex was nominated for the Serverless Champion award in April. With over a decade of experience coding, he’s been evangelizing serverless since 2016.
Today, we’re going to help clarify a few points about serverless, the importance of contributing to open source projects, and the path to becoming a hero in the serverless community.
For the full interview, listen to the podcast.
Q: How long have you been programming?
Q: What keeps you up at night?
I keep thinking of how many hands-on hours are wasted on manual server patching and OS maintenance, both inside small startups and large organizations. I can’t even imagine how many lines of code don’t get shipped every day just because it’s not perfectly ‘containerized’ or because it doesn’t seamlessly integrate with your organization’s 100M LOC code base. Wasted time and unshipped features might be the most likely reasons why organizations fall behind in development.
Q: Why Serverless?
Well, serverless architectures have the potential to solve the problems mentioned above.
Some of their properties and benefits are a direct consequence of the ‘microservices approach,’ such as high availability, failure isolation, and better maintainability and flexibility thanks to highly decoupled components. Some other benefits come from the fully-managed side of your FaaS provider of choice, as well as the vibrant ecosystem of fully-managed services that you can integrate to build your system without reinventing the wheel.
In my opinion, the most significant benefit is a consequence of all the others: speed. When you work with immutable components and well-designed CI/CD pipelines on top of your FaaS layer, you can quickly replicate 99.99% of your stack into multiple environments. And without paying by the hour if nothing is running! You can automate extensive tests very cheaply, and ultimately allow your development teams to be more productive, confident, and committed.
On a more technical level, serverless takes the ‘server’ concept out of your daily workflow. Now, you may argue that ‘containers’ also tried to achieve the same abstraction over the OS/machine, but they don’t remove the concept at all. You still need to work at a low-level with the underlying OS.
Serverless allows you to focus on very granular and highly debuggable/testable pieces of code (i.e., Functions). This has a great impact on velocity, isolation, security, and even the obsolescence of your code.
Q: You’ve been part of the serverless community for a long time. What are the most common challenges your readers ask about?
Well, two years is hardly a ‘long time,’ but for such a young community it’s long enough to witness plenty of changes, use cases, successes, and mistakes.
I believe the top challenge today is how quickly an organization can adopt change, even when that means discarding the last ten years of conventions and full-stack frameworks that previously tried to solve the same problems. Unfortunately, these sophisticated stacks haven’t adapted as quickly, and a whole new set of best practices and tools has been emerging from the community. It doesn’t mean that we ignore lessons learned in the past, but we can’t continue to use most of the tools and frameworks we love (especially the long list of full-stack monolithic web frameworks, such as Django, Rails, Spring, Symfony, etc.).
Q: You’re the author of the AWS Lambda Power Tuning project. Why don’t you tell us more about it?
AWS Lambda Power Tuning was supposed to be a quick-and-dirty weekend project, but it turned out to be a useful hack as a data-driven tool for a lot of Lambda users. The challenge was fine-tuning each Lambda Function’s RAM configuration (or ‘Power,’ since it involves CPU and Networking capabilities as well). Based on the data I collected, most people tend to “guess” the optimal configuration, or use mid-way at around 1GB. In some specific cases, you may want to optimize for performance, in others you could optimize for cost or even a mix of the two.
The tool I developed is built with AWS Step Functions. The state machine will take your Lambda Function and a set of possible RAM configurations as input; it will run the function in parallel enough times to gather statistically relevant information about its execution time, then it will crunch some data.
The outcome of this computation will be the optimal RAM configuration. You can also configure a few parameters to provide a proper input event and to avoid throttling.
The code is available on GitHub, and I’m excited to anticipate that a newer, better, and more production-ready version of this idea will be published soon.
Q: You spoke at many Meetups around the world and also helped organizations in making strategic cloud decisions. What do you think about the cultural changes companies must undergo when using serverless?
I think that depends on what your company culture is like where you work. If your org. has already embraced modern DevOps best practices or taken a microservices approach, you could build on top of the existing infrastructure. Extend the architecture and attach serverless components to it without the need to redesign everything from scratch. Simple.
But, if your org. has been falling a bit behind as far as cloud adoption and managed services, the required change will take more time, but you could act similarly by attaching new serverless components/features to your existing legacy.
Regarding culture and processes, the most prominent change is related to the ever thinner distinction between coding skills and operations skills (because serverless is not ‘operation-less’). When developers can fully own and operate their production code, many things will need to change and quickly.
Automation, infrastructure-as-code, and design for failure (and chaos) are still part of the best practices and must be adopted across all teams.
Q: Are there any cool projects you’re working on that you can give us the inside scoop on?
I am very excited about the ServerlessDays events series. It’s a community-organized and non-profit global conference, similar to DevOpsDays, where local communities can gather to share ideas. It’s intentionally designed to be accessible, with inexpensive tickets and top speakers. The conference motto is ‘One day. One Track. One Community’, and it was born last year under the name: ‘JeffConf.’
I am personally organizing ServerlessDays Milan in Italy, and working with new, localized teams to start conferences around the world. Since every event is non-profit without a centralized protocol, each team remains independent, and that allowed us to bootstrap over 20 events around the world this year.
Q: What’s next?
I do have exciting plans for 2018 and can tell you that I’ll be active in the serverless ecosystem. I’m also looking forward to contributing to more open-source projects and building exciting stuff sans servers (say that 5-times fast).
Community engagement is key for anyone who’d like to help other people by sharing knowledge and ‘talking’ ideas out. Serverless helps solve a lot of problems that companies have by providing the means to ‘ship’ features faster. Search for events local to you – they are everywhere. These small events are great for filling in any technical gaps you might have, helping others solve their problems and getting to know your local community.
In the <CODE> Components Meetups we talk about code components, trends and technologies in software development, and provide hands-on workshops in which participants code together to learn new concepts.
Let’s keep talking, I hope to see you around in one of our next Meetups.