Separation of concerns, abstraction layers and API's Those 3 terms are closely related to each other. They are at the foundation of how current software is being written: by enabling software and system modularity. It allows different individuals, teams and organisations to work separately on common projects and systems in parallel. Those familiar with the premises outlined in the book , know that the ability of the Homo Sapiens to rally, in great number, around common abstractions and concepts is what made it so incredibly successful, and differentiated it from the other primates and species from the "homo" genus. Sapiens, a brief history of humankind An API(Application Interface), is such a common abstraction as mentioned here above. It is a convention, a concept agreed upon by independent parties on how to work and collaborate together around common abstractions . It is the between different software entities. Lingua franca Each party in this dialogue is viewed by the other side as a simplified abstraction. The intrinsic complexity of each part is hidden from the other. This is what is meant by abstraction layer. A good and well known example in the Unix world is "The "everything" is a file". The applications are pretending they are using and talking to files. No matter what complex hardware or concept is hidden behind it, they are all accessed with the simple and known, open, read, write, close API functions. Evolution of the underlying architectures The more the underlying architecture and concepts evolve underneath those API's/abstraction layers, the more inefficient, the more difficult it is to make full use of newer capabilities. It is as if you tried to describe the modern world with the same Latin used by the Romans 2000 years ago. You wouldn't be able to describe and express most of todays objects and concepts in a efficient and clear manner. Nowadays, it is very difficult to write high performance networked applications, with the simple read, write and socket abstractions. To do it, you need to be creative, find loopholes or bypass the abstraction all together. To fully exploit new features, new concepts and keep on relying of the benefits of separation of concerns, the API's and abstracted concepts need to evolve too. Modern cloud native applications Modern cloud native applications are often scalable and distributed systems based on a microservice architecture. The technology stack typically used to implement micro-services is something like this: An application or micro-service running in a container The container is abstracting/containerizing OS services The container runs on top of a virtual machine The virtual machine is running on top of a physical machine Those containers are also part of Kubernetes clusters The Kubernetes cluster is abstracting other OS resources They create overlay networks which work on top of real networks Lets say a micro-service wants to share some data stored in its container with one of its peer-services: Application/Micro Service wants to read data from storage The container pretends to offer storage access to the application On its turn it calls the container storage layer The container storage layer after doing some work of his calls the virtual machine storage layer On its turn it will call the physical machine/server layer storage layer which ultimately will access the physical storage device Once the application has the stored data in its memory, it will try to connect to its peer service. This process will use various layers of API's and indirection's to get to his destination. There is large overhead due to the various abstraction layers we have to go through to get the task done. Lots of lost CPU/$ because of it, lots of performance lost because of it. One of the reason for it, is that the API's were are using. the abstraction layers we are using have not evolved. There is no real reason to use a virtual machine anymore which abstracts a real physical machine. The concept of a server as we used to think off is actually not necessary anymore. We are trying to use yesterdays data-center architectures based on servers, OS and virtual machines to support today;s workloads and applications. As mentioned above, it is as, if you would use old Latin to describe today's world. It would be incredibly inefficient. Note, I am not pretending that today's micro-service based applications are better than old monolithic server based ones. It is just that developing new applications using old concepts holds you back, is complicated and expensive. It is time to rethink the data-center bottom up and re-juvinile the whole stack of abstraction layers and API's we are using. Previously published at https://computersandt.blogspot.com/2020/04/remaining-relevant-abstraction-layers.html

Abstraction Layers and API's for Cloud Native Environments

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

5 Web3 Trends That I'm Keeping an Eye on for the Rest of 2023

Associative Links Explained

Code simplicity: A language independent perspective

Does Golang Follow the Object Oriented Programming Paradigm?

Navigating Apache APISIX: A Strategic Approach to Plugin Priorities and Execution Phases

5 Web3 Trends That I'm Keeping an Eye on for the Rest of 2023

Associative Links Explained

Code simplicity: A language independent perspective

Does Golang Follow the Object Oriented Programming Paradigm?

Navigating Apache APISIX: A Strategic Approach to Plugin Priorities and Execution Phases

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps