You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 24, 2024. It is now read-only.
The architecture section would benefit from some consideration of Serverless aka Function as a Service. Whilst you could view it as an evolution of PaaS, I'd suggest that there are enough architectural differences for it to merit separate consideration. If nothing else, a mention of Serverless as a direction of travel would be worthwhile here.
Is it worthwhile considering the impact on wider organisational capabilities of your cloud architecture? The chosen architecture can have some interesting implications for wider business functions including operations (big differences between IaaS vs SaaS for example) and development teams as well as non-technical domains such as Procurement and Compliance. I've seen a few organisations struggle with procurement when trying to adopt cloud. Procurement teams need to understand the security requirements they should be using to compare and contrast cloud providers for best fit. It's a change in mindset from telling providers what they need to do. In some organisations I've worked with I've seen Procurement and Compliance driving their organisations towards private cloud. [Not that I'd recommend private cloud in general...]. This content would fit in your steps towards the end of the section - 1.2.2.1.
Relating to the above, it may be worth expanding on how a wider cloud strategy drives your cloud security architecture - e.g. public vs private vs hybrid, single provider vs multi-cloud, cloud-agnostic vs cloud-specific (i.e. lock-in vs making the most of a single provider's capabilities) etc. At the moment architecture sounds quite self-contained but in reality you'd want a generic way to tie the architecture to the wider strategy (or at least business context :))
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Three suggestions:
The architecture section would benefit from some consideration of Serverless aka Function as a Service. Whilst you could view it as an evolution of PaaS, I'd suggest that there are enough architectural differences for it to merit separate consideration. If nothing else, a mention of Serverless as a direction of travel would be worthwhile here.
Is it worthwhile considering the impact on wider organisational capabilities of your cloud architecture? The chosen architecture can have some interesting implications for wider business functions including operations (big differences between IaaS vs SaaS for example) and development teams as well as non-technical domains such as Procurement and Compliance. I've seen a few organisations struggle with procurement when trying to adopt cloud. Procurement teams need to understand the security requirements they should be using to compare and contrast cloud providers for best fit. It's a change in mindset from telling providers what they need to do. In some organisations I've worked with I've seen Procurement and Compliance driving their organisations towards private cloud. [Not that I'd recommend private cloud in general...]. This content would fit in your steps towards the end of the section - 1.2.2.1.
Relating to the above, it may be worth expanding on how a wider cloud strategy drives your cloud security architecture - e.g. public vs private vs hybrid, single provider vs multi-cloud, cloud-agnostic vs cloud-specific (i.e. lock-in vs making the most of a single provider's capabilities) etc. At the moment architecture sounds quite self-contained but in reality you'd want a generic way to tie the architecture to the wider strategy (or at least business context :))
The text was updated successfully, but these errors were encountered: