The document discusses a proposed lightweight multi-cloud domain-specific language (DSL) for defining elastic and transferable cloud-native applications. It begins by outlining the research context and motivation to avoid vendor lock-in and make applications portable across different cloud infrastructures. The presentation then describes requirements for a cloud programming language, including supporting containerized deployments, application scaling, lightweight definitions, multi-cloud operations, and infrastructure independence. It proposes a core DSL model and shows how it can be made platform agnostic. An evaluation demonstrates deploying an application to different clouds and runtime environments and transferring it between infrastructures. The DSL is found to fulfill the intended requirements within the limitations of its scope.
%+27788225528 love spells in Knoxville Psychic Readings, Attraction spells,Br...
Towards a Lightweight Multi-Cloud DSL for Elastic and Transferable Cloud-native Applications
1. Towards a Lightweight Multi-Cloud DSL
for Elastic and Transferable Cloud-native
Applications
Peter-Christian Quint, Nane Kratzke (Speaker)
8th International Conference on Cloud Computing and Services Science (CLOSER 2018); Madeira, Funchal, Portugal, 2018
2. The next 20 minutes are about ...
• Cloud applications and vendor lock-in
• Context of our research
• Different cloud orchestration approaches
• Cloud applications and resulting requirements
for a „Cloud Programming Language“
• Language proposal and evalution
• Conclusion and outlook
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
2
Presentation URL
Paper URL
3. Did you know … ?
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
3
2 2
2 4 6
7
7
7 7 11 11
1 1
2 4 7
10
14
21 26 42 44
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016
Relation of considered services
considered by CIMI, OCCI, CDMI, OVF, OCI, TOSCA not considered
80% of cloud services are not even
considered by cloud standards?
and it is getting worse
4. Our research focus …
Prof. Dr. rer. nat. Nane Kratzke
Praktische Informatik und betriebliche Informationssysteme
4
Operate application on current provider.
Scale cluster into prospective provider.
Shutdown nodes on current provider.
Cluster reschedules lost container.
Migration finished.
Quint, P.-C., & Kratzke, N. (2016). Overcome Vendor Lock-In by
Integrating Already Available Container Technologies - Towards
Transferability in Cloud Computing for SMEs. In Proceedings of CLOUD
COMPUTING 2016 (7th. International Conference on Cloud Computing,
GRIDS and Virtualization).
is to avoid vendor lock-in:
• Make use of elastic container
platforms to operate elastic
services being deployable to any
IaaS cloud infrastructure.
• Transfer of these services from one
private or public cloud infrastructure
to another at runtime.
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).
5. Research Methodology
Cloud TRANSIT
5
[KQ2017a] Kratzke, N., &
Quint, P.-C. (2017).
Understanding Cloud-native
Applications after 10 Years
of Cloud Computing - A
Systematic Mapping
Study. Journal of Systems
and Software, 126 (April).
[KP2016] Kratzke, N., &
Peinl, R. (2016). ClouNS - a
Cloud-Native Application
Reference Model for
Enterprise Architects.
In 2016 IEEE 20th
International Enterprise
Distributed Object
Computing Workshop
(EDOCW) (pp. 1–10).
[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).
This
presentations
focus
6. Cloud Application Maturity Level
limits the presented approach
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
6
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)
Montesi F., Guidi C., Zavattaro G. (2014) Service-Oriented
Programming with Jolie. In: Bouguettaya A., Sheng Q., Daniel
F. (eds) Web Services Foundations. Springer, New York, NY
8. 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
8
PRINCIPLES
Due to infrastructure-as-code even the Macro
Architecture can be made executable.
9. 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
10. Requirements
for a Cloud Programming Language
R1: Containerized Deployment
The DSL must be designed to describe and label a
containerized deployment of discoverable services.
R2: Application Scaling
The DSL must be designed to describe elastic services.
R3: Compendiously
The DSL must be designed to be lightweight and pragmatic.
R4: Multi-Cloud Support.
The DSL must be designed to support multi-cloud
operations.
R5: Infrastructure agnostic
The DSL must be designed to be independent from a specifc
ECP or cloud infrastructure.
R6: Elastic runtime environment
The DSL must be designed to define applications being able
to be operated on an elastic runtime environment.
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
10
11. Core Language Model
Requirements R1, R2, R3
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
11
12. Infrastructure and platform agnostic
Requirements R4, R5, R6
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
12
A model-to-model transformer
transforms a universal CNA
definition (UCAML) into a
specific ECP format (Kubernetes
manifests, Swarm compose
files, etc.).
• The runtime environment is
a user decision (other like
Jolie, platform agnostic).
• But the runtime specifics
must not be modeled on the
application level (other like
TOSCA, infrastructure
agnostic).
13. Example („Hello World“)
Elastic webservice for checking prime numbers
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
13
Ucaml::application('prime-service-app',
expose: [Ucaml::expose(from: 'prime-service', port: 8888, as: 'public')],
services: [
Ucaml::service('prime-service',
request: Ucaml::request(cpu: 100, memory: 256, ephemeral_storage: 2),
scale: Ucaml::scalingrule(min: 1, max: 10, cpu: 66),
ports: [8888],
container: Ucaml::container('prime-unit', 'transit/primesvc:latest',
cmd: 'ruby hw-service.rb',
ports: [80]
)
)
]
)
Meanwhile we switched from
Java to a more pragmatic
Ruby-based DSL.
R1 : Containerized
deployments
R1 : Discoverable
services
R2 : Scalable
services
R3 : Pragmatic
description
14. All together …
14
R1 : Containerized deployments
R2: Scalable Applications
R3: Compendiously and pragmatic
R4 : Multi-Cloud Support
R5: Infrastructure agnostic
R6: Elastic runtime environment
UCAML (this paper)
PLAIN
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)
15. Evaluation
E1 + E2
(Practicability)
To evaluate the usability [R3]
we described a Sock-Shop needing
[R1, R2]
deployed the Sock-Shop to Kubernetes,
and Docker Swarm [R6] in AWS, Azure,
GCE and OpenStack [R4]
E3
(Transferability)
For demonstrating IaaS
independence [R4]
we transfered the deployment at
runtime between IaaS
infrastructures of
Amazon Web Services, Microsoft
Azure, Google Compute Engine and
a OpenStack installation.
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
15
16. Evaluation
E1 + E2
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
16
See: https://microservices-demo.github.io/
„Sock Shop simulates an e-
commerce website that sells
socks. It is intended to aid the
demonstration and testing of
microservice and cloud native
technologies.“
17. Results of E3:
Transfers between AWS, GCE, Azure and OpenStack
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
17
Transfer of a 1+5 cluster (one master, five workers)
Only Kubernetes data presented
(Docker Swarm basically the same)
18. Conclusion
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
18
• For UCAML we rated DSL pragmatism and practitioner acceptance
higher than richness of DSL expressions.
• The DSL is intentionally designed for container and microservice
architectures but has limitations outside this scope.
• This limits DSL complexity but reduces possible use cases.
• The DSL supports currently the following container platforms:
• Kubernetes
• Docker Swarm
• And has been tested on the following IaaS infrastructes:
• AWS, GCE, Azure
• OpenStack
• Because it is infrastructure and platform agnostic further infrastructures
and platforms can be extended.
19. Acknowledgement
• Puzzle: Pixabay (CC0 Public Domain, PIRO4D)
• Definition: Pixabay (CC0 Public Domain, PDPics)
• Macro/Micro Architecture: isa-principles.org (CC-SA 3.0, innoQ GmbH)
• Checklist: Pixabay (CC0 Public Domain, Tumiso)
• Road Ahead: Pixabay (CC0 Public Domain, Nel_NZ)
• Air Transport: Pixabay (CC0 Public Domain, WikiImages)
• All cliparts: openclipart.com (CC0 Public Domain)
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
19
Picture Reference
Our research is funded by German Federal Ministry of Education
and Research (13FH021PX4).
Presentation URL
Paper URL
20. About
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
20
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
21. Backup Slides
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
21
22. So, what would a cloud programming
language be?
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
22
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 on the macro
architecture level 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.
23. Cloud-native Application Definition
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
23
[KQ2017a] Kratzke, N., & Quint, P.-C. (2017). Understanding Cloud-native Applications after 10 Years of
Cloud Computing - A Systematic Mapping Study. Journal of Systems and Software, 126 (April).
24. Cloud-native Application
What?
Be IDEAL
• Isolated State
• Distributed
• Elastic
• Automated
management
• Loosely coupled
Why?
There is a need for ..
• Speed (delivery)
• Safety (fault tolerance,
design for failure)
• Scalability
• Client diversity
How?
Integrate ...
• (Micro)service oriented
architectures (M)SOA
• Use API-based
collaboration
• Consider cloud-focused
pattern catalogues
• Use self-service agile
platforms
Prof. Dr. rer. nat. Nane Kratzke
Computer Science and Business Information Systems
24
C. Fehling, F. Leymann, R. Retter, W.
Schupeck, and P. Arbitter, Cloud
Computing Patterns: Fundamentals
to Design, Build, and Manage Cloud
Applications. Springer, 2014.
M. Stine, Migrating to Cloud-Native
Application Architectures. O’Reilly,
2015
A. Balalaie, A. Heydarnoori, and P.
Jamshidi, “Migrating to Cloud-Native
Architectures Using Microservices”,
CloudWay 2015, Taormina, Italy
S. Newman, Building Microservices.
O’Reilly, 2015.
Often heard by practitioners: „A cloud-native application is an
application intentionally designed for the cloud.“ True, but
helpful?