We have the Bricks to Build Cloud-native Cathedrals - But do we have the mortar?
![Can we solve cloud orchestration problems
different?
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
7
TOSCA
[QK2018a] Quint, P.-C., & Kratzke, N. (2018). Towards a Lightweight Multi-Cloud DSL for Elastic and Transferable Cloud-native
Applications. In Proceedings of the 8th Int. Conf. on Cloud Computing and Services Science (CLOSER 2018, Madeira, Portugal).
UCAML
[Kra2017a] Kratzke, N. (2017). Smuggling Multi-Cloud Support into Cloud-native Applications using Elastic Container Platforms.
In Proceedings of the 7th Int. Conf. on Cloud Computing and Services Science (CLOSER 2017) (pp. 29–42).
PLAIN
Jolie
(1st language
for micro-
services)](https://image.slidesharecdn.com/cloud-panel-2018-180119073429/75/we-have-the-bricks-to-build-cloudnative-cathedrals-but-do-we-have-the-mortar-7-2048.jpg?cb=1668808959)
We have the Bricks to Build Cloud-native Cathedrals - But do we have the mortar?
This is some input for a panel discussion about "Challenges of Cloud Computing-based Systems" I attend at the 9th International Conference on Cloud Computing, GRIDs, and Virtualization (CLOUD COMPUTING 2018) in Barcelona, Spain in February 2018. Cloud-native applications (CNA) are build more and more often according to microservice and independent system architecture (ISA) approaches. ISA involves two architecture layers: the macro and the micro architecture layer. Software engineering outcomes on the micro layer are often distributed in a standardized form as self-contained deployment units (so called container images). There exist plenty of programming languages to implement these units: JAVA, C, C++, JavaScript, Python, R, PHP, Ruby, ... (this list is almost endless) But on the macro layer, one might mention TOSCA and little more. TOSCA is an OASIS deployment and orchestration standard language to describe a topology of cloud based web services, their components, relationships, and the processes that manage them. This works for static deployments. However, CNA are elastic, self-adaptive - almost the exact opposite of what can be defined efficiently using TOSCA. For these kind of scenarios one might mention Kubernetes or Docker Swarm as container orchestrators which are intentionally build to operate elastic services formed of containers. But these operating platforms do not provide expressive and pragmatic programming languages covering the macro layer of cloud-native applications. So it seems there is a gap and the question arises, whether we need further (and what kind of) macro layer languages for CNA?
Recommended
More Related Content
What's hot
What's hot(20)
Similar to We have the Bricks to Build Cloud-native Cathedrals - But do we have the mortar?
Similar to We have the Bricks to Build Cloud-native Cathedrals - But do we have the mortar?(20)
More from Nane Kratzke
More from Nane Kratzke(20)
Recently uploaded
Recently uploaded(20)
We have the Bricks to Build Cloud-native Cathedrals - But do we have the mortar?
- 1. We have the Bricks to Build Cloud- native Cathedrals But do we have the mortar? Nane Kratzke Panel Discussion: “Challenges in Cloud Computing-based Systems“ 9th International Conference on Cloud Computing, GRIDs, and Virtualization (CLOUD COMPUTING 2018); Barcelona, Spain, 2018
- 2. The Bricks of Cloud-native Systems • IaaS • PaaS • SaaS • FaaS + BaaS • DBaaS • CaaS • … • XaaS Prof. Dr. rer. nat. Nane Kratzke Computer Science and Business Information Systems 2
- 3. The Mortar of Cloud-native Systems Prof. Dr. rer. nat. Nane Kratzke Computer Science and Business Information Systems 3 Of course, not in your project! Kind of spaghetti code(but on a new level)
- 4. Independent Systems Architecture (ISA) That is how practitioners build cloud applications 1. Modules (and Interfaces) 2. Separate Processes (Container) 3. Macro / Micro Architecture 4. Integration (limited and standardized) 5. Communication (limited set of protocols) 6. Independent continuous delivery pipeline (per module) 7. Standardized operation (across all modules) 8. Standards: enforced via interfaces 9. Resilience (dependent service failures) Prof. Dr. rer. nat. Nane Kratzke Computer Science and Business Information Systems 4 PRINCIPLES Due to Infrastructure as Code even the Macro Architecture can be made executable.
- 5. Two Architecture Levels Decisions for all modules Only very few languages TOSCA, maybe Jolie Decisions for one module Thousands of languages (each module can use its own) MACRO Architecture MICRO Architecture
- 6. So, what would a cloud programming language be? Prof. Dr. rer. nat. Nane Kratzke Computer Science and Business Information Systems 6 A computer programming language is a notation used to write computer programs, which involves a computer performing some kind of computation or algorithm and possibly control of external devices such as printers, disk drives, and so on. Adapted from ACM SIGPLAN/Wikipedia A cloud programming language is a notation used to define cloud applications to be provided via cloud infrastructures or platforms performing processes and possibly composing further internal and external services such as authentication, scaling, storage, messaging, logging, and further domain/problem specific services.
- 7. Can we solve cloud orchestration problems different? Prof. Dr. rer. nat. Nane Kratzke Computer Science and Business Information Systems 7 TOSCA [QK2018a] Quint, P.-C., & Kratzke, N. (2018). Towards a Lightweight Multi-Cloud DSL for Elastic and Transferable Cloud-native Applications. In Proceedings of the 8th Int. Conf. on Cloud Computing and Services Science (CLOSER 2018, Madeira, Portugal). UCAML [Kra2017a] Kratzke, N. (2017). Smuggling Multi-Cloud Support into Cloud-native Applications using Elastic Container Platforms. In Proceedings of the 7th Int. Conf. on Cloud Computing and Services Science (CLOSER 2017) (pp. 29–42). PLAIN Jolie (1st language for micro- services)
- 8. Do we need really further languages? • Cloud applications are composed of distributed processes (deployment units) • that are operated elastically (horizontal scaling) • operated on different platforms and infrastructures • and each deployment unit maybe developed using different programming languages (polyglot). • The units are getting simpler (microservice style). • But complexity never disappears. It is just hidden/capsuled. • If the units are getting simpler, the integration should tend to get more complicated. Prof. Dr. rer. nat. Nane Kratzke Computer Science and Business Information Systems 8
- 9. What programming language is currently covering this kind of complex integration and orchestration as its primary purpose? Prof. Dr. rer. nat. Nane Kratzke Computer Science and Business Information Systems 9 • It took decades and plenty of languages to get only a handful of them for pragmatic application programming on single nodes. • Shall we really trust the most dominant one that established for cloud infrastructure deployments and multi-host environments? • Especially if we know, it has shortcomings regarding elasticity and runtime transferability? TOSCA?
- 10. Acknowledgement • Ruine: Pixabay (CC0 Public Domain) • Definition: Pixabay (CC0 Public Domain) • Power Suply: Pixabay (CC0 Public Domain) • Doors: Pixabay (CC0 Public Domain) • Air Transport: Pixabay (CC0 Public Domain, WikiImages) Prof. Dr. rer. nat. Nane Kratzke Computer Science and Business Information Systems 10 Picture Reference Our research is funded by German Federal Ministry of Education and Research (13FH021PX4). Presentation URL
- 11. About Prof. Dr. rer. nat. Nane Kratzke Computer Science and Business Information Systems 11 Nane Kratzke CoSA: http://cosa.fh-luebeck.de/en/contact/people/n-kratzke Blog: http://www.nkode.io Twitter: @NaneKratzke GooglePlus: +NaneKratzke LinkedIn: https://de.linkedin.com/in/nanekratzke GitHub: https://github.com/nkratzke ResearchGate: https://www.researchgate.net/profile/Nane_Kratzke SlideShare: http://de.slideshare.net/i21aneka