The document outlines a comprehensive overview of a Jamstack architecture for web development on Azure, focusing on the integration of various technologies and applications, including a Liferay portal for recipe sharing and a WordPress event booking system. It discusses the benefits of serverless architectures, the need for scalable and secure hosting solutions, and the use of APIs for dynamic functionality. Additionally, it highlights the challenges of technology lock-in and the importance of independence and exit strategies in content management systems.

1. JAMStack on Azure
Cloud ready architecture for web sites

2. Guess the stack

3. 10 pages of intranet information.
Campus overview, organisational
charts and most important
telephone numbers. Updated 2-3x
per year
Liferay Portal

4. Foodie-Facebook! 1000s of
members put recipes online, like
and share. They can put recipes
on their weekly food plan.
Coaches can comment and help
adjusting.
Wordpress

5. An event page, where people can
select seats and tickets to a
multitude of events in real-time.
They can reserve seats for friends
who can buy within a couple of
hours.
A Java enterprise application

6. An event page, where people can
select seats and tickets to a
multitude of events in real-time.
They can reserve seats for friends
who can buy within a couple of
hours.
A Java Enterprise application,
publishing 20 JSON files and 7 PHP scripts every other hour.
PHP app communicates synchronously with a payment
system via insecure HTTP

7. The tools of our trade

8. Front-End: Markup, CSS, JS
CMS: Data, structures, editors
Applikation: Process, state
Hosting: Availability, stability, security

9. Technology Lock-In

10. Front-End: Markup, CSS, JS
CMS: Data, structures, editors
Applikation: Process, state
Hosting: Availability, stability, security

11. Front-End

12. Templating languages

13. Static site generators

16. Hosting

20. Scaleable, blazingly fast, secure
Deploy it: Storage, Dropbox
It’s just HTML
Sources: Markdown, JSON, APIs
+

21. Some SSGs are more flexible than others
Not so good with binary data
Which increases as site grows bigger
Needs a build process
-

22. Front-End: Markup, CSS, JS
CMS: Daten, Strukturen, Editoren
Applikation: Prozesse, Zustände
Hosting: Availability, stability, security

23. Content

28. That’s nothing for non tech-savvy
users!

29. {
"story": {
"name": "home"
"path": "/"
"content": [
...
{
"component": "hero",
"headline": "This is the concept of Storyblok",
"subheadline": "It would also work for your idea",
"background_image": „../assets/images/your_logo_or_bg.png“
}
...
]
}
}
Hero
Headline
Subheadline
Background Image
Upload
This is the concept of Storyblok
is going to also works great for your
idea
…/assets/images/your_logo_or_bg.png
<h1> This is the concept
<h2> is going to also wor
<img src=“../assets/image

30. CMS status independent of site status
For regular size projects free/cheap plans
100% output independet
CMS, not Content Design System
+

31. What’s your content exit strategy
Big users pay big money
Almost no good open source alternatives
Git as a CMS -> Sounds good, doesn’t work
-

32. Front-End: Markup, CSS, JS
CMS: Data, structures, editors
Applikation: Prozesse, Zustände
Hosting: Availability, stability, security

33. Applications

34. Serverless

35. Serverless is not about having no
servers, it’s about not caring
about servers
“Functions as a Service”

37. Accept: application/json

38. Accept: text/html

41. 30%
70%
3rd Party + Microservices

42. Integration with 3rd party services is easy
Defined Input and Output
Manageable attack surface
Pay what you need
+

43. More interfaces, more contracts
What if we like state
What about platform independence
Serverless architectures are hard
-

44. Front-End: Markup, CSS, JS
CMS: Data, structures, editors
Applikation: Process state
Hosting: Availability, stability, security

45. JAMStack

46. J
A
M
avascript
PIs
arkup

47. J
A
M
avascript
PIs
arkup
Templated markup prebuilt at
deploy time. Using a static site
generator. Deployable anyhwere

48. J
A
M
avascript
PIs
arkup
Server side processes and DB
actions are abstracted into
reusable APIs over HTTPS and
JavaScript

49. J
A
M
avascript
PIs
arkup
Dynamic processes are done on
the client. Via JavaScript.
Deployed markup is extended
with functionality from APIs
client-side.

52. Sum it up

53. Full control of every part in your app
Incremental adoption
Resilient, failsafe, sustainable
Every piece is independent
+

54. Exit strategies!
This is 3rd party land!
Very platform specific
Lots of technologies: Fragmentation
-

55. @ddprrt
fettblog.eu · scriptconf.org · devone.at