from programmer s point of view

Transcription

1 Cloud in practice from programmer s point of view Łukasz Nawojczyk LukeAhead.net contact@lukeahead.net

2 Secret Plan Clouds advantages and disadvantages Pricing Cloud Models (IaaS vs Paas) Internet Application Architecture Distributed Data Design Patterns Security

3 Cloud advantages Hardware abstraction (1) don t care about hardware failures upgrades maintanance

4 Cloud advantages Hardware abstraction (2) vertical scaling without stopping services (more CPU, RAM ) automatic traffic-dependent vertical scaling mini HUGE

5 Cloud advantages Snapshots backup state of your configuration and data clone to make next instance

6 Cloud advantages Horizontal scaling automatic clones of your program instances when there is a need for stops additional instances when not needed

7 Cloud advantages Load Balancing distributing workloads across multiple instances

8 Cloud advantages File/Blob Storage fast, distributed way to store files

9 Cloud advantages Monitoring monitoring tools and reports about health and costs

10 Cloud disadvantages Different cloud providers uses not (fully) compatible technologies Your applications and data are stored in 3rd party data center Cloud provider problems slows or stops your services

11 Cloud price? more costs per resource but no investment for hardware in advance pay only for resources in use so - less money to start

12 Cloud Model Infrastracture as a Service (IaaS) Full access to Operating System on your instance Ability to install any software and configure OS as you wish Requires manual administration (configure by yourself) Unlimited possibilities Amazon EC2, Azure Virtual Machines, OVH Public Cloud, Oktawave

13 Cloud Model Platform as a Service (PaaS) Preconfigured environment Dedicated technologies and tools Defined way to access data and files More automation Faster to start Limited possibilites Google AppEngine (Python/Java/PHP/Go), Azure Websites (.NET), Heroku (Ruby/Node.js/Java/Python)

14 Cloud Model Comparison IaaS (Infrastructure as a Service) Slow to configure Harder deployment More flexibility Easier to migrate PaaS (Platform as a Service) Fast to configure Easier deployment Less flexibility Harder to migrate use when: Freedom is important Mix of multiple technolgies First deployment time is critical You want to use single technology

15 Internet Application program database files user sessions

16 Program Layers FRONTEND API BACKEND Simplified model

17 Distributed Internet Application

18 Distributed Internet Application - Routing

19 Distributed Internet Application - Data

20 Distributed Internet Application - Files

21 Distributed Internet Application - Sessions WHAT ABOUT USER SESSIONS?

22 Distributed Internet Application - Sessions variant A CENTRAL SESSION STORAGE NON-STICKY SESSIONS

23 Distributed Internet Application - Sessions variant B Request IP or cookie Proxy/Load-Balancer decides STICKY SESSIONS

24 Distributed Data Part 1/3 Part 2/3 Part 3/3 DATA PARTITIONS

25 Distributed Data standard querying SEARCH Part 1/3 Part 2/3 Part 3/3 TOTAL TIME: SLOWEST REQUEST/RESPONSE + MERGING

26 Distributed Data routing map/table QUERY BY KEY Key Part A 3 B 1 C 2 D 2 Part 1/3 Part 2/3 Part 3/3 TOTAL TIME: MAPPING + PARTITION QUERY, NO MERGING

27 Distributed Data routing by date context ROUTING NEW PARTITION EVERY YEAR [DATE-start] modulo [parts] +1 QUERY BY DATE Part 1/3 Part 2/3 Part 3/ TOTAL TIME: SINGLE QUERY, NO MERGING

28 Distributed Data routing by entity ID ROUTING hash( [ID] ) modulo [parts] +1 PUT/GET ENTITY BY ID IDs: Part 1/3 Part 2/3 Part 3/3 1,4,7 2,5,8 3,6,9 TOTAL TIME: SINGLE QUERY, NO MERGING

29 Distributed Data routing by user context ROUTING hash( [USER] ) modulo [parts] +1 PUT/GET ENTITIES BY USER Part 1/3 Part 2/3 Part 3/3 A D A A D B E C C C B E TOTAL TIME: SINGLE QUERY, NO MERGING

30 Problem with users data distribution USERS ARE NOT EQUAL (in resource consumption)

31 Distributed Data routing by user context with dedicated resources for BIG USERS Key User X Dedicated Partition A Part 1/3 Part 2/3 Part 3/3 Dedicated A

32 Command-Query Separation (CQS) Command Set Query Get Could be SLOW (changes data) Should be FAST (read only access)

33 Command-Query CRUD Command Create Update Delete Query Read Search Could be SLOW (changes data) Should be FAST (read only access)

34 Command-Query Responsibility Segregation (CQRS) Command Create Update Delete Query Read Search WRITING SUBSYSTEM READING SUBSYSTEM JOURNAL QUEUE

35 Queue is your true friend WORKERS TASKS PRODUCER QUEUE Turn commands into enqueued tasks. Start more workers when needed. Stop when idle.

36 Security Your cloud appliaction is NOT automagically protected from attacks (except DDoS) Change Administrator/root password Setup Firewall Consider Private Network for backend

37 Golden Scalability Principle If it works with two, it probably will work with more. So, always start with at least two. instances numer, language translations, platorms

38 To summarize Cloud allows you to build BIG THINGS. FRONTEND BACKEND API FILES QUEUES SESSIONS MONITORING WORKERS DATA

39 This is it. Thank you! All images downloaded from OpenClipart.org Łukasz Nawojczyk LukeAhead.net