How to successfully adopt serverless in large organizations
By: Edouard Ma Poon
Medium non-members can read the full story here.
Volvo Group Connected Solutions’ cloud journey began approximately a decade ago. We did a replatforming when we migrated to AWS and designed and implemented our services to be cloud agnostic by deploying them in VMs.
Over time, our customers came with more requirements. They wanted us to handle larger volumes of data, provide more services, and expand to new regions. There was also a need to deliver faster, with higher quality and lower cost. Our application teams struggled to keep up with the pace of implementing these requirements while being bound to a tightly coupled architecture, mounting technical debt, a capacity provisioned infrastructure and limitations of our single account setup.
We then made the decision to go serverless.
Why serverless?
Serverless has disrupted the tech industry in recent years and leveled the playing field by giving organizations instant access to the same resources. In fact, it gives startups and small organizations an edge. They can move faster because they have fewer processes in place than larger traditional organizations, and serverless enables this agility.
It’s easy to see why there has been a significant adoption of serverless over the years:
- It eliminates infrastructure management tasks so teams can focus on delivering business value.
- It eliminates the operational overhead so teams can iterate quickly to get to market faster.
- It has a pay-for-value billing model that helps lower and optimize costs.
- Serverless applications automatically scale from zero to peak demands allowing workloads to adapt to customer needs.
- It has built-in high availability.
Best practices for adopting serverless
I would like to highlight different areas that I think large organizations need to consider when adopting serverless as part of their digital transformation. It’s a combination of my own experiences as well as some best practices I think are useful.
These main areas are:
- Get executive support
- Organize your AWS environment using multiple accounts
- Educate teams and start small
- Create a culture of experimentation
- Evolve your architecture
- Utilize internal expertise and bring in external help
Get executive support
Stephan Orban, of Google, said that projects are most likely to succeed if they have support from the top, meaning those who can make large-scale change management. Meaningful change in large organizations is rarely just about the technology. It’s about people and leadership, and it’s about creating a culture that encourages safe-to-fail experiments and smart risk taking instead of creating fear among those who are expected to move the organization forward.
Organizations have an obligation to inspect their processes and create new rules to keep up even if they have invested a lot into creating and establishing controls to maintain their status quo. Organizations need to break free from what they have been. What worked for them in the past will make them unsuccessful in the future.
It is important to get full executive support because this creates a common goal for the organization and aligns both teams and business functions.
Organize your AWS environment using multiple accounts
Assess the technical readiness of your existing platform and prepare to support your digital transformation by laying the foundations for your platform to scale.
We organized our environment into multiple accounts using Organizations. There are several benefits to using multiple accounts such as securing and isolating workloads, easing service quotas and rate limits, and managing budgets and costs. More importantly, in my opinion, is that it gives teams the flexibility, autonomy and the ability to innovate and deliver faster.
Our multi-account strategy is based on design principles from AWS. We created our landing zone by implementing an account factory that automates the process of rapidly and reliably provisioning accounts and resources to different regions based on our standard configurations. We started out by using a combination of Control Tower and the AWS Deployment Framework (ADF) to provision an account baseline which included security guardrails, VPCs, CI/CD pipelines etc. This process was complemented with CloudFormation StackSets, Step Functions, and EventBridge, which gave us more flexibility to unify and streamline the account provisioning and handle the service disparity between different AWS partitions.
Whichever route you take, it’s important to automate this process and standardize your accounts to both scale and easily maintain existing accounts.
Educate teams and start small
When we started our transformation, application teams were still largely shielded from the cloud because of our abstraction layer. They had very little to no knowledge of serverless. Concepts such as events, eventual consistency, roles, permissions, variable latency, Infrastructure as Code, and design patterns such as pub/sub messaging, fan out and event streaming were all new to them.
We began small by choosing a few pilot teams that were forward leaning, had the right attitude and that we knew were not afraid to lead the way and be our champions. This gave us the opportunity to test our landing zone. During this time, we received feedback and learned what worked and what didn’t. That helped us continuously adjust our processes, standardize patterns, and tweak our platform.
As we expanded, we started a training and certification program for all teams to upskill themselves with AWS knowledge. We held Immersion Days that were tailored with relevant AWS services applicable to each team’s products. We also arranged Game Days to give teams opportunities to problem solve real-world technical problems, and organized workshops to introduce techniques and concepts.
Education is an effective step in helping people overcome their fears of what they don’t know.
Create a culture of experimentation
Serverless is a mindset, a culture, and a way of working. But culture is hard to change and curate. Adrian Cockcroft, a former Netflix executive, said, “It’s usually the people and processes that are blockers, not technology problems.” And I agree, it’s important to challenge the status quo and create a culture of experimentation and innovation. Several large organizations like Capital One, General Electric, and Johnson & Johnson have relentlessly challenged the status quo to keep up with customers and stay ahead of competition.
When it comes to platform engineering teams, large organizations often establish shared services developed by these teams to solve common problems, and we adopted a similar approach. While these shared services aim to streamline processes, they can inadvertently slow down progress towards business objectives because they create dependencies on these teams. So, it is important to evaluate the responsibilities of your platform engineering teams and the operating model in your organization. Platform engineering teams should move away from performing functions for application teams and instead become enabling teams. This reduces the dependency on platform engineering teams and creates a DevSecOps culture that gives application teams flexibility, responsibility, and ownership of their products. The development process becomes more agile and improves developer experience by giving teams the freedom to innovate.
“You don’t add innovation to a company — you get out of its way”. — Adrian Cockcroft
Evolve your architecture
In the same way that you need to make new rules for your processes, you need make new rules for your architecture, environment definitions and API contracts. Serverless opens new paradigms in each of these areas.
Serverless enables you to decouple your architectures and make them flexible, allowing you to move faster by reducing dependencies on other teams and minimizes the impact of your changes. Adopting serverless allows your architectures to evolve and adapt for the future. You will be able to make changes many years from now because you were not bound to an architecture that was decided 5 or 10 years ago.
Serverless is largely driven by Event Driven Architecture. The focus of your architecture concentrates on the flow of data and events. If your platform is based on a Service Oriented Architecture, you need to review if and how you could transform your services to serverless. With serverless, as Julian Woods, a serverless advocate at AWS, puts it, “you build in the cloud and not just on the cloud” to take advantage of the reliability, scalability, and security of the cloud. You can do this by replacing or rearchitecting these services with managed services provided by AWS or third party vendors. One thing to keep in mind is to use as many standardized technologies and patterns as possible and move away from custom implementations. This makes integrations easier, and you will be able to retire technical debt, future proof your applications and deliver faster and with more value.
Also, consider the Well-Architected Framework to measure your architectures against best practices. This is complimented by the Well-Architected Tool to apply these best practices.
Utilize internal expertise and bring in external help
Organizations often feel they don’t have the necessary skills to drive or steer their own transformation. But if you have platform engineering teams, you should strongly consider using them because they probably already have all the skills needed.
Platform engineering teams are an excellent source of in-house AWS expertise to help you accelerate the transformation. In fact, I would argue that they are best positioned to help drive your strategy in the right direction because they possess the unique combination of in-depth AWS expertise, experience with serverless, understanding of your application architectures and domain-specific knowledge of your organization. Their deep technical knowledge in these areas combined with industry best practices will help evolve your architecture to get the most out of AWS within the context of your organization. Utilizing these teams will also be an effective cost saving measure and efficient use of existing resources.
Another source of knowledge is external help, such as partners who can provide cloud expertise. They have certified experts with industry experience and knowledge of best practices to help your transformation and evangelize serverless in your organization. In my opinion, this can be invaluable if application teams are struggling to adapt to the transformation and need a catalyst to help drive them forward.
Summary
Adopting serverless as part of your organization’s digital transformation is important to meet changing business and market dynamics. It will require relentlessly challenging status quo at all levels in the organization, from implementing new rules and changing the culture, to modernizing the platform, educating teams, and evolving the architecture. But if done successfully, it will enable your organization to keep up with customer demands and stay ahead of the competition.
Bio:
Edouard Ma Poon
Senior Solutions Architect and serverless evangelist with a special interest in DevSecOps. I work on the cloud platform and have been with Volvo Group Connected Solutions since 2016.
