The first edition was published in 2020, and with the pace of change being as brutal and unforgiving as it is, I started making notes for the second edition within a month of finishing the manuscript. The overall structure has remained the same, but I go far deeper into the different topics in the 2nd edition. There are also more visuals and a couple of new topics. This series of articles provides a summary of each of the chapters with some personal afterthoughts. Serverless Beyond the Buzzword 2nd edition can be purchased here: https://link.springer.com/book/10.1007/978-1-4842-8761-3
Written article continues below the video
The strategy chapter covers several initiatives that should happen before an organisation launches a serverless-first strategy. These initiatives cover the people, processes, and technology that should be in place to use the cloud more productively, especially for modern architectures such as Serverless.
Serverless architecture is quite unlike the previous evolutions of cloud software. As such, existing cloud management strategies are often incompatible. This is especially a challenge in larger enterprises where, for years, the focus has been on optimising the security, delivery, and operation of server-based applications.
For organisations that started with on-premises infrastructure or servers in the cloud, separation of duties is typically a core security strategy for governing IT infrastructure and ensuring compliance. With this approach, application responsibilities are split across multiple teams to avoid any single entity holding every permission to the IT environment and application. While this is workable for on-premises infrastructure and even servers in the cloud, it is too restrictive for Serverless architecture. Instead, we want to enable application teams to be self-sufficient and provision cloud resources themselves. Such a strategy is governed by a central team often called the Cloud Center of Excellence (CCoE), and automated controls will be used in the cloud to ensure the compliance of the code and infrastructure deployed by the application teams.
A CCoE is the cornerstone of a successful modern cloud management strategy. A centralised team governing the use of the cloud within the organisation, its responsibilities include establishing and enforcing security, regulatory, and other compliance in the cloud through a comprehensive cloud management platform that it operates. The CCoE team and the platform together enable the organisation’s application teams, both in technology and capability.
When establishing the CCoE team, there is no single approach that works for all organisations. It is important to have representatives from different domains and viewpoints to ensure a comprehensive and diverse approach to cloud management. The team should include technical members, such as cloud and software architects, data and software engineers, infrastructure and cybersecurity specialists, agile delivery leads, and others, depending on the organisation's needs. However, we also need non-technical members, such as those familiar with relevant regulatory compliance, internal and legal policy, education, and advocacy; finance; community managers; and, of course, specialists in people, culture, and change management.
For Serverless development, the application teams must be able to provision their own cloud resources as part of the application design and development process. However, the organisation still needs to be able to determine which resources and how they are configured. The policies for security, compliance, and best practices defined by the CCoE need to be applied to the requested resources and, where necessary, enforced.
A common term for these automated rule enforcers is controls. Controls can be implemented in the cloud account, several cloud services, and in the application deployment pipeline. We can leverage four types of controls to ensure comprehensive coverage for the organisation.
- First, we have the directive controls. Directive Controls list all the requirements and expectations for cloud usage, usually in documentation and training materials. They don’t enforce anything, only inform.
- Preventive controls are the primary means of enforcing the directives. They restrict the actions that users are allowed to take before they take them. Most organisations would be familiar with this through access permissions and allow listing.
- Detective controls define a set of rules and actively monitor changes within the cloud environment. The controls can send notifications for any non-compliance events. Any follow-up would be at the discretion of those receiving the notifications. They tend to be used as a secondary compliance monitoring layer.
- Lastly, corrective controls are similar to detective controls but go a step further to automatically take remediation action, such as removing or rolling back the non-compliant changes. These are less commonly used as organisations are often uncomfortable with automated changes to an environment.
Tools and frameworks
Chapter 2 covers several tools and frameworks to help achieve a strong Serverless strategy.
A self-service portal is an essential part of enabling the application teams. It helps them onboard projects and provision code repos and pipelines.
A shared central library or knowledge portal will help share, discuss, and improve reusable architecture patterns, best practices, and other knowledge between teams.
An approach to establishing the current and desired states and analysing the gap between them to create a roadmap of tasks that need to happen. Similarly, a framework is provided that can help determine if a given application is a suitable candidate for serverless architecture.
Lastly, this chapter covers event storming. An approach to analysing traditional applications and converting them to an event-driven serverless architecture.
Check out the book's mini site for more information and ordering here: https://serverlessbook.co