When you first embark on cloud, it often begins with a credit card transaction, a shadow IT department or as a proof-of-value with a given project before a more strategic commercial agreement.
Getting clarity on the details of what the cloud provider is responsible for and what you, as a customer, are responsible for can be easily overlooked but is integral to seeing success.
Shared responsibility in cloud is a security framework that states who has responsibility for which elements of security: The customer or the cloud provider.
Cloud providers will often depict the relationship as a high-level diagram (shown below with the AWS shared responsibility model), however, there is a lot more complexity and granularity of understanding needed to really manage the risk and overall cost appropriately.
Because each cloud service is often a piece of open-source software that the cloud vendor has wrapped, the level of complexity that’s contained within that software, to run and manage it, isn’t equal. The amount of customer-owned complexity will therefore depend on the service itself and how much the cloud vendor decided to take responsibility for.
To put this in perspective, one of the first AWS services, S3 (shared object storage), is much more SaaS (software as a service) in nature than something like Kubernetes, which is operating as a PaaS, (platform as a service) layer and IaaS (infrastructure as a service) layer. This fundamentally means that there is much less responsibility on the customer for S3 than Kubernetes.
So, the cloud vendor doesn't take responsibility for everything they offer ... but what does that mean for YOU?
There are a few important things to understand here:
Because there’s still ownership on you on a 'per-service' level, having skills inside of your business that understand how to configure and manage specific services is crucial.
Although the running aspect is removed, the creation and options you provide when you create them, become incredibly important to know. The majority of the breaches that are in the media are often with misconfigurations with the cloud service, which means that what the customer provided as configuration was at fault and not the cloud vendored service itself.
How many skills you will need in-house will depend on what services you consume and how SaaS / PaaS those service offerings are. That unfortunately is not only at a per-cloud-service level but also at a per-cloud level, so it needs to be assessed as you go along.
Some skills are more in demand than others, and the economic principle of supply-and-demand also applies here. The more in-demand the skills, the higher the cost will be on that skill. The more experience an individual has the more inflated the price will be, as experience counts for everything when it comes to critical services that your applications sit inside of.
Knowing which services you plan to adopt will be difficult because you don’t always know at the very beginning what you will or won’t end up using at an application level. You also don’t want to stop or slow-down innovation but you also don’t want to be left with hundreds of services being consumed in different ways across your organisation.
Having a lean process internally on proving out value per cloud service will help keep a tab on what is being used where, and the demand internally across the business. Policies can be enforced in all major cloud vendors across all of your team cloud accounts, projects or subscriptions, to limit what services can be used.
This is quite an upfront process, so it'll require some thought on what the best lean process will be for your organisation. Collaboration will be key however, within those teams, to understand what the use cases are and how deep the teams plan to go on that service and hence how much configuration overhead there is going to be internally.
If there's an opportunity to promote self-service across your teams, then this route is preferred. But it will depend on the internal capability and cloud maturity.
Cloud vendors are incentivised to make consumption incredibly easy, you can use as much as you want and need. This can be a double-edged sword as the value of cloud is the principle of it being easy to get, but it is often the part that causes the biggest cost pain.
Understanding how to monitor ‘how much you have’ v.s. ‘how much you need’ also requires a level of maturity within the team. Providing the right visibility on cost and consumption to a team and making it their responsibility, will help instill good behaviours early on.
Leaving this to when it matters is a difficult journey, as habits and behaviours are instilled inside of teams and responsibilities aren't understood. Trying to change responsibility and habits down the road will undoubtedly not be an easy feat!
This essentially boils down to the skills you have in-house.
As a lot of companies use tools over products, meaning the configuration ownership is higher and therefore making sure teams responsible for those configurations have a high understanding of security will be critical.
Software engineering best practices will be essential when going down the conventional tool and configuration approach:
Are all key aspects of managing clouds safely and appropriately.
One of the reasons organisations get started with cloud is the promising ability to reduce their total cost of ownership.
As the infrastructure management layer is now the responsibility of the cloud vendor, the amount of in-house skills, custom engineering and skills diversity is significantly reduced. However, as cloud-native is an ever-expanding landscape and there are significant tools and products out there, there is a risk that the TCO can increase beyond what it needs to.
How much TCO you need, will depend on the business type and the complexity of the business services you plan to provide. Complex distributed systems with high amounts of scale, will increase the amount of internal engineering needed to meet the demand and hence the amount of customisation in and around the cloud services.
If you’re not one of these businesses, then leaning on in the industry as a whole to offset operational costs will help increase the security footprint but also enable you to keep your teams lean and invest more financially in development over operational overheads.
