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" 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?

Transcript

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
   

   View Slide

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
   

   View Slide

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)
   

   View Slide

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.
   

   View Slide

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
   

   View Slide

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.
   

   View Slide

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)
   

   View Slide

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
   

   View Slide

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 ?
   

   View Slide

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
    Speaker Deck
    

    View Slide

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
    

    View Slide