{"id":733,"date":"2017-08-07T14:19:17","date_gmt":"2017-08-07T14:19:17","guid":{"rendered":"http:\/\/ec2-34-242-84-40.eu-west-1.compute.amazonaws.com\/?p=733"},"modified":"2021-09-07T15:28:52","modified_gmt":"2021-09-07T15:28:52","slug":"osiforcloud","status":"publish","type":"post","link":"https:\/\/tomgeraghty.co.uk\/index.php\/osiforcloud\/","title":{"rendered":"The OSI model for the cloud"},"content":{"rendered":"

[Note: this is now what I call “archival content”. It’s out of date (originally posted in 2017) and I wouldn’t necessarily agree with the content now; particularly in respect to the advent of containerisation. Hopefully it’s still useful though.]<\/em><\/p>\n

While I was putting together a talk for an introduction to AWS, I was considering how to structure it and thought about the \u201clayers\u201d of cloud technology. I realised that the more time I spend talking about \u201ccloud\u201d technology and how to best exploit it, manage it, develop with it and build business operations using it, the more some of our traditional terminologies and models don\u2019t apply in the same way. <\/span><\/p>\n

Take the OSI model, for example:<\/span><\/p>\n

 <\/p>\n

\"\"<\/p>\n

When we\u2019re managing our own datacentres, servers, SANS, switches and firewalls, we need to understand this. We need to know what we\u2019re doing at each layer, who\u2019s responsible for physical connectivity, who manages layer three routing and control, and who has access to the upper layers. We use the terms \u201clayer 3\u201d to describe IP-based routing or \u201clayer 7\u201d to describe functions interacting at a software level, and crucially, we all know what each other means when we use these terms.<\/span><\/p>\n

With virtualisation, we began to abstract layers 3 and above (layer 2? Maybe?) into software defined networks, but we were still in control of the underlying layers, just a little less \u201cconcerned\u201d about them.<\/span><\/p>\n

Now, with cloud tech such as AWS and Azure, even this doesn\u2019t apply any longer. We have different layers of control and access, and it\u2019s not always helpful to try to use the OSI model terms. <\/span><\/p>\n

We pay AWS or Azure, or someone else, to manage the dull stuff – the cables, the internet connections, power, cooling, disks, redundancy, and physical security. Everything we see is abstract, virtual, and exists only as code. However, we still possess layers of control and management. We may create multiple AWS accounts to separate environments from each other, we\u2019ll create different VPCs for different applications, multiple subnets for different functions, and instances, services, storage units and more. Then we might hand off access to these to developers and testers, to deploy and test applications.<\/span><\/p>\n

The point is that it seems we don\u2019t yet have a common language, similar to the OSI model, for cloud architecture. Below is a first stab at what this might be. It\u2019s almost certainly wrong, and certainly can be improved.<\/span>
\n\"\"<\/p>\n

Let\u2019s start with <\/span>layer 1<\/b> – the physical infrastructure. This is entirely in the hands of the cloud provider such as AWS. Much of the time, we don\u2019t even know where this is, let alone have any visibility of what it looks like or how it works. This is analogous to layer 1 of the OSI model too, but more complex. It\u2019s the physical machines, cabling, cooling, power and utilities present in the various datacentres used by the cloud providers.<\/span><\/p>\n

Layer 2 <\/b>is the hypervisor. The software that allows the underlying hardware to be utilised – this is the abstraction between the true hardware and the virtualised \u201chardware\u201d that we see. AWS uses Xen, Azure uses a modified Hyper-V, and others use KVM. Again, we don\u2019t have access to this layer, but a GUI or CLI layered on top. For those of us who started our IT careers managing physical machines, then adopted virtualisation, we\u2019ll be familiar with how layer 2 allowed us to create and modify servers far quicker and easier than ever before.<\/span><\/p>\n

Layer 3<\/b> is where we get our hands dirty. The Software Defined Data Centre(SDDC). From here, we create our cloud accounts and start building stuff. This is accessed via a web GUI, command line tools, APIs or other platforms and integrations. This is essentially a management layer, not a workload layer, in that it allows us to govern our resources, control access, manage costs, security, scale, redundancy and availability. It is here that \u201cinfrastructure as code\u201d becomes a reality.<\/span><\/p>\n

Layer 4.<\/b> The Native Service (such as S3, Lambda, or RDS) or machine instance (such as EC2) layer. This is where we create actual workloads, store data, process information and make things happen. At this level, we could create an instance inside a VPC, set up the security groups and NACLs, and provide access to a developer or administrator via RDP, SSH, or other protocol. At this layer, humans that require access don\u2019t need Layer 3 (SDDC) access in order to do their job. In many ways, this is the actual IaaS (Infrastructure as a Service) layer.<\/span><\/p>\n

Layer 5.<\/b> I\u2019m not convinced this is all that different to layer 4, but it\u2019s useful to distinguish it for the purpose of defining *who* has access. This layer is analogous to layer 7 of the OSI, that is, it\u2019s end-user-facing, such as the front end of a web application, the interactions taking place on a mobile app, or the connectivity to IoT devices. Potentially, this is also analogous to SaaS (Software as a Service), if you consider it from the user\u2019s perspective. Layer 5 applications exist as a function of the full stack underneath it – the physical resources in datacentres, the hypervisor, the management layer, virtual machines and services, and the code that runs on or interacts with the services.<\/span><\/p>\n

Whether something like an OSI model for cloud becomes adopted or not, we\u2019re beginning to transition into a new realm of terminology, and the old definitions no longer apply.<\/span><\/p>\n

I hope you found this useful, and I\u2019d love to hear your feedback and improvements on this model. Take a look at ISO\/IEC 17788 if you\u2019d like to read more about cloud computing terms and definitions.<\/span><\/p>\n

Finally, if you\u2019d like me to speak and present at your event or your business, or provide consultation and advice, please get in touch.\u00a0<\/span><\/p>\n

Tom@tomgeraghty.co.uk<\/p>\n

@tomgeraghty<\/p>\n

https:\/\/www.linkedin.com\/in\/geraghtytom\/<\/p>\n","protected":false},"excerpt":{"rendered":"

[Note: this is now what I call “archival content”. It’s out of date (originally posted in 2017) and I wouldn’t necessarily agree with the content now; particularly in respect to the advent of containerisation. Hopefully it’s still useful though.] While I was putting together a talk for an introduction to AWS, I was considering how … <\/p>\n

Continue reading “The OSI model for the cloud”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1,4],"tags":[94,41,42,96,95,76],"class_list":["post-733","post","type-post","status-publish","format-standard","hentry","category-blog","category-tech","tag-cloud","tag-it","tag-it-management","tag-networking","tag-osi","tag-tech-2"],"_links":{"self":[{"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/posts\/733","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/comments?post=733"}],"version-history":[{"count":5,"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/posts\/733\/revisions"}],"predecessor-version":[{"id":1688,"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/posts\/733\/revisions\/1688"}],"wp:attachment":[{"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/media?parent=733"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/categories?post=733"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tomgeraghty.co.uk\/index.php\/wp-json\/wp\/v2\/tags?post=733"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}