1. 1.
2.
3.
4.
5.
6.
and the end
of microservices
Adaptive Architectures

2. Ala Shiban
klo.dev
@AlaShiban

3. RIOT
GAMES
200M+ Players Worldwide
Top 2 watched games
ESPORTS
$1.7B+ Revenue
1000+ Engineers
120+ Infra Org

4. 1. Why the end microservices
2. Adaptive Architectures
3. Infrastructure-from-Code (Universal Backends)
4. Demo
> talk.go

5. > why-the-end-microservices.ts
● What’s easier?
○ Separate responsibilities
across teams
○ Horizontally scale on smaller
boundaries
○ Limit fault blast radius
microservices

6. > why-the-end-microservices.ts
● What’s harder?
○ Managing deployments and
lifecycle of microservices
○ Allowing services to discover
one another and
communicate
○ Managing the infrastructure
for these services
microservices

7. > why-the-end-microservices.ts
● What’s harder?
○ Managing deployments and
lifecycle of microservices
○ Allowing services to discover
one another and
communicate
○ Managing the infrastructure
for these services
microservices

8. > why-the-end-microservices.ts
● What’s easier?
○ Excellent tooling
○ Feature dev focused
○ Simple horizontal scaling and
deployments
monoliths

9. > why-the-end-microservices.ts
● What’s harder?
○ Faster deployments
○ Fault isolation
○ Organizational boundaries
monoliths

10. > why-does-this-matter.docx
How does that promise go?

11. > what-problems-does-it-solve.cs
How does that promise go?
“Just focus on the ...”

12. > what-problems-does-it-solve.cs

13. > what-problems-does-it-solve.cs
* also pls learn istio, etcd, gRPC, cold boots, IAM, queues, terraform, docker, secret
stores, distributed tracing, auto-scaling rules. You have until Thursday.

14. > what-problems-does-it-solve.cs
1. Make our app aware of Lambda invoke
2. Create new IAC to provision the API
Gateway and wire it to the Lambda process
3. Setup new IAM policies and security
groups
4. Packaging our app in a docker container
5. Uploading it to ECR
6. Setting up a deploy pipeline to set up
the infrastructure and configure the Lambda
to use our container.
7. IAC to create a DynamoDB
8. Picking an SDK to interface with
DynamoDB
9. Rewriting our app to create schemas,
index, and make use of DynamoDB
10. Breaking our app into multiple repos or setting up
hooks for a monorepo
11. Creating dockerfiles for all 3 new services
12. Setting up discovery, configuration, and more for each
service
13. Rewriting all the IAC for the more complex topology
14. There are so many things you didn’t even notice I’m
here
15. IaC for SNS
16. Setting up topics and rewriting the application to use
them
17. Doing work to determine how wakeup with SNS would work
with Lambdas and testing it.
18. More IAM rules

15. > what-problems-does-it-solve.cs
1. Make our app aware of Lambda invoke
2. Create new IAC to provision the API
Gateway and wire it to the Lambda process
3. Setup new IAM policies and security
groups
4. Packaging our app in a docker container
5. Uploading it to ECR
6. Setting up a deploy pipeline to set up
the infrastructure and configure the Lambda
to use our container.
7. IAC to create a DynamoDB
8. Picking an SDK to interface with
DynamoDB
9. Rewriting our app to create schemas,
index, and make use of DynamoDB
10. Breaking our app into multiple repos or setting up
hooks for a monorepo
11. Creating dockerfiles for all 3 new services
12. Setting up discovery, configuration, and more for each
service
13. Rewriting all the IAC for the more complex topology
14. There are so many things you didn’t even notice I’m
here
15. IaC for SNS
16. Setting up topics and rewriting the application to use
them
17. Doing work to determine how wakeup with SNS would work
with Lambdas and testing it.
18. More IAM rules

16. > what-problems-does-it-solve.cs
19. Spin up VPCs
20. Configure subnets, security groups,
IAM permissions
21. Redo your CI/CD pipeline to target
your K8s cluster
22. Reorganize and rewrite your application to use the
EKS interface (REST) vs Lambda (Invoke)
23. Revisit inter-module communication Create Helm
charts, and other YAML specs for K8s
24. Spin up and configure an EKS cluster
What the company has left
Feature Dev
Capacity: 63%

17. ● What’s easy?
○ Separate responsibilities across teams
○ Excellent tooling
○ Testing and debugging, especially locally
○ Managing deployments and lifecycle of microservices
○ Horizontally scale on smaller boundaries
○ Flexible execution unit types (VMs, containers, wasm processes)
○ Allowing the services to discover one another and communicate
○ Option to be managed by cloud providers
○ Autonomous deploys (small change => smallest deploy)
○ Portability
● What shouldn’t be harder
○ Managing the infrastructure for these services
○ Loose coupling of components
○ One misbehaving component doesn’t break reliability for the whole system
> why-the-end-microservices.ts
Desired superset architecture

18. d
> adaptive-architectures.def
● Adaptive Topology
● Adaptive Technology
Adaptive
Architectures

19. > adaptive-architectures.def
● Adaptive Topology
● Adaptive Technology
Adaptive
Architectures

20. > approach-proposal.xaml
tool
optimize
(1)
(2)
(3)
plain code
+ something extra

21. Adaptive Architecture - What does it look like?
02
01 03

22. > names.txt
What’s in a name?

23. > comparison-with-iac.py3
Infrastructure
as code
//NOTE: you usually write this
Terraform
Pulumi
Cloudformation
CDK

24. > comparison-with-iac.py3
Infrastructure (representation)
as code (or yaml)
//NOTE: you usually write this
Terraform
Pulumi
Cloudformation
CDK

25. > example.tf

26. > example.tf

27. > infra-from-code-approach.py3
Infrastructure
from code

28. > infra-from-code-approach.py3
Infrastructure (Inferred)
from (Application) code
//TODO: Come up with a better name

29. > example.py

30. > example.py

31. > example.py

32. > example.py

33. > example.py

34. > aspiration.md
Universal backend code

35. > aspiration.md
> demo.exe
Demo Time

36. > demo.exe
> demo.exe
{
"url":
"https://klo.dev/images/adapt2.png",
"result":
"Intelligence is the ability
to adapt to change - Stephen Hawking
"
}
OCR

37. > demo.exe
> make
BUILD:

38. > demo.exe
> adapt
ADAPT:

39. > demo.exe
> basics
basics

40. > demo.exe
> data
persistence

41. > demo.exe
> microservices
separate services

42. > demo.exe
> async
event driven

43. > demo.exe
> adapt
K8s some of the things

44. klotho
ServiceWeaver
Go // Python // Typescript
C# // JavaScript // Java
Python
Go
Rust
> languages.txt
Wing

45. klotho
ServiceWeaver
SDK
Annotations
Language
Hybrid
> dev-interface.md

46. klotho
ServiceWeaver
Graph-Based
Least
Privilege
Not
Specified
> Permissions 🔒

47. klotho
ServiceWeaver
Terraform
Pulumi
None
> Infrastructure-as-Code Support

48. klotho
ServiceWeaver
Infra-as-Code
Based
None
> Low-level Configurability
Custom
Plugin
Based

49. klotho
Adaptive
Pre-Selected
> Tech Interchangeability
ServiceWeaver

50. 1. Complexity is inherent to
Microservices
2. Adaptive = Monoliths + Microservices
3. Infra-from-Code is here
> summary.end

51. > aspiration.md
> QnA.sh
Ask away

52. > aspiration.md
> exit(1)
Thank you!

53. > aspiration.md
> MORE_INFO.TXT
Appendix

54. klotho
ServiceWeaver
Serverless +
Kubernetes
Kubernetes
Only
> Compute Backing Tech
Serverless
Only

55. > LICENSE.TXT
klotho ServiceWeaver
Open
Source
Source
Available
Closed
Source

56. > approach-proposal.xaml
cloud version
application
code
+ something extra
tool

57. klotho
ServiceWeaver
Self Hosted
PaaS
Only
> Hosting Model
PaaS +
Self Hosted

58. klotho
Multi Cloud
(AWS+GCP+Azure)
Single Cloud
(AWS)
> Cloud Portability
Single Cloud
(GCP)
ServiceWeaver

59. Adaptive Architecture - What does it look like?
02
01 03